Презентация Саши Куценко для UXspb в офисе Яндекса, 26 марта 2014 года, Санкт-Петербург. http://ux-spb.ru/26-marta-v-yandekse-ux-beyond-ui-ierarhiya-potrebnostey-i-motivatsiya-polzovateley/

1. Привет, я — Саша
из компании Aidem
26 марта 2014
Мартовская встреча котов UXspb

2. Спецификация
формы и поведения:
зачем кому и как?»
Доклад
«

3. Алан Купер
cooper.com
Спецификация формы
и поведения — единственный
способ соединить дизайн
с разработкой продукта.»
«

4. Место в продуктовой документации
1. User Requirements Document (﴾URD)﴿
Об аудитории продукта и потребностях пользователей
2. Product Requirements Document (﴾PRD)﴿
О том, как продукт решает потребности пользователей
3. Form & Behavior Specification (﴾F&B spec)﴿
О том, как продукт выглядит и как себя ведет
4. Technical Requirements Documnet (﴾TRD)﴿
О том, как продукт будет разрабатываться и работать

5. Структура документа
1. Вводная часть
Титульный лист, версии документа,
введение, цели проекта, глоссарий
2. Аудитория
Аудитория, цели и задачи аудитории
3. Бизнес
Бизнес-модель, бизнес-процессы
4. Аналитика
Отчеты, метрики, маркетинговые
исследования, выводы
5. Персонажи (﴾бизнес-‐роли)﴿
Портрет, цели, потребности, варианты
использования, сценарии поиска
6. Концепция
Ключевая идея продукта, принцип
взаимодействия, инф.архитектура
7. Логика станд.функций
Навигация, каталог, регистрация,
поиск, система бон.баллов и пр.
8. Экраны
Пользователя, администратора
9. Станд.элементы интерфейса
Поля, списки, переключатели, ошибки,
уведомления, меню и пр.
10.Тексты
Писем, уведомлений, ошибок, смс
11.Данные
Таблицы, параметры, характеристики
12.Требования
К материалам, дизайну, платформе,
браузерам и пр.

6. Спецификации внутреннего
ПО купонного сервиса
На примере

12. Описание экрана
-‐ Задачи и сценарии использования (для сложных экранов)
Предназначение экрана + степень покрытия вариантов использования
-‐ Представление по умолчанию (базовое разрешение)
Основной сценарий взаимодействия, базовый регион, часовой пояс и пр.
-‐ Описание блоков экрана (в состоянии по умолчанию)
Делятся условно по задаче / шагу / смысловому значению / вариативности и тп.
Все взаимодействия: навели, нажали, убрали курсор, прокрутили и т.д. + анимация.
-‐ Представления блоков во всех состояниях + описание
Порядок изложения представлений должен соответствовать сценарию
взаимодействия с ним пользователя. Различные разрешения, регионы и пр.
-‐ Параметры, значения, дополнительные схемы
Типы данных, условия, допустимые значения, поясняющие схемы и пр.

17. В итоге спецификация «BoomBate»
-‐ Новая парадигма
Разработана, показана и описана новая концепция и философия продукта
-‐ 28 уникальных экранов
Показаны и описаны все базовые экраны каждой бизнес-роли
-‐ 94 различных представлений экранов
Показаны представления экранов и отдельных блоков в различных сценариях
использования
-‐ 10+ вспомогательных схем
Схемы бизнес-процессов, информационной архитектуры, вариантов
использования, параллельности задач, ментально-программной модели и пр.
-‐ 116 страниц спецификации
Готовая развернутая инструкция для разработки нового продукта

18. Зачем?

19. -‐ Прочувствовать продукт
-‐ Ничего не упустить (сказать ≠ написать)
-‐ Оценить объем дизайна, разработки, тестирования
-‐ Минимизировать вопросы и споры разных участников
-‐ Стандартизировать приемы и поведение (UX)
-‐ Получить консистенцию дизайна и элементов (UI)
-‐ Сохранить общий уровень качества (размытие)
-‐ Все понимали, чего ждать. И команда, и заказчик.
Чтобы

20. Кому?

21. -‐ Business owner: правильная конвертация идеи продукта в форму
-‐ Product owner: видение общей картины продукта
и его реализации на всех этапах
-‐ Designers: понимание философии продукта, ощущений
и задач, которые должен решать дизайн
-‐ Technical planners: основа для написания тех.требований (TRD)
-‐ Development managers: оценка и планирование реализации
-‐ Developers: четкие инструкции по реализации
-‐ QA engineers & Usability professionals: понимание сценариев
взаимодействия и поведения интерфейса, написание test cases
-‐ Manual writers: основа для написания руководств пользователя,
помощи и пр.

22. Когда?

23. -‐ Не типовая задача
Бизнес ПО, сложный продукт или поведение
-‐ Есть идея, но не понятно что и как делать
Стартапы, новые версии продуктов
-‐ Есть временной/географический разрыв в команде
В создании продукта участвуют разные компании или невозможен прямой
контакт разных участников команды
-‐ Много интерфейсов (﴾существующий продукт)﴿
Требуется стандартизация, консистенция, дизайн-стратегия
-‐ Проектирование — это услуга
Спецификация подписывается и используется в дальнейших этапах реализации
продукта с минимальным привлечением дизайнеров (не желательно)
Когда

24. Итого
Спецификация формы и поведения
является важнейшим компонентом
успешной разработки продукта.
Она экономит время и деньги, делая
команду более сплоченной, а процесс
более стабильным и предсказуемым.

25. Пара рекомендаций
One more thing...

26. 1. Документируйте вовремя. Писать спецификацию на этапе
реализации уже поздно.
2. Описывайте все. Все равно останется масса не описанного.
3. Пишите доступно. Позднее это избавит вас от лишних вопросов.
4. Описывайте, как рассказ. Порядок и сюжетная линия облегчат
работу с документом другим участниками команды.
5. Стандартизируйте приемы и элементы
Это упрощает, ускоряет, повышает надежность, дисциплинирует и
100% окупится на других этапах.
6. Не повторяйтесь. Макеты, содержащие элементы, описанные
ранее, отнимают внимание от главного.
7. Обязательно заканчивайте. Не описанная логика или экран
непременно аукнуться в будущем.

27. +7 (812) 380-79-29
mailbox@aidem.ru
facebook.com/gurick
slideshare.net/gurick
sasha@aidem.ruAidem.ru
презентация здесь