UXPUB 🇺🇦 Дизайн-спільнота: aldr_cwa

Створюй компоненти в Figma з розумом

aldr_cwa — Wed, 07 Feb 2024 08:11:11 +0000

Це переклад статті Jérôme Benoit

Система дизайну Oxygen doctolibs існує вже понад три роки і стає все більш і більш надійною. Три роки додавання нових компонентів, нових процесів, змін, через нові можливості Figma (як авторозмітка), оновлення або перероблення компонентів, дрейфів (розбіжностей між компонентом дизайну і компонентом розробки)...

Все це призвело до того, що бібліотека Figma (раніше називалася 💠Core components) була ближче до Франкенштейна, ніж до стрункої та вишуканої бібліотеки, як нам хотілося б.

Паралельно ми регулярно отримували негативні відгуки від Product Designers, зокрема, про те, що файли Figma дуже важкі, а отже, над ними дуууже повільно і дратівливо працювати. Це дуже важливо, якщо врахувати, що Product Designer працює над Figma щонайменше півдня.

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

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

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

Жахлива правда

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

А потім ми відкрили для себе жахливу правду: файли були важкими, тому що наші компоненти не були важкими, вони були ВЕЛИЧЕЗНИМИ! І, чесно кажучи, ми були шоковані!

Візьмемо для прикладу компонент 💠Pill. Цей компонент має багато варіантів, кілька смислових колірних тем, включає вкладені компоненти з Системи дизайну (Кнопки-піктограми, Аватари, Іконки, Завантажувач, Значки...) і має кілька доступних розмірів, типів і т.д.

А ця 💠Pill використовувала.... 8 684 шари 😱.
NB: залежно від вибору (компонент-джерело або екземпляр) результат лічильника шарів може дещо відрізнятися.

Питання стояло так:
Як створити легкі та ресурсоефективні компоненти, максимізуючи ефективність без шкоди для якості?

Після низки ідей та досліджень ми вирішили зосередитися на 3 напрямках:

1. Видаліть всі непотрібні вкладені компоненти і створіть приватні вкладені компоненти

У варіанті використання 💠Pill (і у всіх наших компонентах сімейства зворотного зв'язку) семантичні іконки не повинні змінюватися, тому ми видалили компонент 💠Icon, що використовується як вкладений, на користь іконки SVG з нашої бібліотеки іконок. Це нам допомогло:

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

2. Спрощення структури

Паралельно ми маємо бібліотеку під назвою 🧰 Helper components, що містить компоненти, які постійно використовуються дизайнерами продуктів, але не враховуються в Системі проектування. Зокрема, ця бібліотека містить зовнішні набори інтерфейсу користувача (клавіатури ОС, сповіщення...), курсори, саморобні елементи для управління організацією файлів (картки, обкладинки проектів...) тощо. У 💠Pill використовувався один з цих допоміжних компонентів для керування падінгами з булевими властивостями - 🧰 Grid Spacer. Ми використовували їх у минулому, щоб мати керування падінгами, а точніше, щоб мати можливість змінювати розмір компонента з булевим значенням без необхідності вводити новий варіант. Ми прибрали 🧰 Grid Spacers і створили більш розумну структуру компонента з авторозмітками.

Для компонентів, які можуть мати невизначену кількість значень, таких як 💠випадаючий список або 💠меню, ми пропонували 10 рядків або елементів за замовчуванням. Це означає, що якщо дизайнеру потрібні лише 2 з них, то 8 інших будуть прихованими шарами, додаючи непотрібну вагу. Для цього конкретного випадку використання і завдяки Mr Biscuit ми створили допоміжні компоненти під назвою 🧰 Swappers. Таким чином, наші дизайнери продуктів можуть вибрати необхідну кількість рядків або елементів, з вертикальним або горизонтальним авторозміщенням.

3. Розділіть компонент

Для компонента 💠Alert раніше ми мали 1 компонент для 3 сімейств варіантів:

Банер (на всю ширину)
Листівка (стиль листівки)
Сповіщення з підказкою (для низького акценту)

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

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

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

У більш глобальному масштабі, наші 64 компоненти представляли понад 130 000 шарів до, порівняно з 21 700 після. Це означає, що 83% шарів було видалено.

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

Стандартизація властивостей

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

Наприклад:

Властивості тексту можуть бути такими: ✏️ label, description - ✏️ label, ✏️ title
Колір теми може бути: UI style, Color, Label color

Ми скористалися можливістю переробити компоненти, щоб створити список властивостей, пов'язаний з тим, який використовується на стороні коду.

Основні моменти такі:

Текстові властивості: завжди відображаються зі смайликом
Булеві властивості або варіанти: завжди відмінюються як у коді, наприклад, has Left asset, has Title, is Closable, is Disabled
Більше стандартних варіантів: прості слова, такі як позиція (position), розмір (size), стан (state), стиль (style), тип (type)

Ми також намагаємося максимально зберегти однаковий порядок властивостей для всіх компонентів.

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

Зробіть компоненти простими у використанні

Раніше всі вкладені компоненти були офіційними компонентами (наприклад, 💠Пункт списку використовував офіційний 💠Аватар). У цьому компоненті ми перестали використовувати офіційні вкладені компоненти, тільки приватні вкладені з виділеною номенклатурою. Таким чином:

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

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

Таким чином, ми полегшуємо повсякденне життя користувачів Design System і можемо мати більш раціональний вплив. Наприклад, еволюція 💠Dropdown (випадаючого списку) не обов'язково потрібна на 💠Combobox (Комбобоксі) (за допомогою 💠Dropdown). І останнє, але не менш важливе: ми менше турбуємо дизайнерів нескінченними оновленнями.

Боротьба з компонентами-примарами

Останнім кроком, і не найпростішим, була публікація нової бібліотеки. Ми визначили два ризики:

Видалення старої бібліотеки може призвести до створення так званих компонентів-привидів, тобто компонентів без вихідного коду, що зазвичай означає, що вихідний компонент було видалено (той, що має кнопку "Відновити компонент", або той, що вказує на бібліотеку, але не на основний компонент).
Створення великої кількості руйнівних змін. Це означає, що якщо дизайнер замінить компонент v1 на v2, оскільки ми змінили всю структуру та властивості, всі перевизначення будуть скинуті.

Тож ми вирішили:

Не публікувати бібліотеку v1, а лише видалити доступ до неї, і позначити їх ☠️ [V1 DO NOT USE] у назві. Таким чином дизайнери можуть легко відрізнити v1 від v2, копіювати, вставляти та використовувати компоненти v1, але не зможуть їх імпортувати. А ми, зі свого боку, все ще можемо виконувати деякі оновлення бібліотеки.
Опублікувати бібліотеку v2 з компонентами, що мають ту саму номенклатуру

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

Функція версійності та розгалуження компонентів

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

X [Major] означає версію, в якій ми зробимо велике оновлення, яке вплине на всю структуру компонентів, що передбачає порушення змін з перевизначенням втрат екземплярів.
Y [Minor] означає версію, в якій ми покращуємо компонент (додаємо нові функції або виправляємо незначні помилки), що не впливає на перевизначення поточних екземплярів.
Z [Patch] означає версію, в якій ми оновлюємо компонент з нульовим впливом на файли дизайнерів.

Висновок

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

Саме тому, відтепер:

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

Щиро дякуємо Майклу Бланкону Тарді за його величезний внесок у те, щоб зробити Oxygen найкращою у своєму класі системою проектування, яку добре засвоїли наші дизайнери та розробники.

Також дякую моїм дорогим колегам по команді UX-райтерів за коректуру: Ханні Ширан та Майку Віннінгтону.

Дякую Lyne Dang Recalt за чудову ілюстрацію для обкладинки (тепер я відчуваю себе художником)

Оцінка конкурентоспроможності: вчіться у конкурентів

aldr_cwa — Wed, 10 May 2023 08:21:10 +0000

Переклад статті з NNGroup

Дані про те, що добре чи погано працює в інших продуктах, врятують вас від непотрібних фіч і спрямують на те, що необхідно вашим користувачам

Оцінка конкурентоспроможності

Це метод порівняння, що показує, як ваш продукт працює в порівнянні з конкурентами.

Порівняння може бути:

Цілісним, за загальними показниками юзабіліті сайту
Порівняння фіч
Контенту
Елементів дизайну

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

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

Цілі

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

Мета конкурентного аналізу:

Побачити, що роблять конкуренти
Зрозуміти, як вони це роблять
Дізнатися, що працює, а що ні

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

Цілі конкурентного аналізу мають бути зрозумілі перед початком роботи. Яке дизайнерське завдання ви намагаєтеся вирішити? Які фічі є привабливими? Яку фічу на вашому сайті ви хочете порівняти?

Вигода

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

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

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

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

Визначення конкуренції

Типовий огляд фокусується на 2-4 конкурентах. Щось більше може бути громіздким і дорогим для дослідження. Якщо у вас велика кількість конкурентів, зробіть початкове рев'ю, щоб визначити які продукти:

Пропонують схожий функціонал і пропозицію

-Пропонують кращий досвід користувача

Використовують інноваційний дизайн
Найсильніший і найважливіший ваш конкурент
Конкуренти, з якими вас порівняють найчастіше

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

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

Рев'ю експерта

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

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

Тестування на користувачах

Під час конкурентного тестування експерт проводить тест вашого дизайну і дизайну конкурентів. Кожен учасник виконує завдання на 2-3 продуктах. Тестування більше 3-х продуктів може бути не під силу для респондентів. Чергуйте показ сайтів для більш точного результату

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

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

Конкурсні оцінки

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

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

Аналіз результатів

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

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

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

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

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

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

Підказка щодо доступних розмірів клікабельних об'єктів

aldr_cwa — Mon, 08 May 2023 17:40:10 +0000

Переклад статті Віталія Фрідмана

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

Rage Taps, метрика розчарування користувачів, Колін Контрарі

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

Ви також можете знайти цілу відео-главу про дизайн для дотику в Smart Interface Design Patterns - разом з 30 іншими розділами, присвяченими UX та патернам дизайну.

Підказка щодо цільових розмірів.

Одна з поширених рекомендацій щодо цільових розмірів для мобільних пристроїв - 44×44 пікселів. Це трохи вводить в оману, оскільки пікселі екрану або, принаймні, незалежні від пристрою пікселі (dips) масштабуються до кратності роздільної здатності дисплея. Отже, на різних екранах пікселі відрізняються, і коли ми говоримо про розміри, ми, ймовірно, повинні говорити про dips, а не про пікселі.

Шпаргалка "Розміри цілей", досліджена та розроблена Стівеном Хубером (Steven Hoober).

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

Згідно з дослідженнями Стівена Хубера в його книзі "Сенсорний дизайн для мобільних інтерфейсів", щоб мінімізувати кількість натискань, нам потрібно прагнути до 11 мм (або 31 піксель на дюйм / 42 пікселі) у верхній частині екрану і 12 мм (або 34 пікселі / 46 пікселів) в нижній частині екрану. У центрі ми можемо зменшити розмір до 7 мм (або 20 пікселів на дюйм / 27 пікселів). Це включає в себе як ширину, так і товщину інтерактивного елемента.

Як перевести точкові одиниці в пікселі CSS або одиниці Android/iOS?

На щастя, Стівен Хубер (Steven Hoober) надає корисну таблицю перерахунку, яка допоможе вам перевести точки в одиниці px і em, SP або DP для Android, точки для iOS і DIP або px для Windows.

Не всі пікселі однакові.

Як ми бачили вище, розміри мішеней змінюються залежно від того, де компоненти з'являються на екрані. Варто зазначити, що згідно з вимогами WCAG 2.1 AAA, всі цілі повинні мати розмір щонайменше 44 на 44 пікселі, за винятком випадків, коли ціль знаходиться у реченні або блоці тексту. Для таких винятків ми можемо використовувати 27 пікселів, але загалом, чим більше, тим краще.

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

Для липких меню у верхній або нижній частині екрана нам, ймовірно, слід прагнути до 44-46 пікселів, а краще навіть більше. Однак для посилань, які з'являються на екрані, коли користувач прокручує сторінку вниз, ми, ймовірно, зможемо уникнути більшості проблем за допомогою менших компонентів.

Веб-сайти музею Франса Галса та данського громадського транспорту з 5 пунктами в нижньому меню.

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

Надання переваги кнопці "Дії" перед окремими піктограмами для таблиць даних.

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

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

Наведення на таблицю для системи дизайну Liferay.

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

Ніяких значків наведення не видно; замість них в інтерфейсі використовується кнопка "Дії", яка показує опції у вигляді накладання.

Надати асистента для складних маніпуляцій.

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

Шаблон помічника дозволяє користувачам переміщатися по об'єкту за допомогою маленької ручки праворуч. Приклад: Тилко.

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

Коли кілька кроків краще, ніж один.

Менше гнівних клацань: Мікроінтеракція Grønland Color Picker, розроблена Ніколасом Пуоджунасом (Mykolas Puodžiūnas).

Завжди максимізуйте область кліків.

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

Панелі навігації в ідеалі повинні бути на всю ширину, тому немає необхідності зосереджуватися саме на області посилань. (Копирайт изображения: Ахмад Шадід)

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

Ахмад Шадід (Ahmad Shadeed) наводить кілька корисних прикладів використання інтервалів для збільшення клікабельних областей і запобігання клікам гніву. Any Lupe надає ще більше рекомендацій у своїй статті про доступні розміри цілей.

Підбиваємо підсумки.

Падінги завжди корисні для будь-якого типу натискання: стилусом, курсором чи пальцем. З статті "Доступні розміри мішеней", Емі Лупе.

Особисто я б завжди збільшував розміри до 30×30px і 48×48px, щоб переконатися, що помилитися дуже складно. І, звичайно, завжди використовуйте повну ширину або повну висоту для областей, на які можна натиснути. Сподіваємось, це допоможе нам повністю усунути будь-які можливі "натискання гніву" з наших веб-сайтів - і багато ваших користувачів будуть щиро вдячні за це.

Ви можете знайти більше інформації про навігаційний UX у відеотеці про розумні патерни дизайну інтерфейсів 🍣 - з живим UX тренінгом, який відбудеться у вересні цього року.

Корисні ресурси

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

"Доступні розміри кнопок", Емі Лупе
"Сенсорні мішені на сенсорних екранах", Аврора Хейлі
"Розширення клікабельної зони", Ахмад Шадід
"WCAG 2.55 для кращих розмірів зони натискання", Тодд Ліббі
"Закон Фітта в епоху дотику", Стівен Хубер
"Сенсорний дизайн для мобільних інтерфейсів", Стівен Хубер
"Типи розміру для кожного пристрою", Стівен Хубер

Як уникнути типових помилок у дизайні кнопок

aldr_cwa — Wed, 03 May 2023 22:06:34 +0000

Переклад статті Адхама Даннавея

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

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

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

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

Поширені помилки під час проектування кнопок

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

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

Група кнопок 1

Щоб допомогти людям зі слабким зором розрізняти компоненти інтерфейсу (наприклад, межі полів форми для заповнення, кнопки та вкладки), зробіть так, щоб коефіцієнт контрастності кольорів був не меншим за 3:1. Декоративні стилі, які не потрібні для виділення компонентів інтерфейсу, можуть мати нижчий коефіцієнт контрастності.

У цьому прикладі коефіцієнт контрастності заливки вторинної кнопки ("Secondary") по відношенню до тла становить менше 3:1. Це занадто мало для того, щоб люди зі слабким зором могли чітко бачити форму кнопки. Хтось може заперечити, що заливка вторинної кнопки - декоративна і їй необов'язково відповідати коефіцієнту контрастності 3:1, щоб бути доступною. Але я вважаю, що заливка необхідна для того, щоб користувач міг ідентифікувати вторинну кнопку як інтерактивний елемент. Без заливки це просто звичайний синій текст, єдиною характеристикою якого є колір. Ми можемо додати обведення до вторинної кнопки, щоб вирішити цю проблему.

Група кнопок 2

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

Група кнопок 3

Щоб ширша аудиторія могла прочитати невеликий текст (18 пікселів і менше), він повинен мати контрастність кольорів щонайменше 4,5:1. Стилі кнопок у цьому прикладі мають наступні проблеми:

Коефіцієнт контрастності тексту на вторинній кнопці занадто низький і має становити щонайменше 4,5:1, щоб забезпечити її доступність.
Основна і додаткова кнопки конфліктують між собою через схожість стилів і недостатню контрастність. Це порушує візуальну ієрархію і робить незрозумілим, яка дія є найважливішою. Оскільки кнопки мають однаковий стиль, коефіцієнт контрастності повинен становити щонайменше 3:1, щоб їх можна було чітко розрізнити.

Група кнопок 4

Ці стилі кнопок мають схожі проблеми з попереднім прикладом:

Вторинна кнопка може бути сприйнята як неактивна через її світло-сірий колір.
Коефіцієнт контрастності тексту другорядної кнопки занадто низький і має становити щонайменше 4,5:1, щоб забезпечити її доступність.
Основна та додаткова кнопки також конфліктують між собою через схожий стиль та недостатню контрастність.

Група кнопок 5

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

Група кнопок 6

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

Стилі кнопок занадто схожі за контрастом і стилем, тому люди зі слабким зором не зможуть відрізнити їх один від одного
Коефіцієнт контрастності обведення третинної кнопки ("Tertiary") має бути щонайменше 3:1, щоб користувачі без зусиль зчитували її та чітко ідентифікували як інтерактивний елемент

Група кнопок 7

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

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

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

Група кнопок 8

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

Група кнопок 9

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

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

Пропозиція щодо кращих кнопок

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

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

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

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

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

7 законів UX, які ви, ймовірно, порушуєте.

aldr_cwa — Tue, 02 May 2023 15:49:27 +0000

Переклад статті BEN MOSS

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

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

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

1. Jakob’s Law

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

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

Однак, слово "перевага" має величезне навантаження. Хоча це правда, що користувачеві легше зрозуміти знайомий патерн дизайну, він не обов'язково надає перевагу знайомому досвіду.

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

2. Гіпотеза про градієнт цілей

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

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

Однак кожен, хто вивчав аналітику електронної комерції, знає, що відмова від кошика - це величезна проблема. У Північній Америці показник покинутих кошиків сягає 74%.

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

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

3. Закон Міллера

За всю історію людства жодне наукове твердження не було так неправильно зрозуміле, як закон Міллера.

Закон Міллера стверджує, що середньостатистична людина може утримувати в робочій пам'яті лише сім, плюс-мінус два (тобто від 5 до 9) об'єктів. Це часто використовується для того, щоб обмежити навігацію в інтерфейсі не більше ніж п'ятьма елементами.

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

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

4. Ефект естетичності та зручності використання

Едмунд Берк якось сказав: "Краса - це обіцянка щастя". Це переконання лежить в основі ефекту естетичності-корисності, який стверджує, що користувачі очікують, що естетично привабливі дизайни будуть більш зручними для використання.

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

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

5. Правило пікового кінця

Правило піку-кінця стверджує, що користувачі оцінюють досвід на основі того, що вони відчували на піку і в кінці, а не на основі середнього значення досвіду.

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

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

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

6. Закон Фіттса

У 1950-х роках Пол Фіттс продемонстрував, що відстань до цілі та її розмір впливають на частоту помилок при виборі цієї цілі. Іншими словами, важче натиснути маленьку кнопку і експоненціально важче натиснути маленьку кнопку, яка знаходиться далі.

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

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

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

7. Бритва Оккама

Жодна колекція законів UX не була б повною без "Бритви Оккама"; на жаль, це ще один закон, який часто неправильно застосовують.

Бритва Оккама стверджує, що при будь-якому виборі правильним є варіант з найменшими припущеннями (примітка: не обов'язково найпростіший, як його часто неправильно цитують).

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

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