Проектуючи Google Material Design на десктопну систему... (частина третя)



Короткий зміст другий частини: редизайн розділу «Операції» (воронка продажів), підбір кольорів для всіх стадій, відступи — повітря — свобода… Упс… Клієнт, ти серйозно? Взяти й запхати тепер все в 1370х768?!.. Прощайте «відступи — повітря — свобода»… Довелося перейти в «стиснутий» стиль.

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

Почну з того, що приділю трохи уваги скорочень текстів для кожної стадії завдань. Так, уважному читачеві велику кількість троеточий різало око. Описові рядка ніяк не хотіли поміщатися хоч мало-мальськи. Навіть не дивлячись на третичность тексту за значимістю (як ви пам'ятаєте з другої частини: спочатку цифра, потім співробітник, потім опис угоди). Особливо сильно це спливло після постановки задачі: «укласти 6 стовпців у 1366 або померти».

Потім з'ясувалося, що третичен саме людина. Назва угоди стало другим за значимістю, після її вартості. Окей. Припустимо. Але що робити і з обрезаными заголовками і описом, яке суперечило ще однієї задачі «укласти 4 видимих угоди для кожного з 6 стовпців?

Клік — це і рішення, і компроміс! Вирішили, що зробимо так, що по кліку картка роз'їжджається, фіксується і підводиться тінню (референс на GMD версію гугл.плюс):



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

Табличний вигляд

Настав час поговорити про альтернативної версії відображення даних в CRM „Chronos“ — табличному вигляді. Потенціал для такого виду вже був закладений в старій версії:



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



Традиційно спробував почати зі значними відступами. Раз не вдалося напустити повітря в „Операції“, значить спробуємо просочити їм таблиці:



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

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



Розкадровка по відгуку „кошика“ на виділення будь рядки:



Налаштування відображення стовпців, безумовно, повинні бути:



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

І в кінці стадії робіт за таблицями вже традиційно (сумний смайлик) „відкачуємо повітря“ з макета...:



Помітили як „Пошук“ очолив тепер меню? З'ясувалося, що в CRM-ке потрібно надати пошуку трохи більший пріоритет. Рішення віддавати під пошукові результати ліву панель меню я знаходжу дуже ергономічним і ефективним. Простенька розкадровка-кликоэмитация:



» Редагування операції

Велика кількість і безліч форм у різних розділах системи — неминуча необхідність. Будь-яка угода всередині CRM супроводжується об'ємним кількістю даних, які співробітник вводить вручну:



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



Крім цього для кожної операції відразу ж видно останні таски і коментарі (наприклад, зелені — це коментарі, сині — це таски). Прямо з екрану співробітник міг створити новий таск по цій угоді:



Або просто залишити коментар для колег:



Вибудовуємо власний сценарій

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



" Редагування клієнта

Трохи пізніше з'ясувалося, що може знадобитися догляд редагування клієнта, при редагуванні/створенні угоди. Була додана посилання «редагувати», вона вела в новий екран для досягнення цієї мети:



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



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

Загальний вигляд екрана редагування клієнта:



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



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

Тому моє завдання перш полягала в тому, щоб підпорядкувати всі переходи між екранами в Chronos'e єдиним правилом! Схематично, я б відбив його якось так:



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

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

0 коментарів

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