Дизайн-мышление — это последняя модная фраза, завоевавшая мир бизнеса и технологий. Похоже, эта фраза появляется почти в каждом контексте. Несколько лет назад Lean UX был в моде, после нескольких лет, сосредоточенных на Lean Startup . За несколько лет до этого каждая технологическая компания, которую я знал, спешила внедрить процессы разработки Agile. Такие эксперты, как Лу Розенфельд, уже делают прогнозы о том, какие новые подходы последуют.
Не то, чтобы какой-либо из этих подходов со временем стал менее полезным, но люди экспериментируют с новыми способами создания продуктов и успешными методами, к которым можно привязаться как «Следующая большая вещь», которая окажется волшебным решением для всех. Проблема заключается в том, что, несмотря на обсуждение чего-то нового, мы не всегда связываем точки наших существующих методов, и люди могут запутаться в том, как наилучшим образом реализовать все вместе.
Читайте дальше, чтобы лучше понять дизайн-мышление, Lean UX и Agile, а также как реализовать элементы каждого из них для вашей команды.
Прежде чем мы зайдем слишком далеко, давайте сделаем шаг назад, чтобы понять каждый подход.
проворный
Давайте проясним: Agile — это подход к разработке программного обеспечения. Она родилась из-за разочарования в традиционных «программных решениях», связанных с программным обеспечением, с длительным периодом сбора предварительных требований и проектных работ, а затем с длительной стадией разработки реализации указанных проектов, но без способности понимать или реагировать на изменяющиеся потребности. В результате команды тратили много времени на создание вещей, которые людям не нужны или не нужны, а компании боролись.
Разработчики программного обеспечения начали экспериментировать с новыми способами построения и разработали набор общих ценностей и принципов, которые помогут командам лучше работать.
- Официальный Agile Manifesto был выпущен в 2001 году и призвал оценить:
- люди и взаимодействия над процессами и инструментами
- рабочее программное обеспечение поверх исчерпывающей документации
- сотрудничество с клиентом в рамках переговоров по контракту
- реагировать на изменения в соответствии с планом
Agile Alliance также определил 12 подробных принципов, которым нужно следовать , но не предписывает каких-либо конкретных процессов, поэтому команды разработчиков часто заканчивают тем, что используют конкретные структуры, такие как Scrum или Kanban, чтобы помочь им понять, как организовать, спланировать и выполнить свою работу. , Особое внимание уделяется независимости групп для самоорганизации, поэтому никакие две Agile-команды не выглядят одинаково даже в рамках одних и тех же отделов или организаций.
Теоретически Agile-подходы не только хорошо сочетаются с практиками UX, но и активно требуют постоянных исследований UX, чтобы постоянно понимать меняющиеся потребности клиентов. Однако на практике команды могут увлечься попыткой выпустить больше рабочего кода быстрее, и может быть трудно вообще посвятить какое-то время проведению исследований или сосредоточению внимания на проектных решениях. Agile команды часто борются с тем, как наилучшим образом включить членов команды UX и их работу в свои практики.
Lean UX
Lean UX был рожден в результате борьбы, которую так много команд внедрили лучшие практики UX, поскольку они адаптировали свои процессы разработки к методам Agile и пытались ускорить время от идеи до реализации. Lean UX — это общий термин для изменения традиционных методов UX в соответствии с более быстрыми временными рамками, что часто означает смещение фокуса с подробных результатов.
Но будьте осторожны: вы также можете услышать о Lean и Lean Startup, которые часто смешиваются, но имеют определенное значение и различные элементы. Бережливое производство основано на передовых производственных методах и ориентировано на общие методы ведения бизнеса и управления с целью сокращения отходов и максимизации стоимости. Lean Startup — это более широкий подход к развитию бизнеса и продуктов, который предлагает включать периоды экспериментов, чтобы уменьшить потери и риски. Условия не являются взаимоисключающими, но и не являются взаимозаменяемыми.
Вернемся к Lean UX: основная идея состоит в том, чтобы изменить традиционные методы проектирования UX, чтобы стать быстрее. Вместо того, чтобы тратить много времени на тщательную разработку и документирование каждого элемента, команда предназначена для быстрой и совместной визуализации идей и сбора отзывов как можно скорее, как от других членов команды, так и от заинтересованных сторон и пользователей.
Джефф Готельф излагает следующий процесс Lean UX: концепция, прототип, внутренняя проверка, внешняя проверка, изучение, повторение и повторение . Этот процесс отражает «обычный» процесс UX, но каждый шаг сокращается.
Допустим, команда работает над интеграцией новой функции. Команда может сначала провести сеанс быстрой доски, чтобы конкретизировать основной рабочий процесс. После того, как группа договорилась о направлении, они могут показать пользователям проект с низким уровнем точности и включить обратную связь, найденную во время совместного сеанса скетча, где они расскажут больше деталей взаимодействия.
Вы заметите, что в этом примере нет полнофункциональных прототипов или подробных отчетов о тестировании, но Lean UX не является оправданием для пропуска шагов. Скорее, это приглашение сделать достаточно для создания общего видения и получения обратной связи, масштабирования и поддержки различных инструментов или методов, так как это наиболее целесообразно для вашего конкретного контекста.
Lean UX также не предлагает вам полностью отказаться от документации, а также от того, что опыт решения принимается профессионалами UX. Скорее, это говорит о том, что вся команда вовлечена в процесс проектирования, поэтому нет никаких неожиданностей или непредвиденных технических проблем. Отзывы собираются рано и часто, и, если необходимо внести изменения, они могут быть сделаны быстро и легко, прежде чем много времени будет потрачено на окончательные проекты.
Дизайн мышление
Дизайн-мышление — это общий подход к творческому решению проблем, популяризированный Stanford d.school и IDEO и недавно принятый многими технологическими компаниями. Этот подход состоит из пяти этапов и предназначен для определения и решения проблем всех видов.
Первый шаг — Empathize , который очень похож на этапы исследований старой школы. Вы собираете как можно больше информации, чтобы узнать о вовлеченных людях, их проблемах и мотивациях и их контексте. Это может означать, что вы делаете такие вещи, как проведение собеседований, наблюдение за людьми в их пространстве, общение с экспертами или изучение прошлых моделей поведения.
Затем вы анализируете то, что собрали, и обобщаете мысли, чтобы определить основную проблему для аудитории, которой вы служите. Посмотрите, что вы узнали о группе, что им нужно, и где могут быть пробелы, чтобы создать краткое изложение проблемы, чтобы сформулировать ваши следующие шаги.
Третий шаг состоит в том, чтобы найти решение для поставленной проблемы, используя творческие приемы, чтобы взглянуть на проблему с разных сторон и предложить как можно больше разных идей. Идея состоит в том, чтобы сначала пойти широко, генерируя множество альтернатив, прежде чем сузить его до нескольких возможных решений для тестирования.
Прежде чем вы сможете собрать какие-либо отзывы, команда должна прототипировать или создавать недорогие представления решения. Прототипом может быть что угодно, от серии эскизов до идеального моделирования пикселя предложенного процесса. Цель состоит в том, чтобы найти такой баланс, чтобы решение выглядело достаточно реальным для получения достоверной обратной связи, но было относительно дешевым и простым в изготовлении.
Наконец, вы хотите протестировать прототипы, поставив их перед реальными или репрезентативными пользователями и наблюдая за тем, что они делают и как они реагируют, а затем используя информацию для формирования следующих раундов.
Вы должны заметить, что, хотя процесс представлен линейно, в действительности фазы могут перекрываться, или что-то, чему вы научитесь по ходу дела, побудит вас вернуться к сопереживанию или определению проблемы. Подход должен быть структурированным, но гибким.
Все это должно звучать довольно знакомо. Проектное мышление — это формула, которая помогает командам совместно понимать и решать проблемы, создавая их вокруг вовлеченных людей и используя обратную связь на ранней и частой основе, что также лежит в основе хорошей практики UX.
Связывая все вместе
Хорошей новостью является то, что каждый из упомянутых мной подходов имеет некоторые ценные компоненты почти для каждой команды. Концентрация Agile на совместной работе, итерации, обратной связи и скорости означает, что команды с меньшей вероятностью будут тратить время на создание вещей, которые никому не нужны, а Lean UX помогает адаптировать традиционные методы UX в соответствии с темпами более быстрых команд разработчиков. Дизайн-мышление дает людям из всех видов дисциплин подход к изучению проблем и сосредоточению внимания на пользователях.
Плохая новость заключается в том, что на практике эти три метода иногда могут противоречить друг другу, поскольку они являются подходами, предназначенными для решения различных проблем. Agile — это программное обеспечение, Lean UX — дизайн и исследовательские процессы, а Design Thinking — инструмент для исследования идей. Очень часто разные люди или группы внутри компании будут нести ответственность за эти разные домены, и их индивидуальные сроки и цели могут не совпадать.
Например, команда стратегов может использовать подходы к проектному мышлению, чтобы исследовать идеи в начале инициативы, а затем начать сотрудничать с дизайнерами UX, чтобы конкретизировать концепции, а тем временем команды разработчиков могут использовать циклы итераций Agile для построить то, что они знают. Это не обязательно линейный процесс, и передача обслуживания и различия между заинтересованными сторонами и ключевыми игроками могут вызвать напряженность или переделку. Иллюстрация Lithespeed делает большую работу по визуализации того, как процессы могут быть успешно переплетены.
Конечно, уникальный набор деталей реализации, которые лучше всего работают для каждой команды и проекта, будет зависеть от целого ряда факторов, таких как организация, в которой вы находитесь, что вы пытаетесь создать и где вы находитесь в этом. процесс.
Следующие шаги должны помочь каждой команде.
Поделился видением
Первый шаг, который я хотел бы сделать, — это привлечь всех участников к каждому из трех основных доменов, чтобы они согласились с общим видением, четко заявили и поделились им со всеми членами команд. Это звучит как очевидный первый шаг, но для каждой команды или человека довольно свойственно иметь свою версию конечного пункта назначения организации. Попробуйте: спросите разработчика, дизайнера UX и стратега по продукту, которые вместе работают над своим видением. Редко все три будут отвечать одинаково, если они вообще могут ответить.
Общее видение должно определять конечную цель компании, а не то, как команды должны туда добираться. Например, видение Амазонки
быть самой ориентированной на клиента компанией Земли, где клиенты могут найти и открыть для себя все, что захотят купить в Интернете, и стремятся предложить своим клиентам самые низкие цены.
Идея состоит не в том, чтобы предписывать, а в том, чтобы убедиться, что все движутся в одном направлении, и вы можете проверить свою работу, чтобы убедиться, что она выровнена.
Очистить измерительные циклы
Команды также должны определить, как они будут измерять успех в сравнении с этим видением. Каждый из этих подходов рекомендует частые эксперименты и циклы обратной связи, но вам необходимо четко определить, к каким результатам вы стремитесь, какие показатели помогут вам понять эти результаты, как вы будете собирать эту информацию и какие параметры будут определять, что вы будете делать дальше.
Мне особенно нравится эта структура гипотезы :
Если мы делаем, строим или предоставляем х вещь ,
Тогда эти люди
Будет ли какой-то желаемый результат .
Мы будем знать, что это правда, когда действенные метрики .
Постарайтесь создать эксперименты, которые позволят ответить на ваши вопросы как можно быстрее и дать вам четкое решение, чтобы вы чувствовали себя комфортно, отказываясь от усилий, которые не дают вам того, кем вы хотите быть.
Помните, что вы можете извлечь максимальную пользу из усилий, которые «провалили» свои гипотезы. В изучении того, что работает хорошо, а что нет, присуща ценность, даже если вам придется отбросить какую-то работу.
Сохранить фокус на пользователя
Основой каждого из этих методов является полное понимание людей, для которых вы решаете, и обеспечение того, чтобы они оставались в центре циклов обратной связи и точек принятия решений на протяжении всего процесса. На практике это означает постоянное общение и изучение ваших существующих и потенциальных пользователей. Важно пробовать новые решения, но также следует понимать, что пользователи и их цели или контексты могут со временем меняться. Продолжайте принимать меры для понимания ваших пользователей и их потребностей независимо от того, где вы находитесь в процессе разработки продукта.
Настройте команды на успех
Межфункциональное сотрудничество является еще одним основополагающим элементом в каждом из подходов, и для групп идеально подходит работа с выделенными членами для нескольких дисциплин, работающих вместе. Обеспечение ценности для ваших пользователей должно быть приоритетом для всех, и лучшие решения приходят от разных людей, вкладывающих свои таланты и знания.
Также важно постоянно проверять свои команды, чтобы оценить, что работает хорошо, а что можно улучшить с точки зрения процесса. То, что работает для одной команды, может не подходить для другой, и важно дать себе время подумать и попробовать что-то новое. Вместо того, чтобы сосредоточиться на конкретном процессе, сосредоточьтесь на приверженности экспериментам и постоянному обучению.
В конце концов, у каждой команды нет единого «правильного» способа внедрить Agile, Lean UX или Design Thinking в свои практики. Каждый подход предназначен для решения конкретной проблемы, и элементы каждого из них могут быть полезны, поэтому вам нужно будет найти то, что работает для вашей команды. Наслаждайтесь экспериментами!