Глава 4: Атомарная разработка (часть 4)
← Предыдущая часть | Следующая глава →
Перед вами перевод книги Atomic Design Брэда Фроста, разработчика интерфейсов, поклонника мобильного интернета и создателя методики «Атомарный дизайн».
Если вы здесь впервые, то лучше начните сначала.
Закатаем рукава!
Теперь, когда мы определились с общим направлением дизайна, можно приступать к разработке интерфейса и системы дизайна, лежащей в его основе. Итак, давайте попробуем превратить расплывчатое «направление» в стройную, функциональную, удобную и исчерпывающую систему.
# От идеи к ее реализации
Превращение сырых наработок в готовые паттерны — весьма абстрактный и еще не отлаженный до конца процесс. Коль скоро вы дочитали до этой главы, вас это не должно удивлять.
При работе над проектом для TechCrunch Дэн Молл взял за основу первоначальные идеи команды о том, как должен выглядеть хедер сайта. Было логично начать именно с хедера, поскольку это один из самых запоминающихся брендированных компонентов страницы. Немного поработав, мы позвонили клиенту, чтобы обсудить варианты.
Несмотря на то, что этот макет — всего лишь сырые наброски, мы смогли провести важные переговоры с клиентом об эстетике, иерархии и будущей функциональности хедера. Поскольку хедер был представлен без окружающего контекста, внимание клиента было полностью сосредоточено на нем, и мы обсуждали вопросы, относящиеся к только к этому элементу.
И хотя клиент был не в курсе, я тем временем поработал над созданием рабочей HTML-версии хедера в Pattern Lab.
С помощью этого черно-белого прототипа мы продемонстрировали интерактивность и адаптивность элемента, что стало поводом более глубокого обсуждения. В итоге мы получили предложения по изменению макета и функциональности хедера, и я внес эти правки прямо во время звонка. Внезапно вся команда и наш клиент стали активными участниками процесса создания дизайна!
Благодаря общему вкладу всех участников мы переработали макет, информационную архитектуру, эстетические детали и функциональность и пришли к решению, на котором в конечном итоге остановились.
Понятно, что хедер не существует в вакууме. Этот компонент был включен в каждый шаблон с использованием Pattern Lab и паттерна Mustache, который мы обсуждали в третьей главе.
{{> organisms-header }}Таким образом мы увидели хедер в контексте других элементов страниц (использовавшихся ранее). Как результат — мы сфокусировались на разработке одного конкретного паттерна, но при этом учли контекст, в котором он будет использоваться.
Как правило, на первых порах дизайн в браузере выглядит в лучшем случае сырым, и это нормально. Цель этапа состоит в том, чтобы проработать основную информационную архитектуру, определить связанные паттерны и начать их общую разметку. Проделав эту работу, вы сможете приступить к дальнейшей проработке конкретных паттернов и отточить структуру.
Тем, кто привык к традиционным, выверенным до пикселя макетам, частично проработанные прототипы могут показаться непривычными. Но гораздо важнее двигаться к результату, нежели наслаждаться ложным ощущением совершенства, поэтому небольшие регулярные обновления лучше масштабного релиза.
# Роль статичных макетов в пост-PSD эру
До этого раздела мы говорили о выборе общего визуального направления и поработали с некоторыми паттернами для практических экспериментов с применением выбранного стиля. Благодаря такому относительно низко-детализированному подходу вы и ваша команда свободно исследуете варианты, проходите через итерации и быстрее получаете обратную связь.
Вместе с тем, никогда не забуду комментарий клиента о самом первом атомарном проекте, над которым я работал: «Эти коллажи элементов выглядят великолепно. Однако, оценить такую работу — все равно что оценить красоту лица, видя один только нос».
Если вы дошли до этого момента в своем процессе разработки, — поздравляю! Получение обратной связи (даже такой) означает, что клиент жаждет большего. И теперь, когда вы определились с визуальным направлением, можете смело использовать результаты наработок в контексте. Вероятно, это повлечет за собой создание детализированных статичных макетов.
Если вы были свидетелем обсуждений на тему «проектирование в браузере», то, наверняка, слышали, будто макеты в Photoshop — полный отстой. Разумеется, это не так. На протяжении всей книги мы не раз обсуждали то, почему важно расщеплять крупные компоненты на атомы и одновременно создавать единое целое. Так вот: статичные макеты эффективны, когда нужно показать полную картину того, как будет выглядеть пользовательский интерфейс. Смысл в том, чтобы понимать когда именно нужны такие макеты и сколько времени нужно уделять работе со статичной проектной документацией.
Для проекта TechCrunch мы создали статичный макет шаблона статьи только после того, как клиент одобрил коллаж элементов. Создание детализированных макетов требует больших усилий, так что сперва мы определились с направлением, чтобы снизить риск напрасной работы, если вдруг ошибемся.
Статичные макеты, как и любой другой инструмент, используются для облегчения переговоров с клиентом. Если клиент говорит: «Это неправильно», то мы возвращаемся к компьютеру и создаем новый макет.
Но если мы слышим: «Можно ли мы переместить это отсюда сюда? Можно ли добавить серую рамку вокруг текста статьи? Можно ли увеличить размер изображения?» — это хороший знак. Он говорит о том, что общее направление выбрано верно, а эти относительно небольшие правки можно внести прямо в браузере.
# Браузерные итерации
Статичные макеты полезно использовать для выработки общей визуальной концепции, но в конечном итоге пользователи будут видеть сайт и взаимодействовать с ним в браузере. Вот почему важно поскорее перенести вашу работу в «естественную среду обитания» и дотачивать ее там.
Благодаря работе в браузере вы решите задачи по компоновке в разных разрешениях, оформите подачу динамических данных (различное количество символов, размер изображений и т.п.), наглядно представите взаимодействие и анимацию, оцените производительность, эргономику и технические моменты (такие как плотность пикселей, рендеринг текста, осуществление прокрутки и работу в разных браузерах).
Статичными макетами этих задач не решить, поэтому к ним следует относиться лишь как к гипотезам, а не истине в последней инстанции. Любая гипотеза подтверждается или опровергается только после проверки в браузере.
Давайте вместо фразы «проектирование в браузере» говорить «принятие решений в браузере». ~Дэн Молл
После того, как вы перенесли проект в браузер, дальнейшая разработка должна вестись именно там. На этом этапе ведущую роль играют фронтенд-разработчики. Они должны создать паттерны, привести их в нужный вид и подключить везде, где они нужны. Графические дизайнеры могут помогать: видя шероховатости в браузере и адаптивной версии, они могут создавать небольшие статичные макеты и сглаживать недочеты, обусловленные адаптивностью, на уровне организма. Такое переключение между традиционными и веб-инструментами задает здоровый итерационный цикл между дизайном и разработкой, где фронтенд-код становится все более надежным и стабильным с каждой итерацией.
Замечательная особенность работы, построенной на паттернах, заключается в том, что по мере того, как каждый паттерн становится совершеннее, любой паттерн поменьше, который входит в его состав, будет также улучшаться. Это значит, что вам придется прикладывать все меньше усилий к созданию новых паттернов по мере развития проекта. А в конечном итоге для создания нового паттерна нужно будет лишь совместить уже существующие.
Последний рывок
Система дизайна обретает форму, и команда делает все возможное, чтобы довести проект до финала. На этом этапе паттерны UI проработаны, нужны лишь несколько финальных штрихов, чтобы отполировать все до блеска и подготовиться к релизу.
UX-дизайнеры трудятся над прототипом, чтобы убедиться в его логичности и интуитивности. Графические дизайнеры причесывают интерфейс и предлагают идеи по улучшению UI-дизайна. Фронтенд-разработчики тестируют работу в различных браузерах и на различных устройствах, а также дают обратную связь по дизайну. Бэкенд-разработчики заняты интеграцией фронтенд-интерфейса с CMS (подробнее об этом в главе 5). И, конечно же, клиенты и заказчики вносят финальные правки-«предложения» по дизайну и контенту. Вся команда вносит свой вклад в руководство по стилю, наводит порядок в библиотеке паттернов и прилагает все усилия, чтобы сайт «взлетел».
Затем, будто в мгновение ока, сайт запущен. Хлопают пробки от шампанского, все друг друга поздравляют и (куда же без них) вылазят какие-то новые баги. Пользователи попадают на ваш новенький сайт, видят красивый, функциональный, последовательный дизайн, и, несомненно, приходят в полный восторг. Миссия выполнена.
То, что в начале казалось глыбой из мрамора, благодаря невероятным усилиям, сотрудничеству, постоянному общению и множеству итераций превратилось в изящную скульптуру. Кроме того, в дополнение к сайту команда создала гибкую, продуманную систему пользовательского интерфейса, бережно собранную в руководстве по стилю.
В этой главе мы рассмотрели все, что касается создания эффективной системы дизайна интерфейса. В следующей главе мы обсудим, как обеспечить успех системы дизайна в долгосрочной перспективе.
Над переводом работают Ольга Кокоулина и Ринат Шайхутдинов.
Если вам понравился перевод, дайте нам знать — нажмите кнопку Clap в левой части экрана.
Видеокурсы и практика по дизайну интерактивных систем: ux/ui, веб-дизайн и бренд-дизайн
Вас ждет плотная проектная практика по анимации интерфейсов, дизайну сайтов, а также мобильных и веб-приложений. Под руководством наставников в стиле «смотри и повторяй»!
Breezzly — это среда для тренировки digital-навыков. Здесь вы встретите комплекты видеокурсов в актуальных инструментах интерактивного дизайна, среди них Figma, Principle и Invision Studio. А каждый проект — это живой кейс с историей, собранной по горячим следам!
