Разные методы имеют разные цели и дают разные результаты. Дизайнеры жалуются на то, что методы маркетинга не работают: люди рассказывают о том, что они делают и чего хотят, но это не соответствует их реальному поведению или желаниям. Маркетологи жалуются, что, хотя проектно-исследовательские методы дают глубокое понимание, таким образом можно наблюдать лишь за горсткой людей. Дизайнеры возражают, говоря, что традиционные маркетинговые методы дают поверхностное представление о большом количестве людей.
Этот спор бесполезен. Оба метода ценны. Исследование клиентов — это своего рода компромисс: глубокое понимание реальных потребностей мы получаем, исследуя небольшое количество респондентов, а обширные надежные данные о покупках — от широкого круга потребителей. Нам необходимо и то и другое. Дизайнеры понимают, что на самом деле нужно людям. Маркетологи понимают, что люди на самом деле покупают. Это не одно и то же, и именно поэтому нужны оба подхода: специалисты по маркетингу и по дизайну должны работать вместе, в одной команде.
Каковы требования к успешному продукту? Во-первых, если никто не покупает товар, то все остальное не имеет значения. Дизайн продукта должен сочетать все факторы, которые влияют на решение покупателя приобрести товар. Во-вторых, после того как люди купили продукт, нужно, чтобы они его понимали и с удовольствием использовали, а для этого он должен отвечать их реальным нуждам. Конструктивные требования должны включать оба фактора: маркетинг и дизайн, покупку и использование.
Генерация идеи
После определения требований к проектированию следующий шаг проектной группы — разработка возможных решений. Такой процесс называется процессом генерирования идеи. Это упражнение можно применять на любой стадии схемы «двойного алмаза»: на этапе поиска правильной проблемы и на этапе поиска ее решения.
Это самое приятное в дизайне: именно здесь важна креативность. Есть много способов создания идей, многие из них можно объединить под названием «мозговой штурм». Какой бы метод вы ни использовали, вот два основных правила, которым обычно следуют при разработке идей:
• Генерируйте много идей сразу. Очень опасно зациклиться на одной или двух идеях уже на первой стадии этого процесса.
• Будьте креативны, невзирая на обстоятельства. Не критикуйте идеи, ни свои, ни чужие. Даже безумные идеи, которые часто кажутся очевидно неправильными, могут содержать какую-то креативную мысль. Позже ее можно будет извлечь и использовать на последнем этапе, когда вы будете выбирать лучшую идею. Не отказывайтесь от идей слишком рано.
Добавлю третье правило:
• Подвергайте все сомнению. Мне очень нравятся «глупые» вопросы. На самом деле они касаются настолько основополагающих вещей, что ответ, кажется, лежит на поверхности. Но если принять их всерьез, часто оказывается, что вопрос на самом деле очень глубокий: очевидное совсем не всегда оказывается таким уж очевидным. Что-то кажется нам ясным просто потому, что так было всегда, но, когда мы ставим это под сомнение, оказывается, что мы не понимаем, почему было так. Очень часто именно такие «глупые» вопросы, заставляющие нас подвергать сомнению очевидное, помогают найти решение проблемы.
Создание прототипов
Единственный способ узнать, разумна ли идея, — проверить ее, создать быстрый прототип, или макет, каждого возможного решения
[55]. На ранних стадиях такого процесса это могут быть наброски, модели из пенопласта и картона или простые изображения, выполненные с помощью обычных графических программ. Я делал макеты в виде таблиц, слайдов PowerPoint, а также эскизов на карточках или стикерах. Иногда идеи лучше всего передавать с помощью скетчей, особенно если вы разрабатываете сервисы или автоматизированные системы, которые трудно прототипировать.
Одна из популярных техник прототипирования называется «Волшебник из страны Оз» в честь классической книги Франка Баума (и ставшего классическим фильма)
[56]. Волшебник на самом деле был обычным человеком, но с помощью спецэффектов ухитрялся казаться таинственным и всемогущим. Другими словами, он был подделкой: у волшебника не было никаких особых магических сил.
Метод «Волшебник из страны Оз» можно использовать для имитации огромной, мощной системы задолго до того, как она будет построена. Он крайне эффективен на ранних стадиях совершенствования продукции. Я когда-то использовал этот метод для тестирования системы бронирования авиабилетов, которая была спроектирована исследовательской группой в центре Пало-Альто корпорации Xerox (сегодня это просто исследовательский центр Пало-Альто, или PARC). Мы приводили людей в мою лабораторию в Сан-Диего по одному, усаживали их в маленькой изолированной комнате и заставляли вводить в компьютер свои требования к туристической поездке. Они думали, что взаимодействуют с автоматизированной программой, разработанной для помощи в организации путешествий. На самом деле в соседней комнате сидел один из моих аспирантов, который читал набранные запросы и набирал ответы (при необходимости просматривая реальные графики перелетов). Эта симуляция позволила нам многое узнать о требованиях к такой системе. Например, мы узнали, что запросы людей сильно отличаются от тех, которые мы разработали в качестве ответов системы. Например, один из выполнявших задание попросил билет туда и обратно из Сан-Диего в Сан-Франциско. После того как система определила нужный рейс в Сан-Франциско, она спросила: «Когда вы хотели бы вернуться?» Человек ответил: «Я бы хотел лететь в следующий вторник, но мне бы хотелось прилететь до занятий, которые начинаются в девять утра». Таким образом, мы поняли, что недостаточно просто понимать предложения: система также должна была решать проблемы, используя пространные знания о таких вещах, как аэропорт, места встречи, схемы движения, задержки на получение багажа и аренду автомобилей и, конечно, парковки — это существенно превышало способности системы. Наша первоначальная цель состояла в том, чтобы она понимала язык. Исследования показали, что цель была слишком узкой: система должна была понимать деятельность людей.
