UX-стратегія на практиці. Частина 3 — Платформенне мислення

UX-стратегія на практиці. Частина 3 — Платформенне мислення
У перших частинах серії статей про UX-стратегії я описав її загальне бачення і дизайнера, який нам потрібен для системного розвитку UX. Що має бути результатом його роботи?

Багато хто звик думати навколо артефактів і процесу їх створення та узгодження. Ми досліджуємо користувачів і ринок, продумуємо сценарії і инфоархитектуру, робимо скетчі і прототипи, готуємо дизайн-макети і гайдлайны, віддаємо їх у розробку. А після всього цього дивимося що вийшло на практиці і вносимо доопрацювання до тих пір, поки не досягнемо відповідності продукту ринку і потрібного рівня якості. Підхід в цілому правильний, але в класичних схемах з околоконвейерным процесом він спалює багато часу на артефакти. Все це розмиває фокус і відповідальність — багато сил витрачається на поліровку побічних документів, а не самого продукту. А оскільки більша частина цих талмудів потрібна тільки для передачі знань між учасниками продуктової команди і швидко застаріває, отримуємо ще і високі транзакційні витрати. Так не годиться.

У цій статті я розповім про те, як перестати мислити документацією і перейти до платформному мислення. Дизайнерам потрібно сприймати свою роботу не як тимчасовий проект по запуску нового дизайну або конкретної функціональності, а як висновок на ринок і розвиток цілісної платформи. Тоді продукт буде рости системно, а UX-стратегія компанії запрацює на всіх рівнях — оперативному, тактичному і стратегічному.

Модель зрілості UX. Стратегічний рівень

Системний підхід до UX продукту
Класичне рішення для системного розвитку продуктів — це гайдлайны і бібліотеки патернів. Вони описують типові інтерфейсні рішення, які зустрічаються при роботі над продуктовою лінійкою. А також правила їх використання та інші деталі, які допомагають дизайнерам, менеджерам, розробникам і тестувальникам домагатися консистентности між екранами, продуктами і командами. Ну і, звичайно ж, здешевлювати і прискорювати розробку за рахунок використання готових рішень. Вони критичні для великих компаній, але однаково корисні для середніх і малих організацій з усталеними продуктами. Та й користувачам консистентним і звичність підвищує комфорт.

Але гайдлайны у звичному розумінні   ще один статичний артефакт, який вимагає проходження рішення щодо додаткового кроку. Народжується ланцюжок «гайдлайн → макет → верстка → реалізація», на кожному з етапів якої втрачаються деталі й генеруються баги. Це дає ряд проблем:

  • Дизайнери часто кажуть, що документацію не читають розробники. Але й самі вони, чесно кажучи, теж ухиляються, якщо синхронізуватися повинні декілька чоловік.
  • Дизайн по специфікації складно реалізувати на 100%, якщо це робиться відразу для декількох продуктів. По-перше, специфікація сама по собі вимагає регулярного оновлення — з'являються нові патерни або знаходяться більш вдалі рішення для вже наявних. По-друге, по ходу редизайну що можуть не встигнути реалізувати і сервіс запускається «майже відполірованим». А вся лінійка продуктів — «майже схожою». І що тоді вважати референсним дизайном? Звичайно, можна провести переформатування, але він виявляється дорогим — його потрібно постійно проводити для кожного продукту.
  • Усе це вимагає величезних зусиль і вільного часу від дизайнера на контроль якості реалізації. Що дорого і втомлює. Не кажучи вже про рутині з регулярною відображенням одних і тих же речей.
  • Оновлення дизайну посилюють проблему. Треба знову йти по всій лінійці — переробляти і контролювати, переробляти і контролювати...
  • Експерименти з дизайном також недешеві. Вони також змушують генерувати побічні артефакти і в результаті посилюють ентропію.


Адок! І це ми ще не говоримо про важливі «нюанси» начебто адаптивного дизайну… Багато в цьому випадку наймають більше дизайнерів. Але ті, хто мислить системно, намагаються знайти рішення на стику дизайну і технологій. Тільки переносячи референсний дизайн з статичної документації на рівень реалізації, можна скоротити ланцюжок до «гайдлайн = дизайн = верстка → реалізація». А значить позбутися від купи геморою по впровадженню, покращення та підтримки продуктів.

Дизайнерсько-технологічна уніфікація
В цю сторону вже йдуть багато великі компанії, що сильно спрощує їм життя і розв'язує руки у розвитку бізнесу. Хороший дизайн можна і потрібно отримувати дешево і швидко, чого неможливо добитися при роботі руками. Яким може бути це технічне рішення? Є два варіанти: простіше, коли ви робите свій маленький Bootstrap і складніше, створюючи повноцінну систему компонентів.

Перший варіант дешевше і швидше у створенні — ви вже отримуєте профіт від полегшення підтримки, недорогих експериментів з дизайном і легкого прототипування. Хоча, по суті, ви просто використовуєте набір HTML/CSS-стилів, який може зламатися при використанні в реальному продукті. За останні кілька років вийшло багато візіонерських статей на цю тему — наприклад, від Mark Otto і Dave Rupert, величезна кількість компаній вже працює за таким принципом.

speakerdeck.com/mdo/build-your-own-bootstrap

Другий варіант дорожче у створенні, зате на виході у вас гарантована якість реалізації дизайну і всі бенефіти від простоти оновлення продуктів. Ми в Mail.Ru Group пішли саме в цю сторону. У такого підходу 5 рівнів зрілості:

  1. Визначені і зашиті в CSS загальні принципи дизайну.
  2. Всі продукти працюють на основі єдиних компонентів.
  3. Є живі гайдлайны, що описують принципи дизайну і єдині компоненти. Вони показують реалізацію, а не скріншоти.
  4. Можна прототипировать сторінки на основі живих гайдлайнов.
  5. Експерименти з дизайном компонентів для порівняння різних підходів.


По дорозі готових компонентів йде не так багато компаній, але є дуже потужні приклади від Intuit з їх екосистемою Harmony, рішення Lonely Planet на базі фреймворку Rizzo, Яндекс.Лего і, звичайно ж, Polymer Project від Google, реалізує Material Design.

Екосистема Intuit Harmony
Екосистема Intuit Harmony

Чим гарний такий підхід?
  • Єдиний візуальний стиль і принципи роботи інтерфейсу, а також його інформаційна архітектура. Це зручно для користувача — група схожих продуктів працює однаково зрозуміло і звично. А також добре для бренду — вся лінійка сервісів виглядає цілісною.
  • Уніфікація дизайну на 90% гарантується підходом до розробки — все готові блоки і елементи беруться з єдиної бази коду і тільки з неї. Ще на 10% — уважністю і вдумливістю при використанні готових рішень. Навіть з ідеального конструктора можна зібрати монстра.
  • Спрощення запуску нових продуктів та редизайну існуючих. У фреймворку є більшість необхідних блоків і компонентів на всі випадки життя, що дозволяє швидко зібрати новий інтерфейс.
  • Контролювати великий пул проектів стає простіше, коли вони влаштовані однаково. Замість сотні окремих проектів ви стежите за парою гайдлайнов.
  • Потрібно малювати менше макетів. Сторінку можна зібрати з готових блоків, причому в майбутньому — без запуску Фотошопа. Це ж стосується різних спец.проектів.
  • Кумулятивний ефект від вдалих продуктових рішень. Наприклад, піднявши глибину перегляду на одному з сервісів, легко застосувати ці поліпшення на інші.
  • Перехід від великих редизайнів раз у кілька років до постійного підтримання актуальності інтерфейсу. Перезапуски забирають багато сил і втрачають тисячі дрібних напрацювань, прикручених до дизайну за довгий час його розвитку.


Та й наступний тренд після флет-дизайну підхопити буде легко і швидко :) Звичайно, гонитва за трендами — не сама похвальна затія. Проте в нашій індустрії періодично трапляються досить різкі злами візуальної парадигми, як це було в минулому році з виходом iOS7, і компанії повинні оперативно реагувати на них.

Загалом, це ключова частина нашої UX-стратегії. Але найважливіше — те, що фреймворк став ще і технічної уніфікацією. Ми робили багато підходів до «снаряду» — писали специфікації, збирали єдиний вихідний, робили бібліотеки елементів і т. п. Але все це швидко йшло на спад, тому що знаходилося в затишному дизайнерському світі і було слабо затребуване розробниками. А ми всі знаємо, як часто «перевирается» дизайн на шляху з макетів в реалізацію. Але якщо один раз зробити код правильним і поширюваними — з'явиться впевненість в якості дизайну, що працює в реальному продукті. Тому один з головних критеріїв успішності будь-яких проектів по уніфікації — їх перенесення на рівень конкретної реалізації.

Bill ScottBill Scott розповідав про своє досвід переходу з Netflix в PayPal у схожому ключі. В PayPal з-за технологічних обмежень потрібно півтора місяці для зміни простого текстового блоку на головній сторінці. Це гальмує розвиток дизайну і робить неможливими часті експерименти. Будучи в Netflix, однією з перших своїх завдань він поставив полегшення процесу розробки. В результаті вийшов сильний HTML5-фреймворк, який працює на всьому спектрі підтримуваних пристроїв.
Ми хочемо використовувати не руки, а голову дизайнера. Завдяки зменшенню рутини, є можливість перевести фокус на продуктові завдання і рішення бізнесу, а також менш помітних, але також важливих дизайнерських проблем.

Компанія також в плюсі. За мінусом вхідної ціни за переклад продуктів на платформу, вона отримує системний підхід до підвищення ефективності продуктів, прискорення виведення на ринок нових функцій, гарантовану уніфікацію дизайну. Здатність говорити однією мовою допомогла нам переконати менеджмент вкластися в фреймворк.

Як побудувати свою платформу
Потрібно перестати мислити екранами і сприймати продукт як платформу. Досвід Apple, Google і Microsoft стане в нагоді, навіть якщо ваша компанія не так масштабна і амбітна — вони відмінно досягли успіху в побудові платформ та екосистем. Якщо розібрати їх на основні складові — загальні принципи візуального стилю і взаємодії, набір власних додатків і величезна кількість додатків від сторонніх розробників (вважай, створених партнерами і аутсорсерами) — то можна знайти багато спільного з роботою будь-продуктової компанії.

Android, iOS, Windows Phone
Android, iOS, Windows Phone

Уніфікацію можна починати з двох сторін. Спочатку створити гайдлайн і після цього застосувати його до існуючим продуктам. Або вдало оновити дизайн одного з них і вибрати як референсний, створюючи потім гайдлайн за його мотивами. Плюси і мінуси є в обох підходів.

Ми в компанії йшли другим шляхом. Масштабується вже перевірений на практиці дизайн, оптимізований за допомогою аналітики та досліджень. Адже напередодні та відразу після релізу проводиться безліч експериментів і тестів, після яких дизайн багато разів коригується. Хоча шлях виходить кілька звивистим, тому зараз ми проводимо рефакторинг отриманого і будуємо систему зверху вниз.

Matt McManusMatt McManus каже, що безперервного дизайну два основних принципи. По-перше, відмовитися від поняття «фінального» дизайну. Дизайнери повинні бути залучені в процес розробки, не тільки його початок. По-друге, дизайнери повинні створювати повторно використовуваний фронт-енд код або інтерактивні прототипи замість статичної документації на зразок PSD.
Можна, звичайно, одночасно робити і продукти, і гайдлайн, але на практиці це займає величезну кількість часу із-за постійних ітерацій «запропонували типове рішення → приміряли на продукти → знайшли кілька нестиковок → обговорили та вирішили проблеми всією командою → знову приміряли на продукти...». А враховуючи, що таких рішень на проектах сотні, реліз не відбудеться ніколи.

Виходячи з накопиченого досвіду, я бачу кілька етапів розвитку платформи:

1. Загальні принципи
На старті роботи з уніфікації необхідно визначитися з основами, на яких буде вибудувана вся платформа. Вони полегшують прийняття дизайн-рішень на всіх рівнях і роблять її розвиток системним. Відмінний приклад   мову дизайну IBM.

Маніфест або загальні принципи дизайну
Це зведення з десятка правил або близько того, які допомагають пров'язати образ бренду з конкретними рішеннями. Так сказати, високорівневий чекліст для перевірки інтерфейсних патернів. Наприклад, один із принципів нашого міжнародного бренду My.com   поєднання мінімалістичного білого фону для всіх робочих поверхонь інтерфейсу з точковими акцентами фірмового червоного кольору, що дозволяє краще виділити айдентики. При цьому ще одна якість бренду — це емоційність і персональність. Щоб підтримати його і не порушувати перше правило, використовуються соковиті фонові підкладки, а основна робоча область лежить на білою напівпрозорою підкладці.

Принципи можуть стосуватися різних речей, які ви вважаєте важливими для бренду. Наприклад, Mailchimp робить особливий акцент на тоні голосу   текстах в інтерфейсі. Microsoft в метро-дизайні наполягає на фокусі на контенті замість хрому, а також виділяє особливу роль анімації. І це виливається в єдиний консистентный experience.

Важливо, щоб маніфест існував не самі по собі, а був прив'язаний до загальної стратегії компанії. У разі дизайн-принципів — в основному через брендинг. Тільки тоді вони будуть працювати в повну силу, а не стануть черговим новомодним методом-іграшкою дизайнерів. Їх будуть розділяти менеджери та інші співробітники компанії, вони будуть дійсно допомагати у прийнятті рішень. Кількість принципів повинно бути розумним, щоб їх можна було запам'ятати і між ними не було дублювання. В якості орієнтира можна пройтися по колекції Design Principles FTW.

Design Principles FTW
Design Principles FTW

Візуальний мова
Конкретні принципи, що лежать в основі візуального представлення, логіки взаємодії та інформаційної архітектури. Якщо маніфест говорить на рівні цінностей, то основи дизайну — про конкретних рішеннях. Для спрощення майбутньої життя платформи потрібно прагнути до високого рівня абстракції у всіх визначеннях.

Інформаційна архітектура. Виходячи із специфіки продукту і його цільової аудиторії, нам потрібно описати принципи розподілу функцій і сценаріїв використання на екрани, вибудувати їх ієрархію і забезпечити навігацію між ними. Якщо ми говоримо про лінійку продуктів, то вони можуть значно розрізнятися і вимагають різних підходів. Тому корисно описати всі — одностраничник, ієрархічна структура, лінійна, мережева, хаб або комбінація з декількох. Кожен з підходів має мати свого роду міні-маніфест — для яких завдань використовується, як перекласти на нього функціональність і сценарії використання продукту. Причому ще краще, якщо з усіма нюансами — найменування категорій та посилань, опис мета-даних, організаційні схеми (алфавіт, географія, хронологія, тематика, завдання, аудиторія, популярність).

Принципи взаємодії. Конкретні навігаційні рішення, реалізують принципи інформаційної архітектури — постійні (включаючи підвал) і контекстні меню (видимі, по правій кнопці миші або довгому натисненню пальцем), пошук, хлібні крихти, інструменти для роботи зі списками (сортування, фільтрування, групування, посторінкова навігація або довантаження), контекстні провязки контенту, системи сповіщення та алертів. Бажано з їх ілюстрованим перекладанням на модель типового екрану, а також рекомендаціями щодо вирішення конкретних продуктових завдань — наприклад, провязки контенту допомагають підвищити глибину перегляду.

Все це повинно спиратися на підтримувані типи пристроїв — великий і мобільний веб, програми для різних платформ (мобільні, планшети, портативні). Для кожного з них можуть бути свої особливості — специфіка методів управління (миша, тач, голос), швидкі дії (гарячі клавіші, жести), забезпечення доступності.

Інтерфейсна сітка. Це крок, за яким шикуються всі елементи інтерфейсу — їх розміри і відступи між ними. Зараз найбільш популярна 8-піксельна, її використовують в тому числі Android і Google в цілому. iOS базується на 11-піксельної, Windows 8 — 5-піксельної. 8-піксельний крок особливо зручний тим, що добре ділиться на 2 — наприклад, можна отримати 2-піксельне заокруглення блоків. Базовий крок визначає можливі відстані. Ми базуємо наше рішення на 4dp замість 8, тому в нашому випадку це 4, 8, 16, 24, 32, 48, 96, 128. Неможливо передати всю ступінь полегшення роботи — кількість спорів і помилок по дрібницях падає на порядок. Дизайнер вибирає розміри не на око, а за єдиними правилами. Правда, корисно вести вимірювання в незалежних від щільності екрану пікселях (dp) замість px.

Структурна сітка. Вона задає набір колонок, в які вкладається основний лейаут інтерфейсу. Дуже популярна 12-колоночная сітка, її використовують більшість популярних фреймворків. Хоча ми використовуємо швидше механізм «ритму» — це набір 40-піксельних колонок з 20-піксельними відступами. Такий підхід дозволив уніфікувати різні покоління дизайну (16 колонок для 1024, 20 для 1280, 24 для 1440, 26 для 1600). Структурна сітка також визначає логіку адаптивності — як лейаут змінюється на різних дозволах.

Лейауты і контейнери. Конкретика на базі структурної сітки — як будуть розміщені робочі області інтерфейсу. 1 колонка, популярна на промо-сайтах? 2 колонки, класичний підхід для практично будь-яких завдань? 3 колонки, все рідше використовуються із-за перевантаженості? Нескінченний потік карток або тайлів, популяризуваний Pinterest? Лейаут може задавати і вертикальні співвідношення, хоча це зустрічається нечасто.

Кожна колонка лейаута — це стек, в якому один за одним поміщаються контейнери конкретних блоків з контентом. Корисно ставити логіку зовнішнього вигляду (межа, фон, тінь, заголовок тощо) і поведінки контенту на рівні самого контейнера. Так буде простіше розвивати платформу, додаючи нові блоки або коригуючи загальні принципи. Наприклад, якщо елементів у блоці більше, ніж можна відобразити на екрані, ми можемо додати посилання на повний список на окремій сторінці, розгорнути їх тут же по кліку на «показати ще», розбити посторінкової навігації або зробити прокручування всередині (вертикальну або горизонтальну). Якщо ми вибрали горизонтальну прокрутку і в майбутньому захочемо переробити стрілки або додати свайп для тач-екранів, нам не доведеться пробегаться за всіма копіями контейнера.

Сюди ж варто віднести і попап.

Інтерфейсна сітка
4 рівня сітки

Шрифтовий сітка. Є безліч підходів до вибору розмірів шрифтів, заснованих на ідеї масштабування від базового тексту. Сервіс Gridlover зібрав, здається, всі можливі. Якщо орієнтуватися на інтерфейсну сітку, то вони повинні бути кратні 4. Для заголовків це легко, хоча на практиці є проблеми з набірним текстом. По-перше, гарне число 16 для основного тексту буває завеликим для конкретного інтерфейсного рішення. По-друге, особливості рендеринга веб-шрифтів в Windows змушують робити багато милиць і обхідних рішень. Але якщо міжрядкова відстань лягає в інтерфейсну сітку, все вже не так погано — і інтерфейсний, і набірний текст не поламають її.

Gridset
Gridset

Колірна палітра. До основи, яку задають основні кольори бренду, повинні бути прописані допоміжні значення. По-перше, це інтерфейсні кольору — білий і чорний (або їх відтінки, якщо чисті значення не підходять), кольору помилок та інших системних повідомлень (червоний, зелений, жовтий), посилання, а також лінійка сірих кольорів (підкладки, межі, допоміжний текст). По-друге, акцентні — наприклад, для позначення категорій контенту. Причому для них може бути задана логіка зміни, якщо потрібні варіації (наприклад, недоступні категорії висвітлюються). Всі кольори в палітрі повинні бути комплементарны основним, заданих брендом.

На додаток до кольорів корисно описати формули для побудови тіней, задати кілька стандартних параметрів прозорості та розмиття фону.

Набір елементів управління. Маючи інтерфейсну і шрифтових сітку, а також колірну палітру, можна системно підійти до роботи над базовими будівельними елементами. Кнопки (головна, звичайна, з додатковими опціями; текстова, иконочная, версія для панелей інструментів), посилання, загальні і спеціалізовані поля введення і випадаючі списки (комбо-бокс, календар, країна з телефонним кодом тощо), перемикачі (чекбокс, радіо-кнопка, тумблер), завантажувачі контенту (фото, відео, файли). Для них повинні бути задані стану: фокус, активне, наведення, недоступне.

В доповнення до елементів форм потрібно описати їх компонування. Розташування назв полів, пояснювальних текстів до них, правила валідації значень і помилок.

Графіка та ілюстрації. Необхідні стандарти для фото та іншої тематичної графіки. Пропорції, типові розміри і їх варіації для різних дозволів. В ідеалі вони повинні вписуватися в колонкову сітку. Те ж саме стосується аватарів.

Інтерфейсні іконки по-доброму повинні бути провязаны з загальним брендингом — можна поступово розвивати їх універсальний набір. Ілюстрації також повинні вписуватися в загальну канву, але тут досить описати загальні підходи до стилістики. Товщина ліній, колірна палітра, принципи передачі об'єму, правила розміщення в інтерфейсі і промо-матеріалах. Великі іконки-ілюстрації можуть ґрунтуватися на метафорах інтерфейсних піктограм, розвиваючи їх у більшій деталізації, а для середнього розміру задати стандартизовану сітку.

Інфографіка та візуалізація. Таблиці, поширені діаграми (кругова, стовпчикову, гістограма, лінійний графік, графік розсіювання) і більш рідкісні (майданна діаграма, кільцева, пелюсткова, діаграма розкиду, Венна, Сэнки), картографія, теплові діаграми, хмара тегів, графи і дерева, плоске дерево, ментальні карти, блок-схеми та діаграми процесів, часові шкали, діаграми зв'язків. Весь цей список потрібен тільки вузькоспеціалізованим сервісів, але найбільш затребувані необхідно описувати.

Анімаційна модель. В ідеалі переходи між станами і екранами інтерфейсу повинні підпорядковуватися певній моделі. Тоді анімація в продукті буде консистентною, а користувачеві буде легко працювати з ним. Наприклад, попап можуть приїжджати зверху екрану і після закриття їхати назад, а якщо це покроковий помічник — після появи основного вікна, нові стани можуть приїжджати праворуч. Для прикладу можна вивчити підходи трьох великих платформ — Android (тонка оркестровка), iOS (до iOS7 і після), Windows Phone (родоначальник сучасного підходу).

Реклама. Рекламна сітка часто визначає зовнішній вигляд, задаючи обмеження сітки дизайнерської. Важливо працювати з комерційним відділом не менш щільно, ніж з розробниками — це дозволить знаходити формати, не рушащие ні дизайн, ні грошовий потік проекту. Необхідно визначити рекламний інвентар — види і розміри медійних і тематичних блоків, принципи брендування блоків і сторінок, встановити стандарти для компонування фулскринов та інших агресивних підходів. Корисно також опрацювати типові рішення для внутрішнього промо. Другий крок — це, власне, сітка, по якій реклама розміщується на стандартних лейаутах.

IBM Design Language
IBM Visual Language

Принципи в коді
Після визначення основних принципів дизайну платформи потрібно закласти їх основу CSS. Дизайнерам вкрай важливо розбиратися в ньому, щоб разом з розробниками вибудувати future-friendly систему. Це як раз те, про що я писав у другий частини цієї серії   підсумковий дизайн в тому чи іншому вигляді визначається на всіх етапах розробки продуктової і важливо не забувати про це, якщо ви хочете працювати системно. Сучасні CSS-препроцессоры начебто SASS і Less дозволяють ставити глобальні змінні і це відмінний спосіб визначити основні принципи в коді. А иконочные шрифти і SVG-спрайт допоможуть зручно працювати з допоміжною графікою.

Завдяки високому рівню абстракції загальних принципів ми отримуємо потужну інтерфейсну математику, яка прибирає саму можливість розбіжностей. Наприклад, щоб отримати кнопку, ми пишемо «Зберегти» базовим розміром шрифту, відміряємо типові відступи зверху, знизу і з боків, заливаємо це простір стандартним кольором для підкладок кнопок, також стандартним кольором обкреслюємо обведення і підкладаємо стандартну тінь знизу. І до тих пір, поки не зміняться константи, ця математика буде приводити всю команду до однакових рішень, навіть якщо дизайнери мало спілкуються між собою. А якщо все це ще й зашито в код — можна легко оновлювати константи, змінюючи всю лінійку продуктів. Нірвана і Валгалла одночасно!

Корисно навести структуру типових сторінок на основі лейаутов. Вони включають шапку, підвал, контентну область, допоміжні колонки. Це допомагає краще розуміти основи використання гайдлайнов.

2. Бібліотека шаблонів і готових рішень
Наступний крок у побудові платформи — це створення готових компонентів і переклад всього дизайну на них. Виходячи з нашої мети спрощення виробничого ланцюжка до «гайдлайн = дизайн = верстка → реалізація», компонент — це готовий код з певним візуальним стилем, логікою роботи і взаємодії з ним. Він повинен бути незалежним від оточення — ми можемо використовувати його на будь-якій сторінці без побоювання, що він зламається.

По суті це і є класичний дизайн-патерн, які дизайнери зазвичай збирали у вигляді бібліотек до інструментів проектування і дизайну, а після цього описували в гайдлайнах. Тільки нам не потрібно кожен раз перевіряти якість його впровадження і підтримувати у всій ланцюжку артефактів. А якщо ми вирішили змінити патерн — потрібно замінити оригінал в єдиній базі коду, після чого він оновиться на всіх використовують фреймворк проектах.

Для опису компонентів вкрай важливо дотримуватися семантики. Як у плані відсилання до базовим принципам — патерн використовує не конкретне значення «шрифт 24 розміру» або «підкладка кольору #F0F0F0», а сенс — «заголовок 2 рівня» або «підкладка для карток». Так і в сенсі загального призначення — основний контент, інформація по темі, додаткові обв'язки. Тоді вся ідея з легким оновленням по всій лінійці продуктів дійсно спрацює.

Приклади компонентів:
  • Навігація   вкладки, алфавітний покажчик, календар, пошук і фільтри, сортування, історія переглядів;
  • Списки   список, матриця, прокручувана стрічка, асинхронна тайловая компонування;
  • Медіа   відео, інфографіка, фотогалерея, пост з соціальної мережі;
  • Інформери   погода, курси акцій і commodities, спортивна статистика, розкладу, гороскопи, світовий час;
  • Соціальна взаємодія   коментарі, опитування, консультації, рейтингування, зворотній зв'язок, шарінг в соц.мережах.


Крім окремих рішень корисно описати і типові сторінки, що складаються з стандартизованих компонентів. Список новин, конкретна публікація, результати пошуку, налаштування, профіль користувача, авторизація і реєстрація, «нульові» стану, серверні помилки і т. п. Сюди ж можна віднести шаблони листів розсилки. Все, що ви починаєте використовувати хоча б двічі, корисно перевести в стандартні рішення. Хоча необхідно враховувати, що такий шаблон повинен бути гнучким в плані використовуваних даних — реальні сторінки можуть мати різні контекстні блоки.

Хтось з читачів вірно помітить, що якщо запускати всі продукти на базі одних і тих же компонентів, то крім уніфікації ми отримаємо ще і унылизацию — всі сервіси виглядають однояйцевыми. Тому платформа повинна давати можливість стилізації продуктів без зміни загальних принципів роботи компонентів. Наприклад, ми в компанії вибрали ідею акцентних кольорів — кожен сервіс має свій колір, що дозволяє виділити його із загальної лінійки. Ми також думали про різних шрифтах, можуть спрацювати декоративні елементи, ілюстрації та іконки.

3. Живі гайдлайны
Гайдлайн повинен бути, по суті, ще одним проектом на базі платформи. Спочатку описуються загальні принципи, які ми витягуємо з основного CSS. Після цього — готові компоненти, які вже використовуються в працюючих продуктах. До кожного з них дизайнер повинен дати опис — для чого і в яких ситуаціях він використовується. Навіть якщо ви будуєте спрощену систему в дусі Bootstrap, перший крок вже здорово допоможе в систематизації роботи.

Описані в такому гайдлайне рішення актуальні на 100%. А контроль якості всієї продуктової лінійки радикально спрощується — дизайнер стежить тільки за референсним паттерном. Причому можна піти ще далі і налаштувати систему «автолечения». Раз в тиждень або місяць скрипт проходить по всім продуктам та порівнює використовуються в їх CSS параметри з референсними. Якщо виявлені розбіжності — дизайнер отримує список проблемних місць.

4. Прототипування
Після того як всі компоненти платформи запущені і працюють, можна зайнятися подальшим спрощенням робочого процесу — відкинути інструменти для створення статичних wireframes і макетів. Якщо живий гайдлайн поряд з прикладом компонента буде виводити його HTML-код, нескладно зібрати готову верстку сторінок в HTML-редакторі на основі шаблонів типових лейаутов. А для вже зверстаних сторінок доопрацювання ще легше вносити «по живому».

Багато дизайнери вже не бояться коду, так і іншим пора залишити страхи. Зараз повним-повно зрозумілих навчалок і готових прикладів, та й самі по собі HTML і CSS прості до неподобства. Не те що б треба закинути Фотошоп або Скетч — подібні інструменти відмінно працюють для пошуку стилістичних напрямків. Але без переходу до дизайну в браузері працювати стає все складніше.

Якщо у компанії достатньо ресурсів і платформа усталилася, можна піти далі і зібрати онлайн-інструмент для візуального прототипування. Виходить, грубо кажучи, Axure в інтернеті — дизайнер або менеджер перетягує готові компоненти на сторінку і отримує інтерактивний прототип. Найкращий приклад у цьому плані   Polymer Project від Google, що дозволяє створювати дизайн гайдлайнам material. Схожі візуальні конструктори існують і для Bootstrap.

Конструктор Polymer Project
Конструктор Polymer Project

Якщо піти ще далі, то хороший інструмент прототипування повинен вміти використовувати реальні та актуальні дані. Відповідальні дизайнери давно відучилися вставляти «lorem ipsum», але це вимагає деякої ручної роботи. Ще більше сил забирає опрацювання крайових станів і легка підстановка даних прототип дозволить швидше перевіряти їх. Це вже роблять з допомогою Sketch для тексту і ілюстрації.

Крім дешевизни створення живий прототип краще працює як інструмент комунікації. Сторінки можна пров'язати один з одним, працює вся логіка і скрипти публічної версії продукту, є адаптивність. Так що раз вирішені проблеми не доводиться бачити знову.

5. Експерименти
Дизайн-патерни, використовувані в платформі, не визначаються раз і назавжди — ми завжди повинні шукати більш вдалі рішення. Це багато в чому пов'язано з експериментами, коли порівнюються декілька альтернативних рішень. Ідеї для них можуть йти від знайдених проблем, цілей зростання продуктових показників, цікавих підходів у конкурентів, загальної потреби регулярного тюнінгу дизайну. Здорово, якщо платформа дозволяє робити це системно і недорого, полегшуючи проведення юзабіліті — і A/B-тестів.

По-перше, потрібна можливість створювати варіації компонентів — наприклад, в нашому рішенні це можливо, оскільки конкретний проект може накладати зміни на стандартний патерн при необхідності (хоча ми намагаємося мінімізувати такі випадки). По-друге, старі версії блоків можна зберігати, в ідеалі — вказуючи в кожному з них результати та деталі експерименту. Тоді можна буде вивчати, як і чому вони працювали (або не працювали) раніше і знаходити інсайти для майбутніх поліпшень. Ну а оскільки сама ідеологія платформи передбачає, що кожен проект отримує актуальну версію компонента з єдиної бази коду, оптимізований в ході тестування варіант швидко пошириться по всій лінійці і ми отримаємо кумулятивний ефект.

6. Алгоритмічний дизайн?
Останні роки все частіше зустрічаються приклади використання алгоритмів для побудови екранів інтерфейсу. Дизайнер і розробник описують логіку обробки вхідних сигналів — контенту, контексту, інформації про користувача та його діях, а далі платформа сама формує дизайн на основі готових шаблонів і принципів. Це дозволяє домогтися тонкого підстроювання під конкретну вузьку ситуацію без необхідності вручну промальовувати і розробляти десятки станів екрану.

Для одного з наших проектів ми описували автоматизовану роботу журнальної верстки. Існуючий контент мав погану семантичну структуру, так що переверстати архів публікацій у сучасний вигляд було б витратним. Та й у цілому не кожен редактор володіє хорошими навичками дизайну. Для цього спеціальний скрипт робив парсинг статті і виходячи з її вмісту (кількість абзаців і слів у кожному з них, кількість фотографій і їх формати, врізки з цитатами і таблицями тощо) вибирав типової патерн для подання шматка статті в ефектному журнальному вигляді. Скрипт також стежив за тим, щоб патерни чергувалися і матеріал виглядав досить різноманітно. Таким чином редакція економить сили на переробці старого контенту в новий вид, а дизайнер просто регулярно додає нові модулі подання. Схожу модель реалізував Flipboard.

Ще один цікавий приклад в цю сторону — нашуміла в минулому році CMS The Grid, яка самостійно підбирає шаблони оформлення контенту, обробляє фотографії. Причому ще й проводить A/B-тести різних підходів для вибору кращого рішення. Інше цікаве напрямок   параметричні шрифти кшталт Robofont, які дають дизайнерам велику гнучкість роботи і нові можливості. Підхід не те що не устоявся — навіть обговорюється рідко, але може здорово допомогти в майбутньому для дійсно проривних рішень. І це буде ще одним рівнем зрілості дизайн-платформи.

The Grid
The Grid

Існуючі приклади
Звучить описана платформа масштабно, але цей підхід не доступний лише великим компаніям. Bootstrap і Foundation відмінно вирішують частина з описаних задач — опис принципів дизайну в коді, живі гайдлайны, прототипування. Хоча і не дають усіх переваг компонентної моделі, коли оновлення лінійки продуктів значно спрощується.

Anna Debenham була однією з піонерів у створенні живих гайдлайнов і разом з Brad Frost веде сильну колекцію готових рішень, статей та прикладів. Це шалено крутий джерело інформації по темі, і я рекомендую кожному прочитати його від початку до кінця.

Styleguides.io
Styleguides.io

Brad Frost, ідеолог концепції Atomic Design, пише книги на цю тему. На його сайті доступні деякі частини з неї, і глави потихеньку поповнюються.

Книга Brad Frost «Atomic Design»
Книга Brad Frost «Atomic Design»

Мобільні додатки
Описана компонентна модель призначена для вебу. Ми думали про її застосування для мобільних додатків — у цьому випадку компонентами служать бандли, тобто поширювані бібліотеки вже з зашитим дизайном. Але поки що сфокусувалися на веб-сервісах.

Як це було у нашому випадку
Ми йдемо по цьому шляху і вже побудували на власній платформі дві групи проектів з п'яти   мобільний веб і контент-проекти. Для цього важливо пройти по всьому процесу створення і впровадження фреймворку:

  1. Створення модельного дизайну і платформи. Необхідно знайти підходяще для наших продуктів і масштабоване інтерфейсне рішення, визначитися зі стилістикою і реалізувати технічну частину фреймворка.
  2. Переклад всіх продуктів на платформу. Бібліотека патернів і єдина база коду активно розширюються за рахунок нових рішень, а бек-енд сервісів приводиться у відповідність з вимогами фреймворка.
  3. Спрощення дизайн-процесу. Технічне рішення вже обкатано та основні завдання вирішені, тому від створення безлічі артефактів можна відмовитися і збирати нові екрани з готових блоків в єдиній базі коду.
  4. Рефакторинг дизайну. Запуск десятка продуктів займає досить значний час, через яке виявляються проблеми в реальному житті сервісів. Так і дизайнерські тренди змінюються.


Зараз у нас паралельно йдуть третій і четвертий етап впровадження фреймворка. Але плюси роботи з ним ми відчули вже на самому початку — кількість зайвої роботи постійно знижується. Озираючись назад, ми напевно змогли б зробити процес створення і впровадження фреймворку правильніше і коротше. Але я розповів про наші правильних і помилкових рішень в деталях, щоб ви змогли пройти цей шлях швидше.

У розвитку гайдлайнов потрібен певний авторитаризм, який допоможе не пропускати несистемних рішень. Якщо це можливо — потрібно завжди використовувати готові патерни. Якщо вводиться щось нове — потрібно пробувати підвести під це рішення вже реалізовані проекти або розуміти, де воно стане в нагоді в майбутньому. Тільки тоді платформа не розповзеться і консистентним портфеля продуктів збережеться. А значить збережуться і зручність розвитку цих продуктів, їх комфортність для користувача і позитивний ефект для всього бренду.

Зараз ми перевіряємо легкість оновлення платформи на практиці — осучаснювати візуальний стиль, адже з моменту його появи в першому референсному проекті минуло кілька років. І це ще один ризик, на який треба йти при впровадженні гайдлайна — доводиться тиснути в собі спокуси вносити в нього різнобій осучасненням окремих частин. Так, якийсь час сервіси можуть виглядати трохи несвіжими. Зате після запуску єдиної платформи оновлювати дизайн буде на порядок простіше.

Разом
Абсолютно впевнений, що будь-яка сучасна UX-стратегія повинна будуватися на подібних принципах, інакше в довгостроковій перспективі все буде погано. Якщо ви хочете закласти хорошу основу для продукту або цілої лінійки продуктів, забудьте про статичні гайдлайны і бібліотеки патернів — це зайвий етап робіт, ще один проміжний артефакт і джерело додаткових трудовитрат.

Плюсів у платформного мислення сила-силенна:

  • Прискорення і здешевлення виведення на ринок нових можливостей продукту.
  • Гарантований спосіб отримати уніфікований дизайн і зберегти єдність в майбутньому.
  • Більш часті і системні експерименти з дизайн-рішеннями.
  • Від поліпшення в одному конкретному продукті виграють і інші.
  • Дизайнер менше працює руками і більше   головою.


Але головне, як вже не раз було відзначено вище, — ми йдемо від героїчних редизайнів до постійно актуальному інтерфейсу. Так що можемо приділити більше часу на продуктову роботу, а не нескінченне обслуговування дизайну. А сам фахівець перестає мислити макетами і виходить за рамки Фотошопу.

P. S. Величезне спасибі всій команді дизайнерів і розробників, завдяки яким все це вийшло! З боку дизайну — Євген Бєляєв, Марія Боброва, Артем Гладков, Геворг Глечян, Євген Боргів, Костянтин Зубанов, Олексій Кандауров, Оксана Каширськая, Олександр Кіров, Мітя Осадчук, Олексій Сергєєв, Павло Скрипкін, Світла Соловйова, Євген Ферулев і я. З боку розробки   Олександр Бекбулатов, Дмитро Бєляєв, Віталій Васін, Павло Вдовцев, Костянтин Ворожейкін, Антон Епрев, Євген Іванов, Андрій Кусимов, Стас Михальський, Сергій Ножкін, Антон Поліщук, Борис Ребров, Павло Рибін Андрій Сумін, Максим Трусів, Арстан Торегожин, Павло Щербінін. А також всім менеджерам і редакторам.

P. P. S. Тільки не треба кидатися в крайнощі! Будь-який новий підхід до роботи не скасовує, а доповнює і видозмінює старі. Нерозумно кричати про те, що передові дизайнери працюють тільки в браузері, а всі, хто залишився в Фотошопі — старі діди. Але й залишатися затиснутими в рамках класичних інструментів — ховати свою кар'єру.





Стаття написана для журналу UXMatters.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.