Презентация Саши Куценко для семинара «Front-end разработка. Менеджерский блок», 29 января 2014 года, Санкт-Петербург. http://leadzeppelin.timepad.ru/event/101471/

1. Привет, я — Саша
из компании Aidem
29 января 2014
Front-end разработка. Менеджерский блок

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

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

4. Первое
Это не техническое задание.
Это про форму и поведение.

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

6. Что это?

7. Разделы документа
Вводная часть
1. Титульный лист
2. Версии документа
3. Введение
4. Цели проекта
5. Аудитория
6. Цели аудитории
7. Глоссарий
8. Бизнес
9. Продукт
10.Аналитика
11.Персонажи (бизнес роли)
12.Варианты использования
13.Инф. архитектура
Основная часть
14.Концептуальная логика
(напр. навигация, каталог)
15.Логика стандартных функций
(напр. поиск, рег-ция, оплата)
16.Логика специальных функций
(напр. система бон.баллов)
17.Экраны покупателя
18.Экраны менеджера (админа)
19.Стандартные элементы
20.Тексты писем / уведомлений
21.Данные (таблицы, хар-ки)
22.Требования к материалам
23.Общие требования
(дизайн, платформа, браузеры)

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

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

23. Зачем?

24. 1. Чтобы проектировщик сам понимал (сказать ≠ написать).
2. Ничего не упустить (представления в различных сценариях).
3. Чтобы оценить объем (дизайна, разработки, тестирования).
4. Чтобы минимизировать споры (неизменность решений).
5. Чтобы у разработчиков/тестировщиков было меньше вопросов.
6. Чтобы потом не переделывать («вовремя не подумали»).
7. Чтобы стандартизировать приемы и поведение (UX).
8. Чтобы получить консистенцию дизайна и элементов (UI).
9. Чтобы заложить векторы развития и масштабируемости.
10.Чтобы объединить команду одной идеей (все знают что делают).
11.Чтобы все (команда, заказчик) понимали, чего ждать.
12.Чтобы подписывать не бесполезные бумажки (ТЗ), а дело.
13.Чтобы сохранить общий уровень качества (размытие).

25. Кому?

26. 1. Bussiness owner: правильная конвертация концепции продукта
в форму.
2. Product owner: видение общей картины продукта
и его реализации на всех этапах.
3. Designers: понимание философии продукта, ощущений
и задач, которые должен решать дизайн.
4. Technical planners: основа для написания технических
требований (TRD).
5. Development managers: оценка и планирование процесса
реализации.
6. Developers: четкие инструкции по реализации интерфейса
и его поведения = минимизация вопросов дизайнерам.
7. QA engineers & Usability professionals: понимание сценариев
взаимодействия и поведения интерфейса, написание test cases.
8. Manual writers: основа для написания руководств
пользователя, помощи и пр.

27. Когда?

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

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

30. Что я хотел вам сказать?

31. 1. Внедряйте проектирование
Объясняйте какие выгоды от этого получите, и вы, и заказчик.
2. Вырабатывайте и используйте гайдлайны и стандарты
Стандартизация, уникальный визуальный язык, UX-стратегия
(особенно продуктовые компании).
3. Занимайтесь дизайном системно
С самого первого продукта компании. Это окупится.
4. Поднимайте качественный уровень проектов
Это даст новые, более финансово привлекательные проекты.
5. Используйте новые подходы в создании продуктов
Это повысит общий уровень знаний и возможностей команды.
6. Делайте качественные продукты.
Любите то, что делаете. Болейте за это.

32. Как?

33. Ответ на вопрос «Как?» заслуживает
отдельного доклада, а может
и нескольких.
До встречи!

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