Ux lean: Lean UX — мелочи для успешных проектов / Хабр

Lean UX — мелочи для успешных проектов / Хабр

Автор: Анастасия Режепп, глава дизайн-студии DataArt.

В этой статье я немного расскажу о методологии Lean UX-дизайна и дам несколько техник и упражнений, показывающих, как ее применять.

Часто у нас возникает следующая проблема: к нам приходит клиент со стартапом: у него есть некая общая идея, а конкретного он ничего сказать не может, т. к. не знает точно, какие функции хотел бы добавить в продукт, а какие убрать. Наша цель — помочь ему в этом разобраться. И в этом нам может помочь метод Lean UX-дизайна.

Что значит “lean”

Слово “lean” переводится на русский как «тощий», «худой», «постный». Если переводить этот термин более специальным образом, то — «бережливый», «экономный», «минималистический». Например, уже есть термин «бережливое производство» — перевод английского “lean production”. Бережливое производство подразумевает постоянное устранение всех видов потерь — это достигается, в том числе, максимальной ориентацией на потребителя. То же самое верно и для подхода бережливого (тощего) UX-дизайна.

Принципы бережливого UX-дизайна

Когда мы следуем методу тощего UX-дизайна, есть несколько моментов, на которые стоит обратить внимание:

• Мы понимаем целевую аудиторию и ее проблемы.
• Мы создаем MVP (Minimum Viable Product — минимально жизнеспособный продукт).
• Мы работаем короткими итерациями.
• Мы постоянно тестируем нововведения на пользователях и, если что-то не так, быстро откатываемся.
• Мы работаем командой: UX-проектировщики, дизайнеры, разработчики и тестировщики работают вместе и постоянно обмениваются мнениями и задачами.

Как работать с MVP

Как происходит работа с минимально жизнеспособным продуктом, с MVP? Мы берем тощий, но жизнеспособный продукт (т. е. с необходимыми функциями, которые могут кого-то заинтересовать) и постепенно на него наращиваем мясо, мышцы, жир — новые функции и свойства. В результате продукт всё больше растет и пользуется всё большим успехом на рынке (по крайней мере, мы на это рассчитываем). Это происходит, потому что мы сразу ориентируемся на конечного пользователя и растем в нужном направлении.

Если мы работаем по бережливому принципу с минимально жизнеспособным продуктом, мы должны:

• Сформулировать видение продукта.
• Сформулировать бизнес-задачи.
• Сформулировать роли пользователей, понять их задачи и цели.
• Соорудить прототип продукта.
• Протестировать его.
• Начать всё заново.

Сейчас так работают уже очень многие.

Зачем нужна «космическая ручка»

Чтобы сразу же двигаться в нужном направлении, важно учесть один важный момент. Часто, недостаточно продумав саму проблему, мы очень быстро перескакиваем сразу в пространство ее решения и действуем уже там. Так бывает не только при разработке приложений, но и в жизни.

Я приведу наглядный пример из области городских легенд — пример «космической ручки». Говорят, что в 1965 г. NASA дало заказ на разработку ручки, которой космонавты могли бы писать в условиях невесомости. За разработку ручки взялась компания Fisher. В итоге «космическая ручка» разрабатывалась целый год (ее и сейчас можно купить в магазинах, между прочим), и на ее разработку потратили значительные средства. «Космической ручкой» действительно можно пользоваться в космосе. В то же время советские ученые предложили собственное решение этой проблемы — простой карандаш. Такая вот русская «космическая ручка», которую и разрабатывать даже не надо.

Это городская легенда (основанная, впрочем, на фактах — просто немного искаженных), но это для нас сейчас неважно. Важно, что на примере этой истории мы можем ясно увидеть, как одни находились в области решения проблемы (это NASA), а другие (советские ученые) — в области самой проблемы. Ведь проблема была не в том, чтобы разработать ручку, которая пишет в космосе, а в том, что космонавтам нужен инструмент, чтобы документировать свои наблюдения. И решение этой проблемы может оказаться очень простым — просто нужно сначала обдумать саму проблему, а не тут же бросаться её решать.

Не «как», а «что»

Чтобы не перескакивать сразу в пространство решения, нужно исходить из правильных вопросов. Важно не начинать тут же думать,

как

мы что-то сделаем: перед этим стоит подумать,

что

мы делаем и

зачем

. Поэтому правильная последовательность вопросов такова:

зачем? -> что? -> как?

Например, бывает, приходит клиент и говорит: «Мое приложение мало кто скачивает — наверное, нужно сделать другую целевую страницу (landing)… Вот я посмотрел, у людей красивые целевые страницы, с анимацией и фотографиями — сделайте что-нибудь похожее». И мы не успеваем оглянуться, как у нас уже пять дизайнеров рисуют анимацию, ищут картинки и т. д. А проблема, может быть, вовсе не в целевой странице — может быть, нужно что-то добавить в приложение, чтобы оно стало пользоваться успехом.

Найти восхититель: модель Кано

И тут я перехожу к следующему упражнению: как нам решить, что добавлять, а что не добавлять в наше приложение — так, чтобы его развитие шло в верном направлении. Я назвала это упражнение «Найти восхититель».

Это упражнение основано на так называемой модели Кано — она была разработана японцем Нориаки Кано лет 50 назад. Согласно теории Кано, у любого продукта все его качества и функции делятся на 3 категории:

• Must-haves (основные, базовые качества).
• Performance benefits (ожидаемые качества).
• Delighters (привлекательные качества, или восхитители).

• Основные качества — то, что должно быть обязательно. Без них продукт существовать на рынке не будет — без этих качеств он просто никому не нужен.
• Ожидаемые качества — те, которые хотел бы увидеть пользователь. Их можно и нужно улучшать. Ведь если вы их увеличиваете и улучшаете, то удовлетворенность пользователя плавно растёт.
• Восхитители, или привлекательные качества —те, что пользователь вообще не ожидает увидеть, но, если он их получает, очень рад.

Теперь проиллюстрируем применение метода Кано на примере свиньи-копилки:

• Одно из ее базовых качеств — у нее должна быть щель, в которую мы кидаем деньги. Если ее не будет, то, даже если мы покрасим свинью в яркие цвета, украсим стразами, ее всё равно никто не купит — по крайней мере, никто ей не заинтересуется в качестве копилки.
• Ожидаемые качества: что мы можем сделать с этой свиньей-копилкой, чтобы она стала лучше? Мы можем изменить ее размер: например, если она будет больше, в нее поместится больше денег. Мы можем изменять размеры отверстия, в которое опускаем деньги — сделать его максимально удобным. Людям это понравится, и поэтому они будут покупать такую копилку.
• Восхититель: например, когда мы опускаем в свинью деньги, она будет хрюкать, и это будет приносить людям невероятный восторг.

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

Функция, которая встречается чаще всего, — наверняка самая важная и популярная. Но, если мы разделим все функции на три категории, будет еще лучше.

Приведем пример. Мы в дизайн-студии ввели с лета производственную гимнастику. Для этого мы установили себе мобильные физкультурные приложения, которые помогают сделать разминку на 10 – 15 минут. И я сравнила эти приложения, используя модель Кано:

• Основными качествами таких приложений оказались: видеоописания упражнений, возможность их комбинировать и составлять свой набор, наличие таймера. Например, без таймера такое приложение достаточно бессмысленно — им очень неудобно пользоваться.
• Ожидаемые качества — количество видео и интересность предлагающихся упражнений.
• Восхитители: в приложении Lazy Monster, к примеру, все упражнения показывает анимированный монстрик — и это нас очень радует. Больше ничего интересного — этом приложении нет — но, видимо, оно популярно именно за счет этого монстрика. В третьем приложении привлекательным качеством являются «ачивки» — возможность бесплатно загрузить дополнительные упражнения.

Кстати, в области мобильных приложений восхитители часто находятся в области дизайна и пользовательского интерфейса — именно это зачастую помогает приложению «взлететь».

«Волшебная палочка»

И тут возникает вопрос — как придумать восхитители? Это не всегда просто. Для придумывания восхитителей я подготовила упражнение «Волшебная палочка».

Мы просто садимся и начинаем мозговой штурм — представляем наш продукт в каком-то мире, где нет никаких ограничений. Мы не сдерживаем свою фантазию и вообще не думаем ни о разработчиках, ни о технических ограничениях — просто придумываем всё, что придет в голову. Впоследствии из всех этих фантазий мы, с большой вероятностью, сможем вытащить какое-либо рациональное зерно — какие-либо функции, которые действительно можно и нужно реализовать.

Для примера я снова взяла физкультурные приложения и подумала, что бы мне могло от них хотеться. Физкультурное приложение могло бы:

• говорить голосом Брэда Питта;
• предлагать сделать 10 приседаний, пока я варю кофе;
• подставлять музыку из любимых фильмов;
• давать нагрузку в соответствии с пульсом и самочувствием;
• и т. д.

В общем, хотелось бы, чтобы приложение работало со мной более интеллектуально. Из этих фантазий мы действительно можем вытянуть нечто реальное: например, приложение можно связать с сайтом «Кинопоиска», чтобы оно знало, какие фильмы мы смотрим. Если есть хорошие инвесторы, можно договориться даже с Брэдом Питтом, чтобы он записал озвучку.

Дымовое «тестирование» на целевой странице

Итак, допустим, мы придумали набор классных функций. Теперь мы можем сделать дымовое «тестирование» на целевой странице (лендинге). Это не настоящее тестирование, потому что мы пока ещё ничего серьезно не разрабатываем. Пока что мы:

• рисуем целевую страницу для нашего продукта;
• перечисляем функции, которые мы придумали;
• проверяем конверсию.

Для этого нам понадобятся, кроме идей, какие-то эскизы будущего приложения, которые мы разместим на целевой странице, и, возможно, какой-то его прототип, выглядящий как настоящий, который продолжим разрабатывать в случае успеха идеи. Главное, чтобы пользователь понимал, что ему предлагают! А для проверки конверсии мы, например, можем поставить на странице кнопку «подписаться на новости» или делаем несколько вариантов планов и подписок и смотрим, сколько людей зашло на страницы и подписалось на новости о проекте или запросили демо-версию. Затем, если конверсия высокая, продолжаем разрабатывать приложение, а если низкая, — сворачиваем затею.

Например, это подход мы вскоре используем для наших финансовых проектов: запустим целевую страницу, где описываются концепты финансовых приложений для молодежи. У каждого приложения будет стоять кнопка «запросить демо-версию», и мы посмотрим, сколько людей захочет посмотреть это демо.

Но есть еще важный момент: делать всё это стоит, только если мы поработали до этого с пользователями и клиентом. Другими словами, выдумывать всё совсем из головы не надо — должна быть всё же какая-то реальная основы, какие-то общие знания, в какую сторону стоит развивать приложение.

Итак, какие темы мы рассмотрели?

Мы поговорили, как:

• Выйти из пространства решения.
• Научиться спрашивать сначала «что», а не «как».
• Делать классификацию функций.
• Работать волшебной палочкой.
• Тестировать то, чего нет.

Спасибо за умные мысли Dan Olsen и leanproductplaybook.com, Kim Goodwin и Designing for the Digital Age.

Эволюция методологии UX процесса — UXPUB

UX процесс кажется запутанным, даже для большинства дизайнеров

В начале был Дональд Норман, и он сформулировал идею дизайна пользовательского интерфейса.

Я придумал этот термин, потому что считал, что Human Interface и юзабилити – слишком узкие понятия. Я хотел охватить все аспекты опыта человека в системе, включая графику промышленного дизайна, интерфейс, физическое взаимодействие и руководство. С тех пор этот термин широко распространился, настолько, что он начинает терять смысл.

— Дональд Норман

К 2016 году Дон Норман решительно заявил,что этот термин был совершенно неправильно понят. Он говорит это в коротком видео на YouTube. Теперь он утверждает, что он дизайнер для людей (извините, я не нашел ссылку на интервью, с этим высказыванием), но он не согласен с названием.

Сложно найти лучший повод, чтобы начать разбираться в странном и запутанном мире современного UX дизайна: даже создатель нашей отрасли не знает, как себя назвать.

Современный UX требует понимания истории дизайна и разработки с 1990-х годов. Они неразрывно связаны между собой.

Классический дизайн пользовательского опыта

В своей чистой форме UX Design основан на каскадной модели разработки.

Продуктовая команда, использующая в своей работе каскадную модель разработки, узнает все, что возможно, до создания даже самого простейшего прототипа. Исследования могут длиться месяцы или даже годы; и их результаты диктуют работу дизайн команды. Фиксация требований до запуска дизайна и фиксация дизайна до начала разработки. Все останется неизменным до версии 2.0. Вот как работает каскадная модель.

Классический процесс UX, который обычно преподается студентам колледжа выглядит так:

1. Проведите исследование, чтобы выявить проблемы
2. Категоризируйте проблемы, которые вы раскрываете
3. Создайте персоны и карты путешествий
4. Генерируйте идеи
5. Создайте и протестируйте прототип
6. Передайте финальную версию прототипа разработчикам
7. Запустите продукт
8. Вернитесь к первому пункту, основываясь на отзывах пользователей

Это по сути каскадная модель. Классические элементы UX (Jesse James Garrett) также следуют этой модели, обеспечивая исполнение снизу-вверх на основании хорошо сформулированных требований.

Проблема в том, что классический UX принципиально несовместим с методом гибкой разработки (также известным как agile).

Agile

Долгое время инновации в Кремниевой долине были обусловлены Законом Мура, в котором говорится, что количество транзисторов в плотной интегральной схеме удваивается примерно раз в два года. Наложите сюда каскадную модель разработки, и вы заметите, что она прекрасно вписывается в 24-месячный период. Циклы бизнеса, дизайна и разработки работали как механизм швейцарских часов, прекрасно настроенный к выпуску нового чипсета Intel.

Затем в один прекрасный день Sony, Toshiba и IBM (Альянс STI) решили, что закон Мура был слишком медленным.

STI создали первый cell chip, в котором было собрано 8 микропроцессорных ядер на одной пластине (на его основе работала Playstation 2). Многоядерная архитектура изменила все.

Закон Мура не перестал работать, его хакнули. Что действительно перестало работать – каскадная модель разработки.

Скорость и гибкость заменили точность и предсказуемость в качестве конкурентных преимуществ. Компании стали массово переходить к другой хорошо разработанной, но недостаточно используемой методологии разработки – Agile.

Agile-метод фокусируется на проведении быстрой итерации. Он выпускает новый набор функций каждые 2-4 недели, развивая продукт постепенно, а не сразу. Он основан на гипотезе, экспериментах, быстром релизе и измерении в реальном времени. В методологии гибкой разработки нет стадии редактирования, нет совершенства.

Скрупулезный подход каскадной модели «семь раз отмерь, один отрежь», вышел из моды быстрее, чем StarTAC в комнате, полной iPhone.

Хотя, была одна маленькая проблема

Классический UX работал на каскадной модели.

С выпуском функционала один или два раза в месяц не было времени ждать, пока UX дизайнеры выполнят свой процесс. В Agile-номенклатуре UX стал стопором, и это было плохо.

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

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

Спросите, что значит Agile для такого дизайнера?

Если вы ответили «UI / UX Designer», возьмите печеньку.

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

Однако это стоило дорого.

Предвзятость UI / UX в отношении цифрового и графического дизайна сильно исказила восприятие бизнес-миром того, что делает дизайнер. До сих пор слишком много предприятий по-прежнему считают UX визуальной дисциплиной. Поскольку Дон Норман пытался объяснить, это неправильно.

Ситуация не начала улучшаться до 2013 года.

Экономный UX (Lean UX)

Lean UX – это решение от Джеффа Готельфа, дающее ответ на проблему практики UX в гибкой среде. В своем оригинальном шедевре Джефф перевернул всю отрасль UX с ног на голову. В его книге представлен ряд стратегий и действий по выравниванию, которые позволяют UX работать внутри agile и быстро обновлять проекты на основе отзывов пользователей.

В то время, как классический UX основан на требованиях, Lean UX основан на результатах. Если вам нужен быстрый справочник по тому, как это работает, у О’Рейли есть бесплатная глава, доступная онлайн, в которой все поясняется понятным языком.

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

Дизайнеры оказались под огромным давлением, чтобы заполнить бэклог спринта (массив работы, которая должна быть выполнена), прежде чем они действительно поняли, что они создают. В результате многие циклы разработки тратились на функции, которые никогда не попадали в конечный продукт. Среди менеджмента проектов пара Lean UX / Agile была известна большим количеством расходов и переделок.

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

Проблема расходов и переделки в этих условиях была настолько серьезной, что она часто мешала принятию Lean UX. Это представляло собой настоящую загадку для стартапов, которые хотели обеспечить сильный UX-компонент, не возвращаясь назад к каскадной модели разработки.

Джейк Кнапп и Google Ventures, как гром среди ясного неба, решили проблему с дизайн спринтом. Темные времена UX наконец-то закончились.

Дизайн спринт от Google Ventures

Если бы вы взглянули на дизайн-спринт и сказали: «Подождите, это просто очень быстрый классический UX», вы бы не были далеко от истины. Разница (и гениальность) заключается в том, что это классический UX с невероятно низкой точностью. Это разница между художественным шедевром и эскизом на салфетке, но он работает.

Цель дизайнерского спринта – взять все существующие исследования проблемы, раскрыть их суть, а затем генерировать идеи с бешенной скоростью. Идеи затем оцениваются с точки зрения дизайна, ориентированного на человека. Команда голосует за подходящие идеи. Затем дизайнеры создают прототип с низкой точностью (чаще всего за один день), который едва ли достаточно хорош для тестирования потенциальных пользователей. Результаты теста, если они положительны, формируют цели для дизайнеров, чтобы они достигли высокой точности; таким образом подпитывая цикл Lean UX / Agile.

Магия.

«Любая достаточно развитая технология неотличима от магии». – Артур Чарльз Кларк

Dual Track дизайн

ВАЖНО: dual–track agile часто относится к расколу между исследованиями и проектированием в среде Lean UX. Я обновил эту статью, чтобы ссылаться на dual–track дизайн в надежде уменьшить путаницу.

Итак, теперь мы подходим к современной методологии UX.

Как и следовало ожидать, в dual track дизайне есть два пути (уровень дедукции Шерлока Холмса):

1. Дизайн мышление / исследования дизайн спринта
2. Итеративное экспериментирование The Lean UX / Agile

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

Но откуда берется эта оценка, если производственная команда занята практикой Lean UX?

Самый эффективный ответ – выделить на нее специальную команду. Исследовательская группа изучает результаты более всесторонне в фоновом режиме. Поскольку эта исследовательская группа не привязана к темпу спринта Agile-метода, у них все еще есть возможность выделить 3 месяца, чтобы прийти к выводу.

Каждые несколько месяцев у производственных команд появляется свежая мысль, пополняющая бэклог новыми идеями для экспериментов. В одной из компаний, с которыми я работаю сейчас, есть целая команда обработки и анализа данных, которая передает данные нескольким творческим подразделениям. Новые идеи возникают редко, так как у исследователей более долгий цикл доставки, но, когда дело касается наработок на будущее – это замечательно.

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

Поэтому dual track дизайн лучше всего работает, когда специализированная исследовательская группа работает вне сферы активной группы продуктов. Вы, наверное, догадались, что это дорогостоящее предприятие. Вы не ошиблись.

Я могу вам сказать, что это дешевле существующих альтернатив: работы без UX или заниматься проблемой расходов и переделки чистого Lean UX.

Выводы

1. Вначале был Дон Норман и он сформулировал понятие UX.
2. Другие новаторы, такие как Джесси Джеймс Гарретт, раскрыли идеи Дон Нормана и родился классический процесс UX.
3. Классический UX хорошо работал со стандартным ритмом каскадной модели разработки, и все были счастливы. UX по-прежнему был нишевой практикой.
4. Инновации игнорировали Закон Мура, и каскадная модель разработки больше не работала.
5. Поэтому классический UX был несовместим с современной методологией гибкой разработки.
6. UI / UX дизайнеры перешли на дизайн, ориентированный на пользователя. Он имеет решающее значение для роста UX в области дизайна, но ограничен по охвату. Его предубеждение к цифровому и графическому дизайну сильно исказило восприятие бизнес-миром роли UX. Это остается проблемой и сегодня.
7. Lean UX был задуман Джеффом Готельфом в 2013 году и подарил нам дизайн интерфейса в гармонии с разработкой продукта. Внезапно исследователи, дизайнеры взаимодействия, дизайнеры информации и всевозможные специализированные UX специалисты начали пользоваться спросом.
8. К сожалению, Lean UX был неэффективен, когда план продукта не был четко определен, что привело к значительным расходам и переделкам.
9. Google Ventures придумали дизайн спринт, который позволил командам быстро определить и протестировать прототипы с низкой точностью. Это начало цикл Lean UX для новых групп продуктов и эффективно устранило проблему расходов и переделок.
10. Dual Track дизайн соединил модель дизайн спринта от Google Ventures с методологией Lean UX Джеффа Готельфа. Это уже развивающаяся дисциплина с начала 2018 года.

Итак, что же такое UX дизайнер в мире dual–track?

Дизайнер UX – это лидер, генератор проницательности и креативных идей, поставщик контекста. UX дизайн на самом деле не имеет каких-либо результатов, кроме ценности.

Большинство из нас не являются UX дизайнерами, если мы не возглавляем команду, скорее, мы работаем в области UX дизайна.

Этого достаточно, чтобы запутать кого угодно.

Этого достаточно, чтобы раздражать даже Дональда А. Нормана.

На момент написания статьи автор занимал должность Principal UX Designer в Dell EMC’s Digital Marketing Studio в Сан-Франциско. Он начал изучать HTML в 1997 году и создал свой первый сайт в 1999 году. Профессиональные дизайнеры и предприниматели могут связаться с ним в LinkedIn или Twitter.

Введение в Lean UX. Lean UX — невероятно полезный метод при… | by Vladimir Nikitinsky

Lean UX — невероятно полезный метод при работе над проектами, в которых используется метод Agile-разработки. Традиционные методы UX часто не работают, когда разработка ведется быстрыми темпами — не хватает времени, чтобы реализовывать UX так же быстро. По сути, Lean UX и другие формы UX преследуют одну и ту же цель —предоставлять удобство для пользователей, просто способ работы над проектом немного отличается. Итак, давайте посмотрим, как это может работать.

Lean UX ориентирован на опыт и в меньшей степени – на результат, чем традиционный UX. Это требует более высокого уровня сотрудничества со всей командой. Основная цель — сосредоточиться на получении обратной связи как можно раньше, чтобы ее можно было использовать для принятия быстрых решений. Природа Agile-разработки заключается в том, чтобы работать в быстрых итеративных циклах, и Lean UX имитирует эти циклы, чтобы гарантировать, что сгенерированные данные могут использоваться в каждой итерации.

Author/Copyright holder: Vimeo. Copyright terms and licence: Public Domain

В традиционном UX проект строится на учете требований и конечных результатов. Цель состоит в том, чтобы обеспечить как можно более подробную информацию о результатах и адекватно отвечать требованиям, изложенным в начале проекта.

Lean UX немного отличается. Вы не зацикливаетесь на подробных результатах. Вы стремитесь внести изменения, которые улучшат продукт здесь и сейчас — по сути, чтобы изменить результат к лучшему.

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

Что такое гипотеза? Гипотеза— это в основном утверждение того, что мы считаем истинным. Они предназначены для выработки общего понимания идеи, которая позволяет каждому приступить к работе. Совершенно очевидно, что предположения могут быть неверными и могут быть изменены в ходе проекта по мере того, как в команде развивается лучшее понимание.

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

• Кто наши пользователи?
• Для чего используется продукт?
• Когда это используется?
• В каких ситуациях это используется?
• Какая будет самая важная функциональность?
• Что является самым большим риском для доставки продукта?

На каждый вопрос может быть несколько ответов. Это оставляет нам больше предположений, которые имеет смысл обрабатывать. В этом случае команда может быстро расставить приоритеты в своих предположениях после их генерации. В общем, вы бы расставили приоритеты в своих предположениях в зависимости от риска, который они представляют (каковы последствия того, что это сильно неверно? Чем серьезнее последствия, тем выше приоритет) и уровня понимания рассматриваемой проблемы (чем меньше вы знаете, тем выше приоритет).

Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0

Гипотезы, созданные в Lean UX, предназначены для проверки наших предположений. Это простой формат, который можно использовать для быстрого и легкого создания собственных гипотез.

Пример: Мы считаем, что для пользователей смартфонов очень важно дать людям возможность сохранять свой прогресс в любое время. Это позволит достичь более высокого уровня завершения регистрации. Мы продемонстрируем это, когда сможем измерить улучшение текущего показателя завершения на 20%.

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

Если мы обнаружим, что невозможно подтвердить нашу гипотезу, возможно, мы движемся в неправильном направлении, потому что наши результаты четко не определены.

Одним из больших преимуществ такой работы является то, что она устраняет большую часть «я не думаю, что это хорошая идея» и политической борьбы в процессе проектирования UX. Каждая идея будет проверена, и критерии доказательства будут четко определены. Нет доказательств? Тогда пора отбросить идею и попробовать что-нибудь еще.

Если каждый может понять гипотезу и ожидания от нее, они, как правило, будут счастливы подождать, чтобы убедиться, что она верна, вместо того, чтобы страстно обсуждать свою собственную субъективную точку зрения.

Минимальный жизнеспособный продукт (MVP) — это основная концепция Lean UX. Идея состоит в том, чтобы построить максимально простую версию концепции, протестировать ее и, если нет ценных результатов, отказаться от нее. Многообещающие MVP можно затем без особых хлопот включить в дальнейшие этапы проектирования и разработки.

Это отличный способ максимизировать ваши ресурсы и одна из причин, почему он так хорошо работает с Agile-разработкой — он позволяет проводить множество экспериментов без «священных коров».

Author/Copyright holder: Jussi Pasanen. With acknowledgements to Aarron Walter, Ben Tollady, Ben Rowe, Lexi Thorn and Senthil Kugalur. Copyright terms and license: All rights reserved

Исследования и тестирование пользователей по самой природе Lean UX основаны на тех же принципах, что и в традиционных средах разработки UX. Однако подход, как правило, «быстрый и грязный» — результаты необходимо предоставить до начала следующего Agile Sprint; таким образом, гораздо меньше внимания уделяется сложным, тщательно документированным результатам и больше внимания необработанным данным.

Обязанности по исследованию также имеют тенденцию более широко распределяться по всей команде, чтобы не было «узких мест», создаваемых тем, что единственный ресурс UX-дизайна пытается самостоятельно выполнить всю работу в сжатые сроки. Это часто заставляет ресурсы разработки выполнять «практическую» работу UX, а также повышает уровень понимания и поддержки работы UX внутри команды разработчиков.

Это верхнеуровневый обзор Lean UX, и, конечно же, он гораздо шире, чем вы можете охватить в короткой статье. Однако эти базовые концепции должны позволить вам начать двигаться в правильном направлении, когда дело доходит до внедрения Lean UX в вашей Agile-среде.

Visual Studio — Развиваем методики Lean UX

• Статья
• 07/26/2016
• Чтение занимает 14 мин

В этой статье

---

Май 2016

Том 31 номер 5

Карл Мелдер | Май 2016

Продукты и технологии:

Visual Studio, диагностика, отладка, PerfTips, условные точки прерывания

В статье рассматриваются:

• бережливая разработка;
• Lean UX;
• обратная связь с пользователями;
• дизайн продуктов;
• дизайн функций.

В Visual Studio 2015 Microsoft предложила несколько новых средств отладки и диагностирования, которые подробно описаны в статье Эндрю Холла (Andrew Hall) в номере «MSDN Magazine» за март 2016 года «Debugging Improvements in Visual Studio 2015» (msdn.com/magazine/mt683794). Для средств, в которых произошли существенные изменения UX, Microsoft взяла на вооружение подход Lean UX, где для получения информации, на основе которой ведется разработка, используются итеративные эксперименты и прямые отклики от пользователей.

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

Lean UX

Lean UX дополняет методики бережливой разработки (lean development), завоевывающие популярность в нашей отрасли. Эрик Рис (Eric Ries) определил бережливую разработку как методику «Разработка, измерение и обучение» в своей вышедшей в 2011 году книге «The Lean Startup» (Crown Business), в которой он описывает подход с использованием «экспериментов, основанных на бизнес-гипотезах». Аналогично Lean UX — это набор принципов и процессов, где центральное место занимает непрерывная начинающаяся на очень ранней стадии проверка пользователями, когда вы проводите эксперименты по проверке своих гипотез о пользователях и дизайне продукта в чрезвычайно коротких циклах. Итерации по разработке дизайна выполняются очень быстро, и их основная цель — решение конкретных задач пользователей. Хорошим справочником по методике является вышедшая в 2013 году книга Джеффа Готелфа (Jeff Gothelf) «Lean UX» (O’Reilly Media), в которой он приводит инструкции и диаграммы, помогающие группам внести ясность в то, чего они надеются достичь.

Для групп, разрабатывающих отладочные среды в Visual Studio, Lean UX — подход с активным коллективным взаимодействием, в котором вся группа, включая менеджеров программ, исследователей UX, разработчиков и дизайнеров UX, участвует в генерации идей, генерации гипотез и интерпретации показанного и рассказанного пользователями.

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

Проблемы дизайна

Технологии Microsoft — богатый источник данных, благодаря которым разработчики могли бы использовать удобные способы диагностирования проблем. Однако в UX-лабораториях пользователи раз за разом прибегают к ручному «прохождению» выполняемого кода, несмотря на преимущества, которые обеспечивают такие инструменты, как Profiler. Данные мониторинга, трассировки и ведения журналов остаются невостребованными из-за неактивного использования Visual Studio Profiler, несмотря на уверенность, что он способен сделать поиск проблем с производительностью гораздо эффективнее. Для таких инструментов, как Visual Studio, с которыми пользователь работает восемь или более часов в день, может оказаться непросто убедить его сменить свой стиль работы. Поэтому группы предпочитают следовать естественному стилю работы пользователя при анализе проблем производительности с помощью отладки и создании пользовательской среды.

Технологии Microsoft — богатый источник данных, благодаря которым разработчики могли бы использовать удобные способы диагностирования проблем.

При использовании традиционного подхода по принципу водопада на довольно ранней стадии провели бы опрос фокус-групп, получили бы отзывы, написали бы подробную спецификацию и запланировали бы на момент, когда кодирование почти завершено, изучение удобства использования. Пользователи получили бы задание поработать с новыми средствами и выявить проблемы, как при поиске «багов». В Visual Studio 2015 мы выбрали совершенно другой подход.

Процесс исследования

Вместо того чтобы планировать исследование удобства в использовании на момент, когда будет доступен работающий код, мы заранее выделили двух пользователей, которые должны были этим заниматься каждую пятницу в течение большей части цикла разработки продукта. Эти дни мы неформально называли «пятницами учащенного пульса». Пользователи приходили примерно на пару часов, и их время делилось между экспериментами, которых могло быть от двух до четырех. Для каждого эксперимента мы пытались наиболее точно предположить, сколько времени на него выделить. Каждый эксперимент служил для того, чтобы помочь Microsoft побольше узнать о своих пользователях и том, как они работают, или для опробования идеи. Чтобы продвигаться дальше, идеи в области дизайна должны были выдержать минимум три недели, в течение которых они должны были давать положительные результаты. Под положительными результатами понималось, что по ощущениям пользователей решение было полезным для них, упрощало обнаружение новых функций и работу с приложением или что можно было продемонстрировать улучшение в ключевых ситуациях.

Исследование UX часто делят на количественную и качественную категории, когда развитие бизнеса и продукта определяется сочетанием мониторинга/анализа и отзывов от пользователей. На раннем этапе количественных исследований получение отзывов пользователей означает получение их реакции на идеи. Группа принимает во внимание не только то, что они говорят, но и их физические реакции, выражения лиц и интонации голоса. Кроме того, пользователям дают практические задания, например исправить «баг», связанный с производительностью, без помощи со стороны исследовательской группы, которая наблюдает за ними, как показано на фотографии на рис. 1. Это значит, что пользователям дают побороться. Сотрудники группы снимают их на видео для последующего анализа и делают заметки о том, что они увидели и услышали. Наблюдения за пользователями помогают группе понять их стиль работы и идентифицировать невысказанные потребности — усовершенствования, о которых пользователи могут не просить, но способные существенно улучшить продукт.

Рис. 1. Исследовательский сеанс, проводимый с пользователем

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

Каждую неделю к непрерывному исследованию новых перспектив привлекались различные участники. Пользователи, которые выделялись для исследований, участвовали в них и за которыми мы наблюдали, могли работать как во внутренних группах, так и у поставщиков. Группа не искала пользователей, имеющих опыт именно в диагностике. Вместо этого привлекались просто активные пользователи Visual Studio. Значит, каждую неделю у нас были пользователи с разными навыками, опытом и рабочим контекстом. Это дало группе возможность каждую неделю узнавать что-то новое и позволило систематизировать информацию. Кроме того, группа могла развивать свои идеи так, чтобы они имели успех у более широкой аудитории.

Не менее важным было обеспечить баланс во взаимодействии группы с пользователями. То, как задавались вопросы, могло существенно повлиять на результаты и сделать обсуждение пристрастным. Группа вырабатывала привычку всегда задавать вопросы, допускающие различные ответы: вопросы исследования определялись тем, что сказал или не сказал пользователь. Например, если пользователь утверждал, что ему что-то не нравится, мы просто просили: «Расскажи об этом подробнее». Группа не пыталась что-либо предположить и при каждой возможности выдвигать предположения и гипотезы. Эти навыки относятся к области UX и использовались каждым членом группы. Если вы хотите подробнее познакомиться с этими методиками интервьюирования, рекомендую книгу Синди Альварес (Cindy Alvarez) «Lean Customer Development» (O’Reilly Media, 2014).

Ранние сеансы «с учащенным пульсом» и непоколебимый подход к работе

В начале разработки продукта группа выдвинула идею помочь пользователям в мониторинге производительности их кода. Группа создала макет для исследований и представила его пользователям «пятниц учащенного пульса». Даже после трех недель итераций по усовершенствованию дизайна постоянно звучало, что пользователи не до конца понимают, зачем это нужно, и что «пожалуй, было бы лучше это отключить!». Это вряд ли было то, что хотела слышать группа, но это нужно было услышать.

Но, кроме того, в ходе наблюдений за тем, как пользователи диагностируют проблемы приложений, стало ясно, что группе нужен UX , в котором проще осуществлять навигацию по коду. Несмотря на то, что имелось несколько окон отладчика с дополнительной информацией, пользователям было сложно одновременно следить за несколькими окнами. Группа видела, что многие пользователи фокусируют внимание на коде и зачастую мысленно «проходят» выполняемый код. Это может показаться очевидным любому разработчику, который читает статью, но нас удивило то, насколько несокрушим такой стиль работы, хотя есть дополнительные инструменты, предназначенные для того, чтобы решать эти задачи эффективнее.

Группа сначала визуализировала идеи в Photoshop, причем крайне опытному дизайнеру требовалось более дня на то, чтобы сгенерировать макет для получения отзывов. Photoshop в большей мере помогает создавать высококачественный UI. Затем группа начала использовать вместо Photoshop Microsoft PowerPoint и надстройку для создания эскизов (aka.ms/jz35cp), что позволило каждому члену группы быстро создавать представления своих идей в среднем качестве. Такие эскизы давали пользователям представление о том, как может выглядеть реализация, но в то же время были достаточно грубыми для того, чтобы можно было сказать пользователям, что это рабочий вариант дизайна и полученная от них информация напрямую повлияет на него. Конечным результатом было то, что стало гораздо проще отбросить итоги 30-минутной работы, если эксперимент терпел неудачу. Кроме того, можно было проверять идеи — даже если группа знала, что они не заработают на практике, отзывы помогали генерировать новые идеи.

Чтобы получить отзывы на модель взаимодействия с пользователем, каждый слайд презентации PowerPoint представлял либо действие пользователя, либо ответ системы на это действие. При создании набросков взаимодействия мы показывали с помощью значка курсора, где пользователь сделает щелчок. Это было полезно при обмене идеями и проработке деталей. Однако мы удаляли значок курсора перед показом наброска пользователям. Это позволяло группе спросить пользователей, что они собираются делать далее, и, таким образом, с минимальными издержками выявить возможные проблемы обнаружения функций. В случае каждого слайда с ответом системы мы также спрашивали пользователей, добились ли мы успеха, что позволяло знать, получили ли мы устраивающий нас отзыв. Такой подход к получению отзывов в исследовании UX называют «процессом когнитивного прохождения» (cognitive walkthrough process), и он может помочь идентифицировать кое-какие проблемы на самых ранних этапах проектирования взаимодействия. При этом он позволяет заранее выявить области, о которых надо позаботиться и в которых для доведения решения до ума потребуются дальнейшие итерации и эксперименты.

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

«О, это потрясающе!»

Группе нужно было найти способ показать в коде информацию о производительности, не снижая читаемость кода, и дать пользователям возможность вести отладку, «охватывая» код. Code Lens — средство Visual Studio, позволяющее видеть информацию о хронологии редактирования, «багах», тестировании модулей и ссылках, — послужило источником идей для создания потенциальной модели взаимодействия и визуального дизайна. Группа экспериментировала с макетами нескольких идей, показывая пользователям, как можно было бы выводить показатели производительности в миллисекундах, когда разработчик выполняет код в пошаговом режиме (рис. 2).

Рис. 2. Ранний макет, где во время сеанса отладки показываются данные о производительности

Самым первым признаком того, что мы что-то нащупали, оказалось то, что участник (это был менеджер по разработке) оживился во время ознакомления со средой. Должен подчеркнуть, что ему просто показали предлагаемую среду без какой-либо базовой информации. Когда он осознал, что видит, он начал задавать вопросы о подробностях и был весьма увлеченным, когда говорил. Он сказал, что это могло бы быть решением проблемы, заключающееся в том, что его начинающие разработчики выбирают неправильные подходы при кодировании и в результате у приложений оказывается низкая производительность. В его текущем процессе проблемы с производительностью разрешались в ходе трудоемкого процесса анализа кода, который был тяжелым бременем для него и его группы. Он почувствовал, что эта идея могла бы помочь его начинающим разработчикам усвоить, как писать производительный код, когда они только начинали этим заниматься. Он дал такой комментарий: «Может ли это [PerfTip] быть политикой [в Visual Studio]?». Другой пользователь после осознания ценности этой возможности, заметил: «Вот что выделяет Visual Studio — возможности, доступные, когда вы «стоите» на строке кода!».

Кроме того, этот ранний отзыв вызвал у группы интерес к этой потенциальной возможности как к точке входа для средств диагностирования, решающей кое-какие проблемы обнаружения функциональности. Группа предположила, что PerfTips будут «спусковым крючком», побуждающим пользователей опробовать наш обширный инструментарий.

Проработка деталей

Все, что делалось до этого момента, ограничивалось только макетами — мы не тратили ресурсы на кодирование. Если идее давали ход, то в PowerPoint разрабатывались более подробные макеты, а также альтернативные варианты дизайна. Однако, когда мы достигли предела в том, что можно сделать с помощью макетов, осталось несколько серьезных исследовательских проблем.

• Убедиться, что при показе PerfTips во время отладки общей логики они не отвлекают внимание, но при этом их легко обнаружить при решении проблем производительности.
• Группа хотела, чтобы пользователи корректно интерпретировали показатели производительности, измеренные после последнего прерывания выполнения.
• Пользователи рекомендовали показывать значения, только когда производительность вызывает беспокойство, но никто не мог предложить пороговое значение, используемое по умолчанию.
• Вызывало беспокойство то, что есть издержки отладки, добавляющие к показателям несколько миллисекунд, а это снизит ценность средства в глазах пользователей.

Группа реализовала минимальную версию средства, работающую только в определенных условиях. Затем создала приложение с проблемами в логике и производительности, чтобы пользователи могли заниматься диагностикой. Пользователей просили идентифицировать конкретную причину проблемы. Если им не удавалось это сделать, группа могла определить, почему они не добились успеха, исходя из того, что она видела и слышала. Затем можно было изменить дизайн и повторить попытку на следующей неделе. Кроме того, в это время была подготовлена доступная для внешних пользователей CTP-версия и осуществлялся ее мониторинг. В ней PerfTips связывались с окном свойств, чтобы пользователи при желании могли без труда изменить пороговые значения. Группа пришла к следующим выводам.

• PerfTips не отвлекают внимание пользователей при исправлении проблем в логике. Нужно даже немного оживить PerfTips, чтобы они были более заметны для пользователя, который занимается решением проблем производительности.
• Кое-какие простые изменения фраз, например добавление слова «elapsed» (прошло), полностью избавляют пользователей от путаницы при интерпретации данных о времени выполнения.
• Пороговые значения только сбивают пользователей с толку, если не показывать их систематически, и нельзя определить просто значение, которое будет работать в большинстве случаев. Некоторые пользователи говорили, что, поскольку они знают свой код лучше всех, они лучше других могут судить о том, какое время выполнения приемлемо.
• Пользователи понимали, что значения не совсем точны из-за издержек отладчика, но они постоянно говорили, что им совершенно не мешает то, что они видят значения с этими погрешностями.

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

В общем, через несколько недель итераций группа начала постоянно получать положительные результаты, когда давала пользователям задание идентифицировать источник проблем производительности. Без каких-либо подсказок пользователи давали полные энтузиазма отзывы с комментариями наподобие «фантастика» или «о, это потрясающе!».

Заметки

Делая заметки, группа научилась избегать каких-либо выводов после сеанса до тех пор, пока ее сотрудники не соберутся, чтобы обсудить происшедшее. Еще более полезным было делать заметки без какой-либо обработки в режиме реального времени, пытаясь буквально записать то, что сказали или сделали пользователи. Грамматика и произношение не имели значения. Эти заметки стали для группы справочными материалами, к которым прибегали, чтобы освежить точку зрения пользователей о случившемся и выработать идеи по шаблонам, которые мы наблюдали в течение нескольких недель.

Microsoft OneNote оказалось очень удобным приложением для того, чтобы планировать тесты, сохранять необработанные заметки и быстро набрасывать выводы. У нас всегда был специальный «ответственный за заметки», который записывал все, что видит и слышит. Это давало другим членам группы возможность взять передышку и полностью сосредоточиться на пользователе. Для тех, кто не мог присутствовать физически, мы организовывали «прямые линии» по Skype; каждый член группы получал приглашение понаблюдать и поучиться. Кроме того, эти сеансы записывались для членов группы, которые пропустили их из-за конфликтов во встречах и хотели бы посмотреть их позже. Еще видеозаписи позволяли заново посмотреть моменты, требующие дополнительного внимания. На совещаниях группы по результатам каждой недели давалась информация о том, что следует сделать на следующей неделе. Писать формальные отчеты не было необходимости, и это только замедлило бы всю работу.

Заключение

Проектирование и разработка PerfTips были лишь небольшой долей того, что мы делали, проводя еженедельные эксперименты. Мы исследовали множество идей, проводя до четырех экспериментов на пользователя каждую неделю. Переработка Breakpoint Settings — еще один пример экспериментов, которые проводились неделю за неделей, чтобы получить в результате итерации более удобную и эффективную среду. Применяя Lean UX, группа имела возможность снижать риски и в то же время черпать идеи из увиденного и услышанного на экспериментах. Эти эксперименты вывели работу наугад из формулы проектирования функциональности. Идеи поступали из многих источников, а источником вдохновения было наблюдение за естественным трудом разработчиков.

Если пользователи не видели ценности в идее, можно было без особых усилий и затрат создать новый макет и начать заново. Кроме того, неудачи помогали генерировать новые идеи. Надеюсь, что примеры и советы по Lean UX вдохновят вас попробовать все это. Серия книг «Lean», упоминаемая в этой статье, послужит вам руководством и основой при применении этого подхода.

Поучаствуйте в программе

Группа исследования Microsoft UX ищет разработчиков всех типов, которые готовы напрямую поддерживать обратную связь и принять участие в нашем непрерывном эксперименте. Чтобы подписаться, оставьте на aka.ms/VSUxResearch немного информации о ваших технических знаниях и о том, как лучше с вами связаться.

Хотел бы особо поблагодарить всех, кто тем или иным способом участвовал в проекте. Вы только представьте себе «пятницы учащенного пульса», на которых толпа людей изо всех сил следит, учится и размышляет о том, как добавить в Visual Studio продуманную и полезную функциональность. Особую благодарность хотел бы выразить Дэну Тейлору (Dan Taylor), который возглавлял группу разработки и с высоко поднятой головой решал технические проблемы. Благодаря глубоким техническим знаниям и прагматичному подходу Эндрю Холла (Andrew Hall) группа все время двигалась вперед. Фрэнк Ву (Frank Wu) постоянно генерировал идеи в области дизайна и обладал сверхъестественной способностью ухватить суть идеи и найти способ выразить ее простыми словами.

---

Карл Мелдер (Karl Melder) — старший исследователь UX, постоянно применяющий при разработке UX свои знания и опыт в исследовании UX, в информатике, понимании человеческих и UI-факторов. Последние 15 лет занимается совершенствованием взаимодействия Visual Studio с разработчиками, ориентируясь на широкий круг пользователей.

Выражаю благодарность за рецензирование статьи экспертам Microsoft Эндрю Холлу (Andrew Hall), Дэну Тейлору (Dan Taylor) и Фрэнку Ву (Frank Wu).

---

Discuss this article in the MSDN Magazine forum

Автор Lean UX Джефф Готельф о том, почему дизайну должно быть место за столом

Опубликовано: 2021-10-20

В эпоху, когда кажется, что дизайнер находится на вершине иерархии технологической индустрии, трудно представить себе мир, в котором о дизайне отошли на второй план.

Если основатели организации не являются дизайнерами и не имеют опыта, когда хорошо спроектированные продукты играли ключевую роль в их жизни, это часто может быть последней дисциплиной, которую нужно привнести в команду. Автор Джефф Готельф все время видит это в своей работе консультантом для средних и крупных компаний, и это неизбежно приводит к столкновению культур, когда дизайнеры чувствуют себя обесцененными. Но если эти руководители дизайна смогут воспользоваться возможностью сесть за стол переговоров, они смогут собрать междисциплинарную команду, которая решит реальные проблемы клиентов, докажет свою ценность и в конечном итоге изменит будущее компании и продуктов, которые она поставляет.

Джефф — автор Lean UX (который учит, как быстро экспериментировать с дизайнерскими идеями) и совладелец Sense & Respond Press , издателя коротких практических книг для занятых руководителей. Он присоединился ко мне для беседы, которая варьировалась от стратегии превращения дизайна в ДНК компании до уроков, которые мы можем извлечь из человеческого пушечного ядра в цирке.

Не хватает времени? Вот пять быстрых выводов:

1. Вы должны проникнуться глубоким сочувствием к покупателю. То, что вы понимали своего клиента, когда создавали компанию, не обязательно означает, что эти потребности и эти болевые точки совпадают сегодня — или что вы удовлетворяете эти потребности таким же мощным образом, как и год назад.
2. В компаниях, не имеющих дизайнерской ДНК, Джефф рекомендует создать «собственный стартап», когда небольшая команда дизайнеров будет внедрять инновации, решая проблему, и доказывает свою ценность, оказывая положительное влияние на клиентов.
3. Сосредоточьтесь на результатах, а не на выходе. Вместо того, чтобы рассматривать доставку продукта как показатель успеха, переключите свое внимание на изменения в поведении клиентов как на признак того, действительно ли ваши усилия были успешными.
4. Всегда проверяйте свои предположения. Учитесь на человеческом пушечном ядре, с которым работал Джефф, который был серьезно ранен, когда сотрудники цирка следовали тому же старому процессу, который у них всегда был, даже несмотря на то, что условия изменились.
5. Вы должны вести свой бизнес с восторженным скептицизмом: жгучее чувство, что вы всегда можете делать что-то лучше, и вы взволнованы и полны энтузиазма, чтобы узнать, что это такое.

Если вам нравится наша беседа, посмотрите другие выпуски нашего подкаста. Вы можете подписаться на iTunes , транслировать на Spotify или получить RSS-канал в любом проигрывателе. Далее следует слегка отредактированная стенограмма эпизода.

---

Развитие карьеры

Ди: Джефф, огромное спасибо за то, что присоединились к нам сегодня на подкасте. Расскажите нам немного о себе и о том, как вы стали экспертом во всем, от процессов гибкости до дизайна продукта и общей цифровой трансформации.

Джефф: Я начал свою карьеру, как и любой другой, вернувшись в Интернет. 1.0 дней делал все, что было в наших силах, чтобы запускать веб-сайты в сети, то есть HTML и небольшой интерфейс. Что интересно, по мере того, как возрастала сложность Интернета, возрастала и сложность работы, которую мы выполняли. И поэтому я сначала стал немного больше специализироваться на информационной архитектуре, затем на дизайне пользовательского опыта, а затем на управлении продуктами. Я достиг критической точки примерно через 10 лет моей карьеры. Я понял, что, несмотря на то, что я в первую очередь дизайнер, на самом деле я ничего не проектировал. Я писал спецификации документов. А в хороший день будет реализовано 50% этих спецификационных документов, а это значит, что в хороший день 50% моей работы было выброшено. В плохой день было выброшено намного больше. Я не хотел бы продолжать идти по этому пути, если бы так было в течение следующих 10 лет.

К счастью для меня, я оказался в положении, когда я возглавлял команду дизайнеров в Нью-Йорке и организацию, которая переходила от разработки программного обеспечения водопада к гибкой разработке программного обеспечения. Моя ответственность заключалась в том, чтобы создать команду дизайнеров, использующую этот новый гибкий стиль работы. Это было около 12 лет назад, и тогда никто не знал, как это сделать. У многих людей были плохие ответы и неправильные ответы о том, как это сделать. Итак, мы решили решить эту проблему и поговорили с людьми, которые пытались, но не преуспели, и мы узнали много вещей, много анти-шаблонов, и мы повторили. Затем, примерно через шесть месяцев, мы с командой придумали что-то, что сработало для нас, и я начал писать и говорить об этом, и внезапно мне предложили возможность написать об этом книгу. Были и другие люди, которые занимались подобной работой. Я познакомился с Джошем Сейденом, который стал моим соавтором, и книга оказалась очень успешной. Lean UX была книгой, и она изменила то, чем я зарабатывал себе на жизнь. Люди перестали просить меня разрабатывать программное обеспечение и говорили: «Джефф, у нас тоже есть все те же проблемы. Приходите, расскажите нам, как вы, ребята, сделали это на Ladders ».

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

Оставайтесь гибкими по мере роста

Ди: В каких компаниях базируются эти команды?

Джефф: Я обычно работаю с крупными и средними компаниями. Чаще всего это то, что мы сегодня назвали бы традиционными, устоявшимися видами бизнеса: обычные розничные торговцы, банки, страховые компании, телекоммуникационные компании и тому подобное.

Ди: Вы произнесли речь, в которой говорили о The New York Times , которая, возможно, традиционно не приняла бы технологических практик, но вы сказали, что они начали воспринимать себя как технологическую компанию.

Джефф: Да, и это абсолютно необходимо для их успеха, потому что они были подавлены новостными организациями, использующими цифровые технологии, такими как BuzzFeed, Huffington Post и так далее. И знаете, они не могли этого понять: «Как мы можем быть раздавлены видео с кошками, когда мы лучшие журналисты в мире?» Когда они наконец осознали, что должны думать о себе как о цифровой компании, которая занимается выдающейся журналистикой, это коренным образом изменило то, как они работают. Они по-прежнему занимаются журналистикой, которой занимались раньше, но каналы доставки более разнообразны. Каденции разные. Доверие к старому печатному аспекту резко снизилось. И самое главное, они меняют ритм работы. Они понимают, что у нас не только 24-часовой цикл новостей, но и 24-часовой цикл потребления. У нас есть люди, которые все время смотрят новости, и мы сможем лучше их обслуживать, если научимся это делать.

«Я это часто слышу, особенно сегодня в крупных компаниях. Они говорят: «Мы скучаем по старым временам, когда мы были меньше». Мы скучаем по дням стартапов, когда мы могли просто принимать решения быстрее и реагировать более гибко »».

Ди: С какими проблемами, по вашему мнению, сталкиваются команды разработчиков и разработчиков по мере того, как бизнес начинает расти?

Джефф: Здесь много проблем, но это забавно: около десяти лет назад я работал в быстрорастущем стартапе четыре года. Я присоединился примерно к 200 сотрудникам, а когда я ушел из компании, их стало около 400 или 450 человек. Что было интересно, так это то, что по мере того, как компания продолжала расти, настроения, казалось, росли. Я часто это слышу, особенно сегодня в крупных компаниях. Они говорят: «Мы скучаем по старым временам, когда мы были меньше. Мы скучаем по дням стартапов, когда мы могли просто быстрее принимать решения и более гибко реагировать. Чтобы что-то сделать, не потребовалось семь разных подписей. Двенадцати человек не нужно было смотреть на все «. Я часто это слышу. По мере увеличения масштабов этих компаний для них, похоже, возникает проблема в сохранении темпов и гибкости, которые были у них, когда они были меньше.

Примеры задач масштабирования из выступления Джеффа Готельфа о масштабировании бережливого производства

Ди: Что могут сделать люди, прежде чем они достигнут этого, чтобы защитить себя от этого в будущем?

Джефф: Вчера я разговаривал с основателем, который управляет компанией из 80 человек, и 20 из них занимаются разработкой продуктов. Он задавал мне очень похожие вопросы, и он сказал: «Послушайте, я хочу убедиться, что мы действительно хорошо разрабатываем продукт, потому что я хочу посадить эти семена прямо сейчас. По мере того, как мы масштабируемся до 200, 400, 500, 1000 человек, я хочу, чтобы эти семена процветали, чтобы мы понимали, как мы работаем, что мы ценим и как мы измеряем успех ». Я обнаружил, что это очень вдохновляет в том смысле, что вы не слышите, чтобы многие основатели говорили такое.

Основатели, как правило, очень и очень уверены в своей точке зрения и в том, как все должно быть. Потому что они должны нести с собой людей в этой вере. Но с этой целью этот конкретный человек сказал: «Послушайте, я знаю свое дело. Я знаю своих клиентов. Но вы знаете, что? Разработка цифровых продуктов — не моя сила. И поэтому я действительно хочу сейчас поработать, чтобы собрать эти семена ». Я думаю, что если вы окажетесь в аналогичном положении — даже если у вас есть организация из ста человек, занимающаяся разработкой продуктов, что все еще мало по стандартам крупных компаний, — у вас есть реальная возможность создать структуру вознаграждения. и культуру, в которой ценится автономия, ценится ориентированность на клиента, ценится гибкость, ценится принятие решений на основе фактов и создается безопасное пространство для этих вещей.

Глубокое сочувствие к клиенту

Ди: Если вы пытаетесь следить за новыми конкурентами или выходить на новые рынки, что бы вы посоветовали командам сохранить баланс между реакцией, но не чрезмерной реактивностью или несосредоточенностью в своих ответах?

Джефф: Одна из вещей, которые я рекомендую практически каждой команде, с которой я работаю — потому что я еще не встречал команду, которая делает это в меру своих возможностей — это то, что они всегда должны быть привязаны к тому, что их клиенты ищут, что они делают, каковы их потребности и как они развиваются. Это особенно интересно, если вы пытаетесь выйти на новый рынок или соседний рынок и так далее. Насколько хорошо вы знаете этот рынок? Насколько хорошо вы знаете клиентов на своем или прилегающем рынке? Какие у вас есть практики, чтобы убедиться, что вы глубоко сочувствуете этому клиенту и продолжаете это делать?

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

То, что вы понимали своего клиента, когда создавали компанию, не обязательно означает, что эти потребности и эти болевые точки совпадают сегодня — или что вы удовлетворяете эти потребности таким же мощным образом, как и год назад. Поэтому вам действительно нужно сосредоточиться на том, насколько хорошо вы знаете своего клиента и как быстро вы сможете продолжить изучение его меняющихся потребностей.

«То, что вы понимали своего клиента, когда начинали компанию, не обязательно означает, что эти потребности и эти болевые точки сегодня совпадают»

Ди: В этом есть смысл. Если отвлечься от процессов: у вас был потрясающий опыт в дизайне, и я хотел бы услышать, как, по вашему мнению, дизайн-команды, в частности, должны приспосабливаться.

Джефф: Это действительно интересно, потому что я провел 10 лет в качестве дизайнера в окопах, а затем несколько лет возглавлял команды дизайнеров, поскольку мир переходил к гибким методам работы. Это был нелегкий переход, и он по-прежнему остается трудным, потому что то, что мы просим дизайнеров и просим их делать последние десять с лишним лет, — это открыть процесс проектирования. Я собираюсь сказать, что это не обязательно золотой век продуктов, но это был золотой век процессов для дизайнеров, когда мы все занимались водопадом. И я вам скажу почему: это потому, что у нас была фаза проектирования. Иногда это было три месяца, а иногда — три дня. Но независимо от того, сколько он длился, он был нашим, верно?

Это был этот черный ящик, в котором требования приходили с одной стороны, а с другой стороны выходили красивые вещи. А то, что происходило посередине, было нашим миром, и мы должны были делать в нем все, что хотели. Этого пришлось отказаться, чтобы построить организации, ориентированные на гибкость, в которых мы работаем сегодня. Нам просто нужно открыть процесс дизайна и вовлечь в него людей, которые традиционно не были дизайнерами, и показать работу намного быстрее, чем мы когда-либо делали раньше. Это по-прежнему является проблемой для многих дизайнеров, но это всегда было самым большим препятствием для хорошей интеграции дизайна в эти гибкие процессы.

«Нам просто нужно открыть процесс дизайна и вовлечь в него людей, которые традиционно не были дизайнерами, и продемонстрировать работу намного быстрее, чем мы когда-либо делали раньше»

Ди: Как вы думаете, есть ли элемент дизайнеров, не желающих делиться собственностью?

Джефф: Совершенно верно. Послушайте, если я дизайнер, и я приглашаю на встречу менеджера по продукту и инженера, и мы обсуждаем дизайн, и мы совместно проектируем вещи, то что мне делать? Я думал, что это моя работа. Разве они не пишут код и не управляют продуктами? Так что в этом есть ценность. Произошел сдвиг в восприятии ценности, которую вы приносите организации. Ваша работа как дизайнера должна развиваться, чтобы соответствовать этому новому миру. Вы не просто человек, который перемещает пиксели в порядке, который хорошо выглядит, соответствует потребностям пользователя и имеет для них смысл. Вы также являетесь фасилитатором. Вы голос покупателя. Вы — связующее звено между бизнес-инжинирингом и управлением продуктом. Чтобы стать успешным дизайнером в 2019 году, существует гораздо более широкий набор компонентов, чем в 2009 или 1999 годах, если на то пошло.

Ди: Считаете ли вы, что из-за такого исторического подхода по мере роста компаний дизайну все больше пренебрегают?

Джефф: Я никогда не слышал об организации, которая сказала бы: «О, у нас много дизайнеров. Нам больше не нужно ». Кажется, всегда сложно набрать достаточное количество дизайнеров в штат, и недостатка в открытых дизайнерских вакансиях нет. Если вы посмотрите на LinkedIn по запросу «UX-дизайнер» или «интерактивный дизайнер», в настоящее время открыты тысячи вакансий. С одной стороны, я вижу, что дизайном пренебрегают, не нанимают, не укомплектовывают персоналом и не привлекают. С другой стороны, есть тысячи открытых вакансий. Так что это действительно интересная загадка: кто нанимает, кого они нанимают и почему не хватает дизайнеров в определенных организациях, хотя, похоже, для них нет недостатка в рекомендациях по работе. Это странная смесь, с которой я еще не согласился, но одна вещь, которая очевидна для всех, — это то, что у них вообще не может быть дизайна. Теперь, сколько у них дизайна? Это варьируется от организации к организации.

Создание ДНК дизайна

Ди: Одна вещь, которую вы упомянули ранее на этой неделе, заключается в том, что у многих компаний нет дизайна в их ДНК, и это проблема. Я считаю это заявление действительно интересным.

Джефф: Послушайте, если основатели организации не дизайнеры и не происходят из среды, где хорошо продуманные продукты играли ключевую роль в их жизни и влияли на них и тому подобное, то часто это одна из последних вещей. попасть в команду, конечно, в ситуации стартапа. Это проблема, когда вы начинаете привлекать дизайнеров, потому что они будут противоречить культуре организации. И если они вступают в конфликт с культурой, они не собираются задерживаться надолго. Таким образом, возникает вопрос: «Если у вас сегодня нет дизайнерской ДНК в организации, как вы ее получите?» Один из способов добиться этого — привлечь дизайнера-лидера — кого-то, кто не только сам является талантливым дизайнером, но и может влиять на организацию, демонстрируя ценность, которую приносит дизайн, и может начать влиять на то, как работает компания, — чтобы внедрить дизайнерские практики в эта каденция, а затем в конечном итоге доказать ее ценность. Об этом можно говорить целый день; можно показывать красивые картинки; вы можете поговорить об Apple, Netflix и Nest и обо всех этих примерах отличного дизайна. Но, в конце концов, если я не смогу доказать вам, что мои коллеги повышают ценность наших клиентов и нашей компании, вы никогда не отстанете от этого.

«Люди говорят, что инновации — это работа каждого, не так ли? Я действительно не согласен с этим »

Ди: Считаете ли вы, что, поступая таким образом, дизайнеры действительно могут возглавить или научить культуре инноваций в организации?

Джефф: Совершенно верно. Как только дизайнер накопит достаточный опыт и проработает достаточное количество проектов, он хорошо подходит для начала этой роли фасилитатора, которая привлекает менеджеров по продуктам, привлекает инженеров, привлекает основателей и бизнес-лидеров и привлекает других дизайнеров и создает инновационную практику. вокруг них, что решает серьезные проблемы клиентов. И я видел, как дизайнеры исполняют эти роли. Я вижу, что это происходит все чаще и чаще в крупных организациях, потому что лидеры дизайна в конечном итоге оказываются за столом и имеют возможность получить доступ к широкому кругу лиц внутри этих организаций. И это дает им авторитет и доверие, чтобы затем сказать: «Послушайте, я определил эту проблему клиента, и если вы дадите мне четырех человек, мы сможем работать вместе как небольшая внутренняя команда стартапов и начать внедрять инновации. решить эту проблему, и мы можем доказать вам, что это сработает ». Я очень хорошо видел эту работу.

Ди: Если вы действительно можете сделать это успешно, то думаете ли вы, что это поможет, когда компания достигнет фазы масштабирования?

Джефф: С одной стороны, люди говорят, что инновации — это работа каждого, верно? Я действительно не согласен с этим. Я не думаю, что инновации — это работа каждого в организации. Я считаю, что постепенные улучшения должны быть чьей-то работой в компании. Послушайте, инновации означают, что вы будете пытаться найти способы изменить то, как вы в настоящее время ведете бизнес.

Ди: Полагаю, если все ему мешают, тогда он становится немного занят.

Джефф: Верно. Кто на самом деле обслуживает систему? Итак, у нас есть команды, занимающиеся конкретными задачами, с мандатом на инновации, а затем мы должны создать эти команды и убедиться, что они включают в себя дизайнеров. Вот и все. Но это должна быть чья-то работа, а не работа всех.

«Без кого-то, кто понимает клиента — кто знает, как спроектировать этот опыт и кто знает, как прототипировать эти вещи — этот процесс всегда будет терпеть неудачу»

Ди: Если вы — компания, у которой нет дизайна в ДНК, как вы можете найти что-то подобное?

Джефф: Когда вы разговаривали с Джошем Сейденом, он говорил с вами о результатах, а не о результатах. Подводя итог: вместо того, чтобы рассматривать поставку программного обеспечения как меру успеха, мы ориентируемся на изменение поведения наших клиентов как на меру успеха. Вот в чем разница. Если организация зашла слишком далеко по определенному пути, где дизайн постоянно остается вне обсуждения — если они начнут доводить свою работу до результатов — она ​​не сможет добиться успеха, если не включит дизайнеров в этот процесс. Вот почему: если я скажу вам создать приложение для iPhone, вы можете пойти и создать приложение. Оно могло быть хорошо спроектировано или плохо спроектировано, но вы создали приложение, и это было мерилом успеха. Мы его отправили. Если я скажу вам: «Я хочу, чтобы вы увеличили мобильную торговлю на 15%», то внезапно вы и ваша команда должны найти лучшую комбинацию кода, дизайна, требований, функций, ценностного предложения, модели ценообразования. и так далее, чтобы это произошло. И без кого-то, кто понимает клиента — кто знает, как спроектировать этот опыт и кто знает, как прототипировать эти вещи — этот процесс всегда терпит неудачу. Если вы зашли слишком далеко, и если организация может переключиться на управление результатами, она начнет форсировать разговор о дизайне, что в конечном итоге приведет к найму этих людей в команду.

Уроки человеческого пушечного ядра

Ди: Есть одна история из вашего прошлого о том, как вы работали в цирке, и она меня очень, очень поразила. Я не буду разрушать это, потому что я хотел бы, чтобы вы рассказали это аудитории, но мне интересно, если компания расширяется, можно ли провести какую-то аналогию с растущей компанией?

Джефф: Я расскажу историю, и тогда я определенно смогу связать ее, потому что я рассказываю эту историю не просто потому, что она крутая или интересная, есть причина. Моя первая работа после университета была в цирке. Я был звукооператором и светотехником в цирке братьев Клайд Битти Коул, представлявшем собой цирк с тремя тентами. Это был очень традиционный вид цирка, который ходил вверх и вниз по восточному побережью Америки около девяти месяцев. Я провел в дороге полгода и встретил много интересных людей. Одним из самых интересных людей, которых я встретил в то время, было человеческое пушечное ядро. Этот парень был олицетворением того, что в США мы называем «полностью американским»: футболист, светлые волосы, голубые глаза, подтянутый. И его работа заключалась в том, чтобы буквально вылетать из пушки во время двухминутного выступления в каждом шоу. У нас было по два шоу каждый день, поэтому он работал четыре минуты в день и попал в сетку с другой стороны палатки. Это был акт.

Это было 20 лет назад, и это был довольно механический процесс. Здесь не было цифровых технологий. Очевидно, это была пружина, а не настоящая пушка. По сути, он скользил по стволу пушки, и начальник манежа нажимал кнопку, и пружина срабатывала, и она выталкивала его, и он перелетал и приземлялся в сети. Теперь они определяют, где поставить сеть, используя манекен, который весит примерно так же, как этот парень. Мы подъезжали к новому месту, и они ставили палатку, вгоняли грузовик с пушкой, парковали его, прицеливали пушку, вставляли манекен, стреляли из него, и где бы он ни приземлялся, они там ставили сеть.

«Насколько серьезно мы потерпим поражение, зависит от того, насколько серьезны наши предположения. В цирковой истории у нас было довольно серьезное предположение, что этот парень благополучно приземлится в сети, потому что он делал это постоянно в течение многих лет ».

Ди: Это не самая точная наука.

Джефф: Ага. Но это работало каждую ночь в течение многих лет, верно? А однажды ночью грузовик с пушками опоздал на цирк, и вместо того, чтобы проверить это место той ночью, они собирались сделать это утром. Манекен оставили на ночь, и пошел дождь. На следующий день они сделали то же самое, что и ночь за ночью в течение многих лет. Они вставили манекен, выстрелили из него, и где бы он ни приземлился, они натянули сеть.

И в тот день перед 4000 детей человеческое пушечное ядро ​​вошло и помахало на прощание. Когда пушка выстрелила в него, он был значительно легче манекена и пролетел мимо сетки на глазах у всех этих детей. Он не погиб, но был тяжело ранен. И это печальная история, но, по крайней мере, он выжил, чтобы рассказать ее в конце. Так зачем мне рассказывать историю? Очевидно, потому что это интересно, и не у многих есть цирковые истории.

Ди: Нет. Держу пари, что в этом подкасте цирк упоминается впервые. Я собираюсь вернуться и проверить.

Джефф: Но послушайте, здесь речь идет о предположениях, верно? Здесь речь идет о предположениях. Мы делаем ряд предположений, и какое-то время они остаются верными, и мы прекращаем их проверять. Мы перестаем гарантировать, что они верны. Мы перестаем их проверять. В какой-то момент они перестанут быть правдой. И когда они перестанут быть правдой, то, что мы делаем, потерпит неудачу. Насколько серьезно мы потерпим поражение, зависит от того, насколько серьезны наши предположения. В цирковой истории у нас было довольно серьезное предположение, что этот парень благополучно приземлится в сети, потому что он делал это постоянно в течение многих лет. Если вы строите свой бизнес, начинаете масштабироваться и делаете предположения, что, даже если вы становитесь больше и получаете больше клиентов, все будет оставаться таким же. В какой-то момент это сломается, и это будет иметь решающее значение для успеха вашей культуры, вашей организации и вашего бизнеса.

Джефф: Поэтому важно постоянно проверять эти предположения. Мне нравится фраза — я выучил ее из выступления на TED Talk парня по имени Астро Теллер, отличное имя. Он руководит Google X, лабораторией лунных снимков. В своем выступлении он использует фразу «восторженный скептицизм». Вы должны вести свой бизнес с восторженным скептицизмом. Это жгучее чувство, что всегда можно сделать что-то лучше. Всегда есть что-то, что вы должны улучшить, и вы взволнованы и полны энтузиазма, чтобы узнать, что это такое и как это сделать. Это ключ ко всему этому.

Пресса «Разумно и ответь»

Ди: Мне это нравится. Перед тем, как мы закончим, Джефф, я хотел бы спросить тебя еще об одном. Очевидно, мы сами выпускаем книги в Intercom, и я понимаю, что вы сами управляете издательским издательством под названием Sense & Respond Press. Вы хотите нам немного рассказать об этом?

Джефф: Совершенно верно. Мы уже упоминали Джоша Сейдена. Джош — мой давний соавтор, деловой партнер и друг. Мы управляем Sense and Respond Press, издательством бизнес-книг, которое издает короткие практические книги по бизнесу для занятых руководителей. Книги никогда не превышают 12 000 слов. Это примерно 45 минут чтения, может быть, час. Они сосредоточены на гибкости бизнеса, цифровой трансформации, управлении продуктами и дизайне.

Выборка книг, изданных Sense and Respond Press

Мне нравится эта пресса, потому что мы помогаем людям разблокировать их первую книгу, и все больше и больше мы используем ее как платформу, чтобы помочь недостаточно представленным меньшинствам выпустить свою первую публикацию в мир. И мы в восторге от этого. У нас опубликовано 10 книг, которые вы можете найти на сайте senseandrespondpress. com. У нас в работе еще семь книг, и мы всегда ищем новых авторов, так что загляните на сайт. Если есть что-то, о чем, по вашему мнению, вы хотели бы написать, сообщите нам.

Ди: Значит, люди могут просто предлагать вас прямо через сайт?

Джефф: Совершенно верно. Мы будем рады услышать от всех присутствующих.

Ди: Помимо Sense & Respond Press, где люди могут не отставать от вашей работы?

Джефф: Впервые за долгие годы я снова объединил все на своем собственном веб-сайте. Я действительно в восторге от этого. JeffGothelf.com — это то место, где вы можете найти сообщения в блогах, события, ссылки и т. Д. Это все есть.

Ди: Замечательно. Спасибо большое, Джефф. Было очень приятно поболтать с вами.

Джефф: Спасибо, Ди. Это был взрыв.

Руководство для начинающих по Lean UX (+ 5 уроков от Джеффа Готхельфа)

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

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

Это требует сотрудничества между командами и отделами, а также частого взаимодействия с вашими пользователями.

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

Введите Lean UX.

Lean UX — это система управления дизайном, созданная для помощи в создании хорошо продуманных продуктов за счет частого сотрудничества между командами, постоянной итерации и частого контакта с вашими пользователями.

Как и многие системы дизайна, Lean UX содержит множество движущихся частей. Но как только ваша команда приступит к работе, вы обнаружите, что это интуитивно понятный и плодотворный способ быстро получить представление о том, чего хотят ваши пользователи.

Вот почему мы хотим рассказать вам, что такое Lean UX, его преимущества для дизайнеров и как вы можете начать применять этот процесс в своей компании.

Что такое Lean UX?

Джефф Готхельф, организационный дизайнер и руководитель группы дизайна UX, представил миру бережливый UX, опубликовав в 2013 году книгу «Бережливый UX: проектирование отличных продуктов с помощью Agile Teams ». 

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

Он использовал полученные знания вместе со своей командой и разработал Lean UX. С тех пор он провел последние несколько лет, обучая системе всех, кто готов слушать.

(Оптимизируйте свою командную работу с помощью мозгового штурма с помощью InVision Craft.)

Книга заложила основу для различных способов, которыми компании управляют своим UX-процессом, и представила систему, которая подчеркивает следующее:

• Удаление отходов. Система стремится отказаться от обычных, отнимающих много времени тактик, таких как частое документирование, путем создания минимально жизнеспособных продуктов, которые способствуют быстрому обучению.
• Постоянное сотрудничество. Lean UX объединяет команды из «дизайнеров, разработчиков, менеджеров по продуктам, инженеров по обеспечению качества, маркетологов и других» посредством частых контактов и общения (From Lean UX ).
• Больше экспериментов. Дизайнеры используют быстрые эксперименты со своими проектами, чтобы раскрыть более обоснованную информацию и уроки о своих продуктах.

(Посмотрите наш вебинар с Джеффом Готхельфом, где он рассказывает об уроках, которые он извлек за пять лет преподавания и внедрения Lean UX.)  

В основе Lean UX лежит идея радикальной прозрачности . Каждая команда должна часто сообщать друг другу о своих выводах, чтобы устранять любые препятствия и выполнять работу, необходимую для быстрого выпуска продукта.

Из Lean UX :

«Благодаря таким частым и ранним обсуждениям команда узнает об идеях каждого и может раньше приступить к работе.Если они знают, что для предлагаемого решения требуется, например, определенная внутренняя инфраструктура, инженеры команды могут приступить к этой работе, пока проект уточняется и дорабатывается. Параллельные пути разработки и проектирования программного обеспечения — самый быстрый путь к реальному опыту».

Как только вы разрушите стены общения между членами вашей команды, вы будете готовы к Lean UX.

Таким образом, Lean UX — это не столько система, сколько образ мышления, который должен принять каждый член вашей компании, если вы хотите добиться успеха.

Как работает процесс Lean UX

Прежде чем приступить к процессу Lean UX, вам нужно вспомнить, что говорит Готельф: Lean UX — это образ мышления.

Чтобы мышление стало эффективным, оно должно быть принято всеми в вашей компании.

Из Lean UX :

«Это переосмысление требует общеорганизационной позиции смирения. Это требует, чтобы команды и менеджеры использовали свои знания, навыки и креативность, как это могли бы сделать ученые: они предлагают свое лучшее решение, а затем проверяют, правы ли они.

Все члены вашей организации должны быть в курсе и понимать Lean UX, чтобы он был эффективным.

Итак, давайте взглянем на сам процесс.

Система может быть разбита на четыре процесса:

1. Исходы, предположения, гипотезы
2. Дизайн
3. Создание MVP
4. Исследования и обучение

Давайте рассмотрим каждый из них и посмотрим, как они работают.

Примечание. Это КРАТКИЙ обзор.О каждом разделе можно сказать много. Чтобы лучше понять Lean UX и весь процесс, возьмите копию Lean UX и прочтите ее самостоятельно.

Результаты, предположения и гипотезы

В то время как большинство процессов создания программного обеспечения сосредоточены на функциях и результатах, Lean UX проливает свет на результаты продукта и то, как они приносят пользу (или не приносят пользу) пользователю.

Чтобы добиться хороших результатов, Lean UX переходит от того, что, по мнению дизайнеров, требуется от продукта, к их предположениям .

Предположения — это просто ваши убеждения или ожидания, основанные на том, что вы знаете о своих пользователях.

Да, они полны риска и могут быть совершенно неверными. Но они важны для создания отправной точки для вашей команды.

Существует четыре типа допущений:

• Бизнес-результаты. Так выглядит готовое. Как вы узнаете, что ваш продукт был успешным?
• Пользователи. Люди, для которых вы создаете свой продукт.Кто они? Как выглядит их личность?
• Пользовательские результаты. Это то, что ваши пользователи хотят от вашего продукта. Каковы их болевые точки? Как ваш продукт может их решить?
• Особенности. Как вы будете улучшать свой продукт в будущем, чтобы дать пользователям желаемый результат.

Исходя из ваших предположений, вы затем перейдете к созданию гипотезы . Это включает в себя превращение ваших предположений в утверждения гипотез.

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

(Изложите свои гипотезы с помощью InVision Freehand.)

Гипотезы — отличный способ установить, что, по вашему мнению, вы знаете о своих пользователях и что им нужно. Это основа для вашей дальнейшей работы.

Дизайн

Здесь вы начинаете фактически разрабатывать свой продукт.Это также может быть время, когда вы можете проверить свои гипотезы.

Из Lean UX :

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

И недостаточно запереть свою команду дизайнеров в комнате, медленно заполняющейся водой, и заставить их разработать продукт до того, как они утонут (слишком конкретно?). Помните: вы должны разработать совместно.

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

Существует множество различных способов организации встреч и бесед по мере разработки проектов. Чтобы узнать больше, ознакомьтесь с четвертой главой Lean UX.

Вся эта работа становится частью минимально жизнеспособного продукта.

MVP (минимально жизнеспособный продукт)

Какой наименьший объем работы мы можем сделать, чтобы узнать больше о нашей гипотезе? Это вопрос вашего минимально жизнеспособного продукта (MVP).

Мы уже писали об этом раньше, но MVP — это самое основное выражение вашего продукта. Идея состоит в том, чтобы выпустить простой продукт, чтобы посмотреть, как на него отреагирует ваша целевая аудитория.

В The Lean Startup Эрика Рисса MVP определяется как «версия нового продукта, которая позволяет команде собрать максимальное количество проверенных знаний о клиентах с наименьшими усилиями.

И ваш MVP может иметь самые разные формы. Вот некоторые из них:

• Каркасы. Некачественные версии вашего продукта. Для получения дополнительной информации, вот наша статья о том, как создать каркас.
• Мокапы. Высококачественные полномасштабные версии вашего продукта с дизайном, цветами и значками.
• Прототипы. Очень простая версия вашего продукта с минимальной функциональностью и дизайном. Чтобы узнать больше, ознакомьтесь с нашим руководством по быстрому прототипированию.

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

Если вы хотите узнать, как создать MVP, прочитайте нашу статью об этом здесь.

Когда у вас есть MVP, пришло время глубоко изучить реакцию ваших пользователей.

Исследования и обучение

Эта часть процесса посвящена проверке.

Вы на правильном пути? Дает ли ваш продукт пользователям то, что им нужно? Что нужно изменить?

Чтобы исследования и обучение были эффективными в Lean UX, необходимы две вещи:

• Непрерывный. Внедряйте методы «небольших неформальных качественных исследований» в каждый спринт (из Lean UX ).
• Совместный. Команды должны работать кросс-функционально, а не в отдельных подразделениях, чтобы «построить общее понимание» (из Lean UX ).

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

(Работайте лучше вместе с помощью InVision Cloud.)

Ваши пользователи также будут частью этого процесса, будь то беседы, интервью, опросы или что-то еще. Разговоры, которые вы получите, подтвердят ваши гипотезы. Как только вы поймете, что вам нужно изменить и улучшить, пришло время вернуться к началу и сделать все заново!

Промойте и повторяйте, пока не получите продукт, который удовлетворит потребности ваших пользователей.

Стоит ли использовать Lean UX?

Несмотря на то, что у Lean UX есть много преимуществ, есть пять, которые могут побудить вас попробовать его самостоятельно:

• Расширенное сотрудничество
• Улучшенные результаты
• Оптимизированный процесс обратной связи
• Сокращение времени выхода на рынок
• Усиленное исследование пользователей

Расширенное сотрудничество

Lean UX-команды традиционно кросс-функциональны.

Это означает, что они привлекают людей из самых разных областей для совместной работы над созданием продукта.

«Разные команды создают лучшие решения, потому что каждая проблема рассматривается с разных точек зрения», — пишет Готельф. «Создание разнообразных команд ограничивает потребность в закрытых процессах, основанных на передаче полномочий. Вместо этого команды могут обмениваться информацией в неформальной обстановке, что способствует более раннему сотрудничеству и повышению эффективности команды».

Улучшение результатов

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

«Хотя управлять запуском определенных наборов функций легко, мы часто не можем предсказать, будет ли функция эффективной, пока она не появится на рынке», — пишет Готельф. «Управляя результатами (и прогрессом в их достижении), мы получаем представление об эффективности функций, которые мы создаем».

Это дает разработчикам свободу быстро производить минимально жизнеспособные продукты на основе своих предположений и смотреть, как они работают. Если это не работает хорошо, они могут отреагировать и внести необходимые изменения.

Готельф продолжает: «Если какая-то функция работает плохо, мы можем принять объективное решение о том, следует ли ее сохранить, изменить или заменить».

Это связано со следующим преимуществом Lean UX:

Оптимизированный процесс обратной связи

Lean UX построен на концепции, согласно которой дизайнерам выгоднее делать, чем говорить о том, что они делают.

«Более ценно создать первую версию идеи, чем потратить полдня на обсуждение ее достоинств в конференц-зале», — пишет Готельф.

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

Если вы тратите свое время на размышления и впадаете в ужасный «паралич анализа», вы создаете потери, чего вы не хотите с Lean UX.

Это подводит нас к…

Сокращение времени выхода на рынок

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

Все, что не способствует достижению этой цели, является отходами и безжалостно вырезается.

Согласно методологии Lean UX, в основе каждого вашего решения должен лежать вопрос: «Действительно ли этот помогает нам создавать хороший продукт для пользователей?» Если ответ отрицательный, то вам, вероятно, не следует этого делать.

Это относится к собраниям, документации и даже к заинтересованным сторонам. Ваши пользователи должны быть на первом месте с каждым из ваших дизайнерских решений — это приводит нас к…

Расширенное исследование пользователей

Как и любой хороший процесс проектирования, Lean UX ставит пользователя на первое место.Тем не менее, Lean UX делает упор на вовлечение пользователя как можно раньше и чаще.

Как? С ГОБ.

Нет, так ребенок не назовет тебя на школьном дворе (хотя, наверное, и так). GOOB означает «выйти из здания».

Это идея о том, что команды не должны сидеть взаперти в офисах, споря о мелочах дизайна. Вместо этого они должны выйти в мир и получить обратную связь от своих пользователей — и они должны сделать это раньше, чем позже.

«Проверьте свои идеи с помощью сильной дозы реальности, пока они еще молоды», — пишет Готельф. «Лучше узнать, что ваши идеи не соответствуют действительности, прежде чем вы потратите время и ресурсы на создание продукта, который никому не нужен».

Следующие шаги

Прежде чем что-то делать, обязательно зайдите в местный книжный магазин и купите экземпляр Lean UX.

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

Желаем удачи — и обязательно расскажите нам о своем опыте работы с Lean UX!

Что такое Lean UX? | 3 ключевых этапа бережливого UX-дизайна

Правда в том, что в любой организации, большой или маленькой, сложно найти общий язык для всех. Вот почему Doodle , компания, предоставляющая программное обеспечение как услуга (SaaS), в которой работает чуть более 50 сотрудников и 250 миллионов активных пользователей, обратилась к Lean UX, чтобы улучшить свои продукты эффективным, основанным на фактах и ​​ориентированным на клиента способом.Другими словами, принципы Lean UX помогают продуктовым командам Doodle вносить изменения, которых хотят их клиенты, разумным и эффективным способом, чтобы они могли расти быстрее и увеличивать свою прибыль .

Недавно я встретился с Джеком Берглундом, директором по продукту в Doodle , чтобы поговорить о его стратегии разработки продуктов. Он был очень прозрачным, поэтому, если вы ищете реальный пример того, как использовать Lean UX для дизайна цифровых продуктов, вы попали в нужное место.

Содержание

Кейс Lean UX: что такое Doodle и кто такой Джек Берглунд?

Doodle — это онлайн-инструмент, который помогает людям более эффективно планировать встречи. Он синхронизируется со всеми основными системами календаря (Google, Outlook, iCal от Apple и т. д.) и позволяет пользователям опрашивать приглашенных на собрания, чтобы найти удобное для всех время.

Компания Doodle, основанная в 2007 году, имеет штаб-квартиру в Цюрихе и офисы в Берлине, Тель-Авиве, Израиле и Белграде. Сегодня более 250 миллионов человек используют Doodle каждый год, и он доступен более чем на 25 языках.

В качестве директора по продуктам Doodle Джек Берглунд использует Lean UX, чтобы направлять гибкие межфункциональные команды для разработки продуктов, которые нравятся клиентам.

Звучит слишком жаргонно? Не волнуйтесь, я все распаковаю для вас… и обещаю, что к тому времени, когда мы закончим, это уже не будет так похоже на мультфильм Дилберта.

Что такое бережливый UX?

Lean User Experience (UX) Design — это процесс проектирования, ориентированный на пользователя, который включает в себя методологию Lean и Agile для сокращения потерь и создания продуктов, ориентированных на пользователей. Бережливый дизайн взаимодействия с пользователем опирается на совместный подход и быстрое экспериментирование/прототипирование, чтобы получить обратную связь от пользователей, предоставив им минимально жизнеспособный продукт (MVP) как можно раньше.

Процесс Lean UX вырос из более ранних систем управления процессами, таких как Lean Manufacturing , которые использовались крупными компаниями (такими как Intel, Nike, Toyota и Ford) для устранения потерь в производстве. Lean UX взял принципы, которые изначально были разработаны для физических продуктов, и адаптировал их для разработки программного обеспечения.

БЕРЕЖЛИВЫЙ UX ИСХОДИТ С БЕРЕЖЛИВОГО ПРОИЗВОДСТВА, КОТОРОЕ ИСПОЛЬЗУЕТСЯ КРУПНЫМИ КОМПАНИЯМИ ВО ВСЕМ МИРЕ.

Что отличает производство программного обеспечения? Во-первых, вам не нужно следовать старой идее «семь раз отмерь, один раз отрежь».Вместо этого ваши группы Agile-продуктов (состоящие из экспертов из разных отделов) могут выдвигать идеи, быстро их тестировать и пересматривать на основе отзывов клиентов и удобства использования.

Как говорит Джефф Готельф в Lean UX: проектирование отличных продуктов с помощью гибких команд , «Вы можете измерить один раз, один раз отрезать, один раз измерить, один раз отрезать, один раз измерить, один раз отрезать, навсегда». Это роскошь, которую имеют команды разработчиков продуктов SaaS и электронной коммерции. Поскольку они работают в виртуальном пространстве, у них просто нет таких же физических ограничений на дизайн взаимодействия с пользователем, как у Toyota или Nike.

Как так? Если вы представитель Toyota, вы не можете попробовать пять разных рулевых колес за один месяц, чтобы увидеть, какое из них улучшит качество обслуживания клиентов . Но если вы Doodle, вы можете добавить новый флажок в продукт «Создать опрос», посмотреть, будет ли он полезен, и настроить его соответствующим образом.

Использование Lean UX для оценки жизнеспособности продукта

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

В следующем тематическом исследовании показано, как за счет интеграции принципов Lean UX в качестве основы методологии Agile команда разработчиков сократила потери и оптимизировала производственный процесс.

Проблема: покрытие одинокого варианта использования

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

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

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

Проведя опрос пользователей с участием 30 представителей различных ИТ-компаний по всему городу, мы поняли, что хотя аналогичная проблема существует и в других компаниях, наше решение не соответствует привычкам более широкой аудитории.Продукт, который мы разрабатывали до этого момента, не учитывал пользователей с различной близостью к ресторанам, предпочтениями в отношении заказов и оплаты и т. д.

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

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

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

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

1. Как убедить начальство отказаться от этого продукта и согласиться на совершенно новое решение.
2. Как не допустить, чтобы команда потеряла мотивацию и не почувствовала, что месяцы работы потрачены впустую на то, что мы должны были лучше изучить в самом начале.
3. Как убедиться, что наши идеи продуктов тщательно проверены, чтобы быть уверенными, что мы на правильном пути.
4. Как ускорить процесс и убедиться, что все согласны с быстро приближающимися сроками поставки.

После признания того, что мы не подтвердили должным образом нашу предыдущую идею продукта, было важно пересмотреть наш подход.

Бережливые принципы UX

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

Процесс состоит из трех основных этапов: сборка, измерение и изучение . Структура Lean UX рекомендует привлекать как можно больше участников и заинтересованных сторон, чтобы получить разнообразие точек зрения и идей для решения продукта. Это означает вовлечение всех, от дизайнеров, владельцев продуктов/бизнеса, менеджеров проектов и маркетинга до программистов, в процесс проектирования.

Lean UX требует, чтобы вся команда была вовлечена в процесс решения проблем и проверки продукта.

Lean UX побуждает команду работать быстрее и эффективнее, ограничивая процесс временем. Чтобы максимизировать эффективность упражнения, ознакомьтесь с законом Паркинсона и ограничьте временные рамки для каждой фазы, чтобы обеспечить положительное давление и скорость.

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

Адаптация процесса Lean UX

Основываясь на нашем конкретном проекте и потребностях команды, мы внесли несколько корректировок в метод, описанный в Lean UX Джеффа Готхельфа. Более подробное описание того, как использовать тот же метод в своей команде, можно найти в книге.

Lean UX обеспечивает основу для создания решений проблем и их проверки.

Шаг 1. Соберите и проанализируйте данные.
Во-первых, мы проанализировали ранее проведенные опросы пользователей и представили то, что мы отметили как основные болевые точки пользователей.

Шаг 2: Разработайте гипотезы.
Каждый из членов команды написал свою собственную гипотезу, чтобы ответить на основные вопросы о продукте и бизнесе из рабочих листов книги. Затем мы обсудили все идеи и сопоставили их с помощью матрицы, которая сравнила размер риска, который эти предположения несут для бизнеса, с тем, что мы действительно знали о них.

Команда использовала рабочие листы, подобные этому, из книги Lean UX, чтобы сформулировать проблемы и решения, которые они представляли.

Шаг 3. Разработайте план проверки.
Мы составили план проверки каждой гипотезы — что мы хотели измерить, какие показатели мы будем отслеживать и какие результаты будут означать, что они прошли успешную проверку.

Шаг 4: Разработка персонажей.
Мы создали персонажей на основе предыдущих опросов пользователей.Очень важно не только доверять своему собственному опыту, но и знать, для кого вы создаете свой продукт, и всегда проектировать с учетом конечного пользователя.

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

Шаг 5. Расставьте приоритеты функций на основе ценности, которую они обеспечивают.
Для мозгового штурма функций и выбора того, что пойдет в разработку, мы объединили наш подход Lean UX с MoSCoW Prioritization.Такой подход помогает командам расставлять приоритеты в решениях в соответствии с доступными ресурсами. Буквы означают:

• Обязательно
• Должен быть
• Может быть
• На этот раз не будет

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

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

Шаг 6: Все делают наброски идей.
Все члены команды должны были набросать собственные решения, представить их и получить отзывы. Хорошие идеи исходят не только от дизайнеров — важно вовлечь всех в процесс, чтобы убедиться, что вы не упустите несколько отличных предложений.

Независимо от способностей к рисованию, каждый член команды должен участвовать в наброске решений и представлении их остальной команде для обратной связи.

Шаг 7. Уточните решение и протестируйте его.
Мы вместе рассмотрели эскизы и нашли оптимальное решение. Затем мы создали вайрфреймы с низкой точностью и объединили их в простой MVP, который мы могли показать пользователям и проверить, имеет ли вообще смысл наша новая идея.

Шаг 8. Получите отзыв.
В последний день мы запланировали пользовательское тестирование с потенциальными клиентами. Вся команда проводила тестирование парами: один брал интервью, а другой писал заметки. Это было очень важно для того, чтобы вся команда услышала реакцию на свое решение, предлагающую различные точки зрения, чем можно было ожидать.

Мы показали тестировщикам каркасы на мобильных телефонах и попросили их имитировать простукивание, объяснить, чего они хотят достичь, и поделиться своими мыслями по ходу дела.

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

К счастью, потенциальные первопроходцы, с которыми мы тестировали, были в восторге от нашего решения.

Документация пользовательского тестирования и собранных отзывов.Комментарии к документам Google используются для дальнейшего обсуждения улучшений и облегчения совместной работы (изображение размыто из-за конфиденциальности).

Преимущества Lean UX

Эксперимент удался, и мы решили включить методологию Lean UX в регулярные процессы компании в будущем. На протяжении всего процесса тестирования продукта мы часто отправляли участвующим членам команды опросы, чтобы оценить их реакцию — отзывы всегда были положительными. Команда доверяла методу Lean UX и была уверена, что он ведет нас в правильном направлении.

Наш самый большой успех заключался в том, что процесс проектирования Lean UX помог всем в команде заинтересоваться этим потрясающим, ранее пугающим разворотом. Другие преимущества для команды включают в себя:

• Положительные реакции команды и мотивация отказаться от предыдущей версии продукта и начать работу над новой концепцией
• Проверка основного продукта и основных функций целевой аудиторией
• Демонстрация важности раннего тестирования для бизнеса, обеспечивающего успех продукта
• Улучшение положения команды дизайнеров в компании, а также среди коллег

Применение принципов Lean UX к разработке продукта

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

Использование принципов Lean UX в процессах разработки продуктов может повысить эффективность вашей команды и улучшить ваши продукты. Адаптируйте и адаптируйте структуру к конкретным потребностям и динамике вашей команды.

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

• • •

Дальнейшее чтение в блоге Toptal Design:

Руководство дизайнера по бережливому и гибкому UX

Большинство из вас, возможно, слышали термины «бережливый» и «гибкий» — или «бережливый пользовательский опыт» (UX) и «гибкий UX» — используемые для описания подхода команды или компании. Возможно, вам также было интересно, что это значит для вас как специалиста по UX и чем эти подходы отличаются от вашего существующего процесса. В этом руководстве рассматриваются некоторые часто задаваемые вопросы, которые помогут вам внести свой вклад в команды, использующие эти подходы.

Что такое Lean UX?

Давайте начнем с того, что означает Lean UX. Дженис Фрейзер, пионер индустрии дизайна и UX, ввела термин Lean UX. Она является партнером-основателем легендарной дизайнерской фирмы Adaptive Path и опытным тренером по бережливому стартапу, и она определяет термины просто и ясно: «Lean UX — это UX-практика, адаптированная для бережливых стартапов, а Agile UX — это UX-практика, адаптированная для команд, работающих с Agile. ”

В начале процесса проектирования большинство продуктовых команд не уверены, какое решение является правильным, и им необходимо изучить различные направления проектирования, прежде чем найти оптимальное решение.Вот в чем суть Lean UX — формулировка гипотезы и ее проверка до того, как приступить к созданию чего-либо.

Lean UX фокусируется на результатах, а не на результатах. Он позиционирует UX-дизайнеров как активно сотрудничающих членов команды продукта или услуги, стремящихся проверить свои предположения и гипотезы посредством партизанского пользовательского тестирования и экспериментов с концепциями минимально жизнеспособных продуктов (MVP).

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

Внедрение Lean UX означает создание культуры постоянного обучения. Непрерывное исследование стимулирует процесс разработки продукта и побуждает членов команды разработчиков искать лучшие решения.

Принципы Lean UX включают кросс-функциональные команды (работа в командах с различными наборами навыков), команды, ориентированные на проблемы (не просто создают функции, а решают проблемы), производят как можно меньше отходов (исключая всю работу, которая не получает желаемого результата). ваша команда ближе к ожидаемому результату), а также культура постоянных открытий и улучшений. См. полный список принципов ниже.

15 основных принципов Lean UX определяют команды разработчиков. Изображение предоставлено Беном Ральфом.

Где зародился подход Lean?

Помимо конкретного контекста UX, может быть полезно получить базовое понимание самих Lean и Agile. Lean и Agile имеют разные истории происхождения, и сами слова могут иметь несколько разные интерпретации, связанные с ними. Хотя в настоящее время они практикуются комплексно в некоторых командах разработчиков программного обеспечения, они не обязательно идут рука об руку.

Бережливое производство может относиться к нескольким различным идеям, а именно к бережливому производству, бережливому управлению, бережливой разработке программного обеспечения или бережливым стартапам. В контексте технологий и дизайна мы обычно имеем в виду бережливую разработку программного обеспечения или бережливые стартапы.

Бережливое производство берет свое начало в бережливом производстве, которое возникло у производителя автомобилей Toyota в Японии в конце 1940-х и начале 1950-х годов. В 2003 году Мэри и Том Поппендик написали книгу под названием « Бережливая разработка программного обеспечения », в которой описано, как применять семь принципов бережливого производства к разработке программного обеспечения.В 2008 году Эрик Райс начал излагать концепцию бережливого стартапа, которая применяет теорию бережливого управления к стартапам в технологической сфере. Его книга 2011 года « Бережливый стартап » — одна из самых продаваемых бизнес-книг, когда-либо написанных.

Что такое Agile UX?

Agile UX пытается интегрировать практику UX с командами разработки программного обеспечения Agile. Поскольку Agile задумывался как инженерная практика, изначально он не объединял UX и дизайн. В сообществе UX ведется много споров о том, насколько совместимы эти практики.Agile UX направлен на внедрение итеративного подхода к разработке и улучшению функций, которые создаются за счет совместной работы команды и управления отзывами клиентов.

Lean UX фокусируется на этапе проектирования процесса разработки программного обеспечения, в то время как Agile UX интегрирует процесс проектирования UX в методологии Agile. Изображение предоставлено Райли Пелоси.

Откуда возник Agile-подход?

Agile обычно относится к гибкой разработке программного обеспечения. На протяжении 1990-х годов наблюдалась негативная реакция на тщательно спланированные и регулируемые подходы к разработке программного обеспечения, когда команды развивали свои подходы к более легким и гибким, таким как схватка, кристально чистое и экстремальное программирование.Вместо того, чтобы выпускать все сразу, agile-команда выполняет работу небольшими частями, которые легче тестировать.

Процесс разработки программного обеспечения Agile включает серию спринтов перед запуском. Изображение предоставлено Танди Гильерме.

В 2001 году группа из 17 разработчиков программного обеспечения объединилась и опубликовала «Манифест гибкой разработки программного обеспечения». Вот несколько ключевых моментов из манифеста:

• Люди и взаимодействие важнее процессов и инструментов
• Рабочее программное обеспечение важнее подробной документации
• Сотрудничество с клиентами важнее переговоров по контракту
  • Реагирование на изменения вместо следования плану
3 Манифест определил методологию гибкой разработки программного обеспечения, какой мы ее знаем сегодня. Agile стал универсальным термином, который часто охватывает эти подходы. Это относится к способу работы, который фокусируется на совместной работе, ограниченных по времени рабочих блоках (спринтах) и постепенном развитии продукта и набора функций при создании программного обеспечения.

Как Lean и Agile помогают создать лучший дизайн

Есть поговорка (иногда приписываемая Лауре Кляйн):

Lean помогает создавать правильные вещи. Agile поможет вам построить все правильно.

Несмотря на то, что у этих подходов есть свои нюансы, оба они ориентированы на тесно сотрудничающие команды, которые стремятся итеративно создавать качественные продукты, имея возможность разбивать работу на более мелкие части и реагировать на изменения.

Как Lean, так и Agile-разработка программного обеспечения основаны на наборе принципов. Вы можете прочитать больше о «Двенадцати принципах гибкой разработки программного обеспечения» и «Семи принципах бережливой разработки программного обеспечения», но для наших целей синтез их основного направления изложен в этой статье Codementor:

Парадигма Agile, изложенная в «Манифест Agile» отдает предпочтение коротким циклам итераций и частым поставкам, а не целостному сквозному представлению. Таким образом, E2E [сквозной] фокус уникален для бережливого производства.На самом деле именно из-за конструкции E2E Lean (а не Agile) чаще применяется в качестве организационной структуры и стиля управления.

Как упоминалось выше, бережливый дизайн UX часто фокусируется на сокращении потерь, а бережливый стартап делает упор на цикл «создание-измерение-обучение», который пытается ответить на ключевые вопросы о ценности для клиента и бизнеса посредством создания MVP, ориентированного на гипотезы.

Визуализация процесса Lean UX (также известного как цикл Lean UX) фокусируется на последовательном переходе к решению.Изображение предоставлено Беном Ральфом.

Если вы внимательно посмотрите на цикл «создать-оценить-изучить Lean UX», вы заметите этапы обнаружения, определения, разработки и доставки, которые могут быть частью традиционного процесса проектирования с двойным ромбом. Однако ключевое различие между традиционным подходом к проектированию и дизайном Lean UX заключается в том, что этапы определения и разработки повторяются. Это означает, что как команда мы будем искать наилучшие возможные решения, прежде чем создавать прототипы решений.

Двойной алмазный процесс Lean UX включает этапы обнаружения, определения, разработки и реализации.Изображение предоставлено Беном Ральфом.

Что нужно знать дизайнерам при работе с этими подходами?

По мере того, как компании перенимали методы работы Lean и Agile, у дизайнеров UX возникли проблемы, поскольку они пытались адаптировать свой собственный процесс проектирования, ориентированный на человека, к этим подходам. Некоторые из этих проблем существуют как в Lean UX, так и в Agile UX:

• Одна команда, одна мечта. Для того чтобы Agile и Lean могли эффективно интегрировать UX, необходимо получить признание важности и ценности роли UX.Для этого требуется определенная степень зрелости организационного дизайна (и Lean, и Agile имеют прямую связь с корпоративной культурой, поэтому мышление Lean и Agile должно быть встроено в принципы системы дизайна UX), а также поддержка на уровне руководства. UX-дизайн должен рассматриваться как равноправный участник процесса.
• Найдите время для исследования пользователей. Гибкая разработка программного обеспечения с самого начала была ориентирована на эффективное и действенное создание, поэтому в этом процессе не всегда есть место для явного исследования.Многие дизайнеры пытались найти подходы, чтобы адаптироваться к этому, например, начиная со Спринта 0, который позволяет провести фундаментальную исследовательскую работу до начала разработки. Существует много дискуссий о том, как команда дизайнеров может работать в правильном темпе, чтобы дизайн не отставал от разработки.
• Достижение нужного уровня документации . Подходы Lean и Agile подчеркивают важность создания рабочих продуктов, а не сосредоточения внимания на создании документации.Для UX-дизайнеров определенные типы артефактов дизайна имеют решающее значение для изучения и развития продукта, например, диаграммы информационной архитектуры (IA) или каркасы. Диаграммы

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

Наброски на бумаге — это полезный подход к более легкой UX-документации в рамках команд Lean или Agile.Изображение предоставлено Adobe Stock Photo.
• Изучение языка. Как и любой метод, Agile и Lean имеют свой собственный набор уникальных терминов и ритуалов. Для Agile понимание того, что подразумевается под скрамом, спринтами, бэклогом, пользовательскими историями и эпиками, будет полезно для дизайнеров. В рамках бережливого производства такие слова, как предположения, гипотеза, минимально жизнеспособный продукт (MVP) и опорные точки, являются одними из основных понятий. Общий язык и понимание между членами команды составляют основу любой работы.

Повышение ценности важнее догмы о процессе

Цитируя Скотта Кука: «Успех не в реализации функции; Успех заключается в том, чтобы научиться решать проблему клиента». Независимо от методологии и подхода, которые решит использовать команда, конечной целью дизайнеров UX является создание ценности как для бизнеса, так и для пользователей. Как UX-дизайнер в команде, способность сотрудничать, быть гибким и приспосабливаться повысит ваши шансы на успех. Lean UX и Agile UX дают дизайнерам образ мышления и модели для повышения их вклада.

Дополнительные ресурсы

Для дизайнеров UX, работающих с Agile и/или Lean командами, изучение этих подходов и их мышления является важной частью вашего вклада. Есть много книг, сообщений в блогах и статей, в которые можно погрузиться. Начните с «Манифеста гибкой разработки программного обеспечения», а затем ознакомьтесь с некоторыми публикациями Nielsen Norman об интеграции UX и Agile.

Книги Agile Experience Design и Agile! помогают дизайнерам глубже погрузиться в повседневную жизнь Agile-команды. Lean Startup — это основополагающий текст для понимания концепции бережливого производства в контексте технологической компании. Lean UX и В книге Lean Product Book также должны быть описаны все, что нужно знать дизайнеру.
А если вам нужна дополнительная информация о системах дизайна UX, XD Ideas поможет вам.

Что такое Lean UX? — О’Рейли

Поскольку тенденция разработки программного обеспечения неизбежно склоняется к постоянному совершенствованию, непрерывному обучению и гибкости, то и практика проектирования должна меняться и меняться, чтобы быть максимально эффективной для цифрового мира.Модели процессов UX, унаследованные от его предшественников — графического дизайна, промышленного дизайна и архитектуры — загружены заранее и тяжеловесны, предназначены для выходных данных, которые представляют собой физические продукты и объекты. Но эти модели процессов рушатся, когда уже невозможно просчитать все заранее, как в случае создания сложных программных приложений. Lean UX — это призыв к итеративной работе, оптимизации дизайна и устранению потерь, сотрудничеству в межфункциональных командах и, что наиболее важно, сохранению клиентоориентированности при принятии решений.

«Мы увидели в появлении Agile разумный процесс работы с этим податливым, бесконечно изменчивым материалом [то есть программным обеспечением], где вам не нужно дважды отмерять, один раз отрезать. Вы можете один раз измерить, один раз отрезать, один раз измерить, один раз отрезать, один раз измерить, один раз отрезать и так навсегда», — говорит Джош Сейден, дизайнер, стратег и соавтор книги Lean UX: Designing Great Product with Agile Teams . «Когда [Agile] стал вращающимся двигателем в центре производства программного обеспечения, все остальные части производства программного обеспечения [и их] модели процессов начали конфликтовать.Люди начали спрашивать: «Какая модель процесса, которую мы можем использовать, будет работать с этими методами Agile, которая не потеряет ценности, которую мы привносим как дизайнеры, и на самом деле будет использовать преимущества этих новых моделей процессов? «… Я думаю, что Lean UX — это общий термин для всех этих подходов, которые хорошо работают в контексте Agile». Lean UX оптимизирует дизайн для мира Agile, применяя инструменты и методы цифрового дизайна по мере необходимости.

Учитесь быстрее.Копать глубже. Смотрите дальше.

Истоки Lean UX

Lean UX восходит к бережливому производству, системе, которая направлена ​​на устранение потерь в производстве — тех видов деятельности, которые не добавляют ценности для конечного потребителя — с максимальной эффективностью. В книге «Машина, изменившая мир» , опубликованной в 1990 году, авторы Джеймс П. Вомак, Дэниел Т. Джонс и Дэниел Рус впервые описали подход бережливого производства, основанный на производственной системе Toyota (TPS).Подход Toyota к бережливому производству помог добиться значительного роста компании, которая стала одним из крупнейших автопроизводителей в мире.

В 2008 году Эрик Райс в своей новаторской книге The Lean Startup , применил методы бережливого управления к бизнесу и разработке продуктов, побуждая предпринимателей следовать итеративному циклу обратной связи «создание-измерение-обучение» для проверки бизнес-гипотез путем получения отзывов клиентов. на минимально жизнеспособном продукте (MVP).Этот процесс позволил стартапам быстро проверить свои идеи на рынке.

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

Обзор

Lean UX основан на наборе основных принципов, каждый из которых направлен на максимизацию ценности и минимизацию потерь при разработке программного обеспечения. Цикл бережливого UX может быть выражен как «подумай-сделай-проверь», что не отличается от цикла обратной связи «создание-измерение-обучение» метода Lean Startup .

Подумай

Мы начинаем наш цикл Lean UX с формулирования наших предположений о проблеме — что мы знаем или думаем, что знаем об этой области. У нас могут быть предположения о наших потенциальных пользователях и их целях или о том, какие функции программного обеспечения могут помочь им в достижении этих целей. Затем мы превращаем эти предположения о проблеме в гипотезу, которую мы можем проверить и подтвердить с помощью отзывов наших пользователей. На этом этапе мы также формулируем, как может выглядеть успешный результат, состояние, к которому мы стремимся и которым мы управляем.

Сделать

Далее мы проектируем совместно. Наша цель — создать минимально жизнеспособный продукт (MVP), который может быть прототипом или даже наброском, чтобы помочь нам проверить предположения, сформулированные в нашей гипотезе, на реальных пользователях. Lean UX отдает приоритет совместному творчеству — наброскам, белой доске и неформальным беседам — для продвижения дизайна вперед, а не для достижения конкретных результатов.

Рис. 1. Быстрые наброски могут проиллюстрировать поток идеи или концепции дизайна. Изображение предоставлено: Юхан Сонин (CC BY 2.0). Рисунок 2. Электронная доска может быть важным методом совместного проектирования. Изображение предоставлено: Юхан Сонин (CC BY 2. 0).

Чек

Текущие исследования дают нам возможность быстро проверить нашу гипотезу, проверить наш MVP с клиентами и подтвердить или опровергнуть его, в зависимости от обстоятельств. В идеале мы будем разговаривать с клиентами через регулярные промежутки времени, возможно, раз в неделю, и получать обратную связь. Исследование бережливого UX является совместным и распределяется по всей команде, чтобы каждый мог ознакомиться с ним и выработать общее понимание.

Помня об этом основном цикле «думай-делай-проверяй», давайте рассмотрим некоторые ключевые принципы Lean UX.

Принципы Lean UX

Действовать как одна команда

Чтобы создать общее представление о клиентах и ​​о том, что им больше всего нужно, дизайнеры, инженеры и менеджеры по продуктам должны работать вместе в одной команде. «На самом деле речь идет о [создании] этого межфункционального сотрудничества вокруг того, что мы строим, для кого мы это строим, [и] как выглядит успех, что является действительно трудным разговором в большинстве компаний», — говорит Джефф Готельф, организационный дизайнер и соавтор Lean UX . «Потому что в большинстве компаний успех заключается в следующем: «Мы выпустили функцию. Это за дверью. Мы успешны». [Но] это начало. На мой взгляд, это начало разговора с рынком».

«Общее понимание возникает в результате тесного сотрудничества между этими дисциплинами, — объясняет Готельф. «Вот где эффективность и прирост производительности приходят с Lean UX». Например, проводя совместные опросы пользователей, члены команды получают информацию из первых рук об отзывах и могут понять причины, по которым те или иные результаты оказались именно такими.Благодаря этим общим знаниям члены команды могут быстро сосредоточиться на выяснении того, что делать с проблемой.

Само собой разумеется, что с такой ценой совместной работы удаленным командам может быть трудно практиковать Lean UX. «Философия остается прежней. Просто [что] компания должна оптимизировать культуру удаленного доступа», — говорит Готельф. «Они должны предоставить своим командам инструменты, позволяющие выполнять такую ​​совместную работу. Затем, самое главное, они должны бодрствовать в одно и то же время.Если часовые пояса не пересекаются ни в каком производственном плане, то нет, не получится. Это самая большая проблема».

Конечно, цифровые технологии существуют для обеспечения совместной работы в режиме реального времени в рассредоточенных командах. Мы можем легко вовлекать удаленных коллег в такие действия, как наброски, интерактивная доска, видеоконференции и совместное использование экрана. Несколько примеров таких приложений включают вездесущие Slack или HipChat для командных бесед; Basecamp или Asana для управления проектами; и GoToMeeting, Blue Jeans или Zoom для видеоконференций, не говоря уже о Skype и Google Hangouts.Существуют также инструменты для совместной работы, такие как Mural и Realtime Board, для мгновенного сотрудничества с виртуальными стикерами и досками.

Решите правильную проблему

Практика Lean UX требует, чтобы команды быстро получали обратную связь от клиентов. Чем больше мы сможем поговорить с клиентами вместе, тем лучше для нас будет. «Мы должны учиться двигаться вперед небольшими непрерывными партиями с постоянной обратной связью», — говорит Зайден. «Мы делаем это… [путем] построения нашего процесса на основе непрерывного обучения».

Lean UX организует команды вокруг обучения, используя небольшие шаги, небольшие единицы работы и постоянное взаимодействие с клиентами или пользователями.«Я думаю, что во многих местах, где вы видите падение Agile, люди думают, что Agile — это просто выполнение небольших приращений работы. На самом деле Agile — это небольшие непрерывные циклы обратной связи», — говорит Сейден. Благодаря постоянной обратной связи и обучению от клиентов, более вероятно, что мы оттачиваем и решим правильную проблему.

Например, наличие группы пользователей или первых пользователей, участвующих в разработке продукта от концепции до завершения, может принести дивиденды. Для технических приложений и программного обеспечения B2B это может быть особенно важно.Ваша команда может выбрать один день в неделю, когда новые проекты или прототипы будут рассматриваться или тестироваться вместе с группой. Отзывы пользователей информируют о следующей неделе работы. Иногда еженедельных обзоров может быть слишком много, в зависимости от ритма команды дизайнеров — двухнедельные обзоры также могут быть эффективными. Выберите интервал, который лучше всего подходит для вашей группы.

Работая небольшими порциями, мы можем тестировать потенциальные решения и снижать риски. Если решение, которое мы разрабатываем, не работает, мы обнаруживаем, что нам нужно попробовать что-то еще или даже переформулировать проблему.Постоянный вклад пользователей поможет убедиться, что команда действительно понимает проблему и ее различные аспекты и правильно ее диагностирует.

Совместное проектирование

Для Lean UX дизайн — это функция, а не человек . «В нашем маленьком агентстве, которое у нас было четыре года, мы действительно видели это… смешение вод между дизайном продукта и проектированием. На самом деле нам было трудно сказать: «Он наш дизайнер», [что] было очень ограничивающим утверждением, или «Она наш инженер», — говорит Готельф.«Я вижу размытие линий. Я вижу гораздо более совместное будущее».

Lean UX опирается на хорошо управляемое, непрерывное сотрудничество при проектировании. Например, в Involution Studios, бостонской фирме по разработке программного обеспечения, где я работаю и которая специализируется на здравоохранении, проекты создаются таким образом, чтобы клиенты и команда разработчиков могли максимально тесно сотрудничать как в виртуальной, так и в физической среде. Проекты обычно начинаются с многодневных семинаров в студии, где с помощью дизайнерских упражнений, совместных обедов и т. д., команда может начать объединяться в единое целое. В студии — историческом большом бальном зале со старинной архитектурой, первоначально построенном на рубеже 20-го века — есть открытые рабочие места на балконе, на которых могут разместиться дизайнеры клиентов, разработчики или менеджеры по продукту, чтобы помочь команде проекта интегрироваться в одну рабочую группу.

Кроме того, большинство стен в бальном зале, а также в конференц-залах и на кухне окрашены с помощью IdeaPaint, наносимого и стираемого поверхностного покрытия, которое поощряет спонтанный совместный дизайн и интерактивную доску.А когда команда проекта физически не вместе, они общаются и делятся знаниями, используя различные цифровые инструменты, от Basecamp до DropBox, от Google Drive до Slack.

Планы меняются, поэтому планируйте соответственно

Lean UX требует, чтобы дизайнеры совершенствовали свое понимание по мере того, как они обнаруживают новую информацию. Работа с программным обеспечением почти всегда означает работу в ситуациях с высоким уровнем неопределенности. «Очень сложно предсказать, сработает ли решение, которое вы предлагаете людям, и будет ли оно иметь желаемый эффект», — говорит Сейден.«Это своего рода отправная точка, верно? … Как заставить их вести себя в этих системах? Мы не знаем, и это означает, что вместо модели, в которой мы делаем тщательное планирование, нам нужно оптимизировать, чтобы делать маленькие шаги и учиться по ходу дела, а также быть открытыми для изменений».

Однако легче сказать, чем сделать, быть открытым для перемен. Это может быть трудно даже для дизайнеров и разработчиков, чей рабочий мандат заключается в создании таких изменений. Например, бывают моменты, когда информация, полученная в результате пользовательского тестирования или обзоров, показывает, что первоначальные предположения для наших гипотез о дизайне были неверными, что было опровергнуто наблюдением за пользователями, фактически взаимодействующими с программным обеспечением или продуктом.В этих случаях перед нами стоит задача изменить курс, когда наши предположения окажутся ложными, что редко вызывает приятные чувства, по крайней мере, поначалу. Такая гибкость — не желание быть правым, а скорее готовность ошибаться и следовать по пути, который демонстрируют доказательства, — может быть критически важной чертой для дизайнера или разработчика.

Результаты? Не так много.

Еще один ключевой принцип Lean UX — снижение акцента на проектировании результатов.

Другие процессы проектирования могут благоприятствовать предварительной работе, будь то исследование, информационная архитектура, интерактивный дизайн, макеты пользовательского интерфейса или прототипирование, при этом на каждом этапе создается отдельный набор результатов.Но этот подход плохо работает в среде Agile. Lean UX — это корректировка вашего процесса проектирования, чтобы он стал более совместимым с Agile.

«Как вы берете все эти инструменты [дизайна] и применяете наиболее подходящие из них в наиболее подходящее время и с соответствующим уровнем усилий?» говорит Готельф. «Вы избавляетесь от потерь в процессе проектирования и уходите от работы с конечными результатами». Это не означает, что процесс Lean UX лишен результатов. «Это означает, что нужно создавать только те артефакты, которые вам нужны, чтобы передать разговор на один шаг вперед», — объясняет Готельф.

«Я думаю, что наиболее важным [принципом Lean UX]… является [] минимально жизнеспособный разговор », — говорит Готельф. «Что я имею в виду, как дизайнер, что самое важное, что вам нужно сообщить дальше? Кому вам нужно это сообщить? Тогда какой наименьший объем работы вам нужно сделать, чтобы это общение состоялось? Я думаю, что если бы существовала заповедь Lean UX, то это действительно так».

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

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

«Теперь, если мне нужно объяснить [что-то] руководителю, которого на самом деле не волнуют пиксели и все такое, возможно, мне придется создать прототип и провести его через это», — говорит Готельф.«Может быть, нам нужно полностью разработать что-то, чтобы показать это и донести эту мысль. Может быть, мне придется прийти на эту презентацию с небольшим количеством доказательств, своего рода исследованием, которое я тоже провел. Мне нужно проделать такой объем работы, чтобы сделать это дело убедительным».

Этот принцип предпочтения обсуждений результатам ради самих результатов — отличный пример адаптации дизайна к миру Agile. Но, хотя Lean UX — это эволюционный шаг к непрерывному процессу, он, тем не менее, имеет общие характеристики с другими устоявшимися методологиями проектирования, которые могут быть не очевидны сразу.

Lean UX и дизайн-мышление

Еще одна методология, которая разделяет с Lean UX основанный на фактических данных подход к дизайну продукта, — это дизайн-мышление. У них есть ряд общих элементов. Фактически, Lean UX опирается на дизайн-мышление во многих важных областях: наблюдение за клиентом, понимание и развитие эмпатии, совместный мозговой штурм для поиска различных решений и измерение влияния этих решений для определения лучшего.

Но между ними есть и различия.Lean UX рассматривает формальные процессы и методы как рамки, которые можно и нужно изменять по мере необходимости. Когда дело доходит до соблюдения конкретных шагов или способов ведения дел, Lean UX использует прагматичный и утилитарный подход, особенно когда речь идет о получении отзывов от клиентов и пользователей. Например, дорогие формальные юзабилити-тесты вряд ли найдут место в процессе Lean UX, в то время как партизанские юзабилити-тесты с несколькими пользователями более вероятны. Для формального юзабилити-теста требования могут включать лабораторию с различными технологиями наблюдения, набор и планирование значительной группы пользователей, а также разработку протокола тестирования.В зависимости от количества тестируемых пользователей затраты могут достигать десятков тысяч долларов. Напротив, партизанское юзабилити можно проводить везде, где вы сталкиваетесь с пользователями, подходящими для вашего продукта. Если у вас есть продукт с общей пользовательской базой, вы можете протестировать свои проекты в общественном пространстве, например в кафе. «Формальность — вот где для меня игра. Да, все компоненты дизайн-мышления подходят. Используйте то, что вам нужно, чтобы двигаться вперед в правильном направлении. Но основные принципы тесно связаны», — говорит Готельф.

Lean UX в действии: CarMax

Как компания использует технологии, чтобы сделать процесс покупки подержанного автомобиля более успешным? Это был вопрос, который CarMax, крупнейший розничный продавец подержанных автомобилей в США, задал, когда начал применять принципы Lean UX в работе, применяя итеративный экспериментальный подход к дизайну и разработке продукта.

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

CarMax также внедряет Lean UX в свою работу, что, как следствие, развивает их корпоративную культуру. Это изменило то, как компания нанимает сотрудников, то, как они создают команды (например, в проектах могут участвовать заинтересованные лица из разных отделов), то, как они стимулируют эти команды, то, как эти команды взаимодействуют с руководством, виды деятельности, которые они выполняют. команды, и даже их физическое пространство.Например, офис организации продуктов компании — центр цифровых и технологических инноваций в центре Ричмонда, штат Вирджиния, — представляет собой переоборудованное музыкальное заведение, созданное специально для улучшения совместной работы. Расположенное в историческом здании Lady Byrd Hat пространство может вместить до 120 сотрудников, включая архитекторов приложений, дизайнеров UX и разработчиков программного обеспечения.

«Я думаю, интересная часть этой истории, — говорит Готхельф, — заключается в том, что иногда эти усилия [Lean UX] выявляют некоторую обратную связь, которая не обязательно является тем, что компания хочет услышать.«Мы вложили значительные средства в эту конкретную инициативу». Угадайте, что? Это неправильная инициатива. … Это самая сложная часть во всем этом. Это весело и весело, когда обратная связь и знания, которые вы получаете, подтверждают вашу гипотезу. [Но] когда они обесценивают ваше мышление… самое сложное в этом — изменить курс. Одно дело изменить курс дизайна или проектной группы. Другое дело — стратегически сменить курс в организации, на что это в конечном итоге оказывает влияние.Доказано, что это увлекательно».

Вы можете узнать больше о практическом примере CarMax Lean UX в книге Готельфа и Сейдена, Lean UX .

Что дальше, Lean UX?

Поскольку Lean UX продолжает внедряться на рынке, куда он приведет компании в будущем?

«Я надеюсь и ожидаю, что этот способ работы просто станет нашим способом работы, — говорит Готельф, — когда мы перейдем в пост-agile-мир, пост-бережливый мир UX. Придет что-то новое, но… ценности сотрудничества, принятия решений на основе фактов, смирения, клиентоориентированности, я ожидаю, что эти ценности [сохранятся].Это то, что я вижу в движении вперед, разрушение бункеров».

«Программное обеспечение никуда не денется, — говорит Сейден. «Теперь это факт жизни, и непрерывные методы — это способ работы в программном обеспечении. … Мы действительно переходим от таких моделей конвейерных процессов к моделям непрерывных процессов. Я вижу молодых дизайнеров, с которыми я разговариваю, и они [говорят]: «Да, вот как вы работаете. Я не понимаю. Почему вы говорите об этом Lean UX? Это просто дизайн».

Создание продукта в цифровой среде полностью отличается от того, как мы создавали продукты раньше.Таким образом, Lean UX — это эволюция процесса проектирования в сторону цифрового будущего, где ключевыми являются быстрые изменения, непрерывное обучение и адаптация. Удивительно, но для такой эволюции процесса требуется время даже в самых технологичных отраслях, таких как программное обеспечение. Но мы определенно в пути.

Ресурсы

Готовы глубже погрузиться в Lean UX? Ознакомьтесь с этими ресурсами.

Lean UX: проектирование отличных продуктов с помощью гибких команд , Джефф Готельф и Джош Сейден

Чувствовать и реагировать: как успешные организации прислушиваются к клиентам и постоянно создают новые продукты , Джефф Готельф и Джош Сейден

UX для бережливых стартапов: более быстрые и интеллектуальные исследования и проектирование взаимодействия с пользователем , Лаура Кляйн

Справочник по бережливому продукту: как внедрять инновации с минимально жизнеспособными продуктами и быстрой обратной связью с клиентами , Дэн Олсен

Lean UX и Agile | Полнодневное обучение Nielsen Norman Group

«Я действительно многому научился на этом уроке.Мы не практикуем ни UX, ни AGILE, и после этого курса я действительно меньше их боюсь, чем раньше. «Новые» для нас технологии на самом деле кажутся более выполнимыми!»

Линн Сэй, графство Марин

«Курс был веселым, интересным, понятным, и ведущий был великолепен.»

Филип Лоу, Гербалайф

«Анна — отличный оратор. Материал ее курса очень четкий, хорошо организованный и красиво оформленный. Она очень хорошо осведомлена, а ее отраслевой опыт делает ее очень близкой.»

Эффи Халберт, Cox Automotive

«Пейдж — отличный оратор! Мне очень понравился большой объем предоставленной информации. Этот курс очень ориентирован на принципы/лучшие практики, но он также дает некоторое представление о том, как достичь целей бережливого/гибкого производства, нарушив несколько правил.»

Даррен Соррелс, Valorem LLC

«Рейчел великолепна! Мне очень понравился этот урок! Мне нравится взаимодействие и упражнения. Действительно классный класс! Я многому научился!»

Сильвия Креттол, CalPERS

«Я вместе с нашими коллегами-разработчиками предложил много идей по повышению эффективности нашего UX-процесса.Спасибо!»

Макнамара, Sandia National Labs

«Это лучший класс. Собирает все воедино.»

Хизер Хокинс

«Отличный курс! Очень увлекательные практические упражнения.»

Фредерика Квам, Accenture

«Отличный обзор принципов бережливого производства и гибкой разработки. Удивительное количество контента для однодневного занятия. Я также ценю множество практических практик, которые мы изучили.»

 

«Идеальный баланс анализа отраслевых кейсов и практических фреймворков UX.Я просто чувствую ее страсть к дисциплине Lean UX. Обязательно порекомендую это любому серьезному практикующему врачу.»

Клив Вонг

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

 

«Один из самых ярких моментов моей недели! У Хоа огромный опыт и знания. Отличный класс!»

Джефф Лашинс, Autodesk

«Мы только начали использовать Agile в нашей компании, и этот курс помог мне придумать, как лучше внедрить UX-процесс с минимальными проблемами (при условии, что команда готова!).Упражнение по юзабилити-тестированию было веселым и информативным. Поделюсь со своими командами.»

 

«Отличный класс! Множество практических концепций.»

Райан Стирс, Сент-Луис, Миссури

«Хоа заставил меня хотеть кричать… ПРОПОВЕДУЙ!! через регулярные промежутки времени. Информация и упражнения давали богатые знания и опыт. Я так рад вернуть его и способствовать принятию UX Agile! Спасибо».

Кристиан Стаффорд, Lockheed Martin

«Практические упражнения сразу воплотили концепции в жизнь.»

Бек Пламбе, Сиднейский университет

«Этот курс был очень полезным. Мне понравилось, что не было слишком много времени потрачено на то, что такое Agile, но было сосредоточено на большом количестве практических советов и советов по работе.»

 

«Это было очень полезно и познавательно. Моя команда и я будем использовать многое из того, что мы узнали.»

Сет Корнфельд, UX-менеджер, Bluetooth SIG, Inc.

«В настоящее время я работаю в команде 1UX в своем отделе, поэтому не использую методы Agile или Lean, но эта сессия была отличной тем, что дала мне идеи о том, как формировать некоторые методологии, чтобы помочь мне стать лучшим дизайнером UX и выделить больше ресурсов. .»

Оливия Каршник, 3M

«На данный момент мой любимый докладчик на конференции. Хоа привлекательна, проницательна и интерактивна. Она не просто читает свои слайды, но превращает семинар в однодневную дискуссию, основанную на великолепных тематических исследованиях, исследованиях и опыте.»

Бриджит Хафф, Объединенная сеть обмена органами

«Если вы хотите работать с UX в Agile-среде, не прибегая к ярлыку «узкое место» и не пропуская все свои исследования — пройдите этот курс. Он покажет вам, как это сделать.»

 

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

Эллисон Зубал, Overstock.com

«Курс помог мне упорядочить мои мысли о моем текущем процессе UX и дал мне инструменты, чтобы сделать его лучше. Узнав о решениях, которые другие используют для решения общих проблем профессионалов UX.Контексты Agile стали источником вдохновения для идеи, которую я с нетерпением жду реализации».

Брайан Коултер, Caktus Group

«Как общий ресурс, этот курс был для меня очень ценным. Теперь у меня есть хорошие идеи о том, как по-новому подходить к своей работе, а также к управлению, что, надеюсь, улучшит общую работу UX в моей компании».

Frederik VB Lauriosen, Sundhed Дания

«Отличный и понятный курс, который поможет вам понять вашу рабочую среду на высоком уровне.Я определенно рекомендую его всем, кто хочет улучшить свой рабочий процесс и отношения со своей командой.»

Синди Тани, AppFolio, Inc.

«Идеальное сочетание лекций и упражнений. Отличное сочетание тем.»

Тодд Александр

«Хоа великолепно преподает этот класс, ему очень понравилось количество взаимодействий и знаний, а вовлеченность была идеальной. Очень понравилось это, особенно занятие по созданию бумажных прототипов — так здорово!»

Рози Д’Анджело

«Я сказал себе, что если во время этой конференции в моих заметках будет 10 звезд, это того стоило.Было 22 звезд: что попробовать, что вспомнить, что исследовать и, возможно, попробовать вместе с моей командой.»

Крис Рейдер

«Это отличный курс для людей, которые хотят лучше понять, как UX сочетается с различными методами разработки. Я бы порекомендовал его разработчикам, менеджерам по продажам, а также дизайнерам».

Кристина Бакке, Moker IT

«Даже если вы новичок в Agile, инструменты и упражнения просты для понимания и демонстрируют явные преимущества для любой команды разработчиков UX/продукта.»

Кевин Булье, группа кадров

«UX в Agile обеспечивает прочную основу передовых практик, подкрепленных реальным опытом для UX-команд любого размера».

Кристин Ковиня, Allstate

«Как опытный дизайнер, прошедший этот курс и в настоящее время работающий в рабочей среде Agile, этот курс действительно дал мне понимание и выполнимый план в отношении различных болевых точек при попытке интегрировать работу UX в бэклог и Agile
рамки.»

Питер Чантасена, Skyline Technologies, Грин Бэй

«Мне очень понравился этот курс, потому что он помог освежить знания в областях, которые мне нужно отточить, и в областях, которые мне нужно узнать больше и реализовать вместе с моей командой. Мне понравились все тематические исследования, сетевое взаимодействие и ритм курса. Это было большим подкреплением для меня, потому что я знаю, что нахожусь в нужной области и должен продолжать заниматься этим Пейдж и Анна проделали большую работу, создав легко усваиваемую историю для процесса Lean UX и Agile.Слова могут звучать устрашающе, но этот курс был очень удобным. Если бы меня попросили, я бы обязательно прошла этот курс снова!»

Кэтлин Лоу, невозможное, вид на горы

«Пейдж и Анна были замечательными инструкторами. Курс проходил в хорошем темпе, и он был увлекательным даже в виртуальной среде.»

Рэйчел Уэтерли, Буз Аллен Гамильтон

«Отличный курс с правильным балансом теории и инструментов/методов для начала работы или улучшения вашего UX-процесса и того, как его можно переплести с разработкой.»

Лизетт ван Гамерен, DHL, Утрехт

«Мне очень понравилось, как практические примеры и примеры из жизни внесли свой вклад в сюжетную линию курса.»

Дрик ван Дейк, VITAS, Маарсен, Нидерланды

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

Джейк Роу, appdetex, Бойсе

«Я думаю, что этот курс чрезвычайно полезен для дизайнеров, продакт-менеджеров и даже разработчиков.Он охватывает различные рабочие процессы UX в организациях, плюсы и минусы, возможные области улучшения и компоненты, которые должны быть включены в гибкий поток, включая время, которое должен занять каждый шаг. Это было восхитительно! Это не готовая модель для подражания, а модульная и изменяемая в зависимости от потребностей бизнеса. Мне очень нравится тот факт, что ближе к концу курса были рассмотрены различные сценарии организации и добавлен список советов! Это было изысканно, как и любой другой курс NN/g!.»

Ли Ма, ProvantageX, Нью-Йорк

«Один из моих любимых ораторов, очень информативно, прекрасные упражнения и примеры!»

Йолани Алькантара, Laureate Education Inc., Гондурас

«Рэйчел Краузе — феноменальный ведущий, чрезвычайно увлекательный и действительно знающий свое дело! Вы можете сказать, что она очень увлечена этой областью, и она наполняет каждую тему такой энергией, советами здравого смысла и оптимизмом».

Эми Аллар, Фултон Банк, Гаррисберг, Пенсильвания

«Как UX-директор, я много лет пытался внедрить UX в Agile.Я начал с SCRUM и перешел на SAFe. Этот класс помог мне увидеть общую картину и предоставил методы, которые помогут мне сообщать о нашем процессе, продвигающемся вперед. Я чувствую облегчение, потому что у меня есть более твердое понимание и стратегия. NN/g спасает жизнь!»

Крис Говернски, Homecare Homebase, Wichita

«Множество идей, очень полезное для любого UX-дизайнера, работающего в гибкой среде».

Арджун Лингампалли, Таргет, Австралия

«Работа в традиционной среде водопада, этот курс был сложным, но и освежающим.Я получил новые знания и понимание некоторых концепций и тактик Agile/Lean UX, которые могут быть частично интегрированы в команды, с которыми я работаю и поддерживаю.»

Клара Юн, Меда, Дейтон, Огайо

«Большое количество ценной информации, подготовленной в очень легкой для понимания и усвоения форме. День пролетел так быстро, как я не ожидал.»

Амр Эльгеддави, Берлин, Германия

«Отлично! Анна великолепна!»

Сара Браганка, Королевское химическое общество, Кембридж, Великобритания

«Лучший курс на данный момент, глубокие идеи, веские аргументы в поддержку, хорошие тематические исследования… очень круто!»

Иоаннис Яннис, Cisco

«Анна была великолепна. Информация была очень полезной, и я могу сразу же использовать ее со своими коллегами.»

Майкл Хансен, Крогер, Портленд, Орегон

«Курс представлял собой удивительное сочетание теории, примеров из реальной жизни и полезных методов, которые я могу использовать в своей повседневной работе. Преподаватель был очень заинтересован и был рад ответить на вопросы о наших конкретных рабочих задачах. некоторые из моих существующих способов работы и вдохновили попробовать новые вещи!Спасибо.»

Сара Кронин Роджер, IBM

«Этот курс был отличным инструментом для дизайнеров, которые хотели узнать больше о том, как лучше сотрудничать с их продуктовыми командами, а также о том, как лучше управлять нашим временем во время спринтов. Спасибо, Анна и Пейдж! являются хорошим содержанием в презентации, так как она содержала примеры тематических исследований, которые принесли большую пользу классу в том, как подходить к аналогичным вопросам.Упражнения были достаточно понятными, чтобы понять концепцию экономичности и гибкости.»

Стефани Чан, Гонконг

«Я занимаюсь Agile уже 3 года, и этот курс открыл мне глаза. У меня появился новый взгляд на вещи, которые идут не очень хорошо, и появились идеи по улучшению моей рабочей среды. Большое спасибо!»

Лина, Германия

«Этот курс помог мне укрепить подход к работе. Я хотел бы привлечь к этому курсу остальную часть организации, чтобы у всех нас было общее понимание и оценка наших ролей и обязанностей.»

Тамзин Уорд, Лидс, Англия

«Очень полезно для любого UX-практика, работающего в бережливой или гибкой среде».

Эйрик Гринде, Буве, Осло, Норвегия

«Жаль, что я не прошел этот курс год назад — есть так много вещей, которые я хотел бы применить завтра к своей команде.»

Гуру Тиру, Омобоно, Лондон, Великобритания

«Очень полезно, когда ваша команда переходит на гибкий UX».

Kalle Yrjänä, Veikkaus Oy, Вантаа

«Этот курс на многое открыл мне глаза.Наша продуктовая команда и UX-профессионалы очень хорошо ладят с разработкой, а также с исполнительной командой, но мы все еще сталкиваемся со временем и часто «приходится» пропускать пользовательское тестирование и другую работу с UX. Это тот вид обучения, который можно применить сразу же, и я намерен использовать его для решения этой проблемы».

Кристал Кэри, Frazer Computing, Inc., Кантон

«Этот курс действительно дает мне прекрасную возможность продолжать лучше интегрировать работу с UX в моей организации. Кроме того, связи, которые я установил с другими профессионалами UX, были потрясающими, определенно отличная система поддержки после окончания конференции.»

Чарли Фуэнтес, Abarca Health, Пуэрто-Рико

«Я определенно рекомендую этот курс. Мне понравились групповые занятия, чтобы понять, как единомышленники практикуют LEAN UX или как они борются. Было приятно иметь возможность делиться знаниями с другими, а также учиться у тех, у кого больше опыта. .»

Стивен Карри, Highroads, Белфаст, Северная Ирландия

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

Jing Yang, Tetra Pak, Лунд, Швеция

«Этот курс я бы порекомендовал всем UX-специалистам. Мы все работаем в той или иной форме процесса доставки, и этот курс разбивает детали этих различных процессов на удобоваримые фрагменты.»

ДеАндре Хаттон, Visa, Inc., Остин, Техас, США

«Этот курс определенно предназначен для команд, которые ищут лучшие способы совместной работы, чтобы уменьшить выгорание и отток сотрудников. Он пропагандирует лучшие практики для UX и Agile. Я многому научился на этом курсе и рекомендую его».

Найф, Teck Resources, Ванкувер, Канада

«Если вы хотите узнать больше о Lean и Agile, этот курс — просто находка! Получите его!»

Мей Ненадич, Telia Company, Стокгольм, Швеция

«Курс полезен для всех продуктовых команд, будь то продакт-менеджеры, POS-менеджеры, UX-специалисты, исследователи, копирайтеры, с упором на роль UX в этом процессе.Мне понравился тот факт, что это побудило UX-дизайнеров взять на себя больше ответственности, когда дело доходит до планирования и объема продукта. Групповые упражнения были отличными, и мне понравился практический элемент взаимодействия с другими людьми, совместной работы и общения, что является одним из ключевых факторов при работе в Agile».

Яир Бахар, Гоэнри, Лондон, Великобритания

«Мне понравилось, как вы четко изложили темы, а также возможность сосредоточиться на чате.
Вопросы и ответы были познавательными! Я бы хотел, чтобы это длилось дольше, потому что вопросы очень основаны на полевых условиях.»

Стефан Олару, IBM, Бухарест, Румыния

«Если ваша организация пытается перейти на Agile или даже думает о переходе на Agile, то этот курс для вас. Он даст вам методы управления Agile таким образом, чтобы дать вам пространство, необходимое для UX, которое необходимо сделать должным образом. Авторитет Анны советы помогут вам убедиться, что ваша команда использует Agile эффективно и правильно».

Марк Клири, Министерство бизнеса, инноваций и занятости, Веллингтон, Новая Зеландия

«Этот курс помог мне освежить знания и открыл глаза на мой небольшой опыт работы с Agile.Если вы новичок или планируете перейти на Agile, этот курс идеально подходит для вас. Вы узнаете много нового о том, что происходит в Agile-среде, и о том, каков наилучший план игры».

Данали Лопрададо, GCash, Метро Манила, Филиппины

«Настоятельно рекомендуется, даже если вы думаете, что знаете об Agile все…»

Boon Cheong, Govtech, Сингапур

«Анна Кейли была великолепна! Материал курса был богатым, а предоставленный метод Lean UX можно сразу применить к командам UX.Упражнения прошли весело и по делу. Анна позаботилась о том, чтобы в конце каждого дня было время, посвященное ответам на все вопросы».

Рим Сабри, Сиэтл

«Анна может предоставить проверенные рекомендации по каждому отдельному сценарию, с которым вы столкнулись при интеграции UX и Agile. Я получил полное представление о том, что и когда работает лучше всего, и обо всех нюансах, влияющих на этот процесс, методологию и организационные решения. Упаковано с содержанием, к которому я буду обращаться снова и снова.»

Мэри Макиннис, Университет Айдахо, Москва, штат Айдахо, США

«Если вы знакомы с agile-методами, но не знаете, как последовательно внедрять в процесс бережливый UX, вы не одиноки! Этот курс даст вам много советов, как лучше сотрудничать с вашими командами доставки, проводить более бережливые исследования и управлять своим временем. и загруженность. Мне понравилось!»

Марион Каммерер, MYOB, Мельбурн, Австралия

«Мне очень понравилось. Анна отличный и интересный инструктор.Я ценю множество реальных примеров и практических шаблонов, которыми она поделилась с классом».

Лука Тараско, Healthware Group, Турин, Италия

«Если вы работаете над продуктом, особенно цифровым, этот курс просто необходим. Он дает вам совершенно другой взгляд на интеграцию нашей деятельности по UX с другими экспертами, и общий опыт просто потрясающий!»

Анджело, Digital Attitude, Милан, Италия

«Пройдите этот курс! Анна проделывает фантастическую работу, обучая нас тому, как расставлять приоритеты, оставаться организованными, быть инклюзивными, эффективными и результативными в нашей работе в Agile-среде.»

Жюстин Бенуа, BigBear, Inc., Арлингтон, Вирджиния, США

«Этот курс начинается с подробного обзора принципов и практики Lean UX и Agile. И завершается хорошо аргументированными подходами и некоторыми удивительно простыми действиями, чтобы привести UX и его партнеров в соответствие.
Хотя он не для новичков, он был чрезвычайно доступен для UX-специалистов с ограниченным опытом Agile, а также привносил методы и идеи для улучшения работы тех, кто работал в Agile много лет.
Ведется постоянная борьба за согласование рабочих процессов и взаимоотношений разработки и UX. Этот курс, конечно, не последнее слово в этой теме, но он предлагает несколько лучших вариантов и самых ясных путей, с которыми я сталкивался.»

Бен Киммел, Truist Bank, Дарем, Северная Каролина, США

«Принимайте! В этом курсе есть шаблоны, реальные навыки и инструменты, которые вы можете взять с собой. Мне понравилось использование комнат обсуждения Zoom и практические занятия, которые мы могли проводить виртуально».

Бонни Гастингс, Министерство труда, восстановления экономики и инноваций, Виктория, Британская Колумбия, Канада

«Ценный курс.Анна Кейли отлично рассказала сложную тему.»

Бобби Кантрелл, Атланта, Джорджия

«Курс отлично подходит для людей, которые хотят внедрить Agile в практику своей компании (в частности, для ролей UX).»

Лаура Рива Паласио, Jonajo Consulting, Чиуауа Мексика

«Если вы работаете внутри или совместно с agile-организацией, этот курс предоставит вам инструменты и идеи, которые вы можете использовать в своей организации для повышения эффективности процессов и предоставления ценности.»

Эмма Александер, Deere & Co, Давенпорт, Айова, США

«Курс Lean UX и Agile идеально определяет проблемы, с которыми сталкиваются многие дизайнерские группы при работе с гибкими методологиями, и предоставляет набор передовых методов, позволяющих командам дизайнеров преодолевать их и максимально использовать agile-мышление, способствуя совместной работы и позволяет командам двигаться быстрее.
Это помогло мне лучше понять структуру имеющихся у меня знаний и опыта, а также дало несколько советов и идей относительно действий, которые можно начать применять в моей команде.»

Фрэн Уэрта, HP Inc, Барселона

«Этот курс дает действительно всесторонний обзор всех шагов, которые UX должен предпринять в Agile-среде, чтобы перейти от идеи к продукту. Показаны многие методы структурирования задач и эффективного сотрудничества с разработчиками и заинтересованными сторонами».

Робин Ди Капуа, Swisscom, Цюрих

«Устали от ощущения, что никто не знает, как вовлечь вас в свой Agile-мир? Этот курс содержит знания, необходимые для того, чтобы присоединиться и начать совместную работу.»

Дэвид Кили, CDM Smith, Бостон, Массачусетс,

«Рэйчел забавная и делает Agile веселым (снова)».

Оскар Ибарс, ADP, Майами, Флорида

«Я работаю в крупной организации, которая в настоящее время борется с внедрением Agile, и этот курс дал мне дорожную карту не только для внедрения Agile-процессов, но и для улучшения общего рабочего процесса всей организации».

 

Lean UX Документация для отслеживания и коммуникации в Agile

Документирование рабочих процессов и проектных решений — это форма организационной памяти : она не позволяет командам бегать по кругу — повторять ошибки или просто спорить по одним и тем же темам снова и снова.Проблема, с которой сталкиваются UX-практики, работающие в Agile, — это понятие минимальной документации — в попытке работать быстро команды перестают записывать важную информацию. С другой стороны, слишком длинная документация может быть проигнорирована. В любом случае в результате тратится время на вспоминание информации или повторное отслеживание проектных решений вместо того, чтобы экспериментировать и итерировать, чтобы улучшить продукт для конечных пользователей.

В этой статье обсуждается, как документировать и сообщать нужные типы UX-деталей на протяжении всего процесса Agile-разработки продукта.Команды, применяющие эти методы, не будут перегружены избыточной документацией и легко запомнят, что важно.

Документация по Agile-разработке продукта

Независимо от этапа разработки продукта, помните о следующих факторах при работе с UX-документацией: 

• Кто публика? Ответ на этот вопрос должен определять уровень детализации, включенной в документацию, какая информация является приоритетной, а также как и где она передается.Выбор уровня детализации информации, подходящего для аудитории, предотвратит напрасные усилия и сделает информацию легко усваиваемой.
• Какова цель? Предназначена ли документация для предоставления исходного контекста, доказательств или обоснования? Чтобы помочь команде вспомнить что-то позже? Докладывать о прогрессе? Понимание того, зачем нужна документация, поможет вам увидеть, какие детали следует включить.
• Качество превыше количества: Чем меньше, тем лучше: не документируйте каждую деталь или каждую встречу, но достаточно, чтобы прояснить намерение или направление, подвести итоги, обосновать решение или наметить, как что-то должно работать.
• Это циклично и постоянно: Не ждите до последней минуты, чтобы задокументировать детали; делайте это по мере того, как вы исследуете и проектируете, чтобы бросить вызов своим собственным предубеждениям и обоснованиям, сохранить управляемость вашего проекта и добиться лучших результатов.

Когда и как я должен документировать?

Хотя Agile отдает предпочтение отдельным лицам, взаимодействиям и разговорам, а не объемной документации, есть два случая, когда особенно важно дополнить обсуждение облегченной документацией:

1.Прежде чем что-то начнется — например, перед открытием или другим пользовательским исследованием, событием (ранее называвшимся церемонией) или спринтом. Облегченная документация обеспечивает контекст, обеспечивает общее понимание и дает команде возможность вернуться к ней при возникновении вопросов. Для данного вида документации:

• Включите план того, что вы будете делать.
• Будьте краткими — используйте маркированный план или резюме на одной странице.
• Сообщите, как то, что вы сделаете, повлияет на команду.
• Определите, кто отвечает за цели или артефакты.
• Включить даты во входные данные таймбокса и трудозатраты.

2. Когда что-то меняется — например, если дизайн или функция должны двигаться в другом направлении или если цель спринта, выпускаемый инкремент или процесс разработки изменены. Поскольку Agile больше относится к реагированию на изменения, чем к следованию плану, упрощенная документация в этих случаях поможет команде быстро вспомнить, когда и почему произошли изменения, и подготовить ее к более эффективному и быстрому реагированию.В этих случаях:  

• Делитесь изменениями по мере работы.
• Сосредоточьтесь только на главном.
• Используйте существующие инструменты и документы для добавления деталей (например, для дизайнерских решений, систем дизайна, каркасов с аннотациями, каналов Slack, Jira/Confluence, других общих хранилищ документов или кода и т. д.).
• Укажите, кто отвечает за следующие шаги, действия и окончательные решения.
• Включите даты для временных рамок принятия решений и последующих действий.

Сообщение о текущем обучении и прогрессе

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

Не забрасывайте людей громоздкими презентациями, чрезмерно подробными результатами исследований и отзывами, а также расплывчатыми диаграммами и графиками. Их расточительно как создавать, так и потреблять.Вместо этого отправляйте регулярные и краткие отчеты о проделанной работе — через еженедельную сводку по электронной почте. Дайте ему броское и заметное название, например «UX Feedback Friday», чтобы люди с нетерпением ждали его каждую неделю. Не вдавайтесь в подробности и сосредоточьтесь на показателях, которые важны для вашего бизнеса и команды. Включите любые положительные и отрицательные качественные отзывы, которые должна знать команда.

Получайте количественные данные с платформ аналитики или бизнес-аналитики и резюмируйте качественные выводы из недавних исследований пользователей или отзывов, размещенных на платформах, где отслеживаются оценки сетевых промоутеров или удовлетворенности клиентов.Группируйте отзывы по ключевым темам и делитесь наиболее важными моментами.

Еженедельные отчеты о ходе работы должны включать следующее:

1. Название команды или продукта
2. Диапазон дат или период времени, которые отражают данные
3. Прогресс в направлении количественных показателей
4. Положительная качественная обратная связь или поведенческие наблюдения по результатам исследования пользователей
5. Отрицательная качественная обратная связь или поведенческие наблюдения по результатам исследования пользователей
6. Создатели культуры, такие как командные события, тренды или инструменты для расследования
Еженедельные отчеты о ходе выполнения UX помогают установить взаимопонимание с командой и предотвращают информационную перегрузку, когда речь идет об обмене отзывами и отслеживании показателей.Предоставление прогресса и обратной связи с пользователями в понятной форме и через регулярные промежутки времени помогает команде увидеть истинное влияние своей работы и то, на чем следует сосредоточиться дальше. 6 элементов отчета о проделанной работе — (1) название, (2) диапазон дат, (3) количественные показатели, (4) положительные качественные отзывы, (5) отрицательные качественные отзывы и (6) создатели культуры — все они вызываются. в этом примере отчет о проделанной работе.

Преимущества хорошей UX-документации и коммуникации

Хорошая документация по UX гарантирует, что все будут в курсе, и помогает Agile-проектам работать без сбоев.Когда нужная информация собирается с нужным уровнем детализации и в нужных местах, это не расточительно. Хорошая документация способствует лучшему и быстрому принятию решений, помогает представить и обосновать проектные решения и снижает когнитивную нагрузку на команду, действуя как форма внешней памяти. Поддержание организованности мыслительных процессов также укрепляет доверие и доверие к UX со стороны заинтересованных сторон.

No related posts.