Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UXPeople 2015: Юрий Ветров — Платформенное мышление

166,604 views

Published on

Презентация Юрия Ветрова "Платформенное мышление. Как перестать плодить документацию и начать жить" с конференции UX People 2015.

Published in: Design
  • Хорошая презентация! О нашем последнем разговоре, когда я услышал, что он превратился 10 в 10 000 через 2 месяца, я не мог поверить, что это возможно. Я думал, что это может быть ошибка, но Слово на улице - то, что это реально. Если да, то мы можем оказаться в настоящем удовольствии! Я останусь на деле И позвольте вам узнать больше, как только я поговорю с разработчиками, так или иначе, я поеду за ним, так как у них есть 60-дневная гарантия возврата денег, поэтому, если вы не будете молчать, как сказал Джордан, я попрошу вернуть деньги. Между тем, просмотрите видео, которое я рассказал вам о прошлой неделе: http://bit.ly/secretvideopage
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

UXPeople 2015: Юрий Ветров — Платформенное мышление

  1. 1. ПЛАТФОРМЕННОЕ МЫШЛЕНИЕ Как перестать плодить документацию и начать жить ЮРИЙ ВЕТРОВ MAIL.RU GROUP
  2. 2. ПРОДУКТОВЫЙ ДИЗАЙНЕР ФРЕЙМВОРК UX-СТРАТЕГИИ ПЛАТФОРМЕННОЕ МЫШЛЕНИЕ КАК ВНЕДРЯТЬ НА ПРАКТИКЕ АНАЛИТИКА И ИССЛЕДОВАНИЯ ОТ ДИЗАЙН-КОМАНДЫ К ДИЗАЙН-КУЛЬТУРЕ
  3. 3. DOCUMENT-DRIVEN DESIGN Многие привыкли думать вокруг артефактов и процесса их создания и согласования. Мы исследуем пользователей и рынок, продумываем сценарии и инфоархитектуру, делаем скетчи и прототипы, готовим дизайн-макеты и гайдлайны, отдаем их в разработку. А после всего этого смотрим что получилось на практике и вносим доработки до тех пор, пока не достигнем соответствия продукта рынку и нужного уровня качества.
  4. 4. R.I.P. ВОТ ЭТО ВОТ ВСЁ В околоконвейерном процессе подход сжигает уйму времени на артефакты. Это размывает фокус и ответственность – силы уходят на полировку побочных документов, а не продукта. Большая часть этих талмудов нужна только для передачи знаний внутри команды и быстро устаревает – получаем ещё и высокие транзакционные издержки. Так не годится.
  5. 5. ЭПОХА ШРЕДЕРА Нужно воспринимать работу не как временный проект по запуску нового дизайна или конкретной функциональности, а как вывод на рынок и развитие целостной платформы. Тогда продукт будет расти системно, а UX-стратегия компании заработает на всех уровнях – оперативном, тактическом и стратегическом.
  6. 6. 3 УРОВНЯ ЗРЕЛОСТИ UX ХАОС ОПЕРАТИВНЫЙ ТАКТИЧЕСКИЙ СТРАТЕГИЧЕСКИЙ
  7. 7. СИСТЕМАТИЗАЦИЯ ДИЗАЙНА
  8. 8. ГАЙДЛАЙНЫ РЕШАЮТ? Классическое решение для системного развития продуктов – гайдлайны и библиотеки паттернов. Но это ещё один статический артефакт. Рождается цепочка: «гайдлайн → макет → верстка → реализация», на каждом из этапов которой теряются детали и генерируются баги.
  9. 9. 1. ДОКУМЕНТАЦИЮ НЕ ЧИТАЮТ Дизайнеры часто говорят, что документацию не читают разработчики. Но и сами они, честно говоря, тоже филонят, если синхронизироваться должны несколько человек.
  10. 10. 2. ГАЙДЛАЙН ДЛЯ ЛИНЕЙКИ ПРОДУКТОВ? ХА! На практике дизайн по спецификации сложно реализовать на 100%, если это делается сразу для нескольких продуктов.
  11. 11. Во-первых, спецификация сама по себе требует регулярного обновления – появляются новые паттерны, находятся более удачные решения для уже имеющихся. Во-вторых, по ходу редизайна успевают реализовать не всё и сервис запускается «почти отполированным». А вся линейка продуктов – «почти похожей». И что тогда считать референсным дизайном? Конечно, можно провести рефакторинг. Но он оказывается дорогим – его нужно проводить постоянно для каждого из продуктов, при каждом более-менее заметном обновлении.
  12. 12. 3. КОНТРОЛЬ КАЧЕСТВА ДОРОГ И УТОМИТЕЛЕН Всё это требует огромных усилий и уймы времени от дизайнера на контроль качества реализации.
  13. 13. 4. ОБНОВЛЕНИЯ ДИЗАЙНА УСИЛИВАЮТ ПРОБЛЕМУ Нужно снова идти по всей линейке – переделывать и контролировать, переделывать и контролировать…
  14. 14. 5. ЭКСПЕРИМЕНТЫ НЕДЕШЕВЫ Они также заставляют генерировать побочные артефакты и в результате усиливают энтропию.
  15. 15. СПИСОК ПРОБЛЕМ ДЛИННЫЙ И мы ещё не говорим о «нюансах» вроде адаптивного дизайна... Многие просто нанимают больше дизайнеров.
  16. 16. АДОК! БЕЗ ТЕХНИЧЕСКОГО РЕШЕНИЯ НЕ ОБОЙТИСЬ Те, кто мыслит системно, пытаются найти решение на стыке дизайна и технологий. Только так можно сократить цепочку до «спецификация = дизайн = верстка → реализация». А значит избавиться от кучи геморроя по внедрению, улучшению и поддержке продуктов.
  17. 17. У НАС УЖЕ ДВОЙНЯ В этой идеологии мы перезапустили уже две группы продуктов – мобильный веб и контент-проекты. Я расскажу о процессе работы над такой платформой.
  18. 18. ДИЗАЙНЕРСКО- ТЕХНОЛОГИЧЕСКАЯ УНИФИКАЦИЯ
  19. 19. ДВА ПУТИ В эту сторону уже идут многие крупные компании, что сильно упрощает им жизнь и развязывает руки в развитии бизнеса. Хороший дизайн можно и нужно получать дёшево и быстро, а этого невозможно добиться при работе руками. Каким может быть это техническое решение?
  20. 20. А. СВОЙ МАЛЕНЬКИЙ BOOTSTRAP Дешевле и быстрее в создании – вы уже получаете профит от облегчения поддержки, недорогих экспериментов с дизайном и легкого прототипирования. Хотя, по сути, вы просто используете набор HTML/CSS-стилей, который может поломаться при использовании в реальном продукте.
  21. 21. КУЧА КОМПАНИЙ УЖЕ ТУТ В районе 2012-2013 года многие компании не сговариваясь пришли к этой идее. Мы начали тогда же.
  22. 22. BUILD YOUR OWN BOOTSTRAP Тогда же вышла серия визионерских статей от Anna Debenham, Brad Frost, Mark Otto и Dave Rupert. И понеслась!
  23. 23. Б. КОМПОНЕНТНАЯ СИСТЕМА Она дороже в создании, зато на выходе у вас гарантированное качество реализации дизайна и все бенефиты от простоты обновления продуктов.
  24. 24. ПОПАЛИ В ВОЛНУ Мы в Mail.Ru Group пошли именно в эту сторону. Все началось в середине 2012 с простой идеи и эксперимента.
  25. 25. У такого подхода 5 уровней зрелости: 1. Определены и зашиты в CSS общие принципы дизайна. 2. Все продукты работают на основе единых компонентов. 3. Есть живые гайдлайны. Они показывают реализацию, а не скриншоты. 4. Можно прототипировать страницы на основе живых гайдлайнов. 5. Эксперименты с дизайном компонентов для сравнения различных подходов.
  26. 26. INTUIT HARMONY (2014) По пути готовых компонентов идет не так много компаний. Но есть мощные примеры. Экосистема Harmony от Intuit.
  27. 27. LONELY PLANET (2014) Решение на базе собственного фреймворка Rizzo.
  28. 28. POLYMER PROJECT (2014) Платформа от Google, реализующая material design.
  29. 29. ЯНДЕКС.ЛЕГО Основанный на идеологии и технологиях БЭМ конструктор.
  30. 30. 1. ЕДИНЫЙ ВИЗУАЛЬНЫЙ СТИЛЬ, ПРИНЦИПЫ РАБОТЫ ИНТЕРФЕЙСА, ИНФОРМАЦИОННАЯ АРХИТЕКТУРА Это удобно для пользователя – группа схожих продуктов работает одинаково понятно и привычно. И хорошо для бренда – вся линейка сервисов выглядит целостной. {
  31. 31. 2. ГАРАНТИЯ 100% 90% Унификация гарантируется подходом к разработке – все готовые блоки и элементы берутся из единой базы кода и только из нее. Ещё на 10% – внимательностью и вдумчивостью при использовании готовых решений.
  32. 32. 3. ПРОЩЕ РЕДИЗАЙНЫ И ЗАПУСК НОВЫХ ПРОДУКТОВ В фреймворке есть большинство необходимых блоков и компонентов на все случаи жизни, что позволяет быстро собрать новый интерфейс.
  33. 33. 4. ПРОЩЕ КОНТРОЛИРОВАТЬ БОЛЬШОЙ ПУЛ ПРОЕКТОВ Когда они устроены одинаково. Вместо сотни отдельных проектов вы следите за парой гайдлайнов.
  34. 34. 5. МЕНЬШЕ ЛИШНЕЙ РАБОТЫ Нужно рисовать меньше макетов – прощай, рутина! Страницу можно собрать из готовых блоков, причём в будущем – совсем без запуска Фотошопа.
  35. 35. 6. МАСШТАБИРОВАНИЕ УЛУЧШЕНИЙ От улучшения в одном конкретном продукте выигрывают и остальные. Например, если блок новостей по теме повысил глубину просмотров на Авто, это решение очень быстро попадет и в другие сервисы.
  36. 36. 7. ПОСТОЯННАЯ АКТУАЛЬНОСТЬ Уход от героических редизайнов раз в несколько лет к регулярной гигиене дизайна. Перезапуски отнимают много сил и теряют тысячи мелких наработок, прикрученных к дизайну за долгое время его развития.
  37. 37. УПРАВЛЕНИЕ ТРЕНДАМИ Да и следующий тренд после флэт-дизайна подхватить будет легко и быстро :) Бесконечная гонка за трендами – не самая разумная трата сил. Но случаются резкие сломы визуальной парадигмы, как это было с iOS7, и компании должны оперативно реагировать.
  38. 38. КЛЮЧЕВАЯ ЧАСТЬ UX-СТРАТЕГИИ Мы делали много подходов к «снаряду» – писали спецификации, собирали единый исходник, делали библиотеки элементов и т.п. Но всё это быстро затухало, потому что находилось в уютном дизайнерском мирке и было слабо востребовано разработчиками.
  39. 39. Раз и навсегда! Если один раз сделать код правильным и распространяемым – появится уверенность в качестве дизайна, работающего в реальном продукте.
  40. 40. Один из главных критериев успешности любых проектов по унификации – перенос дизайна на уровень конкретной реализации.
  41. 41. BILL SCOTT В PayPal из-за технологических ограничений уходило полтора месяца для изменения текстового блока. Это тормозит дизайн и эксперименты. В Netflix одной из первых задач он облегчил разработку. Получился HTML5- фреймворк для всего спектра устройств.
  42. 42. ИСПОЛЬЗОВАТЬ НЕ РУКИ, А ГОЛОВУ ДИЗАЙНЕРА Благодаря уменьшению рутины, есть возможность перевести фокус на продуктовые задачи и решение менее заметных, но также важных дизайнерских проблем. Повышение основных метрик, приятная анимация, тонкие нюансы адаптивности, приведение рекламы в человеческий вид – в бесконечном потоке на них не всегда хватало времени.
  43. 43. КОМПАНИЯ В ПЛЮСЕ  Системный подход к повышению эффективности продуктов.  Ускорение вывода на рынок новых функций.  Гарантированная унификация дизайна. За минусом входной цены перевода продуктов на платформу. * *
  44. 44. КАК ПОСТРОИТЬ СВОЮ ПЛАТФОРМУ
  45. 45. ХВАТИТ МЫСЛИТЬ ЭКРАНАМИ! Нужно перестать мыслить экранами и воспринимать продукт как платформу. Опыт Apple, Google и Microsoft пригодится, даже если ваша компания не так масштабна и амбициозна – они отлично преуспели в построении платформ и экосистем.
  46. 46. Если разобрать их на основные составляющие:  общие принципы визуального стиля и взаимодействия,  набор собственных приложений,  огромное количество приложений от сторонних разработчиков (считай, созданных партнерами и аутсорсерами), то можно найти много общего с работой любой продуктовой компании.
  47. 47. С ЧЕГО НАЧАТЬ? ДВА ПУТИ Сначала создать гайдлайн и после этого применить его к существующим продуктам. Либо удачно обновить дизайн одного из них и выбрать как референсный, создавая затем гайдлайн по его мотивам. Плюсы и минусы есть у обоих подходов.
  48. 48. МЫ ВЫБРАЛИ ВТОРОЙ ПУТЬ Масштабируется уже проверенный на практике дизайн, оптимизированный с помощью аналитики и пользовательских исследований. Накануне и сразу после релиза проводится много экспериментов и тестов, после чего дизайн много раз корректируется. Несколько извилистый и требует рефакторинга платформы. * *
  49. 49. ОДНОВРЕМЕННО СЛОЖНОВАТО Можно, конечно, одновременно делать и продукты, и гайдлайн, но на практике это занимает огромное количество времени из-за постоянных итераций «предложили типовое решение → примерили на продукты → нашли пару нестыковок → обсудили и решили проблемы всей командой → снова примерили на продукты…». Таких решений на проектах сотни и релиз не состоится никогда. * *
  50. 50. MATT MCMANUS Предлагает понятие «непрерывного дизайна». Нужно забыть про «финальные макеты». А дизайнеры должны быть вовлечены в весь процесс разработки и развития продукта, не только его начало.
  51. 51. ОБЩИЕ ПРИНЦИПЫ Основы, на которых выстроена вся платформа.
  52. 52. ОСНОВЫ Они облегчают принятие дизайн-решений на всех уровнях и делают ее развитие системным. С ними нужно определиться на старте работы по унификации.
  53. 53. 1. МАНИФЕСТ Свод из десятка правил или около того, которые помогают провязать образ бренда с конкретными решениями. Это высокоуровневый чеклист для проверки интерфейсных паттернов – они в нашем духе или нет?
  54. 54. MAILCHIMP Компания делает особенный акцент на тоне голоса – текстах в интерфейсе.
  55. 55. MICROSOFT Метро-дизайн настаивает на фокусе на контенте вместо хрома, а также выделяет особую роль анимации. И это выливается в единый консистентный experience.
  56. 56. MY.COM Один из принципов нашего международного бренда – сочетание минималистичного белого фона для рабочих поверхностей интерфейса с точечными акцентами фирменного красного.
  57. 57. Ещё одно качество бренда – эмоциональность и персональность. Чтобы поддержать его и не нарушать первое правило, используются сочные фоны, а рабочая область лежит на белой полупрозрачной подложке.
  58. 58. ВЕЩЬ В СЕБЕ Важно, чтобы манифест был привязан к общей стратегии компании. В случае дизайн-принципов – через брендинг. Тогда они будут работать в полную силу, а не станут очередным новомодным методом-игрушкой дизайнеров. Их будут разделять менеджеры и другие сотрудники компании, они будут действительно помогать в принятии решений.
  59. 59. DESIGN PRINCIPLES FTW Количество принципов должно быть разумным, чтобы их можно было запомнить и между ними не было дублирования. В качестве ориентира можно пройтись по одной из самых обширных коллекций.
  60. 60. 2. ВИЗУАЛЬНЫЙ ЯЗЫК Конкретные принципы, лежащие в основе визуального представления, логики взаимодействия и инфоархитектуры. Если манифест говорит на уровне ценностей, то основы дизайна – о конкретных решениях. Для упрощения будущей жизни платформы нужно стремиться к высокому уровню абстракции во всех определениях.
  61. 61. ИНФОРМАЦИОННАЯ АРХИТЕКТУРА Исходя из специфики продукта и его целевой аудитории, нам нужно описать принципы разделения функций и сценариев использования на экраны, выстроить их иерархию и обеспечить навигацию между ними.
  62. 62. Если мы говорим о линейке продуктов, то они могут значительно различаться и потребуют различных подходов. Поэтому полезно описать сразу все:  одностраничник,  иерархическая структура,  линейная,  сетевая,  хаб или комбинация из нескольких.
  63. 63. Каждый из подходов должен иметь своего рода мини- манифест – для каких задач используется, как переложить на него функциональность и сценарии использования продукта. Причем ещё лучше, если со всеми нюансами – наименование категорий и ссылок, описание мета-данных, организационные схемы (алфавит, география, хронология, тематика, задача, аудитория, популярность).
  64. 64. ПРИНЦИПЫ ВЗАИМОДЕЙСТВИЯ Конкретные навигационные решения, реализующие принципы информационной архитектуры.
  65. 65.  постоянные меню (включая подвал);  контекстные меню (видимые, по правой кнопке мыши или долгому нажатию пальцем);  поиск;  хлебные крошки;  инструменты для работы со списками (сортировка, фильтрация, группировка, постраничная навигация или подгрузка);  контекстные провязки контента;  системы уведомлений и алертов.
  66. 66. Желательно с их иллюстрированным переложением на модель типового экрана, а также рекомендациями по решению конкретных продуктовых задач – например, провязки контента помогают повысить глубину просмотра. Всё это должно опираться на поддерживаемые типы устройств – большой и мобильный веб, приложения для разных платформ (мобильные, планшеты, носимые). Для каждого из них могут быть свои особенности – специфика методов управления (мышь, тач, голос), быстрые действия (горячие клавиши, жесты), обеспечение доступности.
  67. 67. 1ИНТЕРФЕЙСНАЯ СЕТКА Шаг или модуль, по которому выстраиваются все элементы интерфейса – их размеры и отступы между ними.
  68. 68. Сейчас наиболее популярна 8-пиксельная, ее использует в том числе Android и Google в целом. iOS базируется на 11- пиксельной, Windows 8 – 5-пиксельной. 8-пиксельный шаг особенно удобен тем, что хорошо делится на 2. Например, можно получить 2-пиксельное скругление блоков. Базовый шаг определяет типовые расстояния. Мы базируем наше решение на 4dp вместо 8, поэтому в нашем случае это 4, 8, 16, 24, 32, 48, 96, 128. Полезно вести измерения в независимых от плотности экрана пикселях (dp) вместо px.
  69. 69. Дизайнер выбирает размеры не на глаз, а по единым правилам. Так что количество споров и ошибок по мелочам падает на порядок, сильно меньше расхождений в макетах.
  70. 70. 2СТРУКТУРНАЯ СЕТКА Набор колонок, в которые укладывается основной лейаут интерфейса.
  71. 71. Очень популярна 12-колоночная сетка, её используют большинство популярных фреймворков. Мы используем скорее механизм «ритма» – это набор 40- пиксельных колонок с 20-пиксельными отступами (16 колонок для 1024, 20 для 1280, 24 для 1440, 26 для 1600). Структурная сетка также определяет логику адаптивности – как лейаут меняется на разных разрешениях.
  72. 72. 3ЛЕЙАУТЫ Конкретика на базе структурной сетки – как будут размещены рабочие области интерфейса.
  73. 73.  1 колонка, популярная на промо-сайтах?  2 колонки, классический подход для практически любых задач?  3 колонки, всё реже используемые из-за перегруженности?  Бесконечный поток карточек или тайлов, популяризованный Pinterest? Лейаут может задавать и вертикальные соотношения, хотя это встречается нечасто.
  74. 74. 4КОНТЕЙНЕРЫ Каждая колонка лейаута – это стек, в котором друг за другом помещаются контейнеры конкретных блоков с контентом.
  75. 75. Полезно задавать логику внешнего вида (граница, фон, тень, заголовок и т.п.) и поведения контента на уровне самого контейнера. Так будет проще развивать платформу, добавляя новые блоки или корректируя общие принципы. Например, если элементов в блоке больше, чем можно отобразить на экране, мы можем добавить ссылку на полный список на отдельной странице, развернуть их тут же по клику на «показать ещё», разбить постраничной навигацией или сделать прокрутку внутри (вертикальную или горизонтальную). Если мы выбрали горизонтальную прокрутку и в будущем захотим переделать стрелки или добавить свайп для тач- экранов, нам не придется пробегаться по всем копиям контейнера. Сюда же стоит отнести и попапы. * *
  76. 76. ШРИФТОВАЯ СЕТКА Есть множество подходов к выбору размеров шрифтов, основанных на идее масштабирования от базового текста. Главное, чтобы межстрочное расстояние ложилось в интерфейсную сетку – тогда и интерфейсный, и наборный текст не поломают её.
  77. 77. GRIDLOVER Сервис собрал, кажется, все возможные формулы масштабирования шрифтов в сетке.
  78. 78. Если ориентироваться на интерфейсную сетку, то размеры шрифтов должны быть кратны 4. Для заголовков это легко, хотя на практике есть проблемы с наборным текстом:  Красивое число 16 для основного текста бывает великоватым для конкретного интерфейсного решения.  Особенности рендеринга веб-шрифтов в Windows заставляют делать много костылей и обходных решений.
  79. 79. ЦВЕТОВАЯ ПАЛИТРА К основе, которую задают основные цвета бренда, должны быть прописаны вспомогательные значения. В дополнение к цветам полезно описать формулы для построения теней, задать несколько стандартных параметров прозрачности и размытия фона.
  80. 80.  Интерфейсные цвета – белый и черный (или их оттенки, если чистые значения не подходят), цвета ошибок и других системных сообщений (красный, зеленый, желтый), ссылки, а также линейка серых цветов (подложки, границы, вспомогательный текст).  Акцентные – например, для обозначения категорий контента. Причем для них может быть задана логика изменения, если нужны вариации (например, недоступные категории высветляются). Естественно, все цвета в палитре должны сочетаться с основными, заданными брендом.
  81. 81. НАБОР ЭЛЕМЕНТОВ УПРАВЛЕНИЯ Имея интерфейсную и шрифтовую сетку, а также цветовую палитру, можно системно подойти к работе над базовыми строительными элементами.
  82. 82.  Кнопки (главная, обычная, с дополнительными опциями; текстовая, иконочная, версия для в панелей инструментов);  ссылки;  общие и специализированные поля ввода и выпадающие списки (комбо-бокс, календарь, страна с телефонным кодом и т.п.);  переключатели (чекбокс, радио-кнопка, тумблер);  загрузчики пользовательского контента (фото, видео, файлы). Для них должны быть заданы состояния: фокус, активное, наведение, недоступно.
  83. 83. КОМПОНОВКИ ФОРМ В дополнение к элементам форм нужно описать их компоновки. Расположение названий полей, пояснительных текстов к ним, правила валидации значений и отображения ошибок.
  84. 84. ГРАФИКА И ИЛЛЮСТРАЦИИ Необходимы стандарты для фото и другой контентной графики. Пропорции, типовые размеры и их вариации для разных разрешений. В идеале они должны вписываться в колоночную сетку. То же самое касается аватаров.
  85. 85. Хорошо, если интерфейсные иконки провязаны с общим брендингом – можно постепенно развивать их универсальный набор. Иллюстрации также должны вписываться в общую канву, но тут достаточно описать общие подходы к стилистике. Толщина линий, цветовая палитра, принципы передачи объема, правила размещения в интерфейсе и промо-материалах. Крупные иконки-иллюстрации могут основываться на метафорах интерфейсных пиктограмм, развивая их в большей детализации, а для среднего размера задать стандартизированную сетку.
  86. 86. ИНФОГРАФИКА И ВИЗУАЛИЗАЦИЯ ДАННЫХ Еще одно направление для стандартизации. Обширных список всех возможных типов нужен только узкоспециализированным сервисам, но наиболее востребованные необходимо описывать всем.
  87. 87.  Таблицы;  распространенные диаграммы (круговая, столбиковая, гистограмма, линейный график, график рассеивания);  более редкие (площадная диаграмма, кольцевая, лепестковая, диаграмма разброса, Венна, Сэнки);  картография;  тепловые диаграммы;  облако тегов;  графы и деревья;  плоское дерево;  ментальные карты;  блок-схемы и диаграммы процессов;  временные шкалы;  диаграммы связей.
  88. 88. АНИМАЦИОННАЯ МОДЕЛЬ В идеале переходы между состояниями и экранами интерфейса должны подчиняться определенной модели. Тогда анимация будет консистентной, а пользователю будет легче.
  89. 89. Например, попапы могут приезжать сверху экрана и после закрытия уезжать обратно, а если это пошаговый помощник – после появления основного окна, новые состояния могут приезжать справа. Для примера можно изучить подходы трёх крупных платформ:  Android (тонкая оркестровка);  iOS (до iOS7 и после);  Windows Phone (родоначальник современного подхода).
  90. 90. РЕКЛАМА Рекламная сетка зачастую определяет внешний вид, задавая ограничения сетки дизайнерской. Важно работать с коммерческим отделом не менее плотно, чем с разработчиками – это позволит находить форматы, не рушащие ни дизайн, ни денежный поток проекта.
  91. 91. Нужно определить рекламный инвентарь – виды и размеры медийных и контекстных блоков, принципы брендирования блоков и страниц, задать стандарты для компоновки фулскринов и других агрессивных подходов. Полезно проработать типовые решения для внутреннего промо. Второй шаг – это сетка, по которой реклама размещается на стандартных лейаутах.
  92. 92. 3. ПРИНЦИПЫ В КОДЕ После определения основных принципов дизайна платформы нужно заложить их и в основу CSS. А иконочные шрифты и SVG-спрайты помогут удобно работать со вспомогательной графикой. Дизайнерам крайне важно понимать код, чтобы вместе с разработчиками выстроить future-friendly систему.
  93. 93. Итоговый дизайн в том или ином виде определяется на всех этапах продуктовой разработки и важно не забывать об этом, если вы хотите работать системно.
  94. 94. ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ Современные CSS-препроцессоры вроде SASS и Less позволяют задавать глобальные переменные – это отличный способ определить основные принципы в коде.
  95. 95. Математика в коде! Чтобы получить кнопку: o пишем «Сохранить» базовым размером шрифта + отмеряем типовые отступы сверху, снизу и по бокам + заливаем это пространство стандартным цветом для подложек кнопок + также стандартным цветом очерчиваем обводку + подкладываем стандартную тень снизу. Пока не поменяются константы, эта математика будет приводить всю команду к одинаковым решениям. * *
  96. 96. ТИПОВЫЕ ЛЕЙАУТЫ Полезно привести в пример структуру типовых страниц на основе лейаутов. Они включают шапку, подвал, контентную область, вспомогательные колонки. Это помогает лучше понимать основы использования гайдлайнов.
  97. 97. БИБЛИОТЕКА ПАТТЕРНОВ И ГОТОВЫХ РЕШЕНИЙ Создание готовых компонентов и перевод всего дизайна на них.
  98. 98. КОМПОНЕНТЫ Исходя из цели упрощения производственной цепочки до «спецификация = дизайн = верстка → реализация», компонент – это готовый код с определенным визуальным стилем, логикой работы и взаимодействия. Он независим от окружения – мы можем использовать его на любой странице без опасения, что он сломается.
  99. 99. ТИПОВЫЕ СТРАНИЦЫ Помимо отдельных решений полезно описать и типовые страницы, состоящие из стандартизированных компонентов. Всё, что вы начинаете использовать хотя бы дважды, полезно перевести в стандартные решения.
  100. 100. ПАТТЕРНЫ 2.0 По сути это и есть классический дизайн-паттерн, которые дизайнеры обычно собирали в виде библиотек к инструментам проектирования и дизайна, а после этого описывали в гайдлайнах.
  101. 101. Только нам не нужно каждый раз проверять качество его внедрения и поддерживать во всей цепочке артефактов. А если мы решили изменить паттерн – нужно заменить оригинал в единой базе кода, после чего он обновится на всех использующих фреймворк проектах.
  102. 102. Примеры компонентов:  навигация – вкладки, алфавитный указатель, календарь, поиск и фильтры, сортировка, история просмотров;  списки – список, матрица, прокручиваемая лента, асинхронная тайловая компоновка;  медиа – видео, инфографика, фотогалерея, пост из социальной сети;  информеры – погода, курсы акций и commodities, спортивная статистика, расписания, гороскопы, мировое время;  социальное взаимодействие – комментарии, опросы, консультации, рейтингование, обратная связь, шаринг в соц.сетях.
  103. 103. ТИПОВЫЕ СТРАНИЦЫ Помимо отдельных решений полезно описать и типовые страницы, состоящие из стандартизированных компонентов. Всё, что вы начинаете использовать хотя бы дважды, полезно перевести в стандартные решения.
  104. 104.  Список новостей;  конкретная публикация;  результаты поиска;  настройки;  профиль пользователя;  авторизация и регистрация;  «нулевые» состояния;  серверные ошибки;  шаблоны писем рассылки.
  105. 105. СЕМАНТИКА КОДА Важна для описания компонентов. Как в плане отсылки к базовым принципам – паттерн использует не конкретное значение «шрифт 24 размера» или «подложка цвета #F0F0F0», а смысл – «заголовок 2 уровня» или «подложка для карточек». Так и в смысле общего назначения – основной контент, информация по теме, дополнительные обвязки. Тогда сработает идея с легким обновлением по линейке продуктов. * *
  106. 106. УНИФИКАЦИЯ ИЛИ УНЫЛИЗАЦИЯ? Если запускать все продукты на базе одних и тех же компонентов, то помимо унификации мы получим еще и унылизацию – сервисы выглядят однояйцевыми. Поэтому платформа должна давать возможность стилизации продуктов без изменения общих принципов работы компонентов.
  107. 107. ПРИМЕР СТИЛИЗАЦИИ Мы выбрали идею акцентных цветов – каждый сервис имеет свой цвет, что позволяет выделить его из общей линейки. Могут сработать разные шрифты, декоративные элементы, иллюстрации и иконки.
  108. 108. ЖИВОЙ ГАЙДЛАЙН По сути, еще один проект на платформе.
  109. 109. АКТУАЛЬНОСТЬ 100% Контроль качества всей продуктовой линейки радикально упрощается – дизайнер следит только за референсным паттерном.
  110. 110. Вначале описываются общие принципы, которые мы извлекаем из основного CSS. После этого – готовые компоненты, которые уже используются в работающих продуктах. К каждому из них дизайнер должен дать описание – для чего и в каких ситуациях он используется. Даже если вы строите упрощенную систему в духе Bootstrap, первый шаг уже здорово поможет в систематизации работы.
  111. 111. ЭТА ССЫЛКА ТУТ БУДЕТ ЧАСТО :) И снова сошлюсь на styleguides.io – огромная коллекция инструментов для создания живых гайдлайнов.
  112. 112. АВТОЛЕЧЕНИЕ Раз в неделю или месяц скрипт проходит по всем продуктам и сравнивает использующиеся в их CSS параметры с референсными. Если обнаружены расхождения – дизайнер получает список проблемных мест.
  113. 113. ПРОТОТИПИРОВАНИЕ Когда все компоненты платформы запущены и работают, можно еще больше упростить рабочий процесс.
  114. 114. МЕНЬШЕ ПРОКЛАДОК Там где это уместно, нужно отбросить инструменты для создания статических wireframes и макетов. Если живой гайдлайн рядом с примером компонента будет выводить его HTML-код, несложно собрать готовую верстку страницы в HTML-редакторе на основе шаблонов типовых лейаутов.
  115. 115. ФОТОШОП ДЛЯ ЛОХОВ РЕЖЕ Многие дизайнеры уже не боятся кода. Сейчас полным-полно понятных обучалок и готовых примеров, да и сами HTML и CSS простые до безобразия. Фотошоп и подобные инструменты отлично работают для поиска стилистических направлений. Но без перехода к дизайну в браузере работать становится все сложнее.
  116. 116. AXURE В ИНТЕРНЕТЕ Если у компании достаточно ресурсов и платформа устоялась, можно пойти дальше и собрать онлайн-инструмент для визуального прототипирования. Дизайнер или менеджер перетаскивает готовые компоненты на страницу и получает интерактивный прототип.
  117. 117. КОНСТРУКТОР PROJECT POLYMER Для платформы Google есть демо-конструктор, в котором можно собрать адаптивный интерфейс в гайдлайнах material. https://polymer-designer.appspot.com/
  118. 118. НА БАЗЕ BOOTSTRAP Есть много сервисов, позволяющих собирать страницы проектов на Bootstrap в браузере.
  119. 119. РЕАЛЬНЫЕ И АКТУАЛЬНЫЕ ДАННЫЕ Ответственные дизайнеры отучились вставлять “lorem ipsum”, но это требует некоторой ручной работы. Много сил отнимает проработка краевых состояний и легкая подстановка данных в прототип позволит быстрее проверять их.
  120. 120. КОММУНИКАЦИЯ ПРОЩЕ Помимо того что дизайн становится дешевле и плодит меньше рассинхронизации, живой прототип лучше работает как инструмент коммуникации. Страницы можно провязать друг с другом, работает вся логика и скрипты публичной версии продукта, задана адаптивность.
  121. 121. ЭКСПЕРИМЕНТЫ Поиск лучших дизайн-решений среди множества альтернатив.
  122. 122. ВСТРОЕННЫЕ A/B-ТЕСТЫ Дизайн-паттерны, используемые в платформе, не определяются раз и навсегда – мы всегда должны искать более удачные решения. Здорово, если платформа позволяет делать это системно и недорого, облегчая проведение юзабилити- и A/B-тестов.
  123. 123. Идеи для них могут идти от:  найденных проблем;  целей по росту продуктовых показателей;  интересных подходов у конкурентов;  общей потребности регулярного тюнинга дизайна.
  124. 124. АРХИВ РЕШЕНИЙ Старые версии блоков можно сохранять, в идеале – указывая в каждом из них результаты и детали эксперимента. Тогда можно будет изучать, как и почему они работали (или не работали) раньше и находить инсайты для будущих улучшений.
  125. 125. КУМУЛЯТИВНЫЙ ЭФФЕКТ Сама идеология платформы предполагает, что каждый проект получает актуальную версию компонента из единой базы кода. Так что оптимизированный в ходе тестирования вариант быстро распространится по всей линейке и прокачает показатели всего бизнеса.
  126. 126. АЛГОРИТМИЧЕСКИЙ ДИЗАЙН? Последние годы периодически встречается для построения экранов интерфейса.
  127. 127. ДИЗАЙН АЛГОРИТМОВ Дизайнер и разработчик описывают логику обработки входящих сигналов – контента, контекста, информации о пользователе и его действиях, а дальше платформа сама формирует дизайн на основе готовых паттернов и принципов.
  128. 128. ТОНКАЯ ПОДСТРОЙКА Это позволяет добиться тонкой подстройки под конкретную узкую ситуацию без необходимости вручную прорисовывать и разрабатывать десятки состояний экрана.
  129. 129. АВТОМАТИЗИРОВАННАЯ ЖУРНАЛЬНАЯ ВЕРСТКА Мы описывали для одного из проектов. Контент не имел семантики, а переверстать архив вручную – затратно. Скрипт разбирал статью и исходя из её контента (количество абзацев и слов в каждом, фотографии и их форматы, врезки с цитатами и таблицами и т.п.) выбирал типовой паттерн для представления каждого куска в эффектном журнальном виде. И следил, чтобы паттерны чередовались и материал не выглядел однообразно.
  130. 130. DUPLO Похожую модель недавно реализовал Flipboard.
  131. 131. THE GRID CMS, которая самостоятельно подбирает шаблоны, оформление контента, обрабатывает фотографии. Причем еще и проводит A/B- тесты разных подходов для выбора лучшего решения.
  132. 132. ПАРАМЕТРИЧЕСКИЕ ШРИФТЫ Дают дизайнерам большую гибкость работы и новые возможности. Пример – Robofont.
  133. 133. КОГДА ЖДАТЬ ПРИХОДА? Подход не то что не устоялся – даже обсуждается редко. Но может здорово помочь в будущем для действительно прорывных решений. И это будет еще одним уровнем зрелости дизайн-платформы.
  134. 134. НАШ ОПЫТ
  135. 135. DOUBLE KILL Мы идем по этому пути и уже построили на собственной платформе две группы проектов из пяти – мобильный веб и контент-проекты. Процесс создания и внедрения фреймворка может быть извилистым.
  136. 136. 1. СОЗДАНИЕ МОДЕЛЬНОГО ДИЗАЙНА И ФРЕЙМВОРКА Необходимо найти подходящее для наших продуктов и масштабируемое интерфейсное решение, определиться со стилистикой и реализовать техническую часть фреймворка.
  137. 137. 2. ПЕРЕВОД ВСЕХ ПРОДУКТОВ НА ПЛАТФОРМУ Библиотека паттернов и единая база кода активно расширяются за счет новых решений, а бек-энд сервисов приводится в соответствие с требованиями фреймворка.
  138. 138. 3. УПРОЩЕНИЕ ДИЗАЙН-ПРОЦЕССА Техническое решение уже обкатано и основные задачи решены, поэтому от создания множества артефактов можно отказаться и собирать новые экраны из готовых блоков в единой базе кода.
  139. 139. 4. РЕФАКТОРИНГ ДИЗАЙНА Запуск десятка продуктов занимает достаточно внушительное время, за которое выявляются проблемы в реальной жизни сервисов. Да и дизайнерские тренды меняются.
  140. 140. МЫ В ПУТИ Сейчас у нас параллельно идут третий и четвертый этап внедрения фреймворка. Но плюсы работы с ним мы ощутили уже в самом начале – количество лишней постоянно снижается.
  141. 141. ПРИМЕНИМО И ДЛЯ МОБИЛЬНЫХ Описанная компонентная модель предназначена для веба. Мы думали о её применении для мобильных приложений – в этом случае компонентами служат бандлы, т.е. распространяемые библиотеки с уже зашитым дизайном. Но пока что сфокусировались на веб-сервисах.
  142. 142. ЕСТЬ СВОИ ПРОБЛЕМЫ Оглядываясь назад, мы наверняка смогли бы сделать процесс создания и внедрения фреймворка правильнее и короче. Но я рассказал о наших правильных и ошибочных решениях в деталях, чтобы вы смогли пройти этот путь быстрее.
  143. 143. ЗАКРУЧИВАТЬ ГАЙКИ В развитии гайдлайнов нужен некоторый авторитаризм, который поможет не пропускать несистемных решений. Если это возможно – нужно всегда использовать готовые паттерны.
  144. 144. Если вводится что-то новое – нужно пробовать подвести под это решение уже реализованные проекты или понимать, где оно пригодится в будущем. Только тогда платформа не расползется и консистентность портфеля продуктов сохранится. А значит сохранятся и удобство развития этих продуктов, их комфортность для пользователя и положительный эффект для всего бренда.
  145. 145. ЧУЖИЕ ПРИМЕРЫ
  146. 146. ДОСТУПНО НЕ ТОЛЬКО КРУПНЯКУ Bootstrap и Foundation отлично решают часть задач – описание принципов дизайна в коде, живые гайдлайны, прототипирование.
  147. 147. НА САМОМ ДЕЛЕ НЕТ? Они не дают всех преимуществ компонентной модели, когда обновление линейки продуктов значительно упрощается. Но это в любом случае дешевый способ начать свою платформу. Тем более, что вам предстоит решить ещё уйму задач – перевести продукты на новую технологическую базу, перестроить рабочий процесс.
  148. 148. ANNA DEBENHAM Одна из пионеров в создании живых гайдлайнов. Ведет сильную коллекцию готовых решений, статей и примеров – рекомендую каждому прочитать её от корки до корки.
  149. 149. BRAD FROST Brad Frost, идеолог концепции Atomic Design, пишет книгу на эту тему. На его сайте доступны некоторые части из неё, и главы потихоньку пополняются.
  150. 150. ЧИТАТЬ ОТ КОРКИ ДО КОРКИ! Грандиозная коллекция ресурсов на тему живых гайдлайнов и компонентных систем. Лучше любой книжки!
  151. 151. ЧТО В ИТОГЕ?
  152. 152. Уверен: Любая современная UX-стратегия должна строиться на похожих принципах, иначе в долгосрочной перспективе всё будет плохо.
  153. 153. Хотите заложить хорошую основу для продукта или целой линейки продуктов? Забудьте про статические гайдлайны и библиотеки паттернов. Это лишний этап работ, еще один промежуточный артефакт и источник дополнительных трудозатрат.
  154. 154. Ускорение и удешевление вывода на рынок новых возможностей продукта. Гарантированный способ получить унифицированный дизайн и сохранить единство в будущем. Более частые и системные эксперименты с дизайн- решениями. От улучшения в одном продукте выигрывают и остальные. Дизайнер меньше работает руками и больше – головой.
  155. 155. УХОДИМ ОТ ГЕРОИЧЕСКИХ РЕДИЗАЙНОВ Переход к постоянно актуальному интерфейсу. Больше времени можем уделить на продуктовую работу, а не бесконечное обслуживание дизайна. При этом специалист становится продуктовым дизайнером, который перестает мыслить макетами и выходит за рамки Фотошопа.
  156. 156. P.S.Только не надо бросаться в крайности! Любой новый подход к работе не отменяет, а дополняет и видоизменяет старые. Глупо кричать о том, что передовые дизайнеры работают в только браузере, а все кто остался в Фотошопе – старые деды. Но и оставаться зажатыми в рамках классических инструментов – хоронить свою карьеру. Надеюсь, это не про вас :) * *
  157. 157. CREDITS: ДИЗАЙН ЕВГЕНИЙ БЕЛЯЕВ ЮРИЙ ВЕТРОВ МАРИЯ БОБРОВА АРТЕМ ГЛАДКОВ ГЕВОРГ ГЛЕЧЯН КОНСТАНТИН ЗУБАНОВ АЛЕКСАНДР КИРОВ ЕВГЕНИЙ ДОЛГОВ АЛЕКСЕЙ КАНДАУРОВ ДМИТРИЙ ОСАДЧУК АЛЕКСЕЙ СЕРГЕЕВ ПАВЕЛ СКРИПКИН ЕВГЕНИЙ ФЕРУЛЕВ
  158. 158. CREDITS: РАЗРАБОТКА АЛЕКСАНДР БЕКБУЛАТОВ ДМИТРИЙ БЕЛЯЕВ СТАНИСЛАВ МИХАЛЬСКИЙ СЕРГЕЙ НОЖКИН ВИТАЛИЙ ВАСИН ПАВЕЛ ВДОВЦЕВ КОНСТАНТИН ВОРОЖЕЙКИН АНТОН ПОЛЕЩУК БОРИС РЕБРОВ ПАВЕЛ РЫБИН АНТОН ЕПРЕВ ЕВГЕНИЙ ИВАНОВ МАКСИМ ТРУСОВ АРСТАН ТОРЕГОЖИН АНДРЕЙ КУСИМОВ ПАВЕЛ ЩЕРБИНИН
  159. 159. СПАСИБО! ЮРИЙ ВЕТРОВ www.jvetrau.com twitter.com/jvetrau

×