Моделирование продукта с использованием бумажного прототипирования. Agilecamp, Новосибирск, ноябрь 2011
•Download as PPTX, PDF•
1 like•533 views
Нередки ситуации, когда дизайнеров рядом нет, а проект уже нужно запускать в разработку. Или — собран исчерпывающий бэклог, но не получается узреть, что собой будет представлять будущий продукт. Как увидеть и пощупать продукт, не выныривая из процесса сбора требований? Рассмотрим дешёвую в применении и в то же время изящную и простую практику на основе бумажного прототипирование и подхода к моделированию «Wizard of Oz». Agilecamp, Новосибирск, ноябрь 2011
Моделирование продукта с использованием бумажного прототипирования. Agilecamp, Новосибирск, ноябрь 2011
- 1. Wizard of Oz. Туда и обратно
- 2. Ситуация Собраны требования в виде Story map’а или в любом другом виде, но неясно, что именно необходимо построить
- 3. Идём к задаче • Нужно – увидеть софт – запустить разработку, • Но – некому моделировать – некогда ждать озарения
- 4. Проблемы с требованиями в виде Story Map • Смешивают абстракции разных уровней багофича • Навязывают разрозненные модели • Не показывают единую модель
- 6. Модель — способ воспринимать и думать о приложении или его части. нечто целостное, что потом становится паттерном
- 7. Игрушка. Требования • Развитие у детей от 0 до 3 лет – мелкой моторики – координации движений – восприятия цветов
- 12. Jesse James Garrett’s Elements of User Experience http://www.jjg.net/elements/
- 14. Обычно для появления модели… • Чистят требования • Уточняют сценарии • Эскизируют – структуру данных – диаграмму потока задач – первые экраны • Собирают в целое • Проверяют сборку • Корректируют или меняют модель
- 15. Целое нелинейное Создание хорошей модели похоже на решение нелинейного уравнения – нет общих методов – решение получают эвристически, итерационно – есть критерии сходимости
- 16. Что делать? • получить грубое решение раньше • ускорять итерирование и валидацию
- 19. Но в стиле Дядюшки Римуса, более интерактивные
- 21. Ход игры • Уговор о визуальном языке • Игрок: Что я вижу? • Мастер: – создает экран за 2 минуты – отвечает только визуально – исправления только, если Игрок зашел в тупик и не смог найти чего-то за ход • Игрок мыслит вслух, подаёт команды, спрашивает
- 22. Визуальные языки • Win/Mac GUI • Text UI • Ограниченный набор компонент: Telerik, ExtJS • …
- 24. Оба следуют требованиям, но отвечают за разное
- 26. Отличительные черты метода • Штурм, интенсивный забег • Скорость — убрать избыточный размышлизм • Метод поощряет ошибки Задача не продумать всё, а протоптать дорожку
- 27. Когда остановиться • Установить лимит – итераций – общего времени • Субъективное ощущение проработки сценариев
- 28. Отличие от классики • Обе роли проактивны • Отсутствие – наблюдателей – заранее созданного прототипа • Метод используется не только для проверки, но и для генерации
- 29. Пример • Один экран — одна локация • Задача: покинуть локацию • Играть должно быть интересно
- 32. Обратный ход • Игроки становятся мастерами • Мастеры уходят игроками в другую команду • Новые мастера на запросы игрока демонстрируют созданное решение • Ничего не дорисовывают • Недочёты и ошибки журналируют
- 34. Ревью процесса
- 35. Спасибо за внимание! Спасибо за внимание! Андрей Шапиро проектировщик интерфейса, руководитель проектов @xraizor andrew@ashapiro.ru