1. 1
UX дизайнер:
інструкція користувача
підготувала Таня Зав’ялова
Київ
22 листопада 2014

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

3. 3
Сьогодні розглянемо
Призначення частин
Популярні моделі
Основні технічні характеристики
Усунення несправностей
Розширені можливості

4. 4
4
Призначення
частин

5. 5
Голова
Модулі:
 збору інформації;
 обробки інформації;
 генерації ідей;
 передачі інформації
Використання голови на повну
можливе лише коли всі модулі задіяні
і підключені послідовно! https://www.behance.net/gallery/15430355/IN-THE-DESIGNERS-HEAD

6. 6
www.twolanescreative.com/Images/projects/AltusQ
AQ_head_heart.jpg
Серце
Модулі:
 самооцінки;
 співпереживання;
 перевірки ідей;
 і ще раз самооцінки
Під час активізації творчого процесу
серце і голова дизайнера
зливаються воєдино. Якщо такого
не трапляється – у вас підробка!

7. 7
Руки
Модулі:
 генерації ідей;
 перевірки ідей;
 реалізації ідей
Інколи руки дизайнера
намагаються підключити до чужої
голови, що надзвичайно обмежує
їх функціональність!
Maurits Cornelis Escher, ‘Drawing Hands’

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

9. 9
9
Популярні
моделі

10. 10
В 2014 в IT користуються попитом
User eXperience фацівці
дизайнери інтерфейсів
користувача
юзабіліті
спеціалісти
графічні
дизайнери
проектувальники
взаємодії
юзабіліті
аналітики

11. 11
Графічний дизайнер
РОБИТЬ КРАСИВО
Його задачі:
 загальний стиль;
 кольори;
 композиція;
 графіка:
• іконки;
• іллюстрації
http://www.klandreville.com/
Інструментарій: Photoshop и Illustrator

12. 12
Проектувальник взаємодії
РОБИТЬ
ФУНКЦІОНАЛЬНО
Його задачі:
 зрозуміти процес;
 написати сценарій;
 сформувати екрани;
 опрацювати поведінку
елементів керування
визначення взаємодії по Білу Ферпланку
Інструментарій: папір, діаграми, Axure, Balsamiq, etc.

13. 13
http://alistapart.com/article/quick-and
-dirty-remote-user-testing
Юзабіліті аналітик
ПЕРЕВІРЯЄ ЗРОЗУМІЛІСТЬ
І ЗРУЧНІСТЬ
Його задачі:
 знати користувача;
 виявити проблеми користувача;
 розставити пріоритети;
 відстоювати інтереси
користувача
Інструментарій: прототипи, користувачі, опитувальники і т.д.

14. 14
Юзабіліті спеціаліст
ПЕРЕВІРЯЄ І ПОПРАВЛЯЄ
ЗРОЗУМІЛІСТЬ І ЗРУЧНІСТЬ
Його задачі:
 знати користувача;
 виявляти його проблеми;
 пропонувати вирішення проблем
користувача у вигляді пропозицій до
покращення конкретних екранів,
послідовностей та процесів
 відстоювати інтереси користувача
Інструментарій: прототипи, користувачі, графічні інструменти і т.д.

15. 15
Дизайнер інтерфейсів користувача
РОБИТЬ КРАСИВО
І ФУНКЦІОНАЛЬНО
Його задачі:
 бачення додатку,
як єдиного цілого;
 функціональне
наповнення екранів;
 стиль, кольори і
поведінка
елементів керування
itschapps.com в работе
Інструментарій: зазвичай відразу і Photoshop, і Illustrator, і Axure, etc.

16. 16
Майстер переживаннь (UX фахівець)
ПОВЕЛИТЕЛЬ ЛЮДСЬКИХ
ЕМОЦІЙ
Його задачі:
 знати і відчувати
тонкощі людської душі;
 впроваджувати в інтерфейс
інструменти, що її зворушать;
 і як окремий випадок,
робити зручно, красиво
і функціонально
Інструментарій: все, що він вважає необхідним

17. 17
17
Технічні
характеристики

18. 18
Обов’язкові характеристики
 відчуття прекрасного;
 поінформованість про стан
технічного прогресу;
 уміння читати
думки замовника
на відстані;
 генерація ідей;
 уміння відображати свої думки
на екрані

19. 19
Додаткові характеристики
 внутрішня врівноваженість;
 системне мислення;
 управління часом;
 планування;
 знання тонкщів
технічної реалізації;
 високі комунікативні
здібності;
 уміння відображати свої думки
на папері

20. 20
20
Усунення
несправностей

21. 21
Типи несправностей
НЕСТАЧА КОМУНІКАЦІЇ
НЕВИПРАВДАНІ
СПОДІВАННЯ
ВІДСУТНІСТЬ
ПРОЦЕСУ
ВІДСУТНІСТЬ
ПРОЗОРОСТІ
КОНФЛІКТ
ІНТЕРЕСІВ

22. 22
Результати дослідження
Запропонований дизайн не передбачає
всіх нюансів поведінки додатку
80.5 0.51
Реалізація не така красива, як дизайн 75.0 0.47
На розроблених дизайнером екранах
присутні не всі функції
67.5
0.42
В разробці вже дев’ята версія дизайну
досі не реалізованого продукту
61.5 0.39
Дизайнер наполягає на одному рішенні, тоді як
аналітик чи замовник наполягає на іншому
58.5 0.37
Екрани та функціональні елементи погано узгоджені:
різне розміщення, кольори, шрифти
51.5 0.32
Опитано 106 респондентів
з них 33 менеджера, 36 розробників, 44 аналітика, 17 дизайнерів (є суміщені
ролі)

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

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

25. 25
Приклад несправностей №1
Запропонований дизайн не передбачає
всіх нюансів поведінки додатку:
присутні не всі функції,
передбачені не всі режими роботи…
Причина №3
хтось з команди попросив
прибрати чи додати функцію
і всі забули
Рішення
забезпечити прозорість комунікації

26. 26
Приклад несправностей №2
Реалізація не така красива,
як дизайн
Причина №1
дизайн не передбачає
обмежень середовища, в якому
розробляється додаток
Рішення:
команда розробки має впевнитися, що і дизайнери,
і аналітики знайомі з використовуваним фрейворком

27. 27
Приклад несправностей №2
Реалізація не така красива,
як дизайн
Причина №2
погано задокументований
дизайн, розробникам
доводиться вигадувати
Рішення:
процес, що передбачає ведення документації
і передачу знань

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

29. 29
Приклад несправностей №3
В разробці вже дев’ята версія дизайну
досі не реалізованого продукту
Причина
немає відповідального
за дизайн або вибір концепції
не аргументовано
Рішення:
визначити цілі, фокус,
призначити вланика і відповідального за дизайн

30. 30
Приклад несправностей №4
Дизайнер наполягає на одному
рішенні, тоді як аналітик
чи замовник наполягає на іншому
Причина №1
різні вихідні дані
Рішення:
налагодити регулярний обмін отриманими
даними, такими, як коментарі замовника, технічні
особливості і т.п. на регулярних зустрічах

31. 31
Приклад несправностей №4
Дизайнер наполягає на одному
рішенні, тоді як аналітик
чи замовник наполягає на іншому
Причина №2
відстоюються інтереси різних
зацікавлених сторін: користувача,
замовника чи розробника
Рішення:
поговорити, намагаючись зрозуміти іншу точку
зору, та знайти компроміс

32. 32
Приклад несправностей №5
Екрани та функціональні
елементи погано узгоджені:
різне розміщення, кольори,
шрифти
Причина №1
точкова робота над проектом
за відсутності бачення більшої картини
Рішення:
процес роботи має забезпечувати створення
такої картини (наприклад шляхом спілкування)

33. 33
Приклад несправностей №5
Екрани та функціональні
елементи погано узгоджені:
різне розміщення, кольори,
шрифти
Причина №2
різні люди відповідають за різні частини системи і
погано спілкуються між собою
Рішення:
спілкування, документація, процес

34. 34
Приклад несправностей №5
Екрани та функціональні
елементи погано узгоджені:
різне розміщення, кольори,
шрифти
Причина №3
розробники створюють деякі екрани
без консультації з відповідальним дизайнером
Рішення:
підготовка мокапів і/або узгодження готових екранів

35. 35
35
Додаткові
можливості

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

37. 37
життєвий цикл проекта
ініціація
вимоги
архітектура
розробка
тестування
здача
$
t
вартість помилки

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

39. 39
додаткова цінність дизайну
ініціація
вимоги
архітектура
розробка
тестування
здача
ми робимо
продукт
правильно?

40. 40
додаткова цінність дизайну
ініціація
вимоги
архітектура
розробка
тестування
здача
що і як
ми зробили?

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

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

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

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

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

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

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

48. 48
Підсумуємо
UX дизайн – це інженерна професія
у дизайнерів є спеціалізації
існують різні фактори оцінки доцільності дизайну
є поняття дизайн-прецесу
важливо спілкуватись

49. 49
дякую
tanya.zavyalova@gmail.com