2. Who am I to lecture you?
Веб-дизайнер →
Программист → Аналитик →
Тимлид → Архитектор →
Руководитель проектов →
Проектировщик UX →
Директор по развитию →
Руководитель практики →
Директор по продуктам
4. Проектирование
интерфейсов
«Интерфейсы – это,
оказывается, не про
кнопочки!»
Практика
разработки ТЗ на ПО
• 3 дня
• Выявление
требований
• Разработка
сценариев
использования
• 3 дня, из них 1,5 дня:
• Выявление
требований
• Разработка
сценариев
использования
«Мы это делаем не так.
Мы рисуем макеты
экранов, а к ним уже
пишем требования.»
8. 2 типа проектов
С аналитиками
• Сложная бизнес-логика /
структуры данных
• У пользователей нет
выбора
• Корпоративные системы
• Явно выделенные
процессы анализа
• Неявное проектирование
С
проектировщиками
• Добровольность
использования
• Бизнес зависит от
пользователей
• Продукты, массовые
сервисы
• Явно выделенные
процессы проектирования
• Неявная работа с
требованиями
9. 2 типа проектов
С аналитиками
• Сложная бизнес-логика /
структуры данных
• У пользователей нет
выбора
• Корпоративные системы
• Явно выделенные
процессы анализа
• Неявное проектирование
С
проектировщиками
• Добровольность
использования
• Бизнес зависит от
пользователей
• Продукты, массовые
сервисы
• Явно выделенные
процессы проектирования
• Неявная работа с
требованиями
13. Типовые ошибки при
проектировании интерфейсов
• Интерфейс повторяет структуру хранения
данных («у вас из интерфейса база данных
торчит»), особенно – отношения master-
detail:
«Добавить участников
проекта можно только
после сохранения
карточки проекта»
14. Типовые ошибки при
проектировании интерфейсов
• Система ничего не помнит
• Система не бережет данные пользователя
• Система требует от пользователя высокой
точности манипуляций
• Система не терпит ошибок пользователя
• Система не вникает в типовую ситуацию
пользователя
• Система излишне строга к пользователю
• Система не уверена в себе
15. Что мы знаем о пользователе?
• Система Пользователь ничего не помнит
• Данные пользователя - самое ценное для
него
• Пользователю трудно работать с органами
управления (мышь, тачпад, сенсорная панель)
• Пользователь часто ошибается
• Пользователь занят своими делами (а не
системой). Очень занят! Но не системой!
• Пользователь часто отвлекается
• Пользователь плохо видит
16. Что готовит аналитик
• Роли пользователей
• Требования
– Функциональные
– Нефункциональные
• Сценарии использования
• Описание структур данных
– Словарь
• Бизнес-правила
• Ограничения
• Описание отчетов / макеты экранов
17. Что готовит аналитик
• Роли пользователей
• Требования
– Функциональные
– Нефункциональные
• Сценарии использования
• Описание структур данных
– Словарь
• Бизнес-правила
• Ограничения
• Описание отчетов / макеты экранов
Это уже решения
18. Что важно для UX: роли
• Роли пользователей:
– Сценарий (без системы / с системой)
– Какую проблему решает?
– Цели (рабочие / личные)
– Мотивы (внутренние / внешние)
– Какие решения принимает / совершает
действия (влияние на деятельность вне
системы)
– Кто хочет, чтобы пользователи
действовали именно так?
19. Что важно для UX: роли
• Роли пользователей:
– Сценарий (без системы / с системой)
– Какую проблему решает?
– Цели (рабочие / личные)
– Мотивы (внутренние / внешние)
– Какие решения принимает / совершает
действия (влияние на деятельность вне
системы)
– Кто хочет, чтобы пользователи
действовали именно так?
Бизнес-анализ?
20. Что важно для UX: роли
• Роли пользователей:
– Сценарий (без системы / с системой)
– Какую проблему решает?
– Цели (рабочие / личные)
– Мотивы (внутренние / внешние)
– Какие решения принимает / совершает
действия (влияние на деятельность вне
системы)
– Кто хочет, чтобы пользователи
действовали именно так?
21. Что важно для UX: данные
– Домен (допустимые значения, правила)
– Наиболее вероятные значения
• Или – желаемые для владельцев системы
– Предыдущие значения (что запоминать)
– Зависимость от значений других полей
– Важность по отношению к другим полям (в
контексте)
– Важность значений (сортировка по умолчанию)
– Обязательность для заполнения (в контексте)
– Варианты представления данных (точки
зрения)
22. Что важно для UX:
функциональные требования
• Важность действий:
– Самое важное действие в этом контексте?
(для пользователя или для владельца системы)
• Информация для выполнения действия:
– Какую основную информацию показать?
– Какую дополнительную информацию показать?
– Какую информацию не нужно показывать?
• Дополнительные действия:
– Что еще предложить сделать (в контексте)?
– Совершить обратное действие (до какого момента
возможно?)
25. Что важно для UX: ограничения
• Аппаратные платформы:
– Особенности потребления информации и
взаимодействия
– Какие варианты использования на какой
платформе?
• Технологии:
– Шаблоны интерфейса / типовые элементы
– Руководства по стилю
• Требования информационной безопасности
– Какую информацию нельзя показывать вместе?
26. Что важно для UX: правила
• Бизнес-правила:
– О чем нужно предупредить пользователя?
– Можно ли нарушить правило?
– Что можно посоветовать пользователю?
Правила, связанные с диапазонами данных
(сузить диапазон, расширить диапазон)
– Какие ошибки допустимы? До какого момента
их можно исправить?
• Состояния
– В каких состояниях может находиться система
/ объект?