Your SlideShare is downloading. ×
0
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agile-командах

2,178

Published on

Методики декомпозиции инженерных задач в кроссфункциональной команде программистов хорошо изучены на данный момент. Как быть с декомпозицией на независимые задачи с случае с дизайном интерфейса и …

Методики декомпозиции инженерных задач в кроссфункциональной команде программистов хорошо изучены на данный момент. Как быть с декомпозицией на независимые задачи с случае с дизайном интерфейса и проектированием взаимодействия не всегда понятно, в особенности для молодых команд.

Общее стремление одновременно повысить скорость и качество разработки, приводит к тому, что специалисты в области опыта взаимодействия всё чаще включаются в agile-команды. Как лучше устроить процесс с этом случае. Что следует проектировать сначала, что можно проектировать независимо и что можно отложить на будущие итерации без страха получить несочленимые компоненты. Как без ущерба разделить то, что, по определению, должно быть целостным.

Published in: Design
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,178
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Ключ к решению лежит в балансировании между   несколькими подходами
  • Как и «управление временем» выражение «проектирование опыта взаимодействия» переворачивает всё с ног на голову и стоит понимать, что имеется здесь в виду.
  • Где здесь User Stories? Почему сбор данных предусмотрен только в основании пирамиды? Почему так ватерфольно?
  • Самый простой пример такого вырождения. Структура предполагала участие не более двух пользователей в диалоге, а понадобилось сделать чат с несколькими. Или представим, что заказчики Почтовой программы захотели делать видеозвонки адресатам.
  • Сюда иллюстрацию и
  • Проектировщик взаимодействия натренирован рассматривать опыт цельно. Разбиение на части не поддерживающие workflow, по началу трудно, но даётся со временем.
  • Образные примеры
  • Итерируйте бумажные прототипы. Разработка прототипа в компьютерной системе всегда дороже, это уже разработка, а не можелирование, и не нужна на этапе моделирования
  • Что делать если ядро не успели создать на нулевой итерации
  • Transcript

    • 1. « Шустрый » дизайн Как делить неделимое Андрей Шапиро проектировщик интерфейса, руководитель проектов
    • 2. О чём будем говорить <ul><li>В чем суть проблемы, что такое опыт взаимодействия ( User Experience, UX ) и   можно ли его проектировать </li></ul><ul><li>Как включать проектирование взаимодействия в  Agile разработку </li></ul><ul><li>Способы разделения дизайна на части </li></ul>
    • 3. Agile + UX = ? <ul><li>Scrum и XP молчат об инкрементальности дизайна </li></ul><ul><li>Конфликт двух способов мышления </li></ul><ul><ul><li>Проектировщики взаимодействия «заточены» на целостный подход — Big picture </li></ul></ul><ul><ul><li>Разработчики фокусируются на итеративно-инкрементальной разработке </li></ul></ul><ul><li>Сомнения насчет применимости инженерных практик в случае с UX </li></ul><ul><ul><li>Как можно померить UX? И как тогда этим управлять, если это нельзя измерить. </li></ul></ul>
    • 4. UX «на пальцах». Можно ли его проектировать? Первый опыт общения с приложением не передал пользователю ничего о его действительных назначении и  способах взаимодействия. Любой на планете Земля встретив сейчас объект, напоминающий по   форме масляную лампу, попробует потереть его, усвоив идиому из сказки. дизайн -&gt; усвоение, опыт -&gt; дизайн
    • 5. Что входит в такое «проектирование» <ul><li>Сбор информации о задачах и опыте взаимодействия пользователей </li></ul><ul><ul><li>методы работы </li></ul></ul><ul><ul><li>способы мышления </li></ul></ul><ul><ul><li>особенности восприятия </li></ul></ul><ul><li>Проектирование с учетом имеющихся данных о культурном, нишевом и личном опыте </li></ul><ul><li>Моделирование инноваций в интерфейсе на свой страх и риск </li></ul><ul><li>Проверка того, что получилось, через сбор информации </li></ul>повод для итеративности?
    • 6. 10 лет пирогу Гарретта Компоновка Элементы интерфейса Навигация Структура стоимость изменений Jesse James Garrett’s Elements of User Experience http://www.jjg.net/elements/ Информационный дизайн Проектирование взаимодействия Информацион. архитектура UX через призму разработки
    • 7. Уровни опыта взаимодействия по Гарретту <ul><li>Водопадная модель </li></ul><ul><li>Возможно вырождение </li></ul><ul><li>Сбор данных только в основании пирамиды? </li></ul><ul><li>Неясно как прикрутить к  разработке </li></ul>«Раскраска» Структура Требования Стратегия Компоновка
    • 8. <ul><li>мировая практика </li></ul>Как включать проектирование взаимодействия в  Agile разработку
    • 9. Agile + UX = как ? Опыт мирового Agile- сообщества <ul><li>Проектируйте вперёд хотя бы на одну итерацию </li></ul><ul><li>Отделите проектирование от разработки — используйте для этого параллельный трек </li></ul>Lynn Miller
    • 10. Отделение дизайна от разработки <ul><li>После нулевой итерации треки разработки и проектирования разделяются </li></ul><ul><li>Итерации в треках идут раздельно, но одновременно и сопровождаются частой взаимной обратной связью </li></ul><ul><li>Проектировщики в конце каждой итерации поставляют разработчикам инкремент дизайна, реализующийся в следующей итерации </li></ul><ul><li>Трек проектирования идет всегда хотя бы на одну итерацию впереди </li></ul><ul><li>Акцент на потенциально отгружаемые инкременты по которым можно получить обратную связь от конечного пользователя </li></ul>
    • 11. Параллельные треки разработки и проектирования
    • 12. К чему вы должны быть готовы при двух треках <ul><li>Очень быстро станет понятно, что не хватает ресурсов </li></ul><ul><li>Тройная нагрузка в  UX- команде. Увеличение времени разработчиков </li></ul>
    • 13. Agile + UX = как ? Опыт мирового Agile- сообщества <ul><li>Сделайте проектировщиков взаимодействия частью продуктовой команды </li></ul><ul><li>Отделите моделирование от дизайна </li></ul><ul><ul><li>Моделирование: уровень структуры </li></ul></ul><ul><ul><li>Дизайн: уровни компоновки и раскраски </li></ul></ul>
    • 14. Agile + UX = как ? Опыт мирового Agile- сообщества <ul><li>Проектируйте в команде и повышайте ее дизайнерскую грамотность </li></ul><ul><li>Найдите способы выигрывать время на проектирование </li></ul><ul><li>Разделите работы по проектированию на части </li></ul>0-я итерация Сложные для разработки, но простые для дизайна задачи
    • 15. Agile + UX = как ? Опыт мирового Agile- сообщества <ul><li>Прототипируйте в общих чертах, без излишней детализации. На бумаге дешевле всего. </li></ul><ul><li>Используйте прототип в качестве спецификации </li></ul>
    • 16. Agile + UX = как ? Опыт мирового Agile- сообщества <ul><li>Улучшайте прототипы циклически внутри одной итерации проектирования по методике RITE </li></ul>RITE — Rapid Iterative Testing and Evaluation
    • 17. Agile + UX = как ? Опыт мирового Agile- сообщества <ul><li>Выжимайте всё из   встреч с пользователем </li></ul><ul><li>Культивируйте группу пользователей для непрерывного мониторинга продукта </li></ul>
    • 18. Основной прорыв исходит из двух тезисах <ul><li>Активности в нулевую итерацию </li></ul><ul><li>Отделение моделирования, проектирования и дизайна от разработки </li></ul>
    • 19. Нулевая итерация <ul><li>Длится 2-3 недели и завершается до старта разработки </li></ul><ul><li>Моделируется ядро: элементы информационной архитектуры и важнейшие особенности взаимодействия </li></ul><ul><li>Определяется «большая картина» продукт, на которой будут основаны все последующие инкременты дизайна и неясные пока части </li></ul><ul><li>Что на выходе </li></ul><ul><ul><li>определен уровень «Структуры» и часть «Компоновки» по Гаррету </li></ul></ul><ul><ul><li>определена общая концепция дизайна </li></ul></ul><ul><li>Результаты обсуждены со всеми заинтересованными лицами и разработчиками для прикидки сложности исполнения </li></ul>
    • 20. Как организуют процесс UX + Agile в  Autodesk
    • 21. Как организуют процесс в Autodesk <ul><li>Проектировщик интерфейса входит в продуктовую команду </li></ul><ul><li>Сосредоточение на дизайне необходимом сейчас </li></ul><ul><li>Часть фич может быть сделана наполовину в угоду завершению продукта вовремя </li></ul><ul><li>Итерирование дизайна методом RITE . Ранний поиск ошибок на этапе дизайна. Дизайн до встройки изменяется столько сколько необходимо и сколько позволяет время </li></ul><ul><li>Итерации разработки и проектирования производятся раздельно, но синхронно </li></ul><ul><li>Большие области проектирования делятся на «куски», которые можно охватить в итерации и могут быть инкрементально добавлены в общий дизайн </li></ul>
    • 22. Руководство к разбиению <ul><li>Чётко определить цели проектирования и   обозначить общее направление, в котором движется дизайн </li></ul><ul><li>Убедиться, что каждый «кусок» большого дизайн последовательно достигает ряда целей, закрепляемых на планировании итерации </li></ul><ul><li>Ранние «куски» должны быть фундаментальными и низкоуровневыми. Ими становятся такие особенности дизайна, которые не изменятся, сколько новых кубиков вы на них не поставите </li></ul>
    • 23. Пример требований. Цели дизайна <ul><li>«Перемещение курсора должно быть минимальным при переключении между перемещением, поворотом и масштабированием </li></ul><ul><li>Взаимодействие должно быть плавным и естественным </li></ul><ul><li>Пользователь должен обнаружить как позиционировать выбранную область, но не обязательно в первый час работы </li></ul><ul><li>Функция должна работать схожим образом со слоями» </li></ul>Компонент перемещения поворота и масштабирования в программе Sketchbook Pro 2
    • 24. Пример
    • 25. Требования на UX- итерацию <ul><li>Похожи на User Stories </li></ul><ul><li>Короткие </li></ul><ul><li>Конкретные </li></ul><ul><li>Содержат цели, которым должен отвечать проектируемый «кусок» </li></ul>
    • 26. Что можно проектировать позже <ul><li>Прототипы, зависящие от незавершенной части кода или технологии. </li></ul><ul><li>Всё, что относится к уровню процесса ( workflow) в противовес операционному функциональному уровню. </li></ul><ul><li>Дополнительный навигационный дизайн для сопровождения пользователя по приложению в целях обучения, например. </li></ul><ul><li>Части являющиеся концентраторами для других. Пример, палитра кистей в Sketchbook Pro . </li></ul>
    • 27. И это всё?
    • 28. Общая методология разбиения <ul><li>Сначала низкоуровневые, фундаментальные части, которые не изменятся при добавлении других частей </li></ul><ul><li>Формирование граничных условий для будущей «склейки» </li></ul><ul><li>Формирование целей и граничных условий на текущую стадию дизайна </li></ul>
    • 29. Этап целостного дизайна <ul><li>Смысл и назначение. Это должно быть определено чётко на само раннем этапе </li></ul><ul><li>Модель представления — навязываемая пользователю ментальная модель </li></ul><ul><li>Процесс, способ работы, понимание как достичь результата </li></ul>Целостного видения, а значит проработки на начальном этапе требуют
    • 30. Проработки на начальном этапе требуют <ul><li>Концепция модели представления </li></ul><ul><li>Информационная и   функциональная структуры </li></ul><ul><li>Процесс, если он является значимой частью модели </li></ul><ul><li>Сетка </li></ul><ul><li>Рекомендации по   организации блоков </li></ul><ul><li>Первое приближение навигации </li></ul>В компоновке В структуре
    • 31. Что делится легко и безболезненно <ul><li>Отдельные экраны операционного уровня </li></ul><ul><li>Улучшение поведения отдельных элементов и   блоков интерфейса </li></ul><ul><li>Второстепенная навигация </li></ul><ul><li>Всё уровня «раскраски» </li></ul>
    • 32. Как процесс устроен у нас <ul><li>Стараемся держаться впереди на итерацию с   задачами проектирования </li></ul><ul><li>Применяем иногда быстрое прототипирование в продукте на основе бумажных эскизов и   библиотеки элементов и паттернов проекта </li></ul><ul><ul><li>Разработчик готовит боевой прототип, который становится частью продукта </li></ul></ul><ul><ul><li>Тут же тестируем на пригодность </li></ul></ul><ul><ul><li>Если фича хорошо показала себя и не выкинута, проходимся «тяжелым» дизайном </li></ul></ul>
    • 33. Артефакты продуктовой команды. Мы используем… <ul><li>Бумажные прототипы </li></ul><ul><li>2 синхронизируемых бэклога: продуктовой команды и команды разработчиков </li></ul><ul><li>Доска задач по результатам пользовательского тестирования. Доска улучшений интерфейса </li></ul><ul><li>Наборы элементов и паттернов, собственные интерфейсные словари проектов </li></ul><ul><li>Журналы </li></ul><ul><ul><li>наблюдения за поведением пользователей продукта </li></ul></ul><ul><ul><li>обратной связи с пользователями </li></ul></ul><ul><ul><li>пользовательских тестирований </li></ul></ul>
    • 34. Доска задач по результатам UX- тестирования
    • 35. ЭРГО <ul><li>Моделирование целостной части в фундаменте (нулевой итерации) </li></ul><ul><li>Инкрементальное проектирование кусков в итерациях </li></ul><ul><li>Итерирование внутри итерирования . RITE. </li></ul><ul><li>Богатейшая работа с пользователем на каждой итерации </li></ul>
    • 36. Напутствие и рекомендации проектировщику <ul><li>Тренируйте особенно эти 2 навыка </li></ul><ul><ul><li>как не сделать развивающийся продукт заложником выбираемой модели </li></ul></ul><ul><ul><li>что важно успевать сделать в нулевую итерацию </li></ul></ul><ul><li>Откладывайте окончательный выбор модели представления насколько это возможно </li></ul>
    • 37. Напутствие и рекомендации проектировщику <ul><li>Прекратите проектировать в одиночку </li></ul><ul><li>Инвестируйте время в повышение UX- грамотности команды </li></ul><ul><li>Собирайте библиотеку подходов, идиом, паттернов поведения, найденных при юзабилити тестах для каждого проекта и для команды в целом </li></ul>
    • 38. Напутствие и рекомендации проектировщику <ul><li>Оставайтесь как можно дольше на бумаге </li></ul>
    • 39. Напутствие и рекомендации проектировщику <ul><li>Итерируйте бумажные прототипы — это дешевле и   быстрее </li></ul>
    • 40. Напутствие и рекомендации проектировщику <ul><li>Участвуйте в формулировании критериев приёмки при планировании итерации разработки </li></ul>Фичи на оранжевом, критерии приёмки на синем P.S.: Помните, люди не любят изменения. Они в   любом случае будут встречать их с недовольством.
    • 41. Что почитать на эту тему <ul><li>Jeff Patton , agileproductdesign.com </li></ul><ul><li>Anders Ramsay, andersramsay.com </li></ul><ul><li>Austin Govella, thinkingandmaking.com </li></ul><ul><li>Desiree Sy , Adapting Usability Investigations for Agile User-centered Design </li></ul><ul><li>Lynn Miller, Case Study of Customer Input For a Successful Product </li></ul><ul><li>Sandy Mamoli , nomad8.com </li></ul><ul><li>Jesse James Garrett , jjg.net </li></ul>
    • 42. Спасибо за внимание! Андрей Шапиро проектировщик интерфейса, руководитель проектов Спасибо за внимание! @ xraizor andrew @ ashapiro.ru x-raizor.livejournal.com
    • 43. Процесс моделирования в нулевой итерации <ul><li>Сбор данных об ограничениях из требований </li></ul><ul><li>Откидывание углублений, усовершенствований и привнесенных требований </li></ul><ul><li>Построение диаграмм близости, ментальных моделей, первые наброски процессов — все это только для того чтобы появились первые цельные образы в голове </li></ul><ul><li>Далее идет серия итераций синтеза и проверки первоначальных идей через быстрое эскизирование и  проверку бумажных прототипов </li></ul>
    • 44. Процесс моделирования в нулевой итерации <ul><li>Продумывание процесса взаимодействия и выявления граничных условий, которым должны соответствовать «кубики» для поздней склейки </li></ul><ul><li>Отделение всех операционных частей, они пойдут на позднюю проработку </li></ul><ul><li>Первые эскизы макетов </li></ul>
    • 45. Процесс моделирования в нулевой итерации <ul><li>Проверка макетов и сущностей на состоятельность и работоспособность </li></ul><ul><li>Проверка в кругу основной команды </li></ul><ul><li>Формирование ядра и проверка на наращиваемость </li></ul><ul><li>Запуск в разработку прототипа с минимальной неопределенностью </li></ul><ul><li>Разработка оставшихся неясностей. </li></ul>

    ×