Саша Куценко: "Cпецификация формы и поведения —...

Привет, я — Сашаиз компании Aidem

29 января 2014Front-end разработка. Менеджерский блок

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

Доклад

«

Алан Купер

cooper.com

Спецификация формыи поведения — единственный способ соединить дизайнс разработкой продукта.»

«

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

Первое

Место в продуктовой документации

1. User Requirements Document (﴾URD)﴿Об аудитории продукта и потребностях пользователей

2. Product Requirements Document (﴾PRD)﴿О том, как продукт решает потребности пользователей

3. Form & Behavior Specification (﴾F&B spec)﴿О том, как продукт выглядит и как себя ведет

4. Technical Requirements Documnet (﴾TRD)﴿О том, как продукт будет разрабатываться и работать

Что это?

Разделы документаВводная часть

1. Титульный лист2. Версии документа3. Введение4. Цели проекта5. Аудитория6. Цели аудитории7. Глоссарий8. Бизнес9. Продукт10.Аналитика11.Персонажи (бизнес роли)12.Варианты использования13.Инф. архитектура

Основная часть14.Концептуальная логика

(напр. навигация, каталог)15.Логика стандартных функций

(напр. поиск, рег-ция, оплата)16.Логика специальных функций

(напр. система бон.баллов)17.Экраны покупателя18.Экраны менеджера (админа)19.Стандартные элементы20.Тексты писем / уведомлений21.Данные (таблицы, хар-ки)22.Требования к материалам23.Общие требования

(дизайн, платформа, браузеры)

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

На примере

В итоге спецификация «BoomBate»

1. Новая парадигмаРазработана, показана и описана новая концепция продукта.

2. 28 уникальных экрановПоказаны все базовые экраны каждой бизнес-роли продукта.

3. 94 различных представлений экрановПоказаны все возможные представления экранов и отдельных блоков во различных сценариях использования.

4. 10+ вспомогательных схем и описанийСхемы бизнес-процессов, инф.арх-ры, вар.использования, параллельности задач, ментально-программной модели и пр.

5. 116 страниц спецификацииГотовая и полная инструкция для разработки нового продукта.

Зачем?

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

Кому?

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: основа для написания руководств пользователя, помощи и пр.

Когда?

1. Когда не типовая задачаБизнес ПО, сложный продукт или поведение.

2. Когда есть идея, но не понятно что и как делатьСтартапы, новые версии продуктов.

3. Когда много интерфейсов (﴾существующий продукт)﴿Требуется стандартизация, консистенция, дизайн-стратегия.

4. Когда есть временной/географический разрыв в командеВ создании продукта участвуют разные компании или невозможен прямой контакт разных участников команды.

5. Когда проектирование — отдельный проектСпецификация — документ, который подписывается и используется в дальнейших этапах реализации продукта с минимальным привлечением дизайнеров (не желательно).

На самом деле почти всегда.

Итого

Спецификация формы и поведения является важнейшим компонентом успешной разработки продукта.

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

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

1. Внедряйте проектированиеОбъясняйте какие выгоды от этого получите, и вы, и заказчик.

2. Вырабатывайте и используйте гайдлайны и стандарты Стандартизация, уникальный визуальный язык, UX-стратегия (особенно продуктовые компании).

3. Занимайтесь дизайном системноС самого первого продукта компании. Это окупится.

4. Поднимайте качественный уровень проектовЭто даст новые, более финансово привлекательные проекты.

5. Используйте новые подходы в создании продуктовЭто повысит общий уровень знаний и возможностей команды.

6. Делайте качественные продукты.Любите то, что делаете. Болейте за это.

Как?

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

До встречи!

+7 (812) 380-79-29mailbox@aidem.ru

facebook.com/gurickslideshare.net/gurick

sasha@aidem.ruAidem.ru

презентация здесь