Впровадження дизайн-токенів, або як ми нарешті запустили dark mode

Всім привіт! Мене звати Влад Кравцов, я Product Designer в EdTech-стартапі Mate academy, and it all started when my Mom and Dad I wrote a doc on Design System.

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

Далі розповім, як документ на ~500 слів спровокував низку подій і привів нас до лончу фічі, якою одразу скористалися 54% юзерів.

Найбільш критичні проблеми, які виявили після аудиту

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

1. Дизайнери думають над тим, про що не потрібно думати

Наприклад, який колір обрати для основного тексту. На першій сторінці хтось подумав, що краще gray-80, а на іншій — gray-90, перед цим спробувавши кілька інших варіантів.

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

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

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

2. Одні й ті самі речі виглядають по-різному в різних частинах інтерфейсу

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

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

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

3. Мало кольорів ≠ консистентність

Наша дизайн-система мала доволі маленьку палітру кольорів. Ми її не розширювали, бо думали (спойлер: помилково), що так вона буде більш консистентною.

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

Як ми представляли наші кольори VS що насправді

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

4. Кольори в різних місцях «говорять» про різне, вони не підвʼязані під значення

Наприклад, стан In progress в одному місці може бути сірим, у другому — жовтим, у третьому — синім. Відсутність асоціації = більше часу юзера, щоб зрозуміти інтерфейс / виконати якусь дію = гірший досвід.

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

5. Окрема палітра для мобільного застосунку.

Мобільний застосунок взагалі жив окремим життям. У ньому використовувалась основна палітра, проте логіка її використання відрізнялась. Наприклад, якщо на вебі фон сторінки був сірим, а картки на ній — білі, то в мобайлі, навпаки, сторінка була білою, а картки — сірими.

Пошук рішення

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

Це й привело нас до ідеального рішення — імплементації дизайн-токенів. Бо вони:

— уможливлюють світлу й темну теми;

— забезпечують консистентність всіх частин продукту;

— спрощують прийняття рішень та взаємодію між дизайнерами й розробниками;

— дають змогу за потреби вносити зміни один раз для всієї системи, не потрібно шукати та змінювати жорстко закодовані значення.

Дизайн-токени на практиці

На практиці це значить, що замість певного значення кольору/розміру дизайнер та розробник посилається на функціональне імʼя (токен), яке в собі має набір різних значень під різні теми. Виходить, що зміни відображаються у двох темах одночасно. Наприклад, вводить [колір-тексту] та отримує для світлої теми чорний колір #111111, для темної — білий #ffffff. Коли використовуєш вперше, відчувається як магія.

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

Реалізація

Щоб реалізувати дизайн-токени й, як результат, отримати темну тему і не тільки, потрібно було зробити наступні кроки:

1. Розробити палітру (Core tokens).
2. Розробити систему кольорів (Functional tokens).
3. Написати гайдлайни. Що це таке, як працює, як використовувати тощо.
4. Задевелопити це все як інфраструктуру, яку можуть використовувати девелопери.
5. Перевести інтерфейс з кольорів на токени у Figma.
6. Зробити те саме в коді.

Розробка палітри (Core tokens)

Глобально, потрібно було з хаосу зробити цукерочку, яка була б, якщо коротко (1) консистентною, (2) доступною, (3) масштабованою.

Якщо трішки довше:

• дозволяла б побудувати навколо себе правила використання;
• не потребувала доповнень;
• кольори мали однаковий рівень контрасту, а цей контраст був достатнім;
• різні відтінки одного кольору були консистентними
• була достатня кількість відтінків одного кольору і водночас різні кольори мали помітну різницю;
• кольори залишались знайомими тощо.

Ми досліджували найкращі дизайн-системи і їхні підходи до кольорів. Зрештою сформували набір core tokens — значення кольорів, переведені в назви (значення HEX #ffffff = Core token .white). З цікавого, мали розробити для кожної теми свою сіру палітру: для світлої більш холодну, наближену до синіх, а для темної — більш нейтральну.

Далі для кольорів визначали логіку та правила використання.

Розробка системи кольорів (Functional tokens) і гайдлайнів

Core tokens служать будівельними блоками для functional tokens — токенів, які вже визначають конкретне використання елементів (наприклад, кольори для успішних повідомлень).

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

Наприклад, у багатьох місцях, де іконка використовувалась поруч з текстом, їхній контраст вирівнювався не за допомогою товщини лінії чи розміру, а за допомогою кольору. Чи найкраще це рішення? Не зовсім. Але змінювати цей підхід на даному етапі було не доцільно, тому система врахувала його, як і десятки інших.

Першу ітерацію системи протестували разом з дизайнерами на практиці. Це допомогло виявити якісь упущення і доопрацювати її. В результаті отримали ось такий сет токенів.

Щоб почати застосовувати систему так, як потрібно дизайнерам, які не знали, що таке токени до цього і як з ними працювати, було достатньо презентації самої системи та гайдлайнів і кілька прикладів зібраних за ними екранів.

Задевелопити інфраструктуру

Задизайнену систему я передав колезі Full-stack developer Богдану Максимюку, який реалізував її в коді. Бодя, ти кращий!

Перехід з кольорів на токени кожного екрану інтерфейсу реалізовували усіма функціональними командами. Дизайнери перенесли екрани у Figma, девелопери внесли зміни у код. Величезний респект усій продуктовій команді за пророблену роботу!

Що маємо в результаті?

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

Прихильність користувачів

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

Тож після анонсу теми ми отримали хвилю позитивних відгуків від задоволених користувачів — нині 54% використовують продукт у режимі dark mode.

Консистентість

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

Правила, які не обмежують

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

Порозуміння команд

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

А ще платформа стала просто ще кращою :)