Создание прототипов на 50 % быстрее: ускорьте запуск вашего продукта уже сегодня.

Многие продуктовые команды теряют время еще до начала разработки. Идеи остаются в документах, отзывы приходят с опозданием, а небольшие изменения в дизайне приводят к длительным циклам рассмотрения. Я видел, как команды тратили недели на полировку экранов, которые пользователям никогда не были нужны. Более короткий цикл создания прототипа может изменить ситуацию. Благодаря целенаправленному рабочему процессу некоторые команды могут сократить время на создание прототипа до 50 %, сохраняя при этом ключевые вопросы, связанные с продуктом. Результат — не поспешный макет. Это более понятный способ протестировать идею, прежде чем тратить больше бюджета и времени на разработку. Я начинаю с определения решения, которое должен поддерживать прототип. Прототип должен отвечать на конкретный вопрос: — Могут ли пользователи выполнить основную задачу? - Имеет ли структура страницы смысл? - Какую функцию команде следует создать в первую очередь? - На чем пользователи останавливаются или приходят в замешательство? Когда команда пытается протестировать каждую деталь сразу, работа расширяется. Я предпочитаю выбрать один путь пользователя, например регистрацию, бронирование услуги или совершение покупки. Это позволяет сфокусироваться на прототипе и дает обратной связи четкую цель. Следующий шаг — составить карту кратчайшего полезного пользовательского потока. Для продукта бронирования поток может включать в себя: 1. Выбор услуги. 2. Выбор даты. 3. Введите контактные данные. 4. Просмотр бронирования. 5. Подтверждение запроса. Для этого процесса не требуются все настройки учетной записи, уведомления или варианты оплаты во время первого тестирования. Я добавляю эти части после проверки основного пути. Простая карта потока также помогает командам обнаружить повторяющиеся экраны и пропущенные решения. Я могу удалить лишние этапы перед созданием детального проекта, что снижает необходимость повторной работы в дальнейшем. Я использую многоразовые компоненты, чтобы работа продолжалась. Кнопки, поля ввода, карточки, области навигации и сообщения об ошибках могут следовать общему шаблону. Когда команда меняет цвет, метку или правило макета, обновление можно применить ко всему прототипу, а не перестраивать экран за экраном. Этот метод помогает двумя способами. Это экономит время разработки и дает пользователям более единообразный опыт во время тестирования. Повторно используемые компоненты также упрощают передачу функций разработчикам, поскольку основные правила видны. Я делаю ранние экраны простыми. Прототип с низкой детализацией может показать, понимают ли пользователи суть процесса. Ему не нужны безупречные фотографии, сложная анимация или окончательный вариант. Эти детали могут отвлечь от проверяемого вопроса. Например, команда разработчиков, тестирующая службу доставки еды, может использовать простые блоки изображений и короткие этикетки. Если пользователи не могут найти дату доставки или понять категории меню, визуальная доработка не решит основную проблему. Сначала команде необходимо исправить структуру. Реалистичный контент по-прежнему имеет значение. Текст-заполнитель, такой как «Lorem ipsum», часто скрывает проблемы с макетом. Я использую короткие, правдоподобные этикетки и образцы данных, соответствующие предполагаемому продукту. Форма с надписью «Название компании» создает иные ожидания, чем форма с надписью «Ваше имя». Я тестирую небольшую группу, прежде чем искать широкую обратную связь. Пять человек, соответствующих целевой аудитории, могут выявить повторяющиеся проблемы в ключевом потоке. Я даю каждому задание и наблюдаю за тем, что он делает, не объясняя интерфейс слишком рано. Полезные подсказки включают в себя: - «Пожалуйста, покажите мне, как бы вы выполнили это задание». - «Что вы ожидаете, что произойдет после выбора этого варианта?» - «Что бы вы искали на этом экране?» - «Какая часть кажется неясной?» Я записываю закономерности, а не отдельные предпочтения. Если несколько человек пропустят одну и ту же кнопку, макет может потребовать внимания. Если одному человеку не нравится цвет, но он с легкостью выполняет задачу, этот комментарий может не потребовать изменения продукта. Короткий сеанс обратной связи легче анализировать, если команда использует четкий метод оценки. Я отслеживаю: - Выполнение задачи - Время, потраченное на основной путь - Количество неправильных поворотов - Вопросы, которые задают пользователи - Комментарии, которые появляются более одного раза. Затем команда может выбирать изменения на основе наблюдаемого поведения, а не личного вкуса. Я также установил ограничение по времени для каждого раунда прототипирования. Практический цикл может выглядеть следующим образом: - Полдня на определение основного вопроса - Один день на составление схемы потока - Один-два дня на создание прототипа - Полдня на подготовку теста - Один день на рассмотрение отзывов и внесение изменений. Точный график зависит от размера продукта, возможностей команды и потребностей в одобрении. Небольшая функция может вписаться в более короткий цикл. Службе с несколькими ролями или сложными правилами может потребоваться больше времени. Улучшение на 50% происходит за счет устранения работы, которую можно избежать, а не за счет пропуска полезных исследований. Команды могут достичь этого уровня, когда сокращают уровни утверждения, повторно используют шаблоны проектирования, тестируют один поток за раз и прекращают полировку экранов до того, как будет понятна основная проблема. Распространенной ошибкой является отношение к прототипу как к готовому продукту. Это создает необходимость защищать каждый экран и затрудняет принятие обратной связи. Я отношусь к прототипу как к общему инструменту обучения. Изменение, внесенное во время тестирования, не является сбоем. Это свидетельство того, что команда что-то нашла до того, как разработка покрыла затраты. Рассмотрим примерный случай. Небольшая платформа для встреч запланировала восемь недель на создание своего первого кликабельного прототипа. Команда сократила объем до одного потока бронирования, повторно использовала компоненты формы и протестировала путь с пятью целевыми пользователями. Прототип был готов примерно через четыре недели. Тестирование показало, что пользователи хотели видеть правила отмены, прежде чем вводить свои данные, поэтому команда переместила эту информацию на более ранний уровень. После начала разработки это изменение стоило бы дороже. Более быстрый цикл создания прототипа дает мне больше возможностей задать полезные вопросы: — Решаем ли мы реальную проблему пользователя? - Могут ли люди понять основное действие? - Какая функция заслуживает усилий по разработке? - Что должно измениться перед следующим обзором? Когда рабочий процесс остается целенаправленным, команды могут перейти от идеи к проверенному обучению с меньшими затратами усилий. Сокращение цикла на 50 % – это обещание не для каждого проекта. Это практическая цель для команд, которые упрощают задачу, создают многократно используемые шаблоны и тестируют наиболее важный путь перед добавлением деталей.

Многие идеи продукта остаются на доске, потому что путь от концепции до запуска кажется слишком долгим. Команды проводят недели, обсуждая функции, пересматривая планы и создавая работу, которая может не понадобиться клиентам. Я видел, как это происходило с небольшими командами разработчиков программного обеспечения, агентствами и растущими предприятиями. Проблема редко заключается в недостатке идей. Настоящая задержка связана с нечеткими приоритетами, медленными решениями и тестированием, которое начинается слишком поздно. Более быстрый процесс не означает спешку с выполнением каждой задачи. Это означает удаление работы, которая не помогает продукту достичь полезного результата для потребителя. Начните с одной четкой проблемы Я начинаю с проблемы пользователя, а не со списка функций. Вместо того, чтобы спрашивать: «Что нам следует построить?» Я спрашиваю: - Кто столкнулся с проблемой? - Что они пытаются завершить? - Что делает текущий процесс медленным, дорогостоящим или разочаровывающим? - Как они решают ее сегодня? - Что заставило бы их изменить свою нынешнюю привычку? Целенаправленная постановка проблемы дает команде общее направление. Например: > Мелкие интернет-магазины теряют время, проверяя запасы по нескольким каналам продаж. Это утверждение полезнее, чем: > Нам нужна универсальная розничная платформа. Первое утверждение описывает потребности пользователя. Второй описывает большую и неясную идею продукта. Превратите идею в небольшой тест Продукту не нужны все запланированные функции, прежде чем люди смогут его использовать. Я разделяю идею на три группы: - Необходимо проверить основную проблему - Полезно после раннего отзыва - Не требуется для первой версии В примере с розничной торговлей первый тест может включать в себя: - Одна информационная панель по запасам - Данные из двух каналов продаж - Оповещения о низком уровне запасов - Простой процесс установки Может не потребоваться: - Полноценное мобильное приложение - Настраиваемые отчеты - Расширенные роли пользователей - Автоматизированные заказы поставщикам Благодаря этому первая сборка остается достаточно маленькой для тестирования. Меньший по размеру продукт также облегчает понимание отзывов пользователей. Перед началом разработки поговорите с реальными пользователями Короткий разговор может помешать неделям разработки. Я предпочитаю спрашивать людей о недавнем поведении, а не спрашивать, нравится ли им какая-то идея. Подобные вопросы часто дают более полезную информацию: - Как вы справились с этим заданием на прошлой неделе? - Какая часть заняла больше всего времени? - Какие инструменты вы использовали? - Что пошло не так? - Вы уже платили за решение? Один из примеров — небольшая команда разработчиков программного обеспечения для бронирования. Команда планировала создать большую календарную систему с несколькими представлениями. Пообщавшись с владельцами салонов, они выяснили, что главная проблема не в дизайне календаря. Владельцам не хватало изменений в назначениях, отправленных по разным каналам. Команда изменила первую версию, сосредоточив внимание на обновлениях встреч и напоминаниях клиентам. Продукт стал меньше, его легче тестировать и он стал ближе к повседневной работе пользователей. Создайте правило принятия решений Реализация проектов замедляется, когда каждый выбор требует длительного обсуждения. Я использую простое правило принятия решения: — Помогает ли это проверить основную проблему? - Уменьшает ли это работу пользователя? - Можем ли мы измерить его стоимость? - Можем ли мы отложить его, не блокируя первый тест? Если функция не отвечает этим вопросам, я перемещаю ее в следующий список. Это не означает, что функция не имеет ценности. Это означает, что команда бережет свое время и удерживает внимание на главном вопросе продукта. Составьте общее описание продукта Краткое описание продукта может заменить множество разрозненных сообщений и документов. Я включаю: - Целевого пользователя - Тестируемую проблему - Основной вариант использования - Область применения первой версии - Показатели успеха - Открытые вопросы - Лицо, ответственное за каждое решение Хороший бриф может уместиться на двух или трех страницах. Дизайнеру, разработчику, маркетологу или владельцу бизнеса должно быть легко прочитать книгу без отдельной встречи. Целью не является документирование каждой детали. Цель — помочь людям принимать последовательные решения. Используйте прототипы перед написанием кода Прототип, на который можно нажать, покажет, где пользователи могут запутаться, прежде чем команда приступит к разработке. Я тестирую основную задачу на небольшой группе релевантных пользователей. Я смотрю, где они делают паузу, что они неправильно понимают и какими словами описывают процесс. Прототип не доказывает, что полноценный продукт будет работать. Это помогает команде находить основные проблемы, пока изменения еще просты. Например, финансовое приложение может проверять, могут ли пользователи подключить учетную запись, просмотреть транзакцию и найти итоговую сумму за месяц. Нет необходимости создавать полноценную систему отчетности, прежде чем эти шаги приобретут смысл. Установите короткие рабочие циклы Длинные циклы разработки могут скрывать проблемы до тех пор, пока стоимость изменений не станет высокой. Я предпочитаю короткие циклы с четким результатом: - Определить задачу - Построить наименьшую рабочую версию - Протестировать ее - Обзор того, что было изучено - Корректировка следующей задачи Каждый цикл должен отвечать на вопрос о продукте. Цикл, в котором только добавляются экраны, ничего не изучая, может создать больше работы без улучшения продукта. Короткие циклы также помогают командам раньше обнаружить технические ограничения, нечеткие требования и замешательство пользователей. Оценивайте полезное поведение Продукт может получить положительные отзывы, но при этом не решить проблему. Я выбираю небольшой набор показателей, связанных с задачей пользователя, например: - Время, необходимое для выполнения основного действия - Количество пользователей, завершивших настройку - Повторное использование после первого посещения - Запросы поддержки по одному и тому же шагу - Процент пользователей, выполнивших намеченный рабочий процесс. Эти показатели не должны быть сложными. На начальном этапе может быть достаточно простого отчета о событии или короткого звонка клиенту. Правильная мера зависит от продукта. Инструмент управления задачами может отслеживать выполненные задачи, а служба бронирования может отслеживать завершенные бронирования. Держите маркетинг рядом с работой над продуктом Маркетинг не должен ждать, пока продукт будет готов. Я использую ранний язык продукта, чтобы проверить, легко ли понять сообщение. На понятной странице можно объяснить: - Кому помогает продукт - Какую проблему он решает - Как работает основной рабочий процесс - Что нужно пользователям для начала - Что продукт еще не предоставляет. Это предотвращает распространенное несоответствие: продукт решает одну проблему, в то время как маркетинговая страница обещает нечто большее. Контент, ориентированный на поиск, может поддержать этот процесс, отвечая на конкретные вопросы пользователей. Практические страницы о настройке, рабочем процессе, факторах ценообразования или типичных ошибках часто привлекают более полезных посетителей, чем расплывчатые заявления. Используйте автоматизацию там, где она исключает повторяющуюся работу Автоматизация может сократить рутинные задачи, но не должна заменять оценку продукта. Полезные области могут включать в себя: - Преобразование заметок о собраниях в списки задач - Создание тестовых данных - Проверка повторяющихся записей форм - Отправка приглашений на исследования - Организация обратной связи с клиентами - Создание черновой документации Я все еще просматриваю выходные данные перед их использованием. Автоматизированная работа может сэкономить время, если процесс понятен. Это может создать больше проблем, если цель или вклад неясны. Практический пример экономии времени Команда разработчиков из пяти человек спланировала портал поддержки клиентов. Их первоначальный план включал базу знаний, чат, маршрутизацию заявок, аналитику и мобильное приложение. Команда поговорила с восемью менеджерами службы поддержки и обнаружила, что наиболее распространенной проблемой являются повторные ответы на одни и те же вопросы настройки. Они выбрали меньший по размеру первый выпуск: - Справочные статьи с возможностью поиска - Простая обратная связь по статьям - Отчет, показывающий поисковые запросы без ответов. Команда протестировала рабочий процесс с существующими клиентами, прежде чем добавлять чат или мобильные функции. Планирование и тестирование релиза прошли быстрее, потому что команда решила одну четкую проблему вместо того, чтобы сразу создавать полную систему поддержки. Результат не был гарантирован специальным инструментом или фиксированной формулой. Экономия времени была достигнута за счет меньшего объема работ, более ранней обратной связи и более быстрого принятия решений. Простой рабочий план Я использую эту последовательность действий, когда идею необходимо реализовать в виде продукта: 1. Определите одну проблему клиента. 2. Поговорите с людьми, которые столкнулись с этим. 3. Выберите самый маленький полезный тест. 4. Создайте простой прототип. 5. Протестируйте основную задачу. 6. Установите короткий цикл сборки. 7. Измеряйте поведение клиентов. 8. Улучшите следующую версию на основе доказательств. Цель не в том, чтобы обещать, что каждый продукт можно создать вдвое быстрее. Сложность продукта, размер команды, технические ограничения и потребности клиентов — все это влияет на график. Практический урок легче контролировать: сократите количество неясной работы, заранее проверьте важные предположения и дайте команде решать по одной проблеме за раз. Именно так идея может перейти от обсуждения к полезному продукту с меньшими затратами усилий.

Многие продуктовые команды теряют недели, прежде чем узнают, что на самом деле нужно пользователям. Задержка часто возникает из-за длительных сессий планирования, больших списков функций, неясного владения и тестирования, которое начинается слишком поздно. Я предпочитаю более короткий путь: создать небольшую версию, протестировать ее на реальных пользователях, изучить их поведение и запустить, когда продукт решит одну очевидную проблему. Начните с одной проблемы пользователя Я начинаю с одного простого утверждения: «Я хочу помочь [конкретному пользователю] решить [конкретную проблему] без [обычного разочарования]». Например: «Я хочу помочь независимым дизайнерам отправлять профессиональные счета-фактуры, не тратя часы на настройку бухгалтерского программного обеспечения». Это заявление делает продукт целенаправленным. Это также помогает мне удалить функции, которые кажутся полезными, но не отвечают основным потребностям пользователя. Продукт не обязательно должен решать все проблемы при запуске. Он должен решить одну проблему достаточно хорошо, чтобы люди поняли его ценность. Выберите самую маленькую полезную версию Я перечисляю все функции, которые могут поддержать эту идею. Затем я отмечаю каждый элемент как: - Требуется для основной задачи - Полезен, но не обязателен - Лучше сохранить на потом Для простого продукта бронирования могут потребоваться: - Страница услуги - Доступные временные интервалы - Форма бронирования - Сообщения с подтверждением В первый день может не потребоваться программа лояльности, мобильное приложение, панель управления командой или расширенные отчеты. Такой подход не означает создание плохого продукта. Это означает сокращение дистанции между идеей и отзывами пользователей. Небольшой продукт легче объяснить, создать, протестировать и изменить. Создавайте с учетом отзывов пользователей Я не дожидаюсь, пока каждый экран станет завершенным, прежде чем показывать продукт. Я делюсь ранними версиями с небольшой группой подходящих пользователей. На этом этапе я наблюдаю за практическими сигналами: - Могут ли пользователи понять, что делает продукт? - Смогут ли они выполнить главную задачу? - Где они останавливаются? - Какие вопросы они задают? - Какие части они игнорируют? Я избегаю спрашивать только: «Тебе это нравится?» Люди могут давать вежливые ответы. Их действия часто дают более полезную информацию. Например, команда, создающая инструмент планирования питания, может услышать, как пользователи говорят, что им нужно много фильтров рецептов. В ходе тестирования команда может обнаружить, что пользователям в основном сложно составить еженедельный план. Продукту может потребоваться более простой процесс планирования, а не больше фильтров. Проверьте самое рискованное предположение Каждая идея продукта содержит предположения. Команда может верить: - Пользователи часто сталкиваются с этой проблемой - Они изменят свою текущую привычку - Они поймут предлагаемое решение - Они заплатят за него - Продукт может достичь их через подходящий канал. Я проверяю предположение, которое может вызвать самый большой провал. Если я не уверен, нужна ли пользователям эта услуга, я разговариваю с потенциальными пользователями, прежде чем создавать полноценную платформу. Если я не уверен, работает ли процесс регистрации, я проверяю его с помощью кликабельного прототипа. Если я не уверен в ценах, я представляю четкие планы и прошу пользователей выбрать тот, который соответствует их потребностям. Короткий тест может предотвратить длительную сборку. Установите четкие стандарты запуска Скорость становится рискованной, если команда запускает продукт без базовой проверки качества. Я использую простой список запуска: - Основная задача пользователя выполняется от начала до конца - Формы обрабатывают типичные ошибки - Ключевые страницы загружаются на распространенные устройства - Пользователи могут обращаться в службу поддержки - Четко объясняются детали конфиденциальности и оплаты - Команда может отслеживать основную активность продукта - Известные ограничения сообщаются первым пользователям Продукту не требуется каждая запланированная функция. Для этого нужен надежный основной опыт. Я также отделяю блокировщики запуска от мелких улучшений. Нарушенный этап оплаты должен остановить запуск. Возможно, проблема с небольшим интервалом не потребуется. Запуск для узкой аудитории Запуск меньшего размера дает команде возможность учиться. Я могу начать с одной группы клиентов, одного местоположения или одного варианта использования. Например, инструмент планирования может начаться с независимых тренеров по фитнесу, а не обслуживать каждый сервисный бизнес. Команда может узнать, как тренеры назначают встречи, какие напоминания им нужны и какие термины имеют для них смысл. Такой фокус облегчает интерпретацию обратной связи. Это также обеспечивает управляемость поддержки, пока продукт все еще меняется. Оценивайте поведение продукта после запуска Запуск — это не конец работы над продуктом. Я отслеживаю несколько полезных сигналов, а не собираю все возможные цифры: - Сколько пользователей выполняют основную задачу - Где пользователи покидают процесс - Как часто они возвращаются - Какие функции они используют - Какие вопросы поддержки появляются повторно - Рекомендуют ли пользователи продукт подходящему человеку Цифрам нужен контекст. Большое количество регистраций не доказывает, что продукт полезен, если большинство пользователей так и не выполнили основную задачу. Я объединяю данные о продукте с короткими беседами. Пользователь может отказаться от функции, потому что цена неясна, формулировка сбивает с толку или продукт не соответствует его рутине. Поддерживайте сплоченность команды Быстрая реализация зависит от четких решений. Я веду одно общее описание продукта, в котором фиксируется: - Проблема пользователя - Целевая аудитория - Основная задача - Объем запуска - Открытые вопросы - Результаты тестирования - Решения и их причины Это сокращает повторные обсуждения. Это также помогает проектированию, проектированию, маркетингу и поддержке работать на основе одной и той же информации. Моя точка зрения проста: скорость не достигается за счет спешки с выполнением каждой задачи. Это происходит за счет сокращения ненужной работы, раннего тестирования предположений и четкого определения содержания продукта. Создайте самую маленькую полезную версию. Проверьте это на людях, которые соответствуют целевой аудитории. Исправьте барьеры, которые блокируют основную задачу. Запустите продукт, когда основной опыт будет готов, а затем используйте доказательства для руководства следующим изменением. Свяжитесь с нами по FENG WENJIE: fengwenjie@shjieyan.cn/WhatsApp +8613671807091.

Ссылки Эрик Райс, 2011 г., «Бережливый стартап», Стив Бланк и Боб Дорф, 2012 г., «Руководство владельца стартапа», Джейк Кнапп, Джон Зератски и Брейден Ковиц, 2016 г., «Спринт» Дон Норман, 2013 г., «Дизайн повседневных вещей», Александр Остервальдер и Ив Пинье, 2010 г., «Поколение бизнес-моделей» Тереза Торрес, 2021 г., «Непрерывное открытие» Привычки