В англійській мові є термін — malicious compliance (зловмисне підкорення). Це коли ігнорують здоровий глузд на користь дотримання правил. 

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

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

Як ламати правила дизайн-системи відповідально?

«Правила ж не просто так вигадали», — думають виконавці. Якщо написано, значить так треба робити. І роблять, не думаючи про результат. А потім відбувається така ситуація:

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

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

Здається, всі цілі, трагедії не сталось. Лише якби ж то хтось взяв на себе цю відповідальність.

Дизайн-системи, гайдлайни та дизайнери мають бути гнучкими

«Ми так не робимо. У наших гайдлайнах вказано по-іншому». Часто помічаю таку позицію при роботі над продуктами. Вона може бути як у дизайнерів, так і інших членів команди.

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

Саме тому ми, як професіонали, повинні розуміти, коли варто зробити виняток, бо так, як написано — не працює.

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

Насправді — не завжди повинно.

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

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

Наприклад, ось так виглядає компонент пошуку на сторінці квартири на Airbnb. Він знаходиться на білому тлі (#FFF) і сам має сірий фон (#EBEBEB) для достатнього контрасту. Наче все добре.

А це — головна сторінка Airbnb. Тут побачите такий же компонент, проте цього разу на сірому фоні. Оскільки він живе в іншому середовищі й має тінь, той же сірий колір (#EBEBEB) тепер майже повністю злився з тлом.

То чому б нам не взяти відповідальність на себе й не змінити його на темніший сірий (#DBDBDB)? Ілюстративний приклад від мене:

Так, технічно тепер у нас є «неконсистентність» у дизайні. Додався ще один відтінок сірого, а компонент виглядає по-різному на різних сторінках. Та чи важливо це, якщо у нас з’явилися нормальні контраст та тінь? Можливо, тепер це не проблема цього компонента, а його перевага? 

Та й дуже ймовірно, що темніший сірий вже є в палітрі дизайн-системи й можна використати його, не порушуючи правил.

Щоб порушувати правила дизайн-системи, їх треба знати

Приклад із дизайн-системою Airbnb — скоріше виняток із правил. Інколи дійсно виправдано відходити від гайдлайнів, але часто можна закінчити так, як ця легендарна картинка:

Ігноруйте гайдлайни, щоб зробити краще, а не просто по-іншому.

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

Але залишається запитання.

Як вносити зміни у дизайн-систему чи компоненти й донести це команді?

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

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

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

Пам’ятайте, що розробники використовують готовий, раніше створений компонент. Порівнювати його та вашу версію й шукати відмінності — не найефективніше заняття. 

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

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

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

Користувачам байдуже на зміни у компонентах (майже точно)

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

Ваші користувачі не міряють лінійкою відступи між елементами чи розміри тексту, щоб зловити вас на гарячому. Єдині люди, які за цим слідкують —  ви та ваша команда :)