Напевно, кожен дизайнер чи проєктувальник опинявся в ситуації, коли інші точно знали, як краще зробити. Наприклад, приходиш на командну зустріч, показуєш рішення, щоб обговорити фінальний макет або кейс, а у відповідь отримуєш безліч коментарів як краще зробити. Причому всі коментарі не вписуються в концепцію чи мають повністю невідповідний стилістиці дизайн. Знайомо? Якщо у вас побігли мурашки, ви не самотні.
Чому так відбувається? Колеги можуть пропонувати редагування з різних причин. Наприклад, тому що переживають результат і хочуть допомогти з макетом. Але у продуктовій команді ви UX-експерт. Потрібно вміти відстоювати свою позицію та аргументовано відповідати на пропозиції чи поради команди. А як це зробити, якщо ви під час підготовки рішення не проводили дослідження, розповімо у статті.
Як пояснити ідею чи рішення
Дизайн-процес передбачає розв’язання будь-якої проблеми користувача чи бізнесу. Якщо вас запитують, чому ви хочете зробити саме так, поясніть, що саме такий підхід найкраще вирішує завдання користувача. Для цього рекомендую використовувати інструмент HMW.
How Might We (HMW) – методика для генерації ідей та пошуку рішень на основі проблем чи можливостей. Вона будується на формулюванні питань, що починаються із фрази «Як ми можемо…», щоб стимулювати креативне мислення. Наприклад, «Як ми можемо зробити процес реєстрації більш захопливим та швидким?»
Приклад як обґрунтувати ідею:
«Я прикинув, що так користувачам буде зручніше… Так само зроблено Google.» — неправильно (спиратися на перше рішення, що спало на думку).
«Нагадаю, на грумінгу ми склали діапазон можливих рішень і кожне оцінили з погляду складності технічної реалізації, якості досвіду користувача і досяжності бізнес-показників. Наразі скину в чат посилання на результати цього грумінгу.» — правильно (спиратися на проведений аналіз).
Як обґрунтувати UX/UI
Обговорення UI/UX – широке поле для суперечок. Рішення нескладно обґрунтувати, якщо ви проводили дослідження, наприклад, UX-тестування, карткове сортування або щось інше. Але буває так, що дослідження не було. Тоді можна спиратися на загальноприйняті стандарти, думку експертів чи досвід відомих компаній.
Щоб аргументувати рішення, потрібно самому вірити у нього. Перед проведенням демо для продуктової команди або колег-дизайнерів рекомендую його перевірити самостійно за пунктами списку нижче.
Евристика
Евристика – це рекомендація, правило або судження експерта, яке заведено вважати вірним. Найпопулярніші евристики в UX від експертів Нільсена Нормана, Бена Шнейдермана, Вайншенка і Баркера. Наприклад, серед евристик Нормана є така:
#5: Error prevention. Краще добре оформленого повідомлення про помилку є лише відсутність помилки. Або змініть умови, що провокують помилки, або підкажіть користувачам заздалегідь, щоб вони її не зробили.
Як її застосувати? Наприклад, у меню є опція, яка доступна не всім користувачам, і ви вирішили приховати її від тих, хто має обмеження прав доступу. Якщо вас спитають, чому ви так зробили, можете послатися на цю евристику. Адже якщо залишити таку опцію, деякі користувачі спробують її скористатися, і тоді система виведе помилку.
Перед передачею макетів у розробку корисно перевіряти свої макети по евристикам. Можна використовувати будь-які – наприклад від Нільсена Номана.
Специфікації дизайн-систем вашої компанії чи принципи гайдів Material, Apple.
Мабуть, кожен дизайнер на демо макетах чув зауваження на кшталт: «Мені здається, ця кнопка занадто яскрава і перетягує увагу» або «Якийсь шрифт великий». Якщо в компанії є дизайн-система з описом компонентів та базових стилів, а також специфікації, як з цим працювати, можете надсилати запитувачів до документів. Поясніть, що ви використовували такий шрифт та кнопку, тому що це стандарти прийнятої в компанії дизайн-системи. Якщо документа немає, можете обґрунтувати рішення гайдами, написаними титанами індустрії: Material Design від Google та Human Interface Guidlines від Apple.
Приклад як обґрунтувати UX-стандарти (наприклад, вибір типу компонента):
«Мені здалося, що ця кнопка більше в очі впадає.» — неправильно (спиратися на свою суб’єктивну думку).
«Відповідно до специфікацій нашої дизайн-системи, основна дія має супроводжуватися кнопкою Primary. У сценарії створення додаткового користувача кнопка «Додати користувача\» цільова.» — правильно (спиратися на специфікації дизайн-системи в компанії).
Стандарти доступності (accessibility)
Існують міжнародні стандарти доступності, яких важливо дотримуватись, щоб сайтами могли користуватися всі люди незалежно від стану здоров’я. Ви можете ознайомитися з ними за посиланням. Такі стандарти допоможуть відповісти, чому цей синій такий яскравий чи чому помилка підсвічується не тільки червоним кольором, але ще й іконкою. Наприклад, ви вибрали такий синій, тому що він проходить по стандартах контрастності. А помилка підсвічується іконкою, оскільки «колір не повинен бути основним джерелом інформації для користувачів» — цей принцип є актуальним для користувачів, які не розрізняють кольори. Рекомендую використовувати ці принципи не лише перед командною зустріччю, а й для перевірки власних макетів. Іноді можна випадково забути про якийсь критерій і потім визначити недоліки вже готовому рішенні.
Приклад як обґрунтувати стандарти UX (наприклад, вибір кольору):
«Так буде красивіше за колірним колом.» — неправильно (спиратися на власні уявлення про прекрасне).
«Відповідно до стандартів доступності, колір має бути котрастний для кращої зчитуваності. Цей колірний стиль проходить стандарти контрастності на сірому фоні, наступний колірний стиль у нашій дизайн-системі на цьому фоні не проходить стандарти контрастності. Кому цікаво, можу надіслати сервіс для перевірки контрастності.» — правильно (спиратися на стандарти доступності).
Гештальт-принципи
Гештальт-принципи — це психологічні закони, що описують, як люди сприймають та групують візуальну інформацію. Посилаючись на них, ви відповісте на всі питання на кшталт: «Здається, у цьому компоненті багато повітря». Наприклад, ви згрупували картки товарів за допомогою рамок і отримали зворотний зв’язок: тепер вони виглядають «галасливо». Можете відповісти колегам, що слідували «Принципу спільності». Він говорить: «Елементи, з’єднані візуально, наприклад, рамкою чи лінією, сприймаються як пов’язані». Так що ваше рішення обґрунтоване, адже, наслідуючи психологічні принципи сприйняття інформації, ви зменшуєте когнітивне навантаження, і користувачеві легше знаходити потрібну інформацію.
Інші продукти
Коли ви працюєте без досліджень, а тільки з кабінетними, наприклад, вивчаєте конкурентів на предмет функціональності фічі, один з основних аргументів — апелювати до стандартів на ринку. Тут важливо не скотитися в «а зробімо, як в Apple» і до будь-якого рішення конкурента підходити критично. Деякі продукти вважаються успішними, попри не найякісніший UX. Наприклад, Amazon, хоч і є одним зі світових лідерів у галузі e-commerce, проте у професійній спільноті дизайнерів викликає скоріше здивування, ніж бажання слідувати його патернам. Як це? Все просто: Amazon – багатофункціональний продукт з широким асортиментом та швидкою доставкою, а це і є його основна конкурентна перевага.
Експертиза в UX та у сфері продукту
Цей пункт є релевантним для дизайнерів рівня «Халк», тобто досвідчених сеньйорів. Звертатися до своєї експертизи можна лише за однієї умови: якщо у вас одночасно два важкі «багажі досвіду» — в UX та сфері продукту. Але швидше за все, якщо ви сеньйор, то ви й так це знаєте. І написане вище вам було не нове.
Висновки
Поясніть собі та іншим, чому ви прийняли те чи інше рішення. Чим менше абстрактних формулювань ви використовуватимете, відсилаючи співрозмовника до конкретних рішень, стандартів, правил і гайдів, там менше чутимете сумнівів щодо вашого рішення. І тим швидше ви доростете до дизайнера рівня «Халк».
Автор: Мусієнко Тимофій