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

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

26 марта 2014Мартовская встреча котов UXspb

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

Доклад

«

Алан Купер

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. ТребованияК материалам, дизайну, платформе, браузерам и пр.

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

На примере

Описание экрана

-‐ Задачи и сценарии использования (для сложных экранов)Предназначение экрана + степень покрытия вариантов использования

-‐ Представление по умолчанию (базовое разрешение)Основной сценарий взаимодействия, базовый регион, часовой пояс и пр.

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

-‐ Представления блоков во всех состояниях + описаниеПорядок изложения представлений должен соответствовать сценарию взаимодействия с ним пользователя. Различные разрешения, регионы и пр.

-‐ Параметры, значения, дополнительные схемыТипы данных, условия, допустимые значения, поясняющие схемы и пр.

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

-‐ Новая парадигмаРазработана, показана и описана новая концепция и философия продукта

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

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

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

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

Зачем?

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

Чтобы

Кому?

-‐ Business owner: правильная конвертация идеи продукта в форму-‐ Product owner: видение общей картины продукта

и его реализации на всех этапах-‐ Designers: понимание философии продукта, ощущений

и задач, которые должен решать дизайн-‐ Technical planners: основа для написания тех.требований (TRD)-‐ Development managers: оценка и планирование реализации-‐ Developers: четкие инструкции по реализации-‐ QA engineers & Usability professionals: понимание сценариев

взаимодействия и поведения интерфейса, написание test cases-‐ Manual writers: основа для написания руководств пользователя,

помощи и пр.

Когда?

-‐ Не типовая задачаБизнес ПО, сложный продукт или поведение

-‐ Есть идея, но не понятно что и как делатьСтартапы, новые версии продуктов

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

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

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

Когда

Итого

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

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

Пара рекомендаций

One more thing...

1. Документируйте вовремя. Писать спецификацию на этапе реализации уже поздно.

2. Описывайте все. Все равно останется масса не описанного.3. Пишите доступно. Позднее это избавит вас от лишних вопросов.4. Описывайте, как рассказ. Порядок и сюжетная линия облегчат

работу с документом другим участниками команды.5. Стандартизируйте приемы и элементы

Это упрощает, ускоряет, повышает надежность, дисциплинирует и 100% окупится на других этапах.

6. Не повторяйтесь. Макеты, содержащие элементы, описанные ранее, отнимают внимание от главного.

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

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

facebook.com/gurickslideshare.net/gurick

sasha@aidem.ruAidem.ru

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