2 заметки с тегом

дизайн-фреймворки

Design Sprint

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

Итак, Sprint, далее просто спринт — это пятидневный процесс, позволяющий отвечать на важные бизнес-вопросы посредством проектирования, создания прототипов и тестирования идей с клиентами.

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

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

Итак, поехали.

Готовимся к спринту

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

Понедельник

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

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

Вторник

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

  • Посмотрите на отличные решения от ряда компаний, в том числе вашей.
  • Быстро нарисуйте хорошие идеи на доске.
  • Соберите решения в кучу для следующего дня.

Среда

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

  • Выберите самое сильное решение.
  • Сделайте раскадровку вашего решения.

Четверг

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

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

Пятница

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

Источник The Design Sprint by GV


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

2020   дизайн-фреймворки

Spotify MVP

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

Верхний пример

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

«Вот, сэр, наша первая итерация, переднее колесо. Как вам?»

Конечно же, клиент не доволен. Он хотел получить машину, а получил колесо. Окей, мы сделали ещё четыре итерации и получилась машина. Продукт готов, но тогда в чем смысл итераций — не понятно. Зачем нужны все эти итерации? Почему не сделать сразу машину целиком?

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

Нижний пример

Давайте рассмотрим нижний пример.

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

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

Клиент вряд ли будет доволен этим. Это и рядом не стоит с машиной, которую он заказал. Но это нормально! Мы не пытаемся сделать клиента счастливым на данный момент. Наша главная цель на данный момент — обучаться и проверять. В идеале команда заранее четко объясняет это клиенту, поэтому он не слишком разочарован.

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

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

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

Скейтборд с ручкой! Теперь клиент не должен падать и сильно напрягаться.

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

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

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

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

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

Клиент очень доволен! Почему? Поскольку мы узнали по пути, что он ценит свежий воздух. В конце концов, он получил машину, но лучше, чем планировалось изначально!

Пример: музыкальный плеер Spotify

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

Помните, это был 2006 год, когда потоковое воспроизведение музыки было довольно ужасным опытом, а пиратская музыка была в значительной степени нормой. Техническая часть задачи заключалась в следующем: «Можно ли даже создать клиент, который транслирует музыку мгновенно, когда вы нажимаете кнопку „Воспроизвести“?

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

Но вместо того, чтобы тратить годы на создание огромного продукта, а затем выяснять, верны ли предположения, разработчики сели и сделали прототип. Загрузили музыку на свои ноутбуки и начали экспериментировать, чтобы найти способы сделать воспроизведение быстрым и стабильным. Показатель успеха был „сколько миллисекунд требуется, когда я нажимаю кнопку Play, когда слышу музыку?“. Он должен играть практически мгновенно и продолжать играть плавно, без заиканий.

Получив что-то приличное, они начали проверять себя, свою семью и друзей.

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

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

Пример: Minecraft

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

Это был их скейтборд. Вся связь пользователей и разработчика строилась в Твиттере.

Пример: Lego

Совершенно обратный пример был у Lego. Это продукт Lego Universe, многопользовательский онлайн-мир Lego. Звучит весело, да? Проблема в том, что они были чрезмерно амбициозными и в итоге попытались довести все до совершенства, прежде чем выпустить в мир.

Около 250 человек работали в течение 4-5 лет, и когда релиз, наконец, пришел, прием был очень теплым. Готовая игра была красивой, но не такой веселой, как ожидалось, поэтому продукт был закрыт через 2 года. Скейтборда не было! Почему нет? Потому что скейтборды не удивительны, по крайней мере, если вы ожидаете машину, а культура Lego заключается в том, чтобы доставлять удивительные впечатления!

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

Интересно, что команды Lego Universe фактически использовали Scrum и многократно выпускались — как это делали парни из Minecraft. Но релизы были только внутренними. Так что, скорее всего, были скейтборд, велосипед и так далее, но эти продукты никогда не доходили до реальных пользователей.

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

Выводы

  1. Избегайте доставки больших и сложных продуктов одним пуском. Делайте это итеративно и постепенно. Проверяйте каждую итерацию.
  2. Начните с определения вашего скейтборда — самого раннего тестируемого продукта. Стремитесь к облакам, но проглотите свою гордость и начните с доставки скейтборда.

Источник Making sense of MVP (Minimum Viable Product) — and why I prefer Earliest Testable/Usable/Lovable


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

2020   дизайн-фреймворки