Каждая вторая статья про современные подходы к веб-дизайну содержит в себе аксиому о необходимости прототипирования. Однако признайтесь, часто ли вы делаете зарисовки карандашом на бумаге к каждому проекту? Действительно ли причина только в вашей лени?

Просто не всем клиентам и, соответственно, не всем проектам это нужно. Да, многие маркомы или digital-менеджеры с технарским бэкграундом приветствуют такую схему, так как она вносит системность в работу и в конечном итоге экономит время. Но в России пока большинство тех, кто «эти ваши квадратики» вообще не понимает. И в итоге, вы просто зря тратите время и чужие нервы.

Также обратите внимание, что прототипирование часто повышает расходы на проект для заказчика, это дополнительная итерация, дополнительные человеко-часы.

И наконец, про саму схему. Как и всякая модель, она имеет ценность только, если решает вашу проблему. Помните об этом. На моей практике сроки и обратная связь от клиента нередко ломают красивую последовательность этой модели.

Напоследок вопрос ко всем участникам обсуждения. Кто в вашем агентстве занимается прототипированием? Есть ли у вас выделенные проектировщики, архитекторы? Или это делает project manager или дизайнер? Такая статистика хорошо отразит жизнеспособность этой модели на нашем рынке в настоящий момент.

Относительно внутренней кухни компании AGIMA: Ни один сайт мы не делаем без прототипа, поэтому адаптивный сайт не исключение. Просто прототипы создаются под еще несколько базовых разрешений.

Начинается процесс, с брифования, анализа задачи и опыта конкурентов. То, что Viljami Salminen обозначил как этап подготовки, безусловно, есть важнейший этап работы и ошибки, допущенные в самом начале грозят, перерасти в гигантский ком проблем на последующих этапах.

Второй шаг — создание дизайн-концепции. От ее формы зависит, как будет представлен контент. Делать сайт сразу с реальным контентом — идея хорошая, но совершенно утопическая. На практике, увы, практически никогда этого сделать не удается, поэтому мы даем требования к контенту, которые закладываются на этапе проектирования и уже под эти требования собираем контент. Переписываем, а чаще, пишем тексты и обрабатываем изображения, проводим фото-сессии. Тексты для адаптивных сайтов мы разбиваем на элементы, выстраивая внутреннюю иерархию и формируя микроструктуру для дальнейшего переплетения контента. Эту кропотливую работу могу проделывать только подготовленные специалисты хорошо знакомые со спецификой адаптивного веба, поэтому данный этап мы всегда делаем сами, на основе предоставленных материалов.

Что важно, на протяжении всего цикла работ мы много общаемся с клиентом, обсуждаем детали. Показываем, как будут выглядеть основные страницы и, конечно же, тестируем проект, выявляя баги и неточности. Если процесс выстроен правильно, то и «Финальному Откровению» места не остается.

Относительно последнего пункта: «Повтор цикла. Эскиз -> Прототип -> Дизайн -> Тест -> Обсуждение. До тех пор, пока не заработает». Это кошмар разработчика и показатель его полной не компетентности. На этапе прототипа и эскиза мы обычно имеем полное представление о том, как будет работать сайт и переделка с нуля после теста — нонсенс. 

Многие идеи в статье перекликаются с методологией SCRUM, однако в России очень мало кейсов применения этого подхода к чему-либо, кроме создания программного обеспечения. Крупные российские веб-студии только начинают применять идеи итеративной разработки, это сложно, так как такое внедрение требует существенной модернизации «цеха», перераспределения ролей внутри рабочих групп и пересмотра договорной базы. Также необходимо учитывать специфику практического использования этих методов в реальной проектной работе.

Мы используем итеративный подход к комплексной разработке с лета 2011 года, и отмечу, что такой подход применим не в каждом проекте и не с каждым клиентом. Все зависит от целей, задач и общей степени вовлеченности заказчика в проект. Также адаптивный дизайн сам по себе не решает многих проблем, возникающих при работе над интерактивными и информационными проектами: к примеру, в случае отсутствия адекватного контента и сервисов он становится бесполезным. Поэтому автор статьи делает правильные выводы о важности настоящего контента уже на самых ранних этапах проектирования, поскольку зачастую и заказчики, и подрядчики не уделяют должного внимания структуре и объему контента, что порождает существенные риски на этапе внедрения.

В статье также правильно сделан акцент на том, что при таком подходе крайне важно тестировать рабочие промежуточные версии сайта/приложения на различных устройствах и итерационно демонстрировать результаты. Это лучше традиционного «водопадного» подхода, когда в ходе работ над проектом раздельно обсуждаются автономные артефакты (прототипы, дизайн, контент), но финальный вид страниц с реальным контентом формируется только в самом конце пути. Как правило, в этот момент вносить изменения в макеты или менять логику представления информации уже сложно и дорого.

Важность контента, который будет размещаться на сайте, уже не раз обсуждалась и первобытный метод забивки «рыбой» уже не раз показал свою несостоятельность, а в условиях адаптивного отображения контента внимание этому этапу стоит уделять теперь ещё больше.

Прототип будущей функциональной модели, а в последующем законченного сайта при использовании CMS Drupal полностью снимает риск овертайма по проекту и значительно экономит время клиента и людей, которые работают над проектом. Так же это позволяет полным образом обойти «затыки», которые могут появиться из-за ошибочного проектирования структуры сайта. Гибкость такой разработки заключается в том, что процессы можно запускать параллельно, что значительно ускоряет процесс разработки и тестирования сайта в условиях огромного количества платформ и устройств, под которое затачивается сайт. Что нам стоит на одной базе данных иметь любое количество сайтов с разными шаблонами, которые подготавливаются конкретно под определённое разрешение и платформу, а после тестирования всё объединить и радоваться быстрому достижению цели, работа над которой до финала доступна со всеми изменениями для нашего клиента.

Для работы с CMS Drupal мы используем Ægir, который позволяет нам быстро разворачивать новые копии разрабатываемого сайта для проверки работы функционала, а так же внедрения новых фишек. Это очень радует наших клиентов, так как есть возможность, не прерывая процесс основной разработки, иметь возможность экспериментировать и искать решение, которое максимально приближает к цели, которая стоит перед нами и клиентом.

За статью и в отдельности за ссылку http://beta.typecastapp.com/ огромное спасибо, всегда очень приятно писать комментарии к статьям, которые расширяют кругозор.

Действительно, если разрабатываемый сайт должен быть адаптивным, это вносит изменения в технологический процесс, стандартная схема «прототип-дизайн-верстка-интеграция» не работает. Но статья меня заинтересовала больше другим: описанный процесс вполне применим и целесообразен по разработке «традиционных», не адаптивных сайтов. Большинство веб-разработчиков воспринимают традиционный процесс разработки сайтов как само собой разумеющееся. Думаю, что стоит как минимум попробовать использовать подобный подход на реальных проектах.

Спасибо автору за перевод статьи. Процесс, который указывает автор «Эскиз -> Прототип -> Дизайн -> Тест -> Обсуждение (до тех пор, пока не заработает)», применим не только для разработки мобильных сайтов и приложений, но и в целом для разработки программных продуктов.

Из-за большого количества различных мобильных устройств (разные спецификации, размер и разрешение экрана) требуется проверять правильность отображения мобильного сайта и приложения на большом количестве устройств. Из-за ограниченности размера экрана при разработке дизайна для мобильных устройств с самого начала необходимо работать с реальным контентом клиента, чтобы сделать правильные акценты в донесении информации до пользователя.

При разработке мобильного сайта и приложения дизайнер и программист должны работать вместе на всём этапе работы над проектом, чтобы оперативно корректировать результаты под особенности некоторых устройств.

Хочется обратить внимание, что нужно не забывать ограничивать количество итераций при разработке интерфейса для получения финальной версии проекта, чтобы процесс разработки укладывался в заранее намеченные сроки.