SlideShare una empresa de Scribd logo
1 de 160
ПЛАТФОРМЕННОЕ
МЫШЛЕНИЕ
Как перестать плодить документацию и начать жить
ЮРИЙ ВЕТРОВ
MAIL.RU GROUP
ПРОДУКТОВЫЙ
ДИЗАЙНЕР
ФРЕЙМВОРК
UX-СТРАТЕГИИ
ПЛАТФОРМЕННОЕ
МЫШЛЕНИЕ
КАК ВНЕДРЯТЬ
НА ПРАКТИКЕ
АНАЛИТИКА
И ИССЛЕДОВАНИЯ
ОТ ДИЗАЙН-КОМАНДЫ
К ДИЗАЙН-КУЛЬТУРЕ
DOCUMENT-DRIVEN DESIGN
Многие привыкли думать вокруг артефактов и процесса их
создания и согласования. Мы исследуем пользователей и рынок,
продумываем сценарии и инфоархитектуру, делаем скетчи и
прототипы, готовим дизайн-макеты и гайдлайны, отдаем их в
разработку. А после всего этого смотрим что получилось на
практике и вносим доработки до тех пор, пока не достигнем
соответствия продукта рынку и нужного уровня качества.
R.I.P. ВОТ ЭТО ВОТ ВСЁ
В околоконвейерном процессе подход сжигает уйму времени
на артефакты. Это размывает фокус и ответственность – силы
уходят на полировку побочных документов, а не продукта.
Большая часть этих талмудов нужна только для передачи
знаний внутри команды и быстро устаревает – получаем ещё
и высокие транзакционные издержки. Так не годится.
ЭПОХА ШРЕДЕРА
Нужно воспринимать работу не как временный проект по
запуску нового дизайна или конкретной функциональности, а
как вывод на рынок и развитие целостной платформы.
Тогда продукт будет расти системно, а UX-стратегия компании
заработает на всех уровнях – оперативном, тактическом и
стратегическом.
3 УРОВНЯ ЗРЕЛОСТИ UX
ХАОС
ОПЕРАТИВНЫЙ
ТАКТИЧЕСКИЙ
СТРАТЕГИЧЕСКИЙ
СИСТЕМАТИЗАЦИЯ
ДИЗАЙНА
ГАЙДЛАЙНЫ РЕШАЮТ?
Классическое решение для системного развития продуктов –
гайдлайны и библиотеки паттернов. Но это ещё один
статический артефакт.
Рождается цепочка:
«гайдлайн → макет → верстка → реализация», на каждом из
этапов которой теряются детали и генерируются баги.
1.
ДОКУМЕНТАЦИЮ НЕ ЧИТАЮТ
Дизайнеры часто говорят, что документацию не читают
разработчики. Но и сами они, честно говоря, тоже филонят,
если синхронизироваться должны несколько человек.
2.
ГАЙДЛАЙН
ДЛЯ ЛИНЕЙКИ ПРОДУКТОВ? ХА!
На практике дизайн по спецификации сложно реализовать на
100%, если это делается сразу для нескольких продуктов.
Во-первых, спецификация сама по себе требует регулярного
обновления – появляются новые паттерны, находятся более
удачные решения для уже имеющихся.
Во-вторых, по ходу редизайна успевают реализовать не всё и
сервис запускается «почти отполированным». А вся линейка
продуктов – «почти похожей». И что тогда считать
референсным дизайном?
Конечно, можно провести рефакторинг. Но он оказывается
дорогим – его нужно проводить постоянно для каждого из
продуктов, при каждом более-менее заметном обновлении.
3.
КОНТРОЛЬ КАЧЕСТВА
ДОРОГ И УТОМИТЕЛЕН
Всё это требует огромных усилий и уймы времени от
дизайнера на контроль качества реализации.
4.
ОБНОВЛЕНИЯ ДИЗАЙНА
УСИЛИВАЮТ ПРОБЛЕМУ
Нужно снова идти по всей линейке – переделывать и
контролировать, переделывать и контролировать…
5.
ЭКСПЕРИМЕНТЫ НЕДЕШЕВЫ
Они также заставляют генерировать побочные артефакты и в
результате усиливают энтропию.
СПИСОК ПРОБЛЕМ ДЛИННЫЙ
И мы ещё не говорим о «нюансах» вроде адаптивного
дизайна... Многие просто нанимают больше дизайнеров.
АДОК!
БЕЗ ТЕХНИЧЕСКОГО РЕШЕНИЯ
НЕ ОБОЙТИСЬ
Те, кто мыслит системно, пытаются найти решение на стыке
дизайна и технологий. Только так можно сократить цепочку
до «спецификация = дизайн = верстка → реализация».
А значит избавиться от кучи геморроя по внедрению,
улучшению и поддержке продуктов.
У НАС УЖЕ ДВОЙНЯ
В этой идеологии мы перезапустили уже две группы
продуктов – мобильный веб и контент-проекты. Я расскажу о
процессе работы над такой платформой.
ДИЗАЙНЕРСКО-
ТЕХНОЛОГИЧЕСКАЯ
УНИФИКАЦИЯ
ДВА ПУТИ
В эту сторону уже идут многие крупные компании, что сильно
упрощает им жизнь и развязывает руки в развитии бизнеса.
Хороший дизайн можно и нужно получать дёшево и быстро, а
этого невозможно добиться при работе руками. Каким может
быть это техническое решение?
А.
СВОЙ МАЛЕНЬКИЙ BOOTSTRAP
Дешевле и быстрее в создании – вы уже получаете профит от
облегчения поддержки, недорогих экспериментов с дизайном
и легкого прототипирования.
Хотя, по сути, вы просто используете набор HTML/CSS-стилей,
который может поломаться при использовании в реальном
продукте.
КУЧА КОМПАНИЙ УЖЕ ТУТ
В районе 2012-2013 года многие компании не сговариваясь
пришли к этой идее. Мы начали тогда же.
BUILD YOUR OWN BOOTSTRAP
Тогда же вышла серия визионерских статей от Anna
Debenham, Brad Frost, Mark Otto и Dave Rupert. И понеслась!
Б.
КОМПОНЕНТНАЯ СИСТЕМА
Она дороже в создании, зато на выходе у вас
гарантированное качество реализации дизайна и все
бенефиты от простоты обновления продуктов.
ПОПАЛИ В ВОЛНУ
Мы в Mail.Ru Group пошли именно в эту сторону. Все началось
в середине 2012 с простой идеи и эксперимента.
У такого подхода 5 уровней зрелости:
1. Определены и зашиты в CSS общие принципы дизайна.
2. Все продукты работают на основе единых компонентов.
3. Есть живые гайдлайны. Они показывают реализацию, а не
скриншоты.
4. Можно прототипировать страницы на основе живых
гайдлайнов.
5. Эксперименты с дизайном компонентов для сравнения
различных подходов.
INTUIT HARMONY (2014)
По пути готовых компонентов идет не так много компаний. Но
есть мощные примеры. Экосистема Harmony от Intuit.
LONELY PLANET (2014)
Решение на базе собственного фреймворка Rizzo.
POLYMER PROJECT (2014)
Платформа от Google, реализующая material design.
ЯНДЕКС.ЛЕГО
Основанный на идеологии и технологиях БЭМ конструктор.
1. ЕДИНЫЙ
ВИЗУАЛЬНЫЙ СТИЛЬ,
ПРИНЦИПЫ РАБОТЫ ИНТЕРФЕЙСА,
ИНФОРМАЦИОННАЯ АРХИТЕКТУРА
Это удобно для пользователя – группа схожих продуктов
работает одинаково понятно и привычно.
И хорошо для бренда – вся линейка сервисов выглядит
целостной.
{
2.
ГАРАНТИЯ 100% 90%
Унификация гарантируется подходом к разработке – все
готовые блоки и элементы берутся из единой базы кода и
только из нее.
Ещё на 10% – внимательностью и вдумчивостью при
использовании готовых решений.
3.
ПРОЩЕ РЕДИЗАЙНЫ
И ЗАПУСК НОВЫХ ПРОДУКТОВ
В фреймворке есть большинство необходимых блоков и
компонентов на все случаи жизни, что позволяет быстро
собрать новый интерфейс.
4.
ПРОЩЕ КОНТРОЛИРОВАТЬ
БОЛЬШОЙ ПУЛ ПРОЕКТОВ
Когда они устроены одинаково. Вместо сотни отдельных
проектов вы следите за парой гайдлайнов.
5.
МЕНЬШЕ ЛИШНЕЙ РАБОТЫ
Нужно рисовать меньше макетов – прощай, рутина! Страницу
можно собрать из готовых блоков, причём в будущем –
совсем без запуска Фотошопа.
6.
МАСШТАБИРОВАНИЕ УЛУЧШЕНИЙ
От улучшения в одном конкретном продукте выигрывают и
остальные. Например, если блок новостей по теме повысил
глубину просмотров на Авто, это решение очень быстро
попадет и в другие сервисы.
7.
ПОСТОЯННАЯ АКТУАЛЬНОСТЬ
Уход от героических редизайнов раз в несколько лет к
регулярной гигиене дизайна.
Перезапуски отнимают много сил и теряют тысячи мелких
наработок, прикрученных к дизайну за долгое время его
развития.
УПРАВЛЕНИЕ ТРЕНДАМИ
Да и следующий тренд после флэт-дизайна подхватить будет
легко и быстро :)
Бесконечная гонка за трендами – не самая разумная трата сил.
Но случаются резкие сломы визуальной парадигмы, как это
было с iOS7, и компании должны оперативно реагировать.
КЛЮЧЕВАЯ ЧАСТЬ UX-СТРАТЕГИИ
Мы делали много подходов к «снаряду» – писали
спецификации, собирали единый исходник, делали
библиотеки элементов и т.п.
Но всё это быстро затухало, потому что находилось в уютном
дизайнерском мирке и было слабо востребовано
разработчиками.
Раз и навсегда!
Если один раз сделать код правильным
и распространяемым – появится
уверенность в качестве дизайна,
работающего в реальном продукте.
Один из главных критериев успешности
любых проектов по унификации –
перенос дизайна на уровень
конкретной реализации.
BILL SCOTT
В PayPal из-за технологических ограничений
уходило полтора месяца для изменения
текстового блока. Это тормозит дизайн и
эксперименты. В Netflix одной из первых задач
он облегчил разработку. Получился HTML5-
фреймворк для всего спектра устройств.
ИСПОЛЬЗОВАТЬ НЕ РУКИ,
А ГОЛОВУ ДИЗАЙНЕРА
Благодаря уменьшению рутины, есть возможность перевести
фокус на продуктовые задачи и решение менее заметных, но
также важных дизайнерских проблем. Повышение основных
метрик, приятная анимация, тонкие нюансы адаптивности,
приведение рекламы в человеческий вид – в бесконечном
потоке на них не всегда хватало времени.
КОМПАНИЯ В ПЛЮСЕ
 Системный подход к повышению эффективности
продуктов.
 Ускорение вывода на рынок новых функций.
 Гарантированная унификация дизайна.
За минусом входной цены перевода продуктов на платформу.
*
*
КАК ПОСТРОИТЬ
СВОЮ ПЛАТФОРМУ
ХВАТИТ МЫСЛИТЬ ЭКРАНАМИ!
Нужно перестать мыслить экранами и воспринимать продукт
как платформу.
Опыт Apple, Google и Microsoft пригодится, даже если ваша
компания не так масштабна и амбициозна – они отлично
преуспели в построении платформ и экосистем.
Если разобрать их на основные составляющие:
 общие принципы визуального стиля и взаимодействия,
 набор собственных приложений,
 огромное количество приложений от сторонних
разработчиков (считай, созданных партнерами и
аутсорсерами),
то можно найти много общего с работой любой продуктовой
компании.
С ЧЕГО НАЧАТЬ?
ДВА ПУТИ
Сначала создать гайдлайн и после этого применить его к
существующим продуктам.
Либо удачно обновить дизайн одного из них и выбрать как
референсный, создавая затем гайдлайн по его мотивам.
Плюсы и минусы есть у обоих подходов.
МЫ ВЫБРАЛИ ВТОРОЙ ПУТЬ
Масштабируется уже проверенный на практике дизайн,
оптимизированный с помощью аналитики и
пользовательских исследований.
Накануне и сразу после релиза проводится много
экспериментов и тестов, после чего дизайн много раз
корректируется.
Несколько извилистый и требует рефакторинга платформы.
*
*
ОДНОВРЕМЕННО СЛОЖНОВАТО
Можно, конечно, одновременно делать и продукты, и
гайдлайн, но на практике это занимает огромное количество
времени из-за постоянных итераций «предложили типовое
решение → примерили на продукты → нашли пару
нестыковок → обсудили и решили проблемы всей командой
→ снова примерили на продукты…».
Таких решений на проектах сотни и релиз не состоится никогда.
*
*
MATT MCMANUS
Предлагает понятие «непрерывного
дизайна». Нужно забыть про «финальные
макеты». А дизайнеры должны быть
вовлечены в весь процесс разработки и
развития продукта, не только его начало.
ОБЩИЕ ПРИНЦИПЫ
Основы, на которых выстроена
вся платформа.
ОСНОВЫ
Они облегчают принятие дизайн-решений на всех уровнях и
делают ее развитие системным.
С ними нужно определиться на старте работы по унификации.
1.
МАНИФЕСТ
Свод из десятка правил или около того, которые помогают
провязать образ бренда с конкретными решениями.
Это высокоуровневый чеклист для проверки интерфейсных
паттернов – они в нашем духе или нет?
MAILCHIMP
Компания делает особенный акцент на тоне голоса –
текстах в интерфейсе.
MICROSOFT
Метро-дизайн настаивает на фокусе на контенте вместо хрома, а
также выделяет особую роль анимации. И это выливается в
единый консистентный experience.
MY.COM
Один из принципов нашего международного бренда – сочетание
минималистичного белого фона для рабочих поверхностей
интерфейса с точечными акцентами фирменного красного.
Ещё одно качество бренда – эмоциональность и персональность. Чтобы
поддержать его и не нарушать первое правило, используются сочные
фоны, а рабочая область лежит на белой полупрозрачной подложке.
ВЕЩЬ В СЕБЕ
Важно, чтобы манифест был привязан к общей стратегии
компании. В случае дизайн-принципов – через брендинг.
Тогда они будут работать в полную силу, а не станут
очередным новомодным методом-игрушкой дизайнеров. Их
будут разделять менеджеры и другие сотрудники компании,
они будут действительно помогать в принятии решений.
DESIGN PRINCIPLES FTW
Количество принципов должно быть разумным, чтобы их можно было
запомнить и между ними не было дублирования. В качестве ориентира
можно пройтись по одной из самых обширных коллекций.
2.
ВИЗУАЛЬНЫЙ ЯЗЫК
Конкретные принципы, лежащие в основе визуального
представления, логики взаимодействия и инфоархитектуры.
Если манифест говорит на уровне ценностей, то основы
дизайна – о конкретных решениях. Для упрощения будущей
жизни платформы нужно стремиться к высокому уровню
абстракции во всех определениях.
ИНФОРМАЦИОННАЯ
АРХИТЕКТУРА
Исходя из специфики продукта и его целевой аудитории, нам
нужно описать принципы разделения функций и сценариев
использования на экраны, выстроить их иерархию и
обеспечить навигацию между ними.
Если мы говорим о линейке продуктов, то они могут
значительно различаться и потребуют различных подходов.
Поэтому полезно описать сразу все:
 одностраничник,
 иерархическая структура,
 линейная,
 сетевая,
 хаб
или комбинация из нескольких.
Каждый из подходов должен иметь своего рода мини-
манифест – для каких задач используется, как переложить на
него функциональность и сценарии использования продукта.
Причем ещё лучше, если со всеми нюансами – наименование
категорий и ссылок, описание мета-данных, организационные
схемы (алфавит, география, хронология, тематика, задача,
аудитория, популярность).
ПРИНЦИПЫ ВЗАИМОДЕЙСТВИЯ
Конкретные навигационные решения, реализующие
принципы информационной архитектуры.
 постоянные меню (включая подвал);
 контекстные меню (видимые, по правой кнопке мыши или
долгому нажатию пальцем);
 поиск;
 хлебные крошки;
 инструменты для работы со списками (сортировка,
фильтрация, группировка, постраничная навигация или
подгрузка);
 контекстные провязки контента;
 системы уведомлений и алертов.
Желательно с их иллюстрированным переложением на
модель типового экрана, а также рекомендациями по
решению конкретных продуктовых задач – например,
провязки контента помогают повысить глубину просмотра.
Всё это должно опираться на поддерживаемые типы
устройств – большой и мобильный веб, приложения для
разных платформ (мобильные, планшеты, носимые). Для
каждого из них могут быть свои особенности – специфика
методов управления (мышь, тач, голос), быстрые действия
(горячие клавиши, жесты), обеспечение доступности.
1ИНТЕРФЕЙСНАЯ СЕТКА
Шаг или модуль, по которому выстраиваются все элементы
интерфейса – их размеры и отступы между ними.
Сейчас наиболее популярна 8-пиксельная, ее использует в
том числе Android и Google в целом. iOS базируется на 11-
пиксельной, Windows 8 – 5-пиксельной.
8-пиксельный шаг особенно удобен тем, что хорошо делится
на 2. Например, можно получить 2-пиксельное скругление
блоков.
Базовый шаг определяет типовые расстояния. Мы базируем
наше решение на 4dp вместо 8, поэтому в нашем случае это 4,
8, 16, 24, 32, 48, 96, 128.
Полезно вести измерения в независимых от плотности экрана
пикселях (dp) вместо px.
Дизайнер выбирает размеры не на глаз,
а по единым правилам.
Так что количество споров и ошибок
по мелочам падает на порядок, сильно
меньше расхождений в макетах.
2СТРУКТУРНАЯ СЕТКА
Набор колонок, в которые укладывается основной
лейаут интерфейса.
Очень популярна 12-колоночная сетка, её используют
большинство популярных фреймворков.
Мы используем скорее механизм «ритма» – это набор 40-
пиксельных колонок с 20-пиксельными отступами (16 колонок
для 1024, 20 для 1280, 24 для 1440, 26 для 1600).
Структурная сетка также определяет логику адаптивности –
как лейаут меняется на разных разрешениях.
3ЛЕЙАУТЫ
Конкретика на базе структурной сетки – как будут размещены
рабочие области интерфейса.
 1 колонка, популярная на промо-сайтах?
 2 колонки, классический подход для практически любых
задач?
 3 колонки, всё реже используемые из-за
перегруженности?
 Бесконечный поток карточек или тайлов,
популяризованный Pinterest?
Лейаут может задавать и вертикальные соотношения, хотя это
встречается нечасто.
4КОНТЕЙНЕРЫ
Каждая колонка лейаута – это стек, в котором друг за другом
помещаются контейнеры конкретных блоков с контентом.
Полезно задавать логику внешнего вида (граница, фон, тень,
заголовок и т.п.) и поведения контента на уровне самого
контейнера. Так будет проще развивать платформу, добавляя
новые блоки или корректируя общие принципы.
Например, если элементов в блоке больше, чем можно
отобразить на экране, мы можем добавить ссылку на полный
список на отдельной странице, развернуть их тут же по клику
на «показать ещё», разбить постраничной навигацией или
сделать прокрутку внутри (вертикальную или
горизонтальную).
Если мы выбрали горизонтальную прокрутку и в будущем
захотим переделать стрелки или добавить свайп для тач-
экранов, нам не придется пробегаться по всем копиям
контейнера.
Сюда же стоит отнести и попапы.
*
*
ШРИФТОВАЯ СЕТКА
Есть множество подходов к выбору размеров шрифтов,
основанных на идее масштабирования от базового текста.
Главное, чтобы межстрочное расстояние ложилось в
интерфейсную сетку – тогда и интерфейсный, и наборный
текст не поломают её.
GRIDLOVER
Сервис собрал, кажется, все возможные формулы
масштабирования шрифтов в сетке.
Если ориентироваться на интерфейсную сетку, то размеры
шрифтов должны быть кратны 4. Для заголовков это легко,
хотя на практике есть проблемы с наборным текстом:
 Красивое число 16 для основного текста бывает
великоватым для конкретного интерфейсного решения.
 Особенности рендеринга веб-шрифтов в Windows
заставляют делать много костылей и обходных решений.
ЦВЕТОВАЯ ПАЛИТРА
К основе, которую задают основные цвета бренда, должны
быть прописаны вспомогательные значения.
В дополнение к цветам полезно описать формулы для
построения теней, задать несколько стандартных параметров
прозрачности и размытия фона.
 Интерфейсные цвета – белый и черный (или их оттенки,
если чистые значения не подходят), цвета ошибок и других
системных сообщений (красный, зеленый, желтый), ссылки,
а также линейка серых цветов (подложки, границы,
вспомогательный текст).
 Акцентные – например, для обозначения категорий
контента. Причем для них может быть задана логика
изменения, если нужны вариации (например, недоступные
категории высветляются).
Естественно, все цвета в палитре должны сочетаться с
основными, заданными брендом.
НАБОР ЭЛЕМЕНТОВ УПРАВЛЕНИЯ
Имея интерфейсную и шрифтовую сетку, а также цветовую
палитру, можно системно подойти к работе над базовыми
строительными элементами.
 Кнопки (главная, обычная, с дополнительными опциями;
текстовая, иконочная, версия для в панелей инструментов);
 ссылки;
 общие и специализированные поля ввода и выпадающие
списки (комбо-бокс, календарь, страна с телефонным
кодом и т.п.);
 переключатели (чекбокс, радио-кнопка, тумблер);
 загрузчики пользовательского контента (фото, видео,
файлы).
Для них должны быть заданы состояния: фокус, активное,
наведение, недоступно.
КОМПОНОВКИ ФОРМ
В дополнение к элементам форм нужно описать их
компоновки. Расположение названий полей, пояснительных
текстов к ним, правила валидации значений и отображения
ошибок.
ГРАФИКА И ИЛЛЮСТРАЦИИ
Необходимы стандарты для фото и другой контентной
графики. Пропорции, типовые размеры и их вариации для
разных разрешений. В идеале они должны вписываться в
колоночную сетку. То же самое касается аватаров.
Хорошо, если интерфейсные иконки провязаны с общим
брендингом – можно постепенно развивать их
универсальный набор.
Иллюстрации также должны вписываться в общую канву, но
тут достаточно описать общие подходы к стилистике. Толщина
линий, цветовая палитра, принципы передачи объема,
правила размещения в интерфейсе и промо-материалах.
Крупные иконки-иллюстрации могут основываться на
метафорах интерфейсных пиктограмм, развивая их в большей
детализации, а для среднего размера задать
стандартизированную сетку.
ИНФОГРАФИКА
И ВИЗУАЛИЗАЦИЯ ДАННЫХ
Еще одно направление для стандартизации.
Обширных список всех возможных типов нужен только
узкоспециализированным сервисам, но наиболее
востребованные необходимо описывать всем.
 Таблицы;
 распространенные
диаграммы (круговая,
столбиковая, гистограмма,
линейный график, график
рассеивания);
 более редкие (площадная
диаграмма, кольцевая,
лепестковая, диаграмма
разброса, Венна, Сэнки);
 картография;
 тепловые диаграммы;
 облако тегов;
 графы и деревья;
 плоское дерево;
 ментальные карты;
 блок-схемы и диаграммы
процессов;
 временные шкалы;
 диаграммы связей.
АНИМАЦИОННАЯ МОДЕЛЬ
В идеале переходы между состояниями и экранами
интерфейса должны подчиняться определенной модели. Тогда
анимация будет консистентной, а пользователю будет легче.
Например, попапы могут приезжать сверху экрана и после
закрытия уезжать обратно, а если это пошаговый помощник –
после появления основного окна, новые состояния могут
приезжать справа.
Для примера можно изучить подходы трёх крупных
платформ:
 Android (тонкая оркестровка);
 iOS (до iOS7 и после);
 Windows Phone (родоначальник современного подхода).
РЕКЛАМА
Рекламная сетка зачастую определяет внешний вид, задавая
ограничения сетки дизайнерской.
Важно работать с коммерческим отделом не менее плотно,
чем с разработчиками – это позволит находить форматы, не
рушащие ни дизайн, ни денежный поток проекта.
Нужно определить рекламный инвентарь – виды и размеры
медийных и контекстных блоков, принципы брендирования
блоков и страниц, задать стандарты для компоновки
фулскринов и других агрессивных подходов.
Полезно проработать типовые решения для внутреннего
промо.
Второй шаг – это сетка, по которой реклама размещается на
стандартных лейаутах.
UXPeople 2015: Юрий Ветров — Платформенное мышление
3.
ПРИНЦИПЫ В КОДЕ
После определения основных принципов дизайна платформы
нужно заложить их и в основу CSS. А иконочные шрифты и
SVG-спрайты помогут удобно работать со вспомогательной
графикой.
Дизайнерам крайне важно понимать код, чтобы вместе с
разработчиками выстроить future-friendly систему.
Итоговый дизайн в том или ином виде
определяется на всех этапах продуктовой
разработки и важно не забывать об этом,
если вы хотите работать системно.
ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ
Современные CSS-препроцессоры вроде SASS и Less
позволяют задавать глобальные переменные – это отличный
способ определить основные принципы в коде.
Математика в коде! Чтобы получить кнопку:
o пишем «Сохранить» базовым размером шрифта
+ отмеряем типовые отступы сверху, снизу и по бокам
+ заливаем это пространство стандартным цветом для
подложек кнопок
+ также стандартным цветом очерчиваем обводку
+ подкладываем стандартную тень снизу.
Пока не поменяются константы, эта математика будет приводить
всю команду к одинаковым решениям.
*
*
ТИПОВЫЕ ЛЕЙАУТЫ
Полезно привести в пример структуру типовых страниц на
основе лейаутов. Они включают шапку, подвал, контентную
область, вспомогательные колонки. Это помогает лучше
понимать основы использования гайдлайнов.
БИБЛИОТЕКА
ПАТТЕРНОВ
И ГОТОВЫХ РЕШЕНИЙ
Создание готовых компонентов и перевод
всего дизайна на них.
КОМПОНЕНТЫ
Исходя из цели упрощения производственной цепочки до
«спецификация = дизайн = верстка → реализация»,
компонент – это готовый код с определенным визуальным
стилем, логикой работы и взаимодействия.
Он независим от окружения – мы можем использовать его на
любой странице без опасения, что он сломается.
ТИПОВЫЕ СТРАНИЦЫ
Помимо отдельных решений полезно описать и типовые
страницы, состоящие из стандартизированных компонентов.
Всё, что вы начинаете использовать хотя бы дважды, полезно
перевести в стандартные решения.
ПАТТЕРНЫ 2.0
По сути это и есть классический дизайн-паттерн, которые
дизайнеры обычно собирали в виде библиотек к
инструментам проектирования и дизайна, а после этого
описывали в гайдлайнах.
Только нам не нужно каждый раз проверять качество его
внедрения и поддерживать во всей цепочке артефактов.
А если мы решили изменить паттерн – нужно заменить
оригинал в единой базе кода, после чего он обновится на
всех использующих фреймворк проектах.
Примеры компонентов:
 навигация – вкладки, алфавитный указатель, календарь, поиск
и фильтры, сортировка, история просмотров;
 списки – список, матрица, прокручиваемая лента, асинхронная
тайловая компоновка;
 медиа – видео, инфографика, фотогалерея, пост из социальной
сети;
 информеры – погода, курсы акций и commodities, спортивная
статистика, расписания, гороскопы, мировое время;
 социальное взаимодействие – комментарии, опросы,
консультации, рейтингование, обратная связь, шаринг в
соц.сетях.
ТИПОВЫЕ СТРАНИЦЫ
Помимо отдельных решений полезно описать и типовые
страницы, состоящие из стандартизированных компонентов.
Всё, что вы начинаете использовать хотя бы дважды, полезно
перевести в стандартные решения.
 Список новостей;
 конкретная публикация;
 результаты поиска;
 настройки;
 профиль пользователя;
 авторизация и регистрация;
 «нулевые» состояния;
 серверные ошибки;
 шаблоны писем рассылки.
СЕМАНТИКА КОДА
Важна для описания компонентов. Как в плане отсылки к
базовым принципам – паттерн использует не конкретное
значение «шрифт 24 размера» или «подложка цвета #F0F0F0»,
а смысл – «заголовок 2 уровня» или «подложка для карточек».
Так и в смысле общего назначения – основной контент,
информация по теме, дополнительные обвязки.
Тогда сработает идея с легким обновлением по линейке продуктов.
*
*
УНИФИКАЦИЯ
ИЛИ УНЫЛИЗАЦИЯ?
Если запускать все продукты на базе одних и тех же
компонентов, то помимо унификации мы получим еще и
унылизацию – сервисы выглядят однояйцевыми.
Поэтому платформа должна давать возможность стилизации
продуктов без изменения общих принципов работы
компонентов.
ПРИМЕР СТИЛИЗАЦИИ
Мы выбрали идею акцентных цветов – каждый сервис имеет свой цвет,
что позволяет выделить его из общей линейки. Могут сработать разные
шрифты, декоративные элементы, иллюстрации и иконки.
ЖИВОЙ ГАЙДЛАЙН
По сути, еще один проект на платформе.
АКТУАЛЬНОСТЬ 100%
Контроль качества всей продуктовой линейки радикально
упрощается – дизайнер следит только за референсным
паттерном.
Вначале описываются общие принципы, которые мы
извлекаем из основного CSS.
После этого – готовые компоненты, которые уже
используются в работающих продуктах. К каждому из них
дизайнер должен дать описание – для чего и в каких
ситуациях он используется.
Даже если вы строите упрощенную систему в духе Bootstrap,
первый шаг уже здорово поможет в систематизации работы.
ЭТА ССЫЛКА ТУТ БУДЕТ ЧАСТО :)
И снова сошлюсь на styleguides.io – огромная коллекция
инструментов для создания живых гайдлайнов.
АВТОЛЕЧЕНИЕ
Раз в неделю или месяц скрипт проходит по всем продуктам и
сравнивает использующиеся в их CSS параметры с
референсными.
Если обнаружены расхождения – дизайнер получает список
проблемных мест.
ПРОТОТИПИРОВАНИЕ
Когда все компоненты платформы
запущены и работают, можно еще больше
упростить рабочий процесс.
МЕНЬШЕ ПРОКЛАДОК
Там где это уместно, нужно отбросить инструменты для
создания статических wireframes и макетов.
Если живой гайдлайн рядом с примером компонента будет
выводить его HTML-код, несложно собрать готовую верстку
страницы в HTML-редакторе на основе шаблонов типовых
лейаутов.
ФОТОШОП ДЛЯ ЛОХОВ РЕЖЕ
Многие дизайнеры уже не боятся кода. Сейчас полным-полно
понятных обучалок и готовых примеров, да и сами HTML и
CSS простые до безобразия.
Фотошоп и подобные инструменты отлично работают для
поиска стилистических направлений. Но без перехода к
дизайну в браузере работать становится все сложнее.
AXURE В ИНТЕРНЕТЕ
Если у компании достаточно ресурсов и платформа устоялась,
можно пойти дальше и собрать онлайн-инструмент для
визуального прототипирования.
Дизайнер или менеджер перетаскивает готовые компоненты
на страницу и получает интерактивный прототип.
КОНСТРУКТОР PROJECT POLYMER
Для платформы Google есть демо-конструктор, в котором
можно собрать адаптивный интерфейс в гайдлайнах material.
https://polymer-designer.appspot.com/
НА БАЗЕ BOOTSTRAP
Есть много сервисов, позволяющих собирать страницы
проектов на Bootstrap в браузере.
РЕАЛЬНЫЕ И АКТУАЛЬНЫЕ
ДАННЫЕ
Ответственные дизайнеры отучились вставлять “lorem ipsum”,
но это требует некоторой ручной работы.
Много сил отнимает проработка краевых состояний и легкая
подстановка данных в прототип позволит быстрее проверять
их.
КОММУНИКАЦИЯ ПРОЩЕ
Помимо того что дизайн становится дешевле и плодит
меньше рассинхронизации, живой прототип лучше работает
как инструмент коммуникации.
Страницы можно провязать друг с другом, работает вся
логика и скрипты публичной версии продукта, задана
адаптивность.
ЭКСПЕРИМЕНТЫ
Поиск лучших дизайн-решений среди
множества альтернатив.
ВСТРОЕННЫЕ A/B-ТЕСТЫ
Дизайн-паттерны, используемые в платформе, не
определяются раз и навсегда – мы всегда должны искать
более удачные решения.
Здорово, если платформа позволяет делать это системно и
недорого, облегчая проведение юзабилити- и A/B-тестов.
Идеи для них могут идти от:
 найденных проблем;
 целей по росту продуктовых показателей;
 интересных подходов у конкурентов;
 общей потребности регулярного тюнинга дизайна.
АРХИВ РЕШЕНИЙ
Старые версии блоков можно сохранять, в идеале – указывая
в каждом из них результаты и детали эксперимента.
Тогда можно будет изучать, как и почему они работали (или
не работали) раньше и находить инсайты для будущих
улучшений.
КУМУЛЯТИВНЫЙ ЭФФЕКТ
Сама идеология платформы предполагает, что каждый проект
получает актуальную версию компонента из единой базы
кода.
Так что оптимизированный в ходе тестирования вариант
быстро распространится по всей линейке и прокачает
показатели всего бизнеса.
АЛГОРИТМИЧЕСКИЙ
ДИЗАЙН?
Последние годы периодически
встречается для построения экранов
интерфейса.
ДИЗАЙН АЛГОРИТМОВ
Дизайнер и разработчик описывают логику обработки
входящих сигналов – контента, контекста, информации о
пользователе и его действиях, а дальше платформа сама
формирует дизайн на основе готовых паттернов и принципов.
ТОНКАЯ ПОДСТРОЙКА
Это позволяет добиться тонкой подстройки под конкретную
узкую ситуацию без необходимости вручную прорисовывать
и разрабатывать десятки состояний экрана.
АВТОМАТИЗИРОВАННАЯ
ЖУРНАЛЬНАЯ ВЕРСТКА
Мы описывали для одного из проектов. Контент не имел
семантики, а переверстать архив вручную – затратно. Скрипт
разбирал статью и исходя из её контента (количество абзацев и
слов в каждом, фотографии и их форматы, врезки с цитатами и
таблицами и т.п.) выбирал типовой паттерн для представления
каждого куска в эффектном журнальном виде. И следил, чтобы
паттерны чередовались и материал не выглядел однообразно.
DUPLO
Похожую модель недавно реализовал Flipboard.
THE GRID
CMS, которая самостоятельно подбирает шаблоны, оформление
контента, обрабатывает фотографии. Причем еще и проводит A/B-
тесты разных подходов для выбора лучшего решения.
ПАРАМЕТРИЧЕСКИЕ ШРИФТЫ
Дают дизайнерам большую гибкость работы и новые
возможности. Пример – Robofont.
КОГДА ЖДАТЬ ПРИХОДА?
Подход не то что не устоялся – даже обсуждается редко. Но
может здорово помочь в будущем для действительно
прорывных решений.
И это будет еще одним уровнем зрелости дизайн-платформы.
НАШ ОПЫТ
DOUBLE KILL
Мы идем по этому пути и уже построили на собственной
платформе две группы проектов из пяти – мобильный веб и
контент-проекты.
Процесс создания и внедрения фреймворка может быть
извилистым.
1.
СОЗДАНИЕ МОДЕЛЬНОГО
ДИЗАЙНА И ФРЕЙМВОРКА
Необходимо найти подходящее для наших продуктов и
масштабируемое интерфейсное решение, определиться со
стилистикой и реализовать техническую часть фреймворка.
2.
ПЕРЕВОД ВСЕХ ПРОДУКТОВ
НА ПЛАТФОРМУ
Библиотека паттернов и единая база кода активно
расширяются за счет новых решений, а бек-энд сервисов
приводится в соответствие с требованиями фреймворка.
3.
УПРОЩЕНИЕ ДИЗАЙН-ПРОЦЕССА
Техническое решение уже обкатано и основные задачи
решены, поэтому от создания множества артефактов можно
отказаться и собирать новые экраны из готовых блоков в
единой базе кода.
4.
РЕФАКТОРИНГ ДИЗАЙНА
Запуск десятка продуктов занимает достаточно внушительное
время, за которое выявляются проблемы в реальной жизни
сервисов. Да и дизайнерские тренды меняются.
МЫ В ПУТИ
Сейчас у нас параллельно идут третий и четвертый этап
внедрения фреймворка. Но плюсы работы с ним мы ощутили
уже в самом начале – количество лишней постоянно
снижается.
ПРИМЕНИМО И ДЛЯ МОБИЛЬНЫХ
Описанная компонентная модель предназначена для веба.
Мы думали о её применении для мобильных приложений –
в этом случае компонентами служат бандлы, т.е.
распространяемые библиотеки с уже зашитым дизайном. Но
пока что сфокусировались на веб-сервисах.
ЕСТЬ СВОИ ПРОБЛЕМЫ
Оглядываясь назад, мы наверняка смогли бы сделать процесс
создания и внедрения фреймворка правильнее и короче. Но
я рассказал о наших правильных и ошибочных решениях в
деталях, чтобы вы смогли пройти этот путь быстрее.
ЗАКРУЧИВАТЬ ГАЙКИ
В развитии гайдлайнов нужен некоторый авторитаризм,
который поможет не пропускать несистемных решений. Если
это возможно – нужно всегда использовать готовые паттерны.
Если вводится что-то новое – нужно пробовать подвести под
это решение уже реализованные проекты или понимать, где
оно пригодится в будущем.
Только тогда платформа не расползется и консистентность
портфеля продуктов сохранится. А значит сохранятся и
удобство развития этих продуктов, их комфортность для
пользователя и положительный эффект для всего бренда.
ЧУЖИЕ ПРИМЕРЫ
ДОСТУПНО НЕ ТОЛЬКО КРУПНЯКУ
Bootstrap и Foundation отлично решают часть задач –
описание принципов дизайна в коде,
живые гайдлайны, прототипирование.
НА САМОМ ДЕЛЕ НЕТ?
Они не дают всех преимуществ компонентной модели, когда
обновление линейки продуктов значительно упрощается.
Но это в любом случае дешевый способ начать свою
платформу. Тем более, что вам предстоит решить ещё уйму
задач – перевести продукты на новую технологическую базу,
перестроить рабочий процесс.
ANNA DEBENHAM
Одна из пионеров в создании живых
гайдлайнов. Ведет сильную коллекцию
готовых решений, статей и примеров –
рекомендую каждому прочитать её от
корки до корки.
BRAD FROST
Brad Frost, идеолог концепции Atomic
Design, пишет книгу на эту тему. На его
сайте доступны некоторые части из неё, и
главы потихоньку пополняются.
ЧИТАТЬ ОТ КОРКИ ДО КОРКИ!
Грандиозная коллекция ресурсов на тему живых гайдлайнов и
компонентных систем. Лучше любой книжки!
ЧТО В ИТОГЕ?
Уверен:
Любая современная UX-стратегия должна
строиться на похожих принципах, иначе в
долгосрочной перспективе всё будет
плохо.
Хотите заложить хорошую основу для
продукта или целой линейки продуктов?
Забудьте про статические гайдлайны и
библиотеки паттернов. Это лишний этап
работ, еще один промежуточный артефакт
и источник дополнительных трудозатрат.
Ускорение и удешевление вывода на рынок новых
возможностей продукта.
Гарантированный способ получить унифицированный дизайн
и сохранить единство в будущем.
Более частые и системные эксперименты с дизайн-
решениями.
От улучшения в одном продукте выигрывают и остальные.
Дизайнер меньше работает руками и больше – головой.
УХОДИМ
ОТ ГЕРОИЧЕСКИХ РЕДИЗАЙНОВ
Переход к постоянно актуальному интерфейсу. Больше
времени можем уделить на продуктовую работу, а не
бесконечное обслуживание дизайна.
При этом специалист становится продуктовым дизайнером,
который перестает мыслить макетами и выходит за рамки
Фотошопа.
P.S.Только не надо бросаться в крайности! Любой новый подход к
работе не отменяет, а дополняет и видоизменяет старые.
Глупо кричать о том, что передовые дизайнеры работают в
только браузере, а все кто остался в Фотошопе – старые деды.
Но и оставаться зажатыми в рамках классических
инструментов – хоронить свою карьеру.
Надеюсь, это не про вас :)
*
*
CREDITS: ДИЗАЙН
ЕВГЕНИЙ БЕЛЯЕВ
ЮРИЙ ВЕТРОВ
МАРИЯ БОБРОВА
АРТЕМ ГЛАДКОВ
ГЕВОРГ ГЛЕЧЯН
КОНСТАНТИН ЗУБАНОВ
АЛЕКСАНДР КИРОВ
ЕВГЕНИЙ ДОЛГОВ
АЛЕКСЕЙ КАНДАУРОВ
ДМИТРИЙ ОСАДЧУК
АЛЕКСЕЙ СЕРГЕЕВ ПАВЕЛ СКРИПКИН
ЕВГЕНИЙ ФЕРУЛЕВ
CREDITS: РАЗРАБОТКА
АЛЕКСАНДР БЕКБУЛАТОВ
ДМИТРИЙ БЕЛЯЕВ
СТАНИСЛАВ МИХАЛЬСКИЙ
СЕРГЕЙ НОЖКИН
ВИТАЛИЙ ВАСИН
ПАВЕЛ ВДОВЦЕВ
КОНСТАНТИН ВОРОЖЕЙКИН
АНТОН ПОЛЕЩУК
БОРИС РЕБРОВ
ПАВЕЛ РЫБИН
АНТОН ЕПРЕВ
ЕВГЕНИЙ ИВАНОВ
МАКСИМ ТРУСОВ
АРСТАН ТОРЕГОЖИН
АНДРЕЙ КУСИМОВ ПАВЕЛ ЩЕРБИНИН
СПАСИБО!
ЮРИЙ ВЕТРОВ
www.jvetrau.com twitter.com/jvetrau

Más contenido relacionado

La actualidad más candente

分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司
分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司
分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司schoowebcampus
 
0528 kanntigai ui_ux
0528 kanntigai ui_ux0528 kanntigai ui_ux
0528 kanntigai ui_uxSaori Matsui
 
Lean UX, Уровни UX, UXD процесс
Lean UX, Уровни UX, UXD процессLean UX, Уровни UX, UXD процесс
Lean UX, Уровни UX, UXD процессMitya Osadchuk
 
UIデザインの基本
UIデザインの基本UIデザインの基本
UIデザインの基本Roy Kim
 
The Guide To Wireframing
The Guide To WireframingThe Guide To Wireframing
The Guide To WireframingLewis Lin 🦊
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門陽一 滝川
 
UX Design + UI Design: Injecting a brand persona!
UX Design + UI Design: Injecting a brand persona!UX Design + UI Design: Injecting a brand persona!
UX Design + UI Design: Injecting a brand persona!Jayan Narayanan
 
ワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うな
ワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うなワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うな
ワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うなYoshiki Hayama
 
ITエンジニアに易しいUI/UXデザイン
ITエンジニアに易しいUI/UXデザインITエンジニアに易しいUI/UXデザイン
ITエンジニアに易しいUI/UXデザインRoy Kim
 
そのあとの「デザイン」
そのあとの「デザイン」そのあとの「デザイン」
そのあとの「デザイン」Mari Kimura
 
멘탈모델 1-3장 자료
멘탈모델 1-3장 자료멘탈모델 1-3장 자료
멘탈모델 1-3장 자료beom kyun choi
 
デザイン仕様書(ガイド)の書き方 (初歩者用)
デザイン仕様書(ガイド)の書き方 (初歩者用)デザイン仕様書(ガイド)の書き方 (初歩者用)
デザイン仕様書(ガイド)の書き方 (初歩者用)witstudio
 
アプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClip
アプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClipアプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClip
アプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomCliptakaaya
 
UI設計の土台になる考え方-インテリジェントネット社内勉強会
UI設計の土台になる考え方-インテリジェントネット社内勉強会UI設計の土台になる考え方-インテリジェントネット社内勉強会
UI設計の土台になる考え方-インテリジェントネット社内勉強会INI株式会社
 
自律的なチームを作る
自律的なチームを作る自律的なチームを作る
自律的なチームを作るYuki Kanaya
 

La actualidad más candente (20)

分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司
分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司
分かりやすく、使いやすいデザインを生み出す工夫 先生:池田 拓司
 
0528 kanntigai ui_ux
0528 kanntigai ui_ux0528 kanntigai ui_ux
0528 kanntigai ui_ux
 
デザイン思考入門クラス【2016年1月30日】
デザイン思考入門クラス【2016年1月30日】デザイン思考入門クラス【2016年1月30日】
デザイン思考入門クラス【2016年1月30日】
 
Lean UX, Уровни UX, UXD процесс
Lean UX, Уровни UX, UXD процессLean UX, Уровни UX, UXD процесс
Lean UX, Уровни UX, UXD процесс
 
Android
AndroidAndroid
Android
 
UXとユーザビリティ計測
UXとユーザビリティ計測UXとユーザビリティ計測
UXとユーザビリティ計測
 
UIデザインの基本
UIデザインの基本UIデザインの基本
UIデザインの基本
 
The Guide To Wireframing
The Guide To WireframingThe Guide To Wireframing
The Guide To Wireframing
 
UX / UIデザインって何?
UX / UIデザインって何?UX / UIデザインって何?
UX / UIデザインって何?
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
UX Design + UI Design: Injecting a brand persona!
UX Design + UI Design: Injecting a brand persona!UX Design + UI Design: Injecting a brand persona!
UX Design + UI Design: Injecting a brand persona!
 
ワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うな
ワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うなワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うな
ワークショップのアイデア発想で「AIでユーザーに最適な情報を出します」とか言うな
 
ITエンジニアに易しいUI/UXデザイン
ITエンジニアに易しいUI/UXデザインITエンジニアに易しいUI/UXデザイン
ITエンジニアに易しいUI/UXデザイン
 
そのあとの「デザイン」
そのあとの「デザイン」そのあとの「デザイン」
そのあとの「デザイン」
 
멘탈모델 1-3장 자료
멘탈모델 1-3장 자료멘탈모델 1-3장 자료
멘탈모델 1-3장 자료
 
デザイン仕様書(ガイド)の書き方 (初歩者用)
デザイン仕様書(ガイド)の書き方 (初歩者用)デザイン仕様書(ガイド)の書き方 (初歩者用)
デザイン仕様書(ガイド)の書き方 (初歩者用)
 
UX Design Process
UX Design ProcessUX Design Process
UX Design Process
 
アプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClip
アプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClipアプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClip
アプリを生み出す現場でUI/UXデザイナーが意識するべきこと:RoomClip
 
UI設計の土台になる考え方-インテリジェントネット社内勉強会
UI設計の土台になる考え方-インテリジェントネット社内勉強会UI設計の土台になる考え方-インテリジェントネット社内勉強会
UI設計の土台になる考え方-インテリジェントネット社内勉強会
 
自律的なチームを作る
自律的なチームを作る自律的なチームを作る
自律的なチームを作る
 

Destacado

CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуреCodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуреYury Vetrov
 
Стачка! 2016: Юрий Ветров — Дизайн с выхлопом
Стачка! 2016: Юрий Ветров — Дизайн с выхлопомСтачка! 2016: Юрий Ветров — Дизайн с выхлопом
Стачка! 2016: Юрий Ветров — Дизайн с выхлопомYury Vetrov
 
UX Poland 2014: Y.Vetrov — Applied UX Strategy
UX Poland 2014: Y.Vetrov — Applied UX StrategyUX Poland 2014: Y.Vetrov — Applied UX Strategy
UX Poland 2014: Y.Vetrov — Applied UX StrategyYury Vetrov
 
Юрий Ветров — Алгоритмический дизайн
Юрий Ветров — Алгоритмический дизайнЮрий Ветров — Алгоритмический дизайн
Юрий Ветров — Алгоритмический дизайнYury Vetrov
 
Interaction designers vs algorithms
Interaction designers vs algorithmsInteraction designers vs algorithms
Interaction designers vs algorithmscxpartners
 
UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...
UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...
UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...Yury Vetrov
 
WUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного веба
WUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного вебаWUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного веба
WUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного вебаYury Vetrov
 
Amuse UX 2015: Y.Vetrov — Platform Thinking
Amuse UX 2015: Y.Vetrov — Platform ThinkingAmuse UX 2015: Y.Vetrov — Platform Thinking
Amuse UX 2015: Y.Vetrov — Platform ThinkingYury Vetrov
 
UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...
UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...
UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...UX STRAT
 
А.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияА.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияAnatoly Levenchuk
 
Design in Tech Report 2017
Design in Tech Report 2017Design in Tech Report 2017
Design in Tech Report 2017John Maeda
 

Destacado (11)

CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуреCodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
CodeFest2015: Ю.Ветров — От дизайн-команды к дизайн-культуре
 
Стачка! 2016: Юрий Ветров — Дизайн с выхлопом
Стачка! 2016: Юрий Ветров — Дизайн с выхлопомСтачка! 2016: Юрий Ветров — Дизайн с выхлопом
Стачка! 2016: Юрий Ветров — Дизайн с выхлопом
 
UX Poland 2014: Y.Vetrov — Applied UX Strategy
UX Poland 2014: Y.Vetrov — Applied UX StrategyUX Poland 2014: Y.Vetrov — Applied UX Strategy
UX Poland 2014: Y.Vetrov — Applied UX Strategy
 
Юрий Ветров — Алгоритмический дизайн
Юрий Ветров — Алгоритмический дизайнЮрий Ветров — Алгоритмический дизайн
Юрий Ветров — Алгоритмический дизайн
 
Interaction designers vs algorithms
Interaction designers vs algorithmsInteraction designers vs algorithms
Interaction designers vs algorithms
 
UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...
UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...
UXRussia2014: Юрий Ветров ― Burger-Driven Design. Фреймворк Mail.Ru для унифи...
 
WUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного веба
WUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного вебаWUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного веба
WUD2013: Юрий Ветров — Унификация, vol. 1. Фреймворк Mail.Ru для мобильного веба
 
Amuse UX 2015: Y.Vetrov — Platform Thinking
Amuse UX 2015: Y.Vetrov — Platform ThinkingAmuse UX 2015: Y.Vetrov — Platform Thinking
Amuse UX 2015: Y.Vetrov — Platform Thinking
 
UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...
UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...
UX STRAT USA: Dr Jeffrey Onken, "Experience Mapping UX Change Management In L...
 
А.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектированияА.Левенчук -- Будущее проектирования
А.Левенчук -- Будущее проектирования
 
Design in Tech Report 2017
Design in Tech Report 2017Design in Tech Report 2017
Design in Tech Report 2017
 

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

Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...
Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...
Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...WG_ Events
 
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)SPECIA
 
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Sasha Kutsenko
 
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ... "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...Lead Zeppelin
 
Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...
Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...
Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...Yandex
 
Форум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.Ru
Форум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.RuФорум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.Ru
Форум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.RuYury Vetrov
 
Развитие интерфейса через гайдлайны
Развитие интерфейса через гайдлайныРазвитие интерфейса через гайдлайны
Развитие интерфейса через гайдлайныtfmailru
 
О разработке сайтов в целом
О разработке сайтов в целомО разработке сайтов в целом
О разработке сайтов в целомUplab_University
 
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)Ontico
 
Useful meetup#1 design sprint
Useful meetup#1 design sprintUseful meetup#1 design sprint
Useful meetup#1 design sprintusefulagency
 
Основы быстрого прототипирования
Основы быстрого прототипированияОсновы быстрого прототипирования
Основы быстрого прототипированияMitya Osadchuk
 
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, команда
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, командаUser Experience 2012: Как меняется Mail.Ru — Продукты, процессы, команда
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, командаYury Vetrov
 
вольфсон построение собственного Agile-фреймворка (шаблон)
вольфсон   построение собственного Agile-фреймворка (шаблон)вольфсон   построение собственного Agile-фреймворка (шаблон)
вольфсон построение собственного Agile-фреймворка (шаблон)Magneta AI
 
Дизайн-команда в продуктовой компании
Дизайн-команда в продуктовой компанииДизайн-команда в продуктовой компании
Дизайн-команда в продуктовой компанииCodeFest
 
Тренды в дизайне корпоративных систем 2017
Тренды в дизайне корпоративных систем 2017Тренды в дизайне корпоративных систем 2017
Тренды в дизайне корпоративных систем 2017Alexei Boronnikov
 

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

Основы разработки сайтов by Uplab
Основы разработки сайтов by UplabОсновы разработки сайтов by Uplab
Основы разработки сайтов by Uplab
 
Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...
Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...
Юрий Ветров - Продуктовый дизайнер. Современное понимание профессии - Mail.Ru...
 
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
“Спецификация формы и поведения”. Саша Куценко, Aidem. (29.01.2014)
 
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"
 
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ... "Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
"Написание спецификации формы и поведения: зачем, кому и как." Саша Куценко ...
 
Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...
Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...
Юрий Ветров "Как планируется работа команды проектирования и дизайна интерфей...
 
Форум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.Ru
Форум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.RuФорум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.Ru
Форум Технологий Mail.Ru 2011: Юрий Ветров — Как создаются интерфейсы в Mail.Ru
 
Развитие интерфейса через гайдлайны
Развитие интерфейса через гайдлайныРазвитие интерфейса через гайдлайны
Развитие интерфейса через гайдлайны
 
О разработке сайтов в целом
О разработке сайтов в целомО разработке сайтов в целом
О разработке сайтов в целом
 
Internet Trends
Internet TrendsInternet Trends
Internet Trends
 
Internet Trends
Internet TrendsInternet Trends
Internet Trends
 
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
 
Useful meetup#1 design sprint
Useful meetup#1 design sprintUseful meetup#1 design sprint
Useful meetup#1 design sprint
 
Agile testing
Agile testingAgile testing
Agile testing
 
Основы быстрого прототипирования
Основы быстрого прототипированияОсновы быстрого прототипирования
Основы быстрого прототипирования
 
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, команда
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, командаUser Experience 2012: Как меняется Mail.Ru — Продукты, процессы, команда
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, команда
 
вольфсон построение собственного Agile-фреймворка (шаблон)
вольфсон   построение собственного Agile-фреймворка (шаблон)вольфсон   построение собственного Agile-фреймворка (шаблон)
вольфсон построение собственного Agile-фреймворка (шаблон)
 
Дизайн-команда в продуктовой компании
Дизайн-команда в продуктовой компанииДизайн-команда в продуктовой компании
Дизайн-команда в продуктовой компании
 
UX Design Рrocess
UX Design РrocessUX Design Рrocess
UX Design Рrocess
 
Тренды в дизайне корпоративных систем 2017
Тренды в дизайне корпоративных систем 2017Тренды в дизайне корпоративных систем 2017
Тренды в дизайне корпоративных систем 2017
 

Más de Yury Vetrov

Yury Vetrov — Algorithm-Driven Design
Yury Vetrov — Algorithm-Driven DesignYury Vetrov — Algorithm-Driven Design
Yury Vetrov — Algorithm-Driven DesignYury Vetrov
 
Как работают британские дизайн-студии
Как работают британские дизайн-студииКак работают британские дизайн-студии
Как работают британские дизайн-студииYury Vetrov
 
UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2
UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2
UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2Yury Vetrov
 
UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1
UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1
UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1Yury Vetrov
 
WUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигевать
WUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигеватьWUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигевать
WUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигеватьYury Vetrov
 
DesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.Ru
DesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.RuDesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.Ru
DesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.RuYury Vetrov
 
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft Carrier
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft CarrierWUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft Carrier
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft CarrierYury Vetrov
 
WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...
WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...
WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...Yury Vetrov
 
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...Yury Vetrov
 
IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...
IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...
IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...Yury Vetrov
 
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...Yury Vetrov
 
User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...
User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...
User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...Yury Vetrov
 
Software People 2010: Форматы работы команды проектирования интерфейсов с кли...
Software People 2010: Форматы работы команды проектирования интерфейсов с кли...Software People 2010: Форматы работы команды проектирования интерфейсов с кли...
Software People 2010: Форматы работы команды проектирования интерфейсов с кли...Yury Vetrov
 
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
 
Software People 2009: Управление ожиданиями от процесса проектирования интерф...
Software People 2009: Управление ожиданиями от процесса проектирования интерф...Software People 2009: Управление ожиданиями от процесса проектирования интерф...
Software People 2009: Управление ожиданиями от процесса проектирования интерф...Yury Vetrov
 
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...Yury Vetrov
 
UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...
UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...
UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...Yury Vetrov
 
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...Yury Vetrov
 

Más de Yury Vetrov (18)

Yury Vetrov — Algorithm-Driven Design
Yury Vetrov — Algorithm-Driven DesignYury Vetrov — Algorithm-Driven Design
Yury Vetrov — Algorithm-Driven Design
 
Как работают британские дизайн-студии
Как работают британские дизайн-студииКак работают британские дизайн-студии
Как работают британские дизайн-студии
 
UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2
UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2
UX-Марафон 2016: Ю.Ветров — Дайджест продуктового дизайна, выпуск 2
 
UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1
UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1
UX-Марафон 2015: Ю.Ветров — Дайджест продуктового дизайна, выпуск 1
 
WUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигевать
WUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигеватьWUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигевать
WUD2014: Ю.Ветров — Фоновые исследования. Как много читать, знать и не офигевать
 
DesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.Ru
DesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.RuDesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.Ru
DesignCamp2012: Юрий Ветров — Метро-дизайн в Mail.Ru
 
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft Carrier
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft CarrierWUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft Carrier
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft Carrier
 
WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...
WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...
WUD2011: Юрий Ветров — Design Thinking. Тренинг от Stanford d.School для Mail...
 
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...
 
IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...
IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...
IT2Days:Usability / UXRussia Junior: Всемирная история интерфейсов. 1001 прод...
 
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
 
User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...
User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...
User Experience 2010: Как показывать интерфейс клиенту (так, чтобы не было му...
 
Software People 2010: Форматы работы команды проектирования интерфейсов с кли...
Software People 2010: Форматы работы команды проектирования интерфейсов с кли...Software People 2010: Форматы работы команды проектирования интерфейсов с кли...
Software People 2010: Форматы работы команды проектирования интерфейсов с кли...
 
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...
 
Software People 2009: Управление ожиданиями от процесса проектирования интерф...
Software People 2009: Управление ожиданиями от процесса проектирования интерф...Software People 2009: Управление ожиданиями от процесса проектирования интерф...
Software People 2009: Управление ожиданиями от процесса проектирования интерф...
 
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...
 
UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...
UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...
UXRussia 5: Юзабилити-экспертиза в прямом эфире (Юрий Ветров, Александр Хмеле...
 
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
РИТ: Клиентские технологии 2008: Case Study: Проектирование делового портала ...
 

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

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