UX Дезайнер: Інструкція з користування

Post on 14-Jul-2015

154 views 3 download

Transcript of UX Дезайнер: Інструкція з користування

1

підготувала Таня Зав’ялова

UX дизайнер: інструкція користувача

Київ

22 листопада 2014

2

Більшість користувачів

заглядає в інструкцію,

якщо :

вже щось зламали,

хочуть розібратися з

новою

функціональністю

Який випадок ваш?

3

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

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

Основні технічні характеристики

Сьогодні розглянемо

Розширені можливості

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

4

4

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

5

Голова

Модулі:

збору інформації;

обробки інформації;

генерації ідей;

передачі інформації

Використання голови на повну

можливе лише коли всі модулі задіяні

і підключені послідовно! https://www.behance.net/gallery/15430355/IN-THE-DESIGNERS-

HEAD

6

www.twolanescreative.com/Images/projects/AltusQ

AQ_head_heart.jpg

Серце

Модулі:

самооцінки;

співпереживання;

перевірки ідей;

і ще раз самооцінки

Під час активізації творчого процесу

серце і голова дизайнера

зливаються воєдино. Якщо такого

не трапляється – у вас підробка!

7

Руки

Модулі:

генерації ідей;

перевірки ідей;

реалізації ідей

Інколи руки дизайнера

намагаються підключити до чужої

голови, що надзвичайно обмежує

їх функціональність!

Maurits Cornelis Escher, ‘Drawing Hands’

8

Ноги

Модулі:

транспортування;

дослідження;

захисту від негативної дії

навколишнього

середовища

Дизайнер просто зобов’язаний знати світ

у всьому його різноманітті, бо те,

що він створює багато в чому передає

його власний досвід

9

9

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

10

В 2014 в IT користуються попитом

User eXperience фацівці

дизайнери інтерфейсів

користувача

юзабіліті

спеціалісти

графічні

дизайнери

проектувальники

взаємодії

юзабіліті

аналітики

11

Графічний дизайнер

РОБИТЬ КРАСИВО

Його задачі:

загальний стиль;

кольори;

композиція;

графіка:

• іконки;

• іллюстрації

Інструментарій: Photoshop и Illustrator

http://www.klandreville.com/

12

Проектувальник взаємодії

РОБИТЬ

ФУНКЦІОНАЛЬНО

Його задачі:

зрозуміти процес;

написати сценарій;

сформувати екрани;

опрацювати поведінку

елементів керування

Інструментарій: папір, діаграми, Axure, Balsamiq, etc.

визначення взаємодії по Білу Ферпланку

13

http://alistapart.com/article/quick-and

-dirty-remote-user-testing

Юзабіліті аналітик

ПЕРЕВІРЯЄ ЗРОЗУМІЛІСТЬ

І ЗРУЧНІСТЬ

Його задачі:

знати користувача;

виявити проблеми користувача;

розставити пріоритети;

відстоювати інтереси

користувача

Інструментарій: прототипи, користувачі, опитувальники і т.д.

14

Юзабіліті спеціаліст

ПЕРЕВІРЯЄ І ПОПРАВЛЯЄ

ЗРОЗУМІЛІСТЬ І ЗРУЧНІСТЬ

Його задачі:

знати користувача;

виявляти його проблеми;

пропонувати вирішення проблем

користувача у вигляді пропозицій до

покращення конкретних екранів,

послідовностей та процесів

відстоювати інтереси користувача

Інструментарій: прототипи, користувачі, графічні інструменти і т.д.

15

Дизайнер інтерфейсів користувача

РОБИТЬ КРАСИВО

І ФУНКЦІОНАЛЬНО

Його задачі:

бачення додатку,

як єдиного цілого;

функціональне

наповнення екранів;

стиль, кольори і

поведінка

елементів керування

Інструментарій: зазвичай відразу і Photoshop, і Illustrator, і Axure, etc.

itschapps.com в работе

16

Майстер переживаннь (UX фахівець)

ПОВЕЛИТЕЛЬ ЛЮДСЬКИХ

ЕМОЦІЙ

Його задачі:

знати і відчувати

тонкощі людської душі;

впроваджувати в інтерфейс

інструменти, що її зворушать;

і як окремий випадок,

робити зручно, красиво

і функціонально

Інструментарій: все, що він вважає необхідним

17

17

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

18

Обов’язкові характеристики

відчуття прекрасного;

поінформованість про стан

технічного прогресу;

уміння читати

думки замовника

на відстані;

генерація ідей;

уміння відображати свої думки

на екрані

19

Додаткові характеристики

внутрішня врівноваженість;

системне мислення;

управління часом;

планування;

знання тонкщів

технічної реалізації;

високі комунікативні

здібності;

уміння відображати свої думки

на папері

20

20

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

21

Типи несправностей

НЕСТАЧА КОМУНІКАЦІЇ

НЕВИПРАВДАНІ

СПОДІВАННЯ

ВІДСУТНІСТЬ

ПРОЦЕСУ

ВІДСУТНІСТЬ

ПРОЗОРОСТІ

КОНФЛІКТ

ІНТЕРЕСІВ

22

Результати дослідження

Запропонований дизайн не передбачає

всіх нюансів поведінки додатку80.5 0.51

Реалізація не така красива, як дизайн 75.0 0.47

На розроблених дизайнером екранах

присутні не всі функції

67.50.42

В разробці вже дев’ята версія дизайну

досі не реалізованого продукту61.5 0.39

Дизайнер наполягає на одному рішенні, тоді як

аналітик чи замовник наполягає на іншому58.5 0.37

Екрани та функціональні елементи погано узгоджені: різне розміщення, кольори, шрифти

51.5 0.32

Опитано 106 респондентів

з них 33 менеджера, 36 розробників, 44 аналітика, 17 дизайнерів (є суміщені

ролі)

23

Приклад несправностей №1

Запропонований дизайн не передбачає

всіх нюансів поведінки додатку:

присутні не всі функції,

передбачені не всі режими роботи…

Причина №1

некоректно передано вимоги

Рішення:

налагодити процес передачі та

контролю актуальності вимог у

текстовій формі

24

Приклад несправностей №1

Запропонований дизайн не передбачає

всіх нюансів поведінки додатку:

присутні не всі функції,

передбачені не всі режими роботи…

Причина №2

вимоги змінювались після початку

роботи над дизайном

Рішення

контроль за актуальністю

25

Приклад несправностей №1

Запропонований дизайн не передбачає

всіх нюансів поведінки додатку:

присутні не всі функції,

передбачені не всі режими роботи…

Причина №3

хтось з команди попросив

прибрати чи додати функцію

і всі забули

Рішення

забезпечити прозорість комунікації

26

Приклад несправностей №2

Реалізація не така красива,

як дизайн

Причина №1

дизайн не передбачає

обмежень середовища, в якому

розробляється додаток

Рішення:

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

і аналітики знайомі з використовуваним фрейворком

27

Приклад несправностей №2

Реалізація не така красива,

як дизайн

Причина №2

погано задокументований

дизайн, розробникам

доводиться вигадувати

Рішення:

процес, що передбачає ведення документації

і передачу знань

28

Приклад несправностей №2

Реалізація не така красива,

як дизайн

Причина №3

розробники не приділяють

належної уваги реалізації

запропонованого дизайну

Рішення:

процес, що передбачає донесення важливості та рецензію

впровадженого дизайну і тісну работу дизайнера з іншими

29

Приклад несправностей №3

В разробці вже дев’ята версія дизайну

досі не реалізованого продукту

Причина

немає відповідального

за дизайн або вибір концепції

не аргументовано

Рішення:

визначити цілі, фокус,

призначити вланика і відповідального за дизайн

30

Приклад несправностей №4

Дизайнер наполягає на одному

рішенні, тоді як аналітик

чи замовник наполягає на іншому

Причина №1

різні вихідні дані

Рішення:

налагодити регулярний обмін отриманими

даними, такими, як коментарі замовника, технічні

особливості і т.п. на регулярних зустрічах

31

Приклад несправностей №4

Дизайнер наполягає на одному

рішенні, тоді як аналітик

чи замовник наполягає на іншому

Причина №2

відстоюються інтереси різних

зацікавлених сторін: користувача,

замовника чи розробника

Рішення:

поговорити, намагаючись зрозуміти іншу точку

зору, та знайти компроміс

32

Приклад несправностей №5

Екрани та функціональні

елементи погано узгоджені:

різне розміщення, кольори,

шрифти

Причина №1

точкова робота над проектом

за відсутності бачення більшої картини

Рішення:

процес роботи має забезпечувати створення

такої картини (наприклад шляхом спілкування)

33

Приклад несправностей №5

Екрани та функціональні

елементи погано узгоджені:

різне розміщення, кольори,

шрифти

Причина №2

різні люди відповідають за різні частини системи і

погано спілкуються між собою

Рішення:

спілкування, документація, процес

34

Приклад несправностей №5

Екрани та функціональні

елементи погано узгоджені:

різне розміщення, кольори,

шрифти

Причина №3

розробники створюють деякі екрани

без консультації з відповідальним дизайнером

Рішення:

підготовка мокапів і/або узгодження готових екранів

35

35

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

36

життєвий цикл проекта

ініціація

вимоги

архітектура

розробка

тестування

здача

37

життєвий цикл проекта

ініціація

вимоги

архітектура

розробка

тестування

здача

$

t

вартість помилки

38

додаткова цінність дизайну

ініціація

вимоги

архітектура

розробка

тестування

здача

ми створюємоправильний

продукт?

39

додаткова цінність дизайну

ініціація

вимоги

архітектура

розробка

тестування

здача

ми робимопродукт

правильно?

40

додаткова цінність дизайну

ініціація

вимоги

архітектура

розробка

тестування

здача

що і як ми зробили?

41

що і коли можемо робити

ініціація вимоги архітектура розробка тестування здача

визначення цілей,аналіз котекстута конкурентів

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і як ми зробили?

42

що і коли можемо робити

ініціація вимоги архітектура розробка тестування здача

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і якми зробили?

дослідженнязадач користувача,розробката валідаціяконцепції

43

що і коли можемо робити

ініціація вимоги архітектура розробка тестування здача

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і якми зробили?

інформаційна архітектура,порядок екранів, переходи,перші прототипита їх валідація

44

що і коли можемо робити

ініціація вимоги архітектура розробка тестування здача

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і якми зробили?

подальша деталізація,опрацювання потенційнихпроблемних ситуацій,передача знань

45

що і коли можемо робити

ініціація вимоги архітектура розробка тестування здача

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і якми зробили?

тестуванняз залученнямкористувачівта експертнаоцінка

46

що і коли можемо робити

ініціація вимоги архітектура розробка тестування здача

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і якми зробили?

зворотнійзв’язок

47

артефакти

ініціація вимоги архітектура розробка тестування здача

ми створюємо правильнийпродукт?

ми робимо продукт правильно?

що і якми зробили?

визначення цілей,аналіз котекстута конкурентів

дослідженнязадач користувача,

розробката валідація

концепції

інформаційнаархітектура,

порядок екранів, переходи,

перші прототипита їх валідація

подальша деталізація,опрацюванняпотенційних

проблемних ситуацій,передача знань

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

оцінка

зворотнійзв’язок

звіт

концепція у виглядіекранів, сторібордів,

відео чиінтерактивного

прототипаUX специфікація високого рівня

деталізована UXспецифікація,гід по стилю

звіт з перелікомзнайдених проблем і пропозицій щодо

покращення

перелікпокращень на майбутні версії

48

UX дизайн – це інженерна професія

у дизайнерів є спеціалізації

існують різні фактори оцінки доцільності дизайну

Підсумуємо

важливо спілкуватись

є поняття дизайн-прецесу

49

дякую

tanya.zavyalova@gmail.com