Доклад Юрия Куприянова на конференции Analyst Days-4, 17-18 апреля 2015 г., Минск www.analystdays.com

1. Анализ требований с
точки зрения UX
Юрий Куприянов

2. Who am I to lecture you?
Веб-дизайнер →
Программист → Аналитик →
Тимлид → Архитектор →
Руководитель проектов →
Проектировщик UX →
Директор по развитию →
Руководитель практики →
Директор по продуктам

3. Тренинги
Проектирование
интерфейсов
С Алиной Зотовой
Ergogames / UXcool.ru
Практика
разработки ТЗ на ПО
С Денисом Бесковым
school.system-analysis.ru

4. Проектирование
интерфейсов
«Интерфейсы – это,
оказывается, не про
кнопочки!»
Практика
разработки ТЗ на ПО
• 3 дня
• Выявление
требований
• Разработка
сценариев
использования
• 3 дня, из них 1,5 дня:
• Выявление
требований
• Разработка
сценариев
использования
«Мы это делаем не так.
Мы рисуем макеты
экранов, а к ним уже
пишем требования.»

5. Есть ли у вас в проекте…?

6. Про что читают аналитики:

7. Про что читают проектировщики:

8. 2 типа проектов
С аналитиками
• Сложная бизнес-логика /
структуры данных
• У пользователей нет
выбора
• Корпоративные системы
• Явно выделенные
процессы анализа
• Неявное проектирование
С
проектировщиками
• Добровольность
использования
• Бизнес зависит от
пользователей
• Продукты, массовые
сервисы
• Явно выделенные
процессы проектирования
• Неявная работа с
требованиями

9. 2 типа проектов
С аналитиками
• Сложная бизнес-логика /
структуры данных
• У пользователей нет
выбора
• Корпоративные системы
• Явно выделенные
процессы анализа
• Неявное проектирование
С
проектировщиками
• Добровольность
использования
• Бизнес зависит от
пользователей
• Продукты, массовые
сервисы
• Явно выделенные
процессы проектирования
• Неявная работа с
требованиями

10. Области ответственности
Системный
аналитик
•Полнота
•Однозначность
•Взаимосвязи
•Непротиво-
речивость
Проектировщик
•Эффективность
•Продуктивность
•Удовлетво-
ренность
•Контекст
использования
Целии
необходимые
функции

11. Разница точек зрения
Аналитик
• Смотрит на систему
«сверху»
Проектировщик
• Смотрит на систему с
точки зрения
пользователя

12. Разница точек зрения
Аналитик
• Смотрит на систему
«сверху»
Проектировщик
• Смотрит на систему с
точки зрения
пользователя

13. Типовые ошибки при
проектировании интерфейсов
• Интерфейс повторяет структуру хранения
данных («у вас из интерфейса база данных
торчит»), особенно – отношения master-
detail:
«Добавить участников
проекта можно только
после сохранения
карточки проекта»

14. Типовые ошибки при
проектировании интерфейсов
• Система ничего не помнит
• Система не бережет данные пользователя
• Система требует от пользователя высокой
точности манипуляций
• Система не терпит ошибок пользователя
• Система не вникает в типовую ситуацию
пользователя
• Система излишне строга к пользователю
• Система не уверена в себе

15. Что мы знаем о пользователе?
• Система Пользователь ничего не помнит
• Данные пользователя - самое ценное для
него
• Пользователю трудно работать с органами
управления (мышь, тачпад, сенсорная панель)
• Пользователь часто ошибается
• Пользователь занят своими делами (а не
системой). Очень занят! Но не системой!
• Пользователь часто отвлекается
• Пользователь плохо видит

16. Что готовит аналитик
• Роли пользователей
• Требования
– Функциональные
– Нефункциональные
• Сценарии использования
• Описание структур данных
– Словарь
• Бизнес-правила
• Ограничения
• Описание отчетов / макеты экранов

17. Что готовит аналитик
• Роли пользователей
• Требования
– Функциональные
– Нефункциональные
• Сценарии использования
• Описание структур данных
– Словарь
• Бизнес-правила
• Ограничения
• Описание отчетов / макеты экранов
Это уже решения

18. Что важно для UX: роли
• Роли пользователей:
– Сценарий (без системы / с системой)
– Какую проблему решает?
– Цели (рабочие / личные)
– Мотивы (внутренние / внешние)
– Какие решения принимает / совершает
действия (влияние на деятельность вне
системы)
– Кто хочет, чтобы пользователи
действовали именно так?

19. Что важно для UX: роли
• Роли пользователей:
– Сценарий (без системы / с системой)
– Какую проблему решает?
– Цели (рабочие / личные)
– Мотивы (внутренние / внешние)
– Какие решения принимает / совершает
действия (влияние на деятельность вне
системы)
– Кто хочет, чтобы пользователи
действовали именно так?
Бизнес-анализ?

20. Что важно для UX: роли
• Роли пользователей:
– Сценарий (без системы / с системой)
– Какую проблему решает?
– Цели (рабочие / личные)
– Мотивы (внутренние / внешние)
– Какие решения принимает / совершает
действия (влияние на деятельность вне
системы)
– Кто хочет, чтобы пользователи
действовали именно так?

21. Что важно для UX: данные
– Домен (допустимые значения, правила)
– Наиболее вероятные значения
• Или – желаемые для владельцев системы
– Предыдущие значения (что запоминать)
– Зависимость от значений других полей
– Важность по отношению к другим полям (в
контексте)
– Важность значений (сортировка по умолчанию)
– Обязательность для заполнения (в контексте)
– Варианты представления данных (точки
зрения)

22. Что важно для UX:
функциональные требования
• Важность действий:
– Самое важное действие в этом контексте?
(для пользователя или для владельца системы)
• Информация для выполнения действия:
– Какую основную информацию показать?
– Какую дополнительную информацию показать?
– Какую информацию не нужно показывать?
• Дополнительные действия:
– Что еще предложить сделать (в контексте)?
– Совершить обратное действие (до какого момента
возможно?)

23. Примеры
Наиболее
вероятные
значения?
Зависимости
между
содержимым
полей?

24. Какая информация
важна?
Примеры
Какое основное
действие?

25. Что важно для UX: ограничения
• Аппаратные платформы:
– Особенности потребления информации и
взаимодействия
– Какие варианты использования на какой
платформе?
• Технологии:
– Шаблоны интерфейса / типовые элементы
– Руководства по стилю
• Требования информационной безопасности
– Какую информацию нельзя показывать вместе?

26. Что важно для UX: правила
• Бизнес-правила:
– О чем нужно предупредить пользователя?
– Можно ли нарушить правило?
– Что можно посоветовать пользователю?
Правила, связанные с диапазонами данных
(сузить диапазон, расширить диапазон)
– Какие ошибки допустимы? До какого момента
их можно исправить?
• Состояния
– В каких состояниях может находиться система
/ объект?

27. Спасибо за внимание!
Вопросы?
yksi12@gmail.com
fb.me/yksi12
skype:
yury.kupriyanov