Руководитель отдела дизайна и дизайна интерфейсов Mail.Ru Group Юрий Ветров написал для издания UX Matters — колонка, в которой он рассказал о том, как перейти к платформенному мышлению в процессе создания интерфейсов.
В разделе «Интерфейсы» есть перевод заметки Ветрова.
В первой части серии статей по UX-стратегии.
( Первая часть , Вторая часть — ок.
ред.) Я описал ее общее видение и дизайнера, который нам нужен для систематической UX-разработки.
Каким должен быть результат его работы? Многие люди привыкли думать об артефактах, процессе их создания и утверждения.
Мы исследуем пользователей и рынок, продумываем сценарии и информационную архитектуру, делаем эскизы и прототипы, готовим дизайн-макеты и рекомендации и отдаем их в разработку.
И после всего этого мы смотрим на то, что произошло на практике, и вносим улучшения, пока не добьемся соответствия продукта рынку и необходимого уровня качества.
Подход в целом правильный, но в классических схемах с околоконвейерным процессом тратится много времени на артефакты.
Все это размывает фокус и ответственность — много усилий уходит на доработку сопутствующих документов, а не на сам продукт. А поскольку большинство этих талмудов нужны только для передачи знаний между членами продуктовой команды и быстро устаревают, мы получаем еще и высокие транзакционные издержки.
Это не пойдет. В этой статье я расскажу о том, как перестать думать документацией и перейти к платформенному мышлению.
Дизайнерам необходимо думать о своей работе не как о временном проекте по запуску нового дизайна или конкретной функциональности, а как о выводе на рынок и разработке полноценной платформы.
Тогда продукт будет планомерно расти, а UX-стратегия компании будет работать на всех уровнях — оперативном, тактическом и стратегическом.
Системный подход к UX продукта
Классическим решением для системной разработки продукта являются рекомендации и библиотеки шаблонов.В них описаны типичные интерфейсные решения, встречающиеся при работе над продуктовой линейкой.
А также правила их использования и другие полезные детали, которые помогают дизайнерам, менеджерам, разработчикам и тестировщикам добиться согласованности между экранами, продуктами и командами.
И, конечно же, снизить стоимость и ускорить разработку за счет использования готовых решений.
Они имеют решающее значение для крупных компаний, но одинаково полезны для средних и малых организаций с устоявшимися продуктами.
А для пользователей последовательность и осведомленность повышают комфорт. Но рекомендации в обычном понимании — это еще один статический артефакт, требующий выполнения дополнительного шага в процессе решения.
Рождается цепочка «гайдлайн → верстка → верстка → реализация», на каждом этапе которой теряются детали и генерируются ошибки.
Это дает ряд проблем:
- Дизайнеры часто говорят, что разработчики не читают документацию.
Но, честно говоря, они и сами возятся, если нужно синхронизировать несколько человек.
- Проектирование по спецификации сложно реализовать на 100%, если оно делается сразу для нескольких продуктов.
Во-первых, сама спецификация требует регулярного обновления — появляются новые шаблоны или находят лучшие решения уже существующих.
Во-вторых, при редизайне что-то может не быть реализовано вовремя и сервис будет запущен «почти доведенным до ума».
И вся продуктовая линейка «почти похожа».
А что тогда считается эталонным дизайном? Рефакторинг, конечно, можно сделать, но он оказывается дорогостоящим — его нужно делать постоянно для каждого продукта.
- Все это требует от проектировщика огромных усилий и много времени на контроль качества реализации.
Что дорого и утомительно.
Не говоря уже о рутине регулярного рисования одних и тех же вещей.
- Обновления дизайна усугубляют проблему.
Нам нужно пройти всю линию заново – переделывать и контролировать, переделывать и контролировать.
- Экспериментировать с дизайном тоже недешево.
Они также вызывают появление побочных артефактов и, как следствие, увеличивают энтропию.
Но те, кто мыслят системно, пытаются найти решение на стыке дизайна и технологий.
Только переведя референсный дизайн из статической документации на уровень реализации, можно сократить цепочку до «гайдлайн = дизайн = макет → реализация».
Это значит избавиться от кучи геморроя, связанного с внедрением, улучшением и поддержкой продуктов.
Конструктивно-технологическая унификация
Многие крупные компании уже движутся в этом направлении, что существенно упрощает им жизнь и дает свободу действий в развитии бизнеса.Хороший дизайн можно и нужно сделать дешево и быстро, чего невозможно добиться при работе руками.
Каким может быть это техническое решение? Есть два варианта: более простой, когда вы делаете свой маленький Bootstrap, и более сложный, создавая полноценную систему компонентов.
Первый вариант дешевле и быстрее создавать — вы уже получаете выгоду от более простой поддержки, недорогих экспериментов с дизайном и простого прототипирования.
Хотя, по сути, вы просто используете набор стилей HTML/CSS, которые могут сломаться при использовании в реальном продукте.
За последние несколько лет на эту тему было опубликовано множество дальновидных статей – например, из Марк Отто И Дэйв Руперт , и огромное количество компаний уже работает по этому принципу.
Второй вариант дороже в создании, но в итоге вы получаете гарантированное качество реализации дизайна и все преимущества простоты обновления продуктов.
Мы в Mail.Ru Group пошли именно в этом направлении.
Этот подход имеет пять уровней зрелости:
- Общие принципы дизайна определены и встроены в CSS.
- Все продукты работают на основе общих компонентов.
- Существуют действующие руководства, описывающие принципы проектирования и общие компоненты.
Они показывают реализацию, а не скриншоты.
- Вы можете создавать прототипы страниц на основе действующих рекомендаций.
- Эксперименты с дизайном компонентов для сравнения различных подходов.
Лего и, конечно же, Polymer Project от Google, который реализует Material Design. 
ЭКосистема Intuit Harmony Что хорошего в этом подходе?
- Единый визуальный стиль и принципы работы интерфейса, а также его информационная архитектура.
Это удобно для пользователя – группа схожих товаров работает одинаково понятно и привычно.
Для бренда это тоже хорошо – вся линейка услуг выглядит целостно.
- Унификация дизайна на 90% гарантируется подходом к разработке — все готовые блоки и элементы берутся из единой кодовой базы и только из нее.
Еще 10% приходится на внимательность и продуманность при использовании готовых решений.
Даже из идеального конструктора можно собрать монстра.
- Упрощение запуска новых продуктов и редизайн существующих.
Фреймворк содержит большинство необходимых блоков и компонентов на все случаи жизни, что позволяет быстро собрать новый интерфейс.
- Контролировать большой пул проектов становится проще, если они организованы одинаково.
Вместо сотен отдельных проектов вы следуете нескольким рекомендациям.
- Вам нужно рисовать меньше макетов.
Страницу можно собрать из готовых блоков, а в дальнейшем – вообще не запуская Фотошоп.
То же самое касается и различных спецпроектов.
- Совокупный эффект успешных продуктовых решений.
Например, увеличив глубину просмотра на одном из сервисов, эти улучшения легко применить и к остальным.
- Переход от крупных редизайнов каждые несколько лет к постоянному поддержанию актуальности интерфейса.
Перезапуски отнимают много усилий и теряют тысячи мелких наработок, которые были приложены к дизайну за длительный период его разработки.
Конечно, гнаться за трендами – не самая похвальная идея.
Однако в нашей отрасли периодически происходят довольно резкие переломы визуальной парадигмы, как это произошло в прошлом году с выходом iOS7, и компаниям приходится оперативно на них реагировать.
В целом, это ключевая часть нашей UX-стратегии.
Но самое главное, что фреймворк стал еще и технической унификацией.
Мы взяли много подходов к «снаряду» — написали спецификации, собрали единый исходный код, сделали библиотеки элементов и т. д. Но всё это быстро сошло на нет, потому что находилось в уютном мирке дизайна и было мало востребовано разработчиками.
.
И все мы знаем, как часто дизайн искажается на пути от макета к реализации.
Но если вы один раз сделаете код корректным и распространяемым, вы будете уверены в качестве дизайна, который работает в реальном продукте.
Поэтому одним из главных критериев успеха любых унификационных проектов является их перевод на уровень конкретной реализации.
Билл Скотт сказал о своем опыте перехода с Netflix на PayPal в аналогичном ключе.
В PayPal из-за технологических ограничений на изменение простого текстового блока на главной странице ушло полтора месяца.
Это замедляет развитие дизайна и делает невозможным частое экспериментирование.
Когда он работал в Netflix, одной из его первых задач было облегчить процесс разработки.
Результатом является надежная среда HTML5, которая работает на всем спектре поддерживаемых устройств.
Мы хотим использовать не руки, а голову дизайнера.
Благодаря сокращению рутины можно сместить фокус на проблемы продукта и бизнес-решения, а также на менее заметные, но тоже важные проблемы дизайна.
Компания также в плюсе.
За вычетом входной цены на перенос продуктов на платформу он получает системный подход к повышению эффективности продуктов, более быстрое время вывода на рынок новых функций и гарантированную унификацию дизайна.
Умение говорить на одном языке помогло нам убедить руководство инвестировать в эту структуру.
Как создать свою собственную платформу
Нам нужно перестать думать категориями экранов и воспринимать продукт как платформу.Опыт Apple, Google и Microsoft будет полезен, даже если ваша компания не такая большая и амбициозная — они преуспели в построении платформ и экосистем.
Если разбить их на основные составляющие — общие принципы визуального стиля и взаимодействия, набор собственных приложений и огромное количество приложений от сторонних разработчиков (считайте, что они созданы партнерами и аутсорсерами), — то можно найти очень много характерно для работы любой продуктовой компании.
Андроид, iOS, Windows Phone Объединение может начаться с двух сторон.
Сначала создайте руководство, а затем примените его к существующим продуктам.
Или успешно обновите дизайн одного из них и выберите его в качестве эталона, а затем создайте на его основе руководство.
У обоих подходов есть плюсы и минусы.
Мы в компании ходил второй способ.
Проверенная конструкция, оптимизированная с помощью аналитики и исследований пользователей, масштабируется.
Ведь накануне и сразу после релиза проводится множество экспериментов и тестов, после которых конструкция многократно корректируется.
Хоть путь и оказывается несколько извилистым, поэтому сейчас рефакторим результат и строим систему сверху вниз.
Мэтт МакМанус говорит Этот непрерывный дизайн имеет два основных принципа.
Во-первых, откажитесь от концепции «окончательного» дизайна.
Дизайнеры должны участвовать во всем процессе разработки, а не только в его начале.
Во-вторых, дизайнеры должны создавать многократно используемый интерфейсный код или интерактивные прототипы вместо статической документации, такой как PSD. Можно, конечно, делать и продукты, и инструкции одновременно, но на практике это занимает огромное количество времени из-за постоянных итераций: «предложили типовое решение → опробовали на продуктах → нашли пару несоответствий → обсуждали и решали проблемы всей командой → снова опробовали их на продуктах.
» А учитывая, что таких решений на проектах сотни, релиз никогда не состоится.
Исходя из накопленного опыта, я вижу несколько этапов развития платформы:
1. Общие принципы
В начале работ по унификации необходимо определиться с фундаментом, на котором будет построена вся платформа.Они облегчают принятие проектных решений на всех уровнях и делают его разработку системной.
Отличный пример - язык дизайн IBM. Манифест или общие принципы дизайна Это набор из дюжины правил, которые помогают связать имидж бренда с конкретными решениями.
Так сказать высокоуровневый чек-лист для проверки паттернов интерфейса.
Например, один из принципов нашего международного бренда Мой.
com — сочетание минималистичного белого фона всех рабочих поверхностей интерфейса с точечными акцентами фирменного красного цвета, что позволяет лучше подчеркнуть индивидуальность.
В то же время еще одно качество бренда – эмоциональность и индивидуальность.
Чтобы поддержать его и не нарушить первое правило, используются насыщенные фоновые подложки, а основная рабочая область лежит на белой полупрозрачной подложке.
Принципы могут охватывать самые разные вещи, которые вы считаете важными для бренда.
Например, Майлчимп делает особый акцент на тон голоса - текста в интерфейсе.
Microsoft в дизайне метро настаивает фокусируясь на контенте, а не на хроме, а также подчеркивает особую роль анимации.
И это приводит к единому последовательному опыту.
Важно, что манифест не существует сам по себе, а привязан к общей стратегии компании.
В случае с принципами дизайна – в основном через брендинг.
Только тогда они заработают в полную силу, а не станут очередной новомодной игрушкой-методом для дизайнеров.
Ими будут делиться менеджеры и другие сотрудники компании, они действительно помогут в принятии решений.
Число принципов должно быть разумным, чтобы их можно было запомнить и между ними не было дублирования.
В качестве гида вы можете пройтись по коллекции Принципы проектирования FTW .
Принципы проектирования FTW Визуальный язык Конкретные принципы, лежащие в основе визуального представления, логики взаимодействия и информационной архитектуры.
Если манифест говорит на уровне ценностей, то основы дизайна говорят о конкретных решениях.
Чтобы упростить дальнейшую жизнь платформы, нужно стремиться к высокому уровню абстракции во всех определениях.
Информационная архитектура .
Исходя из специфики продукта и его целевой аудитории, нам необходимо описать принципы разделения функций и вариантов использования на экраны, построить их иерархию и обеспечить навигацию между ними.
Если мы говорим о продуктовых линейках, они могут существенно различаться и потребуют разных подходов.
Поэтому полезно описывать все сразу — одностраничную структуру, иерархическую структуру, линейную структуру, сетевую структуру, хаб или комбинацию нескольких.
У каждого подхода должен быть своеобразный мини-манифест — для каких задач он используется, как перенести на него функционал и варианты использования продукта.
А еще лучше, если со всеми нюансами — названия категорий и ссылок, описание метаданных, организационные схемы (алфавит, география, хронология, тема, задача, аудитория, популярность).
Принципы взаимодействия .
Конкретные навигационные решения, реализующие принципы информационной архитектуры – постоянное (включая нижний колонтитул) и контекстное меню (видимые по щелчку правой кнопкой мыши или длительному нажатию пальца), поиск, хлебные крошки, инструменты для работы со списками (сортировка, фильтрация, группировка, навигация по страницам или загрузка), связывание контекстного контента, системы уведомлений и оповещений.
Желательно с их иллюстрированным представлением на модели типового экрана, а также рекомендациями по решению конкретных проблем продукта — например, ссылки на контент помогают увеличить глубину просмотра.
Все это должно быть основано на поддерживаемых типах устройств — большие и мобильные сети, приложения для разных платформ (мобильные, планшеты, носимые устройства).
Каждый из них может иметь свои особенности — конкретные способы управления (мышь, касание, голос), быстрые действия (горячие клавиши, жесты), обеспечение доступности.
Интерфейсная сетка .
На этом этапе упорядочиваются все элементы интерфейса — их размеры и расстояние между ними.
Сейчас наиболее популярен 8-пиксельный; он используется Android и Google в целом.
iOS основана на 11-пикселях, Windows 8 — на 5-пикселях.
Шаг в 8 пикселей особенно удобен тем, что он хорошо делится на 2 — например, можно получить 2-пиксельное округление блоков.
Базовый шаг определяет возможные расстояния.
В нашем решении мы основываемся на 4dp вместо 8, поэтому в нашем случае это 4, 8, 16, 24, 32, 48, 96, 128. Невозможно передать всю степень удобства работы - количество споров.
а ошибки по мелочам падают на порядок.
Дизайнер выбирает размеры не на глаз, а по единым правилам.
Правда, полезно измерять в пикселях, не зависящих от плотности экрана (dp), а не в пикселях.
Структурная сетка .
Он определяет набор столбцов, в которых разбит основной макет интерфейса.
Сетка из 12 столбцов очень популярна и используется большинством популярных фреймворков.
Хотя мы используем скорее «ритмичный» механизм — набор 40-пиксельных столбцов с 20-пиксельными отступами.
Такой подход позволил унифицировать разные поколения дизайна (16 колонок для 1024, 20 для 1280, 24 для 1440, 26 для 1600).
Структурная сетка также определяет логику адаптивности — то, как макет меняется при разных разрешениях.
Макеты и контейнеры .
Специфика на основе структурной сетки — как будут размещены рабочие области интерфейса.
1 рубрика популярна на промо-сайтах? 2 колонки, классический подход практически для любой задачи? 3 колонки, которые используются все реже из-за перегруженности? Бесконечный поток карточек или плиток, популяризированный Pinterest? В макете также можно указать вертикальные связи, хотя это встречается нечасто.
Каждый столбец макета представляет собой стек, в котором друг за другом размещаются контейнеры конкретных блоков с контентом.
Полезно задавать логику внешнего вида (граница, фон, тень, заголовок и т.д.) и поведения контента на уровне самого контейнера.
Это облегчит разработку платформы за счет добавления новых блоков или корректировки общих принципов.
Например, если в блоке элементов больше, чем можно отобразить на экране, мы можем добавить ссылку на полный список на отдельной странице, сразу развернуть их, нажав «показать больше», разбить их навигацией по страницам.
или прокрутите внутрь (по вертикали или по горизонтали).
Если мы выбрали горизонтальную прокрутку и в будущем хотим изменить дизайн стрелок или добавить свайп для сенсорных экранов, нам не придется просматривать все копии контейнера.
Сюда также следует включить всплывающие окна.
4 уровня сетки Сетка шрифтов .
Существует множество подходов к выбору размеров шрифта, основанных на идее масштабирования основного текста.
Услуга Гридловер Кажется, я собрал все, что можно.
Если ориентироваться на сетку интерфейса, то они должны быть кратны 4. Для заголовков это легко, хотя на практике возникают проблемы с версткой.
Во-первых, красивая цифра 16 для основного текста может оказаться слишком большой для конкретного интерфейсного решения.
Во-вторых, особенности отрисовки веб-шрифтов в Windows заставляют прибегать к множеству костылей и обходных путей.
А вот если межстрочный интервал вписывается в сетку интерфейса, все не так плохо — и интерфейс, и наборный текст его не нарушат. 
Гридсет Цветовая палитра .
Основу, которую задают основные цвета бренда, необходимо сопровождать вспомогательными значениями.
Во-первых, это цвета интерфейса — белый и черный (или их оттенки, если чистые значения не подходят), цвета ошибок и других системных сообщений (красный, зеленый, желтый), ссылок, а также линия серого цвета (фон, границы, вспомогательный текст).
Во-вторых, акцентные — например, для обозначения категорий контента.
Более того, для них можно указать логику изменения, если нужны вариации (например, подсвечиваются недоступные категории).
Все цвета в палитре должны дополнять основные, указанные брендом.
Помимо цветов полезно описать формулы построения теней, задать несколько стандартных параметров прозрачности и размытия фона.
Набор элементов управления.
Имея интерфейс и шрифтовую сетку, а также цветовую палитру, вы сможете системно подойти к работе над основными элементами здания.
Кнопки (основные, обычные, с дополнительными опциями; текст, значок, версия для панелей инструментов), ссылки, общие и специализированные поля ввода и выпадающие списки (комбо-поле, календарь, страна с кодом набора и т. д.), переключатели (флажок, переключатель, тумблер), загрузчики пользовательского контента (фото, видео, файлы).
Для них должны быть установлены состояния: фокус, активный, зависший, недоступный.
Помимо элементов формы необходимо описать их расположение.
Расположение названий полей, поясняющие тексты к ним, правила проверки значений и отображения ошибок.
Графика и иллюстрации .
Стандарты необходимы для фотографий и другой графики контента.
Пропорции, типичные размеры и их вариации для разных разрешений.
В идеале они должны вписываться в сетку столбцов.
То же самое касается и аватаров.
Иконки интерфейса должны быть правильно привязаны к общему брендингу — постепенно вы можете разработать из них универсальный набор.
Иллюстрации также должны вписываться в общую канву, но здесь достаточно описать общие подходы к стилю.
Толщина линии, цветовая палитра, принципы передачи объема, правила размещения в интерфейсе и рекламных материалах.
Крупные иконки-иллюстрации можно взять за основу метафоры иконок интерфейса, разработав их более детально, а для среднего размера задать стандартизированную сетку.
Инфографика и визуализации .
Таблицы, общие диаграммы (круговые, гистограммы, столбцы, линии, разброс) и менее распространенные (площадь, пончик, радар, разброс, Венн, Сэнки), картография, тепловые диаграммы, облако тегов, графики и деревья, плоское дерево, интеллектуальные карты, блок-схемы и диаграммы процессов, сроки, интеллект-карты.
Весь этот список нужен только для узкоспециализированных сервисов, но наиболее популярные из них необходимо описать.
Анимационная модель .
В идеале переходы между состояниями и экранами интерфейса должны следовать определенному шаблону.
Тогда анимация в продукте будет единообразной, и пользователю будет проще с ней работать.
Например, всплывающие окна могут приходить вверху экрана и возвращаться после закрытия, а если это пошаговый помощник, то после появления главного окна новые состояния могут приходить справа.
Например, вы можете изучить подходы трех крупных платформ — Android (тонкая оркестровка), iOS (до iOS7 и после), Windows Phone (основатель современного подхода).
Реклама .
Рекламная сетка часто определяет внешний вид, устанавливая границы дизайнерской сетки.
Важно работать с коммерческим отделом не менее тесно, чем с разработчиками — это позволит найти форматы, не портящие ни дизайн, ни денежный поток проекта.
Необходимо определить рекламный инвентарь — типы и размеры медиа- и контекстных блоков, принципы брендирования блоков и страниц, установить стандарты верстки полноэкранных режимов и другие агрессивные подходы.
Также полезно проработать типовые решения по внутреннему продвижению.
Второй шаг — это, по сути, сетка, на которой размещается реклама на стандартных макетах.
Визуальный язык IBM Принципы в коде После того как вы определили принципы проектирования платформы, вам также необходимо встроить их в CSS. Дизайнерам чрезвычайно важно это понять, чтобы вместе с разработчиками построить систему, ориентированную на будущее.
Именно об этом я писал в вторая часть эта серия — окончательный дизайн в том или ином виде определяется на всех этапах разработки продукта и об этом важно не забывать, если вы хотите работать системно.
Современные препроцессоры CSS, такие как SASS и Less, позволяют устанавливать глобальные переменные, и это отличный способ определить фундаментальные принципы в вашем коде.
А иконочные шрифты и SVG-спрайты помогут удобно работать со вспомогательной графикой.
Благодаря высокому уровню абстракции общих принципов мы получаем мощную интерфейсную математику, исключающую саму возможность несоответствий.
Например, чтобы получить кнопку, мы пишем «Сохранить» базовым размером шрифта, измеряем стандартные отступы сверху, снизу и по бокам, заполняем это пространство стандартным цветом для фона кнопки, а также обводим обводку стандартным цветом и поместите стандартную тень внизу.
И пока константы не изменятся, эта математика будет приводить всю команду к одним и тем же решениям, даже если дизайнеры мало общаются друг с другом.
А если все это еще и зашито в код, то можно легко обновлять константы, меняя всю линейку продуктов.
Нирвана и Валгалла одновременно! Полезно привести пример структуры типовых страниц на основе макетов.
Они включают в себя верхний и нижний колонтитулы, область контента и вспомогательные столбцы.
Это помогает лучше понять основы использования руководств.
2. Библиотека выкроек и готовых решений.
Следующий шаг в построении платформы — создание готовых компонентов и перенос на них всей конструкции.
Исходя из нашей цели упростить производственную цепочку «гайдлайн = дизайн = верстка → реализация», компонент представляет собой готовый код с определенным визуальным стилем, логикой работы и взаимодействия с ним пользователя.
Он должен быть независимым от окружающей среды — мы можем использовать его на любой странице, не опасаясь, что он сломается.
По сути, это классический паттерн проектирования, который дизайнеры обычно собирают в виде библиотек для проектирования и инструментов проектирования, а затем описывают в гайдлайнах.
Только нам не нужно каждый раз проверять качество его реализации и поддерживать по всей цепочке артефактов.
И если мы решим изменить шаблон, нам нужно заменить оригинал в единой кодовой базе, после чего он будет обновляться на всех проектах, использующих фреймворк.
Крайне важно придерживаться семантики при описании компонентов.
Что касается основных принципов, в шаблоне не используется конкретное значение «размер шрифта 24» или «цвет фона #F0F0F0», а значение «заголовок 2-го уровня» или «фон для карточек».
Так в смысле общего назначения — основной контент, информация по теме, дополнительные привязки.
Тогда сама идея легких обновлений всей линейки продуктов действительно сработает. Примеры компонентов:
- Навигация - вкладки, алфавитный указатель, календарь, поиск и фильтры, сортировка, история просмотров.
- Списки — список, матрица, прокручиваемая лента, асинхронная компоновка плиток.
- Медиа – видео, инфографика, фотогалерея, пост из соцсети.
- Информеры - погода, цены на акции и товары, спортивная статистика, расписания, гороскопы, мировое время.
- Социальное взаимодействие - комментарии, опросы, консультации, рейтинги, отзывы, обмен в социальных сетях.
Список новостей, конкретная публикация, результаты поиска, настройки, профиль пользователя, авторизация и регистрация, «нулевые» состояния, ошибки сервера и т.д. Сюда же относятся шаблоны для рассылки писем.
Все, что вы начнете использовать хотя бы дважды, полезно преобразовать в стандартные решения.
Хотя необходимо учитывать, что такой шаблон должен быть гибким в плане используемых данных — реальные страницы могут иметь разные блоки контекста.
Некоторые читатели правильно заметят, что если мы будем запускать все продукты на одних и тех же компонентах, то помимо унификации мы получим еще и унификацию — все сервисы будут выглядеть одинаково.
Поэтому платформа должна обеспечивать возможность стилизации продуктов без изменения общих принципов работы компонентов.
Например, в нашей компании мы выбрали идею акцентных цветов – каждая услуга имеет свой цвет, что позволяет выделить ее из общей линии.
Мы также подумали о том, какие шрифты, декоративные элементы, иллюстрации и значки могут подойти.
3. Живые рекомендации
Руководство должно стать, по сути, еще одним проектом на базе платформы.Сначала мы опишем общие принципы, которые мы извлекаем из базового CSS. После этого идут готовые компоненты, которые уже используются в рабочих продуктах.
К каждому из них дизайнер должен дать описание – почему и в каких ситуациях он используется.
Даже если вы строите упрощенную систему в духе Bootstrap, первый шаг уже очень поможет в систематизации работы.
Решения, описанные в этом руководстве, актуальны на 100%.
А контроль качества всей линейки продукции кардинально упрощается – дизайнер следит только за эталонным образцом.
Более того, можно пойти еще дальше и настроить систему «автовосстановления».
Раз в неделю или месяц скрипт перебирает все товары и сравнивает параметры, используемые в их CSS, с эталонными.
При обнаружении несоответствий проектировщик получает список проблемных мест.
4. Прототипирование
Как только все компоненты платформы будут запущены и заработают, вы сможете еще больше упростить рабочий процесс — отказаться от инструментов для создания статических каркасов и макетов.Если в живой инструкции рядом с примером компонента отображается его HTML-код, то в HTML-редакторе легко собрать готовый макет страницы на основе стандартных шаблонов макета.
А для уже выложенных страниц еще проще вносить улучшения «на лету».
Многие дизайнеры больше не боятся кода, а другим пора оставить свои страхи позади.
Сейчас существует множество понятных туториалов и готовых примеров, а сами HTML и CSS до безобразия просты.
Это не значит, что вам нужно отказаться от Photoshop или Sketch — такие инструменты прекрасно подходят для поиска стилистических направлений.
Но без перехода к дизайну в браузере работать становится все сложнее.
Если у компании достаточно ресурсов и платформа создана, вы можете создать онлайн-инструмент для визуального прототипирования.
Получается, грубо говоря, Axure в Интернете — дизайнер или менеджер перетаскивает на страницу готовые компоненты и получает интерактивный прототип.
Лучшим примером в этом отношении является Полимерный проект от Google, что позволяет создавать дизайны на основе
-
Лечение Синдрома Двойного Щелчка
19 Oct, 24 -
Убунту 10.04 Альфа 3
19 Oct, 24 -
Живые Сказки На Базе Adobe Edge
19 Oct, 24 -
Интернет Через Смс
19 Oct, 24
