Эй, а ты знал, что слово “дизайн” стоит прямо в подзаголовке этой книги? Это правда. Я полагаю, это означает, что, вероятно, пришло время прекратить разговоры об исследованиях и начать говорить о том, что вы делаете со всеми этими знаниями, которые вы собрали, и как вы могли бы начать воплощать эти идеи во что-то более основательное.
Я ценю ваше терпение.
Если вы пропустили первую часть, будем считать, что вы провели исследование. Вы знаете, кто ваш клиент. Вы знаете, в чем его проблема. Вы думаете, что знаете, как решить эту проблему.
Вторая часть этой книги посвящена дизайну. Она проведет вас по всем разделам дизайна, которые понадобятся вам для создания продукта.
В этом разделе рассказывается обо всем, начиная с тонкостей создания прототипа и заканчивая выяснением того, когда он вам не нужен. В нем рассказывается о том, какого рода дизайн вам не следует создавать, поскольку это может сэкономить вам невероятное количество времени и хлопот. В нем даже немного рассказывается о визуальном дизайне.
И да. Мне не сошло бы с рук упоминание Lean в названии, если бы я не говорил о минимально жизнеспособных продуктах. У них есть отдельная глава.
Не поймите меня неправильно. Вы еще далеко не закончили процесс проверки. Но теперь, когда у вас есть полностью подтвержденная идея, не пора ли приступить к созданию и проверке вашего продукта? Я думаю, что пора.
В этой главе:
- Вы узнаете, почему перед разработкой продукта следует разработать тест.
- Получите девять инструментов, которые имеют решающее значение для разработки вашего продукта.
- Поймете, какие из этих инструментов вы можете смело пропустить в зависимости от того, что вы создаете и для кого.
Я должен предупредить вас, что если вы уже являетесь профессиональным дизайнером, то некоторые из описанных ниже действий могут показаться вам утомительными или привести в бешенство. Это нормально. Я не собираюсь учить профессиональных дизайнеров еще лучше справляться со своей работой. Это предназначено для того, чтобы научить других людей создавать дизайн, достаточный для подтверждения или опровержения их первоначальных гипотез. Это также предназначено для того, чтобы научить дизайнеров проектировать в условиях бережливого производства и проверять правильность своей работы.
Дизайн - это богатая и сложная область, которую люди изучают всю свою жизнь с разной степенью успеха. Что еще хуже, в дизайне существуют десятки различных дисциплин — например, понимание того, как должен работать сложный продукт, отличается от разработки красивой брошюры, которая отличается от разработки физического объекта. Все это называется дизайном. Вероятно, потому, что мы дизайнеры, а не лингвисты.
Но, по сути, дизайн - это решение проблем. Как только вы четко определили свою проблему и то, каким вы хотите видеть результат, Lean UX рекомендует вам выполнять как можно меньше работы для достижения желаемого результата, на тот случай, если желаемый результат не совсем идеален. Это означает, что вы выполняете только тот объем работ, который необходим для подтверждения вашей гипотезы.
Иногда сделать очень мало дизайна даже сложнее, чем сделать много. Потому что весь фокус в том, чтобы знать, какой дизайн является наиболее важным в данный момент, а какой - просто пустой тратой времени.
Если вы провели исследование, вы должны достаточно хорошо понимать свою проблему, свой рынок и концепцию своего продукта. Надеемся, у вас есть проблема, которую вы хотите решить, и идея функции или продукта, которые могли бы ее решить. Теперь вам нужно что-то создать.
Возможно, это должно быть очевидно, но есть множество различных вещей, которые вам нужно создавать в течение жизненного цикла продукта. Многие советы посвящены самому первому этапу создания — первоначальному продукту.
Но подавляющее большинство дизайнерских решений принимается после того, как вы создали продукт. Вы постоянно повторяете и меняете свой первоначальный продукт. Или, по крайней мере, так должно быть.
Вот некоторые из действий, которые вам нужно будет выполнить в процессе создания и перестройки вашего продукта. Все это требует определенной проработки дизайна:
- Исправьте ошибку.
- Устраните состояние ошибки.
- Внесите небольшое изменение в процесс взаимодействия с пользователем.
- Создайте совершенно новую функцию.
- Полностью измените визуальный дизайн.
- Измените существующий визуальный дизайн.
- Реорганизуйте продукт.
- Создайте совершенно новый продукт.
- Измените дизайн для другой платформы.
Чтобы еще больше запутать ситуацию, между некоторыми из них есть много неясностей. Например, некоторые исправления ошибок являются опечатками, другие коренным образом меняют процесс, через который проходит пользователь, а некоторые могут вообще не оказывать заметного влияния на пользователя.
Но у всех этих различных типов изменений есть одна очень важная общая черта: в Lean UX вы должны разрабатывать ровно столько, чтобы подтвердить свою гипотезу. И не более того.
Существует процесс, позволяющий сделать это с помощью бережливого производства, и я собираюсь описать его здесь. По мере того, как я буду описывать его, вы будете думать про себя: “Похоже, это огромный объем работы!”
И дело в том, что это действительно большой объем работы. Бережливый дизайн - это не ленивый дизайн. Речь не о том, чтобы пропускать этапы, выполнять некачественную работу или не продумывать взаимодействие с пользователем. На самом деле, бережливый UX имеет много общего с традиционным дизайном, ориентированным на пользователя, а также с гибким дизайном, которые не являются особенно простыми.
Я начал этот раздел с того, что написал пошаговое руководство по разработке продукта, но мне все время хотелось написать: “Следующий шаг - это X, за исключением тех случаев, когда это не так”. Именно тогда я понял, что дизайн такого рода - это не линейный процесс. Это набор инструментов.
Иногда в процессе создания продукта или функции вы будете использовать все эти инструменты. Иногда вы будете пропускать один или два шага. Это нормально. Главное - достаточно хорошо разбираться в инструментах, чтобы знать, когда можно пропустить один из них.
Инструмент 1: по-настоящему понять проблему
Первый инструмент в любом виде дизайна - это истинное понимание проблемы, которую вы хотите решить. В этом смысле Lean UX ничем не отличается от любой другой теории дизайна. К сожалению, это сильно отличается от того, как многие люди практикуют дизайн.
В подавляющем большинстве случаев, когда я общаюсь с предпринимателями, они предлагают мне решения, а не проблемы. Они говорят что-то вроде: “Я хочу добавить комментарии к своему продукту”, а не “У моих пользователей нет возможности общаться друг с другом, и это влияет на их взаимодействие с моим продуктом”.
Перефразируя проблему с точки зрения пользователя, вы помогаете себе понять, что именно вы пытаетесь сделать, прежде чем выяснять, как это сделать.
Я не собираюсь пересказывать, как вы могли бы понять проблему, которую пытаетесь решить. Если это вас смущает, вернитесь назад и прочтите главы со 2-й по 5-ю. Я дам вам подсказку: это включает в себя слушание, наблюдение и другие виды исследований.
Здесь следует отметить, что часто исследования не ограничиваются только пользователями. Мы много говорили о том, как прислушиваться к мнению ваших пользователей, и это, безусловно, самое важное, что вы можете делать. Но именно в этот момент вам также необходимо прислушиваться к заинтересованным сторонам в вашей компании.
Если вы работаете в небольшом стартапе, к счастью, это произойдет быстро. Убедитесь, что в вашей организации работают люди, которые с наибольшей вероятностью поймут проблему, которую вы пытаетесь решить. Этими людьми могут быть практически все сотрудники организации — специалисты по обслуживанию клиентов, инженеры и продавцы - очевидный выбор, если они существуют.
Просто помните, что в вашей организации есть люди, которые, возможно, понимают проблему лучше, чем вы, и убедитесь, что вы используете их знания в процессе проектирования. Они не создают окончательный дизайн и не сообщают вам точно, что нужно людям. Они взвешивают свои соображения о потребностях бизнеса, и их вклад должен быть сопоставлен с вкладом клиентов.
Давайте представим, что у вас уже есть продукт и некоторые люди им пользуются. Однако, как и во многих стартапах, вы получаете сигналы о том, что ваш продукт вызывает недоумение. Например, многие люди заходят на ваш продукт или скачивают ваше приложение, а затем никогда им больше не пользуются. Это хороший признак того, что вы не решаете проблему, которую, как думали люди, вы должны были решить за них. Ваш первый шаг - начать с лучшего понимания проблемы.
Например, вам нужно определить свою базу пользователей:
- Какие люди пользуются вашим продуктом?
- Насколько они знакомы с технологиями?
- Вы в основном пытаетесь помочь новым пользователям или существующим?
- Они платят вам или пользуются вашим продуктом бесплатно?
Вам нужно понимать контекст, в котором они будут использовать ваш продукт:
- Им нужна быстрая помощь в дороге или они сидят за рабочим столом и готовы посвятить время изучению вашего продукта?
- Нужна ли им помощь эксперта или помощь других пользователей в работе?
- Возможно ли, что у них возникнут проблемы в процессе выполнения чего-то важного и срочного?
- Вам нужно больше узнать о потребностях ваших пользователей: Используют ли они ваш продукт для развлечения? Для работы? Чтобы повысить свою продуктивность?
Возможно, вы уже знаете ответы на многие из этих вопросов, но не думайте, что то же самое относится к любой проблеме, которую вы пытаетесь решить для своих пользователей. Определите типы пользователей, контекст и потребности любой конкретной проблемы, которую вы пытаетесь решить. Вы будете использовать всю эту информацию на всех следующих этапах.
Когда это можно пропустить?
Пропускать это никогда не безопасно. Если вы не понимаете проблему, вы не сможете ее решить.
Инструмент 2: Сначала разработайте тест
Если бы мне нужно было выбрать что-то, что действительно отличает Lean UX-дизайн от всех других видов дизайна, то это было бы вот что. У Lean UX всегда есть измеримая цель, и вы всегда должны понимать, как измерить эту цель, прежде чем приступать к проектированию. Если вы этого не сделаете, как вы узнаете, что ваш дизайн сработал? Вот пример из реальной жизни. Когда-то давно я работал в IMVU. Для тех из вас, кто не знает, IMVU позволяет пользователям создавать 3D-аватары и общаться с другими людьми со всего мира. Пользователи настраивают свои аватары с помощью всевозможных виртуальных товаров, таких как одежда, домашние животные и виртуальная среда.
Как и во всех компаниях, нам время от времени приходилось решать, над чем работать дальше. Мы решили, что нашей первоочередной задачей является увеличение определенного показателя — активации. Мы хотели, чтобы как можно больше людей, попробовавших продукт один раз, возвращались к нему снова.
Итак, нашей целью в проекте было увеличить количество активаций.
Нам нужно было выяснить, как мы узнаем, успешен ли проект. Мы решили, что наш проект будет успешным, когда увидели статистически значимое увеличение процента новых пользователей, возвращающихся в течение определенного периода времени.
Чтобы полностью понять, была ли устранена проблема с помощью нашего нового дизайна, мы опубликовали бы все изменения, внесенные нами в ходе A / B-теста, который показал бы старую версию половине новых пользователей, а новую - другой половине. Мы измеряли процент людей, вернувшихся из обеих групп, в течение нескольких недель и смотрели, что произошло.
Теперь мы знали о нашей проблеме, и у нас был проверяемый способ узнать, что мы либо решили проблему, либо продвинулись в ее решении.
Я не собираюсь вдаваться в подробности о различных способах, с помощью которых мы пытались добиться прогресса в этом конкретном показателе. Позже я расскажу подробнее о такого рода изменениях. Достаточно сказать, что некоторые изменения привели к сдвигу, а другие - нет. Что еще более важно, не всегда самые масштабные изменения оказывали наибольшее влияние. Суть в том, что, какие бы изменения мы ни вносили, у нас был объективный способ определить, был ли дизайн успешным или нет.
Есть и другие виды тестов, которые вы могли бы провести вместо строгого A / B-теста, и я расскажу о них позже в книге.
Интересно, что желаемые результаты не всегда очевидны, а A/B-тесты не всегда возможны. В нашем примере оказания помощи людям, у которых возникли проблемы, количество проблем, которые люди решают, на самом деле не является хорошим показателем. Я имею в виду, что вы могли бы легко увеличить количество проблем, которые решают люди, увеличив количество проблем, с которыми они сталкиваются, и это не тот показатель, который вы хотели бы увеличить.
Лучшим показателем в этом случае может быть количество обращений в службу поддержки от пользователей, которые ознакомились с новой функцией, или количество вопросов о конкретных проблемах, с которыми сталкивались пользователи.
Хитрость в том, что все показатели успеха должны быть измеримыми и напрямую связаны с целями вашего бизнеса. Повторюсь, позже в книге я расскажу подробнее о том, как выбрать хорошую цель для теста. Воспринимайте это как досадную уловку, заставляющую вас продолжать чтение.
Когда это безопасно пропустить?
Это тоже не стоит пропускать, хотя я обнаружил, что это конкретное упражнение может занять всего несколько минут. Прежде чем приступить к проектированию или сборке чего-либо, вы должны очень четко представлять, для чего оно предназначено и как узнать, работает ли оно.
Инструмент 3: Напишите несколько историй
Часто, когда мы думаем об историях, мы имеем в виду очень специфические истории Agile-проектирования, которые мы пишем и отслеживаем. Это не те истории, которые вы собираетесь писать.
Вам нужно записывать истории проектирования. Подумайте об этом как о способе разбить вашу проблему на выполнимые этапы. Кроме того, подумайте об этом как о способе оценить дизайн после его завершения.
Хорошей историей для нашего эксперимента с помощью помощи пользователям может быть что-то вроде: “Пользователи, у которых возникли проблемы с внесением изменений в свои учетные записи, могут быстро найти способ решить эту проблему”.
Не забывайте также писать истории администраторов! Вы могли бы добавить что-то вроде: “Представители службы поддержки клиентов могут быстрее добавлять новый контент, чтобы помочь пользователям при возникновении новых проблем”.
Вы заметите, что я не предлагал что-то вроде: “Клиенты могут задавать вопросы другим пользователям и получать немедленные ответы”. Это может быть решением, которое вы исследуете, но слишком четкое представление о том, как вы собираетесь решить свою проблему, может слишком быстро привязать вас к конкретной идее и помешать вам найти лучшие варианты.
Когда это безопасно пропустить?
Записывать истории - это всегда хорошая идея. С учетом сказанного, вы можете отказаться от написания историй ради таких тривиальных вещей, как быстрое исправление ошибок, небольшие изменения в обмене сообщениями или визуальные изменения в дизайне, например, тестирование нового цвета кнопок, которые лучше отображаются в реальном дизайне.
С другой стороны, на написание самых простых историй должно уходить не более нескольких минут, поэтому попробуйте сделать это в любом случае, просто в качестве практики. Иногда в процессе написания дизайнерских историй вы обнаруживаете, что упускаете важную часть дизайна.
Например, я общался со стартапом, который довольно кардинально менял свою домашнюю страницу. Команда считала, что это было очень простое изменение визуального оформления. Однако, как только они начали писать свои истории, они поняли, что одна из частей дизайна заключалась в тестировании различных изображений на домашней странице. Они также поняли, что хотят позволить своей маркетинговой команде продолжать тестировать различные изображения в будущем, а это означало, что для этого им нужен был интерфейс администратора. Создавая истории дизайна, они продумывали такие вещи, как то, как будут вноситься изменения в будущем, — вещи, которые в противном случае они бы упустили.
Инструмент 4: обсудите с командой возможные решения
В зависимости от того, к какому типу людей вы относитесь, это либо самая веселая, либо самая мучительная часть процесса проектирования. Я не собираюсь вдаваться в подробности о том, как лучше всего обсудить ситуацию с вашей командой, но убедитесь, что это очень небольшая целевая группа людей, которые хорошо понимают проблему, которую вы пытаетесь решить.
Если вы правильно использовали инструмент 1, описанный в этой главе, вы уже на правильном пути. Вы уже общались с этими заинтересованными сторонами, когда по-настоящему разбирались в проблеме.
Важным моментом здесь является то, что если вы точно знаете проблему, которую пытаетесь решить, это не означает, что существует единственный очевидный способ ее устранения. Например, довольно типичная проблема для продуктов заключается в том, что новые пользователи понятия не имеют, с чего начать.
Есть десятки способов исправить это. Например, вы можете создать учебное пособие, видеоролик, вебинар, пошаговое руководство, встроенные выноски, всплывающие подсказки или контекстную справку. Черт возьми, если у вас очень мало пользователей, каждый из которых платит огромную сумму денег, вы могли бы лично прийти к каждому клиенту домой и научить его, как этим пользоваться.
Сейчас самое время рассмотреть все эти различные варианты для дальнейшей оценки.
Как я уверен, вам уже говорили, сейчас не время отвергать идеи людей. В нашем примере со справкой вы не хотите игнорировать человека в углу, который говорит что-то вроде: “Что, если бы Райан Гослинг ответил на все вопросы нашей службы поддержки?”, даже если вы считаете, что это не самый экономичный способ оказания помощи пользователям.
Пожалуй, самое важное, что следует учитывать при проведении мозгового штурма, - это то, что он должен быть очень, очень, очень коротким процессом. Люди, которым нравится эта часть работы, постараются вовлечь вас в четырехчасовые совещания по “стратегии”, которые на самом деле являются тонко завуалированными встречами по мозговому штурму.
Не делайте этого. Если вы просто проводите мозговой штурм, а не начинаете спорить из-за каждой глупой идеи (а давайте посмотрим правде в глаза, некоторые идеи действительно глупы, что бы вам ни говорили в школе мозгового штурма), идеи у вас закончатся очень быстро.
Начните занятие с четкого изложения проблемы пользователя и причины, по которой вы решили ее решить. Объясните, как вы будете оценивать успех эксперимента. Затем попросите всех изложить свои идеи в одном-двух предложениях. Пройдитесь по комнате, попросите людей прочитать их идеи, запишите их на доске и не позволяйте им обсуждать что-либо, кроме уточнения определенных деталей идеи.
В зависимости от того, какие идеи представляют пользователи, вы можете сгруппировать их так, чтобы они были понятны вам. Не стесняйтесь группировать их по таким параметрам, как то, на какие показатели это повлияет, простота реализации или проблема клиента, которую вы решаете.
Все это может помочь вам решить, что наиболее важно сделать дальше.
Постарайтесь сделать это менее чем за 15 минут. Серьезно. Если это займет гораздо больше времени, значит, вы привлекаете слишком много людей или говорите о слишком многих вещах.
Не стесняйтесь спрашивать людей в конце, согласны ли они с тем или иным решением, которое они хотели бы попробовать, но, что бы вы ни делали, не принимайте участие в голосовании. Это возможность получить новые идеи, а не какой-то глупый эксперимент с демократическим правительством.
Когда это безопасно пропустить?
Я только что сказал, что вы можете сделать это за 15 минут. Почему вы пропустили это? Правда в том, что, постоянно общаясь со своей командой и заинтересованными сторонами, вы сэкономите себе время в долгосрочной перспективе, потому что они выявят ошибки и проблемы, которые вы могли бы пропустить.
Инструмент 5: Примите решение
Добро пожаловать на самую сложную часть процесса проектирования. Вам нужно выбрать что-то, что можно попробовать. Если вы не можете принимать трудные решения, а затем придерживаться их, по крайней мере, столько, сколько потребуется, чтобы доказать, были ли вы правы или нет, вам придется сменить профессию, потому что это необходимый навык.
Но не волнуйтесь. Я не собираюсь отправлять вас в пустыню с пустыми руками. Я напомню вам об очень важном расчете, который называется ROI — окупаемость инвестиций.
Каждое возможное решение имеет ожидаемую стоимость и ожидаемую отдачу. Конечно, ваши ожидания в отношении обоих факторов, вероятно, совершенно неверны, но вы все равно должны это сделать, потому что по мере того, как вы будете делать больше таких расчетов, у вас будет получаться все лучше и лучше в расчете ожидаемой рентабельности инвестиций. Не поймите меня неправильно. Вы, вероятно, все равно будете терпеть их, но будете терпеть меньше, и это полезное упражнение.
Хороший способ сделать это - создать простой график с осями x и y. Обозначьте одну из них “Ожидаемый доход”, а другую - “Ожидаемые затраты”. Затем нанесите на график все ваши различные характеристики. Хотя вы не сможете точно оценить стоимость каждой отдельной функции, довольно легко определить, какие из них потребуют гораздо больше времени или инженерных усилий.
О, если вы думаете, что на самом деле не знаете, как оценить усилия инженеров, то, возможно, сейчас самое время упомянуть, что вам следует привлечь к этой работе кого-то из инженеров. То же самое касается и других сотрудников вашей компании, на которых могут повлиять ваши изменения. Это могут быть специалисты по маркетингу, обслуживанию клиентов, продажам или кто-либо еще, кому необходимо взвесить непредвиденные затраты или преимущества определенных функций.
Опять же, ни один из этих людей не будет голосовать за принятие правильного решения. Все, что они сделают, - это предоставят достаточно информации о реальных ожидаемых затратах и преимуществах каждой функции, чтобы вы могли принять решение.
В ходе этого процесса важно учитывать, что, в зависимости от размера и сложности вашей компании, этот процесс может быть довольно сложным. Возможно, на данный момент у инженеров недостаточно информации, чтобы составить точную оценку. Специалисты по маркетингу могут дать лишь приблизительную оценку того, какая поддержка им потребуется для внедрения новой функции. Возможно, в отдел продаж нужно добавить что-то, что сделает эту функцию действительно эффективной для них.
Это нормально. На данный момент вам не нужно знать абсолютно все об этой функции. Вам просто нужно как можно раньше заставить всех задуматься о решении, чтобы при возникновении проблем в вашей команде было больше людей, которые могли бы их выявить и устранить.
Когда это безопасно пропустить?
Никогда. Никогда, никогда, никогда. Вы должны принять решение. Нет ничего, с чем я сталкивался бы чаще в неудачных стартапах, чем с фундаментальной неспособностью принять чертово решение. Если вы провели исследование и привлекли свою команду, вы готовы принять решение, даже если не уверены, что оно правильное.
Не волнуйся. Вы собираетесь проверить, правильная это идея или нет. Но сначала вы должны выбрать направление, в котором будете двигаться.
Инструмент 6: Отмена/Проверка подхода
Хотя понимание проблемы и привлечение вашей команды к работе на самом деле не являются обязательными этапами процесса проектирования, всего, что следует за этим, можно избежать с помощью одного простого трюка: обесценивания вашей идеи.
“Что это?” - спросите вы. ”Зачем мне отказываться от своей идеи?" Ответ прост: если вы сможете доказать, что вот-вот совершите серьезную ошибку, у вас будет большая возможность избежать ее совершения. И да, даже если вы использовали все инструменты, описанные в этой главе, вы все равно можете совершить огромную ошибку.
Вот пример. Представьте, что вы работаете в компании электронной коммерции, которая занимается продажей гаджетов. Теперь представьте, что вы потратили много времени на общение со своими пользователями и поняли, что одна из главных причин, по которой люди не покупают гаджеты, заключается в том, что они чувствуют, что у них уже есть слишком много ненужного. Более того, представьте, что еще одна распространенная причина, по которой люди не покупают новые гаджеты, - это цена.
Вы и ваша команда могли бы разумно прийти к выводу, что хорошим решением обеих этих проблем было бы разрешить людям перепродавать свои гаджеты, чтобы приобрести новые. Это была бы вполне разумная гипотеза о способе решения известной проблемы.
Что вам нужно сделать дальше, так это выяснить, неверна ли гипотеза. Слишком часто решение проблемы кажется нам таким очевидным, но оно просто не находит понимания у пользователей. Подумайте, сколько времени вы потратили бы на внедрение целой системы, позволяющей пользователям продавать свои собственные гаджеты на вашем сайте, если бы никто из них на самом деле не хотел их продавать.
В следующей главе я расскажу о заглушках функций, и это то, что вы, возможно, захотите сделать здесь. Придумайте как можно меньше вещей, которые могут опровергнуть вашу гипотезу. В данном примере это может быть кнопка "Продать свой гаджет", расположенная на видном месте в вашем продукте, которая подсчитывает, сколько раз люди нажимают на нее, и выдает приятное сообщение о том, что функция еще не полностью реализована. Если никто так и не нажмет на кнопку, это отличный сигнал о том, что вы не хотите создавать полную версию функции, по крайней мере, до тех пор, пока лучше не разберетесь в проблеме или рынке.
Причина, по которой это так важно, заключается в том, что каждая неудачная функция, которую вы не создаете, экономит ваши деньги и время, позволяя создавать больше функций, которые с большей вероятностью будут успешными
Когда это безопасно пропустить?
Есть некоторые функции или изменения, для проверки которых просто требуется больше времени, чем для создания. Прежде чем внедрять поддельную функцию или придумывать какой-нибудь другой оригинальный тест, чтобы убедиться, что вы движетесь в правильном направлении, спросите себя, сколько времени займет создание этой функции и сколько времени потребуется для тестирования таким образом. Если это почти так же быстро, как просто создать его и протестировать в рабочей среде, то не стесняйтесь это делать.
Инструмент 7: Набросайте несколько подходов
Я большой поклонник создания эскизов на этом этапе процесса проектирования. Вы можете заметить, что мы используем инструмент 7.
К сожалению, многие люди начинают процесс проектирования именно с этого. Дело в том, что как только вы начнете рисовать эскизы, у вас может появиться склонность сосредотачиваться на деталях — где находится кнопка, какие элементы интерфейса связаны друг с другом, сколько текста потребуется.
Ваша цель при создании эскизов - начать разбираться в таких вещах, как расположение элементов на экране и их взаимосвязь. Например, если вы создаете страницу с товаром, чтобы что-то продать, вам почти наверняка понадобится изображение продаваемого товара, кнопка "купить" и цена. Эти элементы, вероятно, должны располагаться довольно близко друг к другу. Однако, кроме этого, у вас есть множество направлений, по которым вы могли бы пойти.
Поскольку создание эскизов происходит очень быстро, это отличное время для выполнения таких вещей, как выполнение основных задач. Часто люди забывают, что то, что они рисуют, почти наверняка не является статичным. В нем есть действия и состояния. Кнопки можно нажимать. Формы могут быть заполнены, иногда неправильно. Когда вы делаете набросок, самое время просмотреть как можно больше различных состояний, чтобы убедиться, что со всеми ними можно справиться.
При создании эскиза интерактивного элемента обязательно добавляйте экран или примечание о том, что происходит, когда пользователь взаимодействует с этим элементом. Если вы добавляете раскрывающийся список, продумайте, что может быть в этом раскрывающемся списке.
Слишком часто я вижу “наброски”, которые настолько расплывчаты, что кажутся совершенно бесполезными. Хотя с технической точки зрения это наброски, они не особенно полезны для того, чтобы помочь вам понять, как пользователь будет взаимодействовать с вашим продуктом. И в этом действительно смысл создания набросков.
Как только у вас будет готово несколько вариантов ваших эскизов, настанет время принять еще несколько решений. Самое важное решение - это то, с какими из них работать дальше, поскольку очень редко бывает хорошей идеей разрабатывать три или четыре совершенно разных проекта, если только у вас нет большого количества скучающих инженеров и целой системы тестирования, уже настроенной для А/Б тестирования всех версий друг против друга.
Для большинства из нас, имеющих ограниченные ресурсы, обычно лучше выбрать один или два эскиза, которые, по нашему мнению, с наибольшей вероятностью устранят проблемы, выявленные в ходе первоначального исследования. Лучший способ сделать это - снова показать свои эскизы реальным пользователям.
Ваша цель при тестировании эскизов с пользователями - не пытаться понять удобство дизайна, а понять в целом, понимают ли потенциальные пользователи, что представляет собой продукт, и могут ли они найти отправную точку для решения всех своих наиболее важных задач.
Давайте рассмотрим пример. Представьте, что вы создали несколько эскизов новой страницы с товаром для электронной коммерции. Вы знаете, что самое важное, что люди могут сделать на этой странице, - это купить продукт или поделиться им с друзьями. Покажите эскизы незнакомым людям, желательно на компьютере. Задайте следующие вопросы:
- Как вы думаете, для чего предназначен этот экран?
- Как бы вы купили что-нибудь?
- Представьте, что, по вашему мнению, это было бы идеально для вашего друга. Как бы вы поделились этим с этим другом?
Не забудьте перепутать порядок, в котором вы показываете людям эскизы, чтобы сначала не все увидели один и тот же эскиз.
Если после того, как вы проделали это четыре или пять раз, ни у кого не возникнет проблем с пониманием ни одного из эскизов, тогда смело выбирайте свой любимый и двигайтесь дальше. С другой стороны, если у всех возникают проблемы со всеми набросками, обратите пристальное внимание на то, куда смотрят люди, и попробуйте сделать несколько новых набросков. Повторять.
Когда это безопасно пропустить?
Когда вы вносите изменения, которые проще передать или протестировать другим способом, вам не нужно создавать эскиз. Например, если вы вносите простые изменения в визуальный дизайн, возможно, будет быстрее и эффективнее отобразить изменения в Photoshop или даже в HTML и CSS.
В других случаях вы можете вносить серьезные изменения в свой продукт, которые, как вы знаете, потребуют создания полностью интерактивных прототипов, и, возможно, захотите начать процесс проектирования с одного из них.
Не делайте наброски ради набросков. Делайте наброски, потому что они помогают вам быстро разрабатывать и передавать свои дизайнерские идеи. А если это не поможет, то вы можете пропустить их.
Инструмент 8: Создание интерактивных прототипов
Я большой поклонник интерактивных прототипов, но часто возникает некоторая путаница в том, что это такое. Давайте внесем ясность: когда я говорю "интерактивные прототипы", я не имею в виду что-то, созданное в PowerPoint, на что кто-то может кликнуть мышкой. Я имею в виду полномасштабный, работающий прототип, который позволяет пользователям исследовать его и чувствовать, что они выполняют поставленные задачи.
Неудивительно, что в книге немного сложно проиллюстрировать то, что я имею в виду, но в интерактивных каркасах есть такие элементы, как виджеты, которые реагируют на действия пользователей, анимация, которая работает, и формы, которые пользователи могут заполнять. Они достаточно интерактивны, чтобы пользователи могли совершать ошибки и исправлять их. Они настолько реалистичны, что пользователи часто думают, что это просто уродливая, скучная, не имеющая визуального оформления версия реального продукта.
Проблема интерактивных прототипов в том, что на их создание уходит много времени. Я имею в виду, что на их создание уходит не так много времени, как на создание реального продукта, потому что часто у них элементарный визуальный дизайн и нет серверной части, о которой можно было бы говорить. Например, у вас может быть интерактивный прототип, который позволяет пользователю почувствовать, что он покупает продукт, но на самом деле он не обрабатывал платеж и ничего ему не отправлял.
В целом, они прекрасно подходят для определения того, что в вашем продукте вызывает путаницу или затрудняет его использование, прежде чем вы начнете писать большой объем кода. Они также служат отличным инструментом для информирования инженеров о том, что именно вы хотите, чтобы они создали.
Например, представьте, что вы создаете процесс оформления заказа. Возможно, вы хотите, чтобы отдельные части интерфейса отображались только после того, как пользователь выполнит определенную задачу. Вместо написания документа, в котором подробно объясняется все, что вы хотите, вы просто включаете это в прототип. Или, может быть, вы хотите, чтобы при нажатии пользователем кнопки появлялась определенная анимация. Вы можете точно отобразить стиль, скорость и поведение анимации в своем прототипе.
Итак, теперь, когда вы знаете все замечательные причины, по которым вам хотелось бы создать интерактивный прототип, вам нужно решить, стоит ли тратить на это время. Есть несколько критериев, которые вы должны использовать для принятия решения.
Во-первых, является ли это сложным взаимодействием? Каждый раз, когда у вас есть последовательность шагов, в которых пользователю необходимо сделать несколько вариантов выбора, вероятно, стоит создать прототип. Несколько шагов означают для пользователей множество возможностей заблудиться или сделать что-то неправильно, и чем сложнее или потенциально запутаннее процесс взаимодействия, тем важнее создать его прототип.
Во-вторых, потребуется ли какое-то время на сборку и, что более важно, потребуется ли какое-то время на исправление, если вы сделаете это неправильно? Одна из главных причин, по которой люди не создают прототипы, заключается в том, что у них просто нет времени, но если это большое и сложное взаимодействие, на создание которого может уйти несколько дней, то также могут потребоваться дни на исправление, если в нем есть что-то особенно запутанное. С другой стороны, если инженер может создать всю рабочую функцию примерно за то же время, которое потребовалось бы мне для создания всего прототипа, я, как правило, совершаю ошибку, просто создавая и тестируя ее в рабочей среде.
В-третьих, как часто вы вносите изменения в свой продукт? Если вы серьезно относитесь к бережливому подходу, то, надеюсь, вы практикуете непрерывное внедрение, чтобы можно было сразу же отправить исправление, а не ждать неделями новую версию продукта, но не у всех такая рабочая среда. Если вы создаете что-то, что просто невозможно изменить на лету, например физический продукт или жестко регламентированное программное обеспечение, то интерактивные прототипы имеют решающее значение для выявления как можно большего числа проблем перед отправкой.
Последний вопрос, который следует задать себе перед созданием интерактивного прототипа, заключается в том, поможет ли он вам, как дизайнеру или владельцу продукта, разобраться в важных аспектах дизайна. Чаще, чем вы думаете, ответом на этот вопрос будет утвердительный ответ.
Видите ли, если вы разрабатываете что-то интерактивное, вам нужно, чтобы оно было... ну... интерактивным.
Например, один экран в процессе оформления заказа может иметь самые разные состояния. В нем может быть несколько типов ошибок, или пользователь может отказаться от процесса оформления заказа и вернуться к нему, или он может вообще отказаться от процесса оформления заказа, или он может перейти по ссылке, чтобы узнать больше об условиях предоставления услуг. Создавая интерактивный прототип, дизайнер вынужден продумывать каждое отдельное взаимодействие на экране и различные состояния, которые могут быть вызваны различными типами ввода.
Что подводит нас к очень важному вопросу: как вы должны создавать свои интерактивные прототипы? И здесь я снова склонен отличаться от других дизайнеров. Я создаю свои интерактивные прототипы в HTML, JavaScript и CSS. Знание программирования в достаточной степени для создания прототипов означает, что у меня есть большая гибкость в том, что я могу проектировать. Я не ограничен возможностями инструментов для создания прототипов.
Но, в любом случае, если вы разбираетесь в каких-то других инструментах, таких как Axure или Flash, которые действительно позволяют создавать полностью интерактивный опыт, используйте их.
Когда это безопасно пропустить?
Если вы разрабатываете что-то очень простое, быстрое и не очень интерактивное, ни в коем случае не используйте интерактивный прототип. Я всегда буду пропускать прототипы таких вещей, как целевые страницы с одним призывом к действию, изменения в сообщениях и небольшие новые функции с очень низкой интерактивностью.
Решение о том, создавать интерактивный прототип или нет, по сути, является вопросом рентабельности инвестиций. Если инженер может создать и выпустить функцию для тестирования за меньшее время, чем потребовалось бы для создания прототипа, часто нет смысла беспокоиться об этом. Однако, если вы рискуете потерять значительное время, доходы или клиентов, внедряя серьезные изменения без должного понимания удобства использования функции, создание и тестирование интерактивного прототипа может стать спасением.
Инструмент 9: тестирование и повторение
Итак, теперь мы перешли к последнему инструменту. Довольно увлекательно! Вы почти закончили! О, за исключением той части, где вам нужно протестировать, вернуться и сделать все заново.
Если вы действительно думаете, что самая первая вещь, которую вы создадите, будет совершенно идеальной и не потребует никаких изменений, вы либо заблуждаетесь, либо являетесь лучшим дизайнером, чем кто-либо из тех, кого я когда-либо встречал. Нет, беру свои слова обратно. Вы полностью заблуждаетесь.
Одно из главных отличий Lean от других методологий заключается в исключительной важности итераций. Видите ли, если вы действительно создадите абсолютно идеальный дизайн с первого раза, вы потратите слишком много времени на подготовку.
Создавайте что-то, создавайте прототипы и предлагайте пользователям как можно быстрее, чтобы выяснить, что им нравится, а что нет, и что они находят ужасно запутанным. Затем устраните проблемы и добавьте то, что, по вашему мнению, им понравится, и продолжайте делать это до тех пор, пока у вас не появится функция, которая понравится людям.
Я знаю, что "девять инструментов" - это слишком много для многократного использования, но вы обнаружите, что они очень быстро осваиваются, как только поймете, что вам не обязательно доводить все до совершенства с первого раза.
Когда это можно пропустить?
Не могу поверить, что вы вообще задали этот вопрос. Мне стыдно за вас. Пообещайте мне, что вы никогда не пропустите тестирование или итерацию. Я серьезно.
Слабо связанная речь: Дайте пользователям то, чего они действительно хотят
В прошлом я пытался научить стартапы проводить собственные исследования пользователей и разрабатывать дизайн. Я заметил, что учу многим одним и тем же вещам снова и снова, поскольку есть несколько моментов, связанных с исследованиями, которые кажутся особенно сложными для новичков.
Одной из наиболее распространенных проблем, и, возможно, самой трудной для преодоления, является склонность принимать решения от пользователей, не понимая сути проблемы.
Другими словами, пользователь говорит: “Я хочу такую-то функцию”, и вместо того, чтобы понять, зачем ему нужна эта функция, предприниматели и владельцы продуктов, как правило, пишут: “Пользователи хотят такую-то функцию”, а затем идут дальше.
Это огромная проблема для новичков, проводящих исследования. Когда вы делаете это, вы позволяете своим пользователям разрабатывать ваш продукт за вас, и это плохо, потому что, как правило, пользователи плохо разбираются в дизайне.
Ооо! вот пример!
Я участвовал в исследовании пользователей компании, предлагавшей дорогостоящий набор продуктов и услуг. Пользователи, заходившие на веб-сайт компании, искали информацию, чтобы правильно оценить, какой набор продуктов и услуг им подходит. Как правило, пользователи в конечном итоге покупали индивидуальный пакет продуктов и услуг.
От нескольких пользователей мы услышали, что им действительно нужно больше тематических исследований. По их словам, тематические исследования были чрезвычайно полезны.
Итак, если вы проводите исследование пользователей и клиент говорит вам, что ему нужны тематические исследования, это может показаться отличной идеей.
К сожалению, пользователь только что предложил вам решение, а не проблему. Причина, по которой это важно, заключается в том, что, исходя из того, в чем на самом деле заключается проблема, вам может быть доступно несколько лучших решений.
Когда мы ответили на запросы пользователей о проведении тематических исследований вопросом: “Почему вы хотите ознакомиться с тематическими исследованиями?” мы получили три разных ответа. Интересно, что пользователи, запрашивавшие тематические исследования, пытались решить совершенно разные проблемы. Но действительно ли тематические исследования были лучшим решением для всех трех проблем?
Это были ответы, а также некоторый анализ.
“Я хочу знать, что делают другие компании, похожие на мою, чтобы у меня было четкое представление о том, что мне следует купить”.
“Проблема” первого пользователя заключалась в том, что он не знал, как подобрать оптимальную коллекцию товаров для своей компании. Это проблема выбора. Это похоже на то, когда вы пытаетесь купить новый домашний кинотеатр, и вам приходится принимать множество взаимосвязанных решений относительно очень дорогих устройств, о которых вы, вероятно, мало что знаете.
Хотя в таких случаях, безусловно, могут быть полезны тематические исследования, зачастую более эффективно решать проблемы выбора с помощью какого-либо механизма рекомендаций или набора предустановленных пакетов.
И то, и другое быстро помогает пользователю понять, что для него является правильным выбором, а не просто дает ему длинное объяснение того, как кто-то другой нашел хорошее решение, которое может быть применимо к пользователю, а может и нет.
“Я хочу знать, какие преимущества получили другие компании от этой покупки, чтобы понять, стоит ли ее покупать”.
“Проблема” второго пользователя заключалась в том, что он хотел быть уверенным в том, что он получает хорошее соотношение цены и качества. Это проблема с показателями. Это похоже на то, когда вы пытаетесь понять, стоит ли покупать более дорогую стереосистему. Вам нужно точно понимать, что вы получаете за свои деньги от каждой системы, а затем сопоставить преимущества и затраты.
Эту проблему можно было бы решить с помощью ценовой матрицы, точно показывающей, какие преимущества предлагаются для различных продуктов. В качестве альтернативы, было бы быстрее и эффективнее отображать на странице описания продукта только соответствующую часть тематических исследований — например, “Клиенты увидели увеличение выручки в среднем на 35% через шесть месяцев после установки этого продукта”.
Сводя все это к тем частям тематического исследования, которые важны для пользователя, вы получаете больше возможностей для отображения этой информации — статистики, показателей и т.д. - на более видных и уместных местах сайта. Это на самом деле повышает значимость этих цифр и повышает вероятность того, что люди их увидят.
“Я хочу посмотреть, с какими еще компаниями вы работаете, чтобы я мог решить, является ли ваша компания уважаемой”.
“Проблема” третьего пользователя заключалась в том, что он никогда не слышал о компании, продающей эти продукты. Поскольку это были дорогие продукты, он хотел убедиться, что компании, о которых он слышал, уже являются клиентами. Это проблема социального доказательства. Это похоже на то, как если бы вы пытались выбрать кого-то, кто поставил бы новую крышу на ваш дом, и попросили бы рекомендаций у своих друзей.
Его актуальную проблему можно было бы решить намного быстрее, если бы мы собрали несколько кратких отзывов клиентов. Зачем тратить время на написание нескольких крупных тематических исследований, если все, что волнует пользователя, - это увидеть логотип Google в списке ваших клиентов?
Почему это важно
Это не должно никого из вас удивлять, но пользователи просят о том, с чем они знакомы, и не обязательно о том, что было бы лучше для них. Если пользователь уже сталкивался с чем-то вроде тематических исследований, то, когда он задумается о том, какую пользу он извлек из них, он попросит повторить то же самое. Он не обязательно будет просто запрашивать ту часть тематического исследования, которая была наиболее актуальной для него.
Проблема в том, что многие люди, которым также могут понравиться некоторые части тематических исследований, не будут утруждать себя их чтением, потому что тематические исследования могут быть довольно длинными или потому что пользователь не считает, что конкретное тематическое исследование применимо к нему.
Очевидно, что это применимо не только к тематическим исследованиям. Например, недавно я наблюдал очень похожую ситуацию, когда покупатели и продавцы в социальных сетях просили создать “систему репутации”, хотя на самом деле они хотели получить какие-то гарантии того, что их не обманут. Я мог бы привести еще десяток примеров.
Вывод заключается в том, что, когда кто-то просит вас о какой-либо функции, вы должны задавать вопросы о том, почему она хочет эту функцию, даже если вам кажется, что вы уже знаете ответ!
Как только вы узнаете, в чем на самом деле заключаются проблемы, вы сможете приступить к их решению наиболее эффективным способом, а не тем, который пришел пользователю в голову во время разговора.
Вместо того, чтобы просто создавать то, о чем просит пользователь, создайте что-то, что решит реальную проблему пользователя. В качестве дополнительного бонуса вы можете в конечном итоге создать функцию меньшего размера и более простую, чем та, о которой просил пользователь.
Сделайте это прямо сейчас!
- Напишите несколько историй: попробуйте разбить текущую функцию на полный набор пользовательских историй.
- Сделайте несколько набросков: Попробуйте взять истории пользователей и создать три приблизительных наброска того, как мог бы выглядеть один из экранов. Если все пройдет хорошо, нарисуйте все экраны для этой функции.
- Узнайте, чего на самом деле хотят ваши пользователи: попробуйте посмотреть на функцию, которая часто запрашивается пользователями, и выяснить, какую проблему они пытаются решить.