Чарівний інтерфейс

Powered Interface
Якось на днях у мене виникла необхідність роздрукувати більше десяти чеків з моєї історії платежів, використовуючи банкомат одного з найбільших банків. Я перейшов у платежі, вибрав "Історія", прокрутивши скроллер списку до потрібного платежу, вибрав його, а потім натиснув кнопку «Операції» і вибрав друк. І так повторювалося для кожного чека: щоразу відбувався перехід в головне меню і все починалося заново. Я задумався — невже, незважаючи на велику кількість джерел інформації UX, досі витрачають величезні бюджети на подібні незручні інтерфейси? Чому розробники не хочуть робити інтерфейс, що дозволяє користувачеві відчути себе чарівником, а роблять користувачів безпорадними в досягненні своїх цілей? Можливо, причина в тому, що, незважаючи на достаток теорії, ці джерела надають мало прикладів з реальних проектів.
Так як ми буквально минулого тижня завершили великий Web-проект, в якому як раз стояла мета розробки зручного інтерфейсу, я вирішив висвітлити у статті, на які основні моменти при проектуванні інтерфейсу варто звернути увагу, і навів приклади нашого рішення.


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

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

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


Природа позитивного враження
Основою позитивного внутрішнього відчуття є привабливість дизайну інтерфейсу з боку чуття людини (зір, слух, смак, нюх, дотик). Зовнішній вплив стимулює роботу відповідного органу чуття, який передає інформацію в мозок. В результаті, людина сприймає це зовнішній вплив, у неї виникають позитивні або негативні відчуття. У випадку програмних інтерфейсів, впливом зазвичай є зовнішній вигляд інтерфейсу, а почуття — зір.
Чи є універсальні рецепти, як зробити так, щоб те чи інше вплив призводило до потрібного сприйняття?.. Як зрозуміти і оцінити, чи зробили ви гарний, привабливий інтерфейс? Відомий промисловий дизайнер Дітер Рамс у пошуках відповіді на ці питання, сформулював 10 принципів хорошого дизайну, підходять для будь-якого виду інтерфейсу. Також існує безліч джерел, де описані модні тенденції і типові рішення в проектуванні візуальних інтерфейсів. Незважаючи ні на що, той факт, наскільки зовнішній вигляд інтерфейсу сподобається користувачам, насамперед залежить від особистості дизайнера, який, у свою чергу, шукає натхнення де завгодно. Схоже, тут як і в живописі — як малювати портрет описано в будь-якому підручнику з основ образотворчого мистецтва, але Джоконду намалював тільки одна людина.
Ми в Dashboard повністю покладаємося на художній смак, інтуїцію та досвід нашого головного дизайнера.


Від новачка до експерта
Алан Купер рекомендує створювати інтерфейс так, щоб новачок швидко почав роботу, експерт знайшов потрібний йому функціонал, а середній користувач комфортно виконував свої повсякденні завдання. Представник кожної категорії користувачів не повинен бути роздратований інтерфейсом.
Dashboard ми зробили систему ненав'язливих «хлібних крихт», що вказують шлях на початковому етапі створення аналітичної панелі. Розглянемо найбільш типовий сценарій створення аналітичної панелі. Безпосередньо після підключення до джерела даних, користувач створює елементи. Першим кроком створення елемента є налагодження зв'язку його з полями джерела даних. Новачкові цього буде достатньо, щоб побачити початковий результат.
Новачок
Середній користувач продовжить роботу, змінюючи прості властивості, наприклад, заголовки або вид діаграми.
Середній користувач
Експерт задасть складні фільтраційні критерії або перейде у властивості Dashboard'а для створення власних обчислюваних полів або параметрів.
Експерт
Порівнюючи з аналогічним нашим рішенням під іншу платформу, помічаємо, що новачкові досить складно зрозуміти з чого почати. Область перетягування полів (Drag Area) не здається важливіше властивостей в стрічці (Ribbon) і якщо почати з властивостей у стрічці, то новий користувач не побачить змін в елементі.
Новачок (інша платформа)
Середнього користувача та експерта буде дратувати необхідність перемикання вкладок стрічки для переходу з властивостей елемента на загальні властивості аналітичної панелі.
Середній користувач (інша платформа)
Експерт (інша платформа)
Користувачі будь-якої категорії завжди будуть якийсь час замислюватися, на яку вкладку стрічки їм перейти, щоб знайти необхідну властивість. Їм буде дуже складно запам'ятати, які властивості необхідно шукати в стрічці, а які в діалогових вікнах області перетягування полів.


Ефективність користувача
Ефективність користувача при роботі з інтерфейсом повинна бути максимальною (повинно бути максимизировано корисна дія інтерфейсу). Це насамперед означає, що необхідний інструментарій для даного функціоналу легко знаходиться, розташований близько і доступний без «выцеливания», тобто як мінімум задовольняється закон Фиттса. З цього закону зокрема випливає, що часто використовувані меню і панелі інструментів оптимально розташовувати по чотирьох сторонах екрану (згадаймо Mac з його верхнім меню).
Сумно, але для додатків, що виконуються в оточенні браузера і випадків, коли необхідно показувати панелі списків і властивостей, що займають занадто багато місця, доводиться йти на компроміс. У нашій аналітичної панелі основна інструментальна панель створення елементів зафіксована зліва — це оптимальне місце для браузерного програми і користувачів, що читають зліва направо. Властивості всієї аналітичної панелі налаштовуються поуровнево через головне меню, спливаюче також ліворуч. Налагодження властивостей елементів знаходиться в їх контексті. При натисканні на елементі, з'являється меню, в якому можна вибрати тип загальних властивостей (згідно з даними, інтерактивність, загальні властивості) і налаштувати їх за допомогою спеціальних елементів управління, про які я розповім нижче. Меню мають достатній розмір, щоб вибір їх елементів не супроводжувався «выцеливанием», а елементи управління з'являються поверх елементів, не займає окреме місце, настільки цінне для простору аналітичної панелі.
Меню і панелі інструментів
Ефективність безпосередньо пов'язана з короткочасною пам'яттю, обсяг обмежений. «Гаманець Міллера» з 7± 2 елементи вже давно служить свого роду законом, але якщо спробувати узагальнити, то все, що перевантажує короткочасну пам'ять, буде знижувати ефективність користувача в процесі роботи з інтерфейсом.
Dashboard ми намагалися робити не більше 7 пунктів меню, редакторах властивостей та інших елементах на одному рівні ієрархії; пунктам давали короткі лаконічні назви.
Доведено, що складні ієрархії в інтерфейсі знижують ефективність користувача, тому їх скорочують або розділяють на модулі.
Нам було досить складно скоротити кількість ієрархій в редакторі властивостей елементів аналітичної панелі (гридов, діаграм тощо). Тут нам допоміг принцип «розділяй і володарюй», або, як зараз прийнято говорити — принцип модульності. Ми розділили налаштування властивостей на різні типи: BindingArea дозволяє візуально уявити елемент з точки зору зв'язків з даними, а контекстні PropertyAccordion'и — з точки зору властивостей (при цьому властивості об'єктів самої BindingArea також редагуються у спливаючому поруч вікні з PropertyAccordion). PropertyAccordion відображає властивості, згруповані в плоский список у вигляді елементів-редакторів і дозволяє редагувати лише одну таку розгорнуту групу (слайд).
BindingArea і PropertyAccordion
Класичний редактор властивостей був занадто нагроможденным і сложноиерархичным, а стрічка займала неприпустимо багато (16:9 моніторів) місця у верхній частині екрана і, як і область перетягування полів, вимагала створення безлічі різнотипних діалогових вікон, специфічних до налаштувань конкретного елемента.
Класичний редактор властивостей (інша платформа)
Стрічка і область перетягування полів (інша платформа)


Корисні звички
Якщо інтерфейс формує корисні звички, це стає його додатковим великим плюсом. Зрозуміти, що піде в підсвідомість користувача досить складно. Проте очевидно, якщо схожі процедури робляться схожим чином, якщо елемент своїм виглядом або розташуванням каже, що з ним потрібно зробити (натиснути, перетягнути, свайпнуть тощо), то подібні речі один раз усвідомлені, вже не виходять з мозку користувача. Також потрібно виключити можливість досягти однієї мети різними шляхами.
Ми в Dashboard зробили налаштування різних видів елементів однакової допомогою BindingArea і PropertyAccordion. Припустимо, користувач налаштовує зв'язки з даними діаграми. У BindingArea він бачить серії, аргументи і значення, вибирає поля джерела даних і налаштовує властивості PropertyAccordion. Потім, наприклад, налаштовуючи грід, він бачить в BindingArea колонки гріду, які по налаштуванню зв'язків з даними схожі з серіями діаграми, як і настроювання властивостей PropertyAccordion.
Параметри діаграми і гріду


Режими
NoModesПозбавитися від режимів в інтерфейсі іноді буває досить складно. Провідні фахівці з UX і HCI вже давно активно агітують за позбавлення від режимів. Відомий співробітник PARC і Apple Ларрі Теслер навіть на своєму авто мав номерний знак з написом «NOMODES» (до речі, і в Twitter Ларрі Теслера можна знайти по імені @nomodes).
Незважаючи ні на що, багато сучасні інтерфейси мають режими, і якщо при перемиканні між режимами інтерфейс належним чином не змінюється, і це може ввести користувача в оману. Наприклад, моя клавіатура Microsoft Natural Ergonomic дозволяє відключити F-режим (F Lock знаходиться поруч з часто використовуваної F12) і у мене періодично буває, що, натиснувши F5, я якийсь час не розумію, чому не відбувається те, що я очікую. Також у багатьох сучасних середовищах розробки в режимі виконання програми можна додавати/видаляти/редагувати модулі і т. п.
Dashboard нам вдалося виключити елементи, що мають різне поведінку в залежності від будь-якого режиму. Ми також не стали робити режим попереднього перегляду ви відразу працюєте з живими даними), не стали розділяти режим налаштування елементів і лэйаута аналітичної панелі. Однак ми зробили режим, змінює доступність редагування елементів перш за все із-за того, що редагування повинно бути доступна обмеженому числу користувачів. Крім того, при безпосередньому аналізі даних немає необхідності у багатьох вікнах налаштувань.
Режими: переглядач (для роботи бізнес-аналітика) і редактор (для адміністратора-творця аналітичних панелей)


Індикатори завантаження
Часто ми чуємо вираз «Як же це гальмує!». Програмісти впевнені: в цьому випадку потрібно оптимізувати і прискорювати ядро обчислень, запити до БД і т. п. Так, їм можна було б, наприклад, порекомендувати розпаралелювання операцій або кешування часто використовуваних даних… але як бути з інтерфейсом? В інтерфейсі необхідно зробити ненав'язливу систему "індикаторів завантаження", де можливо робити подвійну буферизацію, показувати стару «картинку» поки не отримана нова, а при складних зміни інтерфейсу застосовувати плавні анімації.
Dashboard відображає всі панелі з плавною анімацією. При інтерактивних діях (фільтрація і т. п.) з'являється індикатор завантаження в кутку елемента, лоадинг-індикатор має маленький розмір і показується на місці іконки меню, що додатково уникає зайвого промаргивания. Готовий посперечатися, що системи, де показується величезна крутиться лоадинг-панель в центрі кожного елемента, далекі від магії.
Лоадинг-індикатор


Всюдисущий скролінг
У будь-якому інтерфейсі, а особливо в multi-widget інтерфейсі, подібному аналітичним панелям, хотілося б уникнути якого-небудь скролінгу. Звичайно ж, в загальному випадку це неможливо. Але, як відомо, є низку важливих речей, які робляться для поліпшення ситуації, наприклад, де можливо позбавляються від горизонтального скролінгу. Крім цього, ми вважаємо займане scrollbar'ами місце суперечить принципу Едварда Тафти максимізувати співвідношення «корисні дані/чорнило».
Тому в Dashboard ми реалізували свій скролінг, який з'являється поверх контенту при наведенні миші (тобто за поведінкою схожий на той, що ми бачимо в останніх MacOS).
Звичайний скролінг
Ховається (контекстний) скролінг


«Відмінити дію?»
Люди люблять експериментувати, тому інтерфейс повинен уміти відміняти і повертати дію. В даний час системи з undo/redo вже стали стандартом, однак не всі з них позбавлені купи діалогів з підтвердженнями про введення чого-небудь. «Ви впевнені?» — запитують вони. Навіщо зайвий раз напружувати користувача, якщо є одна проста кнопка «Відміна»?
Dashboard дозволяє скасувати і повернути будь-яку дію без зайвих питань.
Undo/Redo


Перше правило юзабіліті (із застереженням)
Будь інтерфейс необхідно «обкатувати» на живих користувачів, спостерігати за ними, запитувати, чим вони керувалися, коли зробили саме так. При цьому ні в якому разі не слухати, що вони просять, окрім випадків, коли під час роботи з інтерфейсом користувач може виявити так звані «desire lines» і розповісти про них розробникам інтерфейсу, щоб не було відомої ситуації:
UX vs Design
Наприклад, я постійно намагався згорнути до цього несворачивающийся слайд PropertyAccordion. Багато користувачів очікували приховування панелі властивостей елемента BindingPanel при повторному натисканні на ньому (раніше повторне клацання не приховував панель, а доводилося натискати кнопку "<" в правому верхньому кутку панелі). Спочатку меню на елементі з'являлося по наведенню миші, і багато користувачів все одно робили додатковий клацання мишею, т. к. очікували виділення саме по клацанню.
Приклади «desire lines»
Знімаючи відео для цієї статті, я постійно відчував брак можливості натиснути Esc для закриття панелей. У документі з юзабіліті-тестування про гарячі клавіші згадали лише 10% користувачів і мова йшла насамперед про Delete.
Очевидно, що на практиці створення такого чарівного інтерфейсу буде ітеративним і, як правило, починається з мінімально життєздатного продукту.
Ми починали саме так і зробили не менше 5 прототипів, які проходили за сценаріями різних користувачів. Незважаючи на це, ми все ще CTP-версія і чекаємо ваших відгуків.


На закінчення хотілося б відзначити, що багато з розглянутих принципів можна і потрібно застосовувати при розробці будь-якого продукту, що має інтерфейс, будь то сушарка для рук або банкомат. Успіх компаній (Apple, Dyson тощо), що враховують ці принципи при розробці інтерфейсів різних пристроїв вже підстьобнув багатьох більш серйозно ставитися до нюансів людського сприйняття і зручності використання. Давайте разом спробуємо зробити життя простіше.
У нашому проекті ми намагалися дотримуватися принципів, описаних у наведених джерелах, частина яких я висвітлив у цій статті. Багато принципи були реалізовані інтуїтивно, на основі нашого досвіду розробки. При цьому в силу термінів на реалізацію проекту і людського фактора, деякі елементи інтерфейсу нам ще слід доопрацювати в бета-версії. Не виключено також, що ми щось упустили і переглянемо якісь принципові моменти.
Список використаних джерел[1] Джеф Раскін 'Інтерфейс', Символ-Плюс, 2010; стор 20
[2] Donald Norman 'Emotional design', Basic Books, 2004; стор. 21
[3] www.quora.com/What-is-a-mental-model
[4] Алан Купер 'Про інтерфейсі', Символ-Плюс, 2009; стор 127
[5] Алан Купер 'Про інтерфейсі', Символ-Плюс, 2009; стор 123
[6] Алан Купер 'Про інтерфейсі', Символ-Плюс, 2009; стор 109
[7] Jeff Gothelf 'Lean UX', o'reilly, 2013; стор 26
[8] www.vitsoe.com/us/about/good-design
[9] artgorbunov.ru/bb/soviet/20150202
[10] ru.wikipedia.org/wiki/Закон_Фиттса
[11] Р. Солс 'Когнітивна психологія', Пітер, 2012; стор 231
[12] psychclassics.yorku.ca/Miller
[13] en.wikipedia.org/wiki/Hick%27s_law
[14] Джеф Раскін 'Інтерфейс', Символ-Плюс, 2010; стор 123
[15] C. Y. Baldwin, K. B. Clark 'Design Rules, Vol. 1: The Power of Modularity', MIT – 2000
[16] Джеф Раскін 'Інтерфейс', Символ-Плюс, 2010; стор 39, гол. 2.3.1.
[17] www.nngroup.com/articles/progress-indicators
[18] Stephen Few 'Information Dashboard Design', o'reilly, 2012; стор. 50
[19] www.nngroup.com/articles/scrolling-and-scrollbars
[20] Edward R. Tufte 'The visual display of quantitative information', Graphics Press, 2009; стор 96
[21] asktog.com/atc/principles-of-interaction-design
[22] www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users
[23] Батлер Д., Лидвелл У., Холден К. 'Універсальні принципи дизайну', Пітер, 2012; стор 76
[24] Jeff Gothelf 'Lean UX', o'reilly, 2013; стор 55

Картинки:
[1] Кадр з фільму «Minority Report», (з) Dreamworks LLC and Twentieth Century Fox Film Corporation, 2002
[2] itsthedatastupid.files.wordpress.com/2010/05/nomodes.jpg
[3] guycooksondotcom.files.wordpress.com/2015/06/user-experience-vs-design.jpeg


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

0 коментарів

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