«Люди не знают, чего хотят, пока не покажут их им»

Один из самых успешных продуктов, когда-либо выпущенных - iPhone. Itâ € ™ s любил за превосходный пользовательский опыт во всем мире. Это исходит из идеи покойного Стива Джобса, который среди прочего славится тем, что не спрашивает у клиента, чего он хочет. В 1985 он сказал:

  

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

. , , Кроме того, в 1997 он сказал:

  

Много раз люди не знают, чего хотят, пока не покажут их им.

В то же время эксперты по пользовательскому опыту здесь, на UX.SE и в других местах, говорят, что вам нужно протестировать идеи, макеты, прототипы и выполнить A /B-тестирование, открытую и закрытую сортировку карт и т. д. для целевой аудитории. Вопрос: нужно ли нам тестировать или не делать этого?

77 голосов | спросил 4rchit3ct 12 MarpmWed, 12 Mar 2014 19:02:52 +04002014-03-12T19:02:52+04:0007 2014, 19:02:52

10 ответов


89

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

Проблема в том, что большинство людей пропускают несколько ключевых моментов. Во-первых, они не Apple:

Статья Forbes, Пять опасных уроков, чтобы учиться у Steve Jobs , перечисляет эти цитаты как # 1. Chunka Mui , автор статьи, называет это:

  

Я действительно думаю, что Джобс был прав , но только в очень узкой категории, к которой он стремился : где его продукты, такие как Mac, iPod, iPhone и iPad, либо переопределили, либо создали категории продуктов. Это не тот домен, в котором играют большинство компаний. Помните также, что Джобс поддержал свои уникальные идеи с невероятно дорогостоящим творческим процессом, заложенным дизайнерами мирового класса . Без талантов Джобса и беспрецедентной творческой команды и процессов, которые он построил вокруг себя, вы не уходите, не занимаясь исследованиями на рынке и не слушая своих клиентов .

Другим является смущение заявлений о маркетинговых исследованиях с помощью тестирования пользователей. Apple выполняет тестирование пользователей!

В 2010 году в баре был найден iPhone 4 >. Дело в том, что iPhone 4 еще не существовал - насколько известно всему населению! Конечно, это не было сделано специально, но скорее всего это был сотрудник, который тестировал .

Другим ключевым моментом является формулировка: хочет и нужна

Люди /пользователи знают, что они хотят. Они «хотят» много чего. Они часто не знают, что им нужно "!

Стив Джобс понял это. В другой статье Цитата о анализе рынка Стив Джобс должна отдохнуть в мире обсуждаются два разных типа рыночных исследований. Понятно, что Apple действительно проводит маркетинговые исследования, но они задают правильные вопросы - они видят, что люди нуждаются из продукта, а не то, что они хотят из него .

(Примечание: я не подразумеваю, что люди «нуждаются» в iPhone, но то, что им «нужно» из продукта, сильно отличается от того, что они «хотят» от него)

  

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

Сайт UXMyths поражает также: Миф № 21: Люди могут сказать вам, что они хотят , в котором есть цитата из Якоба Нильсена (среди многих других отличных примеров):

  

Якоб Нильсен говорит, что «критический отказ от интервью с пользователем заключается в том, что вы просите людей либо запомнить предыдущее использование, либо спекулировать на будущем использовании системы».

В некоторой степени Миф № 29: Люди рациональны также попадает в эту точку.

Последняя точка, люди всегда указывают на iPod, iPhone и iMac в качестве примеров того, почему эти цитаты из Стива Джобса показывают, что «тестирование пользователей не имеет значения». Итак, давайте посмотрим на все другие удивительно успешные продукты, которые Apple выпустила:

введите описание изображения здесь введите описание изображения здесь  введите описание изображенияздесь

По какой-то причине люди забывают, как часто Apple (и Стив Джобс) потерпела неудачу; и есть намного больше примеров, чем только выше.

  

Вопрос: нужно ли нам тестировать или не делать?

Да. Да, мы делаем ... и мы можем использовать Apple в качестве примера почему нам нужно! По двум основным причинам:

  1. Поскольку Apple выполняет тестирование своих продуктов
  2. Потому что иногда, когда вы вводите что-то новое, оно летает, но чаще это терпит неудачу.

UPDATE:

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

введите описание изображения здесь введите описание изображения здесь>> </p>

<p> Моя точка зрения заключается в том, что Стив /Apple провалились много раз, некоторое прошлое и еще несколько ток-иш (G4 Cube). Поэтому, чтобы привести цитаты Стиву в качестве доказательства или не сделать что-то из-за недавнего успеха iPod /iTunes /iPhone, не рекомендуется. На этот раз они все поняли. </p>

<p> Я указываю выше, что <strong> Стив /Apple делает тестирование </strong>, <strong>, они проводят маркетинговые исследования </strong>, а Стив также создал очень талантливую творческую команду в более позднем году Apple, t существует в начале. Но «волшебство» не всегда происходит. </p></body></html>

ответил Evil Closet Monkey 12 MarpmWed, 12 Mar 2014 19:47:46 +04002014-03-12T19:47:46+04:0007 2014, 19:47:46
34

Мы смешиваем две фазы жизненного цикла разработки продукта.

Кавычки «Вакансии» были сосредоточены на Фокус-группах - где вы, по сути, просите потребителей, чего они хотят. Это происходит в начале жизненного цикла разработки (или даже до этого в обнаружении). Часто, если вы сильно полагаетесь на фокус-группы для управления дизайном продукта, вы, как правило, получаете посредственный продукт. Смотрите также: Голливуд и автомобиль Гомера Симпсона .

введите описание изображения здесь>> </p>

<p>  (Выше: автомобиль Гомера Симпсона - моя любимая аналогия того, что вы получаете, когда слишком полагаетесь на фокус-группы)  </p>

<p> Дистилляция философии Джобса заключается в том, что потребители могут только спрашивать, что они знают. И Джобс действительно хотел продвинуться дальше этого и дать потребителю то, о чем они никогда бы не подумали сами по себе. </p>

<p> <strong> Тестирование </strong>, с другой стороны, проверяет продукт, с которым вы столкнулись. Это происходит во время разработки продукта. Сам Стив был известен как один из самых безжалостных и требовательных тестировщиков продуктов, которые когда-либо существовали. Есть много пресловутых историй о том, что Стив вписывается в мельчайшие детали, которые, по его мнению, не соответствовали его стандартам тестирования. </p></body></html>

ответил DA01 12 MarpmWed, 12 Mar 2014 21:42:34 +04002014-03-12T21:42:34+04:0009 2014, 21:42:34
5

Нам нужно точно протестировать , потому что люди не знают, чего хотят, пока не видят это.

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

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

«Любая достаточно продвинутая технология неотличима от фальсифицированной демонстрации». Используется правильно, это действительно полезный инструмент разработки.

ответил keshlam 13 MarpmThu, 13 Mar 2014 17:46:19 +04002014-03-13T17:46:19+04:0005 2014, 17:46:19
3

В основном вы сравниваете продукт и , как его использовать . Хотя кавычки Джобса (и Форда) верны, они относятся к самому продукту .

Как я могу себе представить или Mac (или автомобиль), если я никогда не испытывал этого?

Если мы говорим «нам нужно проверить, работает ли это», мы почти всегда ссылаемся на , как использовать продукт. И это должно быть проверено.

Кроме того, при анализе рынка и тестировании пользователей мы стараемся минимизировать вероятность отказа рынка .

Давайте будем честными - не каждая Идея у нас есть Mac или автомобиль.

ответил Lovis 12 MarpmWed, 12 Mar 2014 19:26:56 +04002014-03-12T19:26:56+04:0007 2014, 19:26:56
3

Я думаю, что это все разные аспекты процесса проекта.

В терминах концептуализации и маркетинговых исследований это то, что происходит до создания, поэтому исследование рынка не является надежным.

A /B Тестирование и прототипирование и т. д. происходит после того, как идеализация прошла, и вы работаете над уточнениями и оценкой признания рынка.

Процесс должен выглядеть следующим образом:

  1. Выяснение потребностей.
  2. Идеальное решение.
  3. Выйдите на конечность и запустите с ним, чтобы создать прототип продукта.
  4. Исследование рынка.
ответил Pdxd 12 MarpmWed, 12 Mar 2014 19:25:35 +04002014-03-12T19:25:35+04:0007 2014, 19:25:35
3

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

Но это не значит, что вы должны просто отказаться от любого тестирования пользователя. Уверен, что вы можете обойтись, но пользовательское тестирование может дать вам представление о том, что вы (и ваша команда), возможно, никогда не придумали.

При создании продукта вы можете отказаться от проведения маркетинговых исследований, потому что вы твердо верите в потребность в продукте. Что касается первого Mac, Стив Джобс и его команда нуждались в этом. Это небольшое исследование рынка само по себе, и это все, что им нужно. Их успех обусловлен тем фактом (или удачей), что потребность превышена, а не только их команде.

Я не думаю, что они не проводили никаких тестов после создания первого Mac (или другого продукта). На самом деле, я считаю, что они сделали так много пользовательских тестов, они, наконец, узнали через пробную версию и ошибку, что они не могли просто спросить людей о том, что им нужно, и что они получили наилучшие результаты, когда они просто наблюдали за пользователем и строили потребности от пользователей, поведение.

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

ответил Paul van den Dool 13 MarpmThu, 13 Mar 2014 14:29:00 +04002014-03-13T14:29:00+04:0002 2014, 14:29:00
2

Позвольте мне взять совсем другой подход к этому вопросу, чем другие ответы.

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

Для больших или (r) эволюционных UX и UI трюк разрабатывает лучшие проекты. Минимизация количества кликов, перемещений и т. Д. И обучение пользователей новым способам взаимодействия с контентом - это то, что вы делаете для этого. Вы все еще можете проводить тестирование, но из-за кривой обучения, которая часто приходит с этим подходом, тесты ненадежны и для надежного использования вам нужен гораздо больший бюджет.

Недостатком второго в конце является то, что существует гораздо больший фактор риска (см. Обезьяна злого шкафа ответьте на это), тогда как - как указано L. Möller - первый подход может свести к минимуму вероятность выхода из строя рынка. В качестве примера этого вы можете посмотреть ответы здесь на UX stackoverflow, а некоторые утверждают, что в настоящее время реализована

  

Сайт x, y и z не делает описание интерактивным

и оттуда (необязательно), почему это так, тогда как другие ответы начинаются с

  

Создание кликабельной области сделает взаимодействие пользователей более эффективным, так как произойдет меньшее количество кликов.

и (необязательно) показывают случаи, когда это делается таким образом.

Теперь, с некоторыми вещами, вы можете сделать это довольно легко (например, сделать все описание кликабельным), но предположим, что в диалоговом окне all будет кнопка отмены в правом нижнем правом углу, и вы будете первый, чтобы выяснить, что, если кнопка «ok» в этом месте лучше - что мы просто предположим ), тогда это случайное действие по-прежнему будет путать пользователей как против (и не только отличные от), к чему они привыкли. Таким образом, в заключении всегда есть затраты на инновации, и вы либо должны быть действительно большими или действительно новыми, чтобы тянуть такие вещи.

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

  • Facebook: Facebook постоянно обновляет свой дизайн и принимает довольно смелые решения время от времени. Почти каждый раз, когда в сообществе происходит огромная обратная косая черта, несмотря на то, что Facebook все еще это делает. Зачем? Потому что не делать этого, это заставит их устареть, после чего каждый переключится на небольшого нового конкурента, который может потянуть за изменение.
  • Windows 8 Metro /Modern design: Хотя с точки зрения пользовательского интерфейса я не являюсь его поклонником, то здесь же. Одна из проблем, однако, состоит в том, что, похоже, они все-таки провели много краткосрочных испытаний, и из-за этого здесь были некоторые недовольные компромиссы.
  • Или возьмите Google Search, поскольку тестирование проходит, они делают невероятную работу. Они запускают эксперименты и удерживают их в течение нескольких месяцев, и они на самом деле тратят время на просмотр эффектов . Это не роскошь, которой обладают большинство компаний, и даже более экзотические изменения выставляются небольшими приращениями в течение длительных периодов времени, поэтому они (чрезмерно) осторожны, но в конце концов они могут сделать довольно большие изменения без отрицательных обратных косых черт.

Всем, выполнить тест , независимо от того, решите, хотите ли вы рискнуть и сначала сделать дизайн, а затем протестировать или сыграть в безопасности и протестировать сначала, а затем спроектировать (и снова проверить) .

ответил David Mulder 12 MarpmWed, 12 Mar 2014 20:34:58 +04002014-03-12T20:34:58+04:0008 2014, 20:34:58
2

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

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

ответил Marc Stober 12 MarpmWed, 12 Mar 2014 20:47:42 +04002014-03-12T20:47:42+04:0008 2014, 20:47:42
2

Нужно отделить, как проектировать что-то и насколько хорошо работает дизайн. Провидец может видеть потребность - даже если он еще не изобрел. Тем не менее - дизайн должен (когда в такой форме) проверяться.

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

ответил Henrik Ekblom 12 MarpmWed, 12 Mar 2014 21:02:59 +04002014-03-12T21:02:59+04:0009 2014, 21:02:59
2

Фокус-группы для определения того, что хотят люди, просто пустая трата времени. Это , о чем говорят Джобс и другие.

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

Фокус-группы, охватывающие экраны макетов, имеют ограниченную полезность. Часто люди действительно не знают, что они хотели бы видеть, пока они не будут активно участвовать в использовании продукта. Тип обратной связи, которую вы обычно получаете, будет «перемещать эту кнопку там », «Мне нужна ссылка здесь » или «Я думаю, что этот элемент должен быть розовым» ... пока они не начнут его использовать. В этот момент у них будет совсем другое представление о том, как его следует выложить и посмотреть.

Для инкрементных изменений в существующих системах слушайте обратную связь. С чем люди борются? Является ли то, что они просят о правильном пути решения проблемы, или есть что-то более фундаментальное в работе? Можете ли вы сразу решить две проблемы, возможно, они даже не знали? Остерегайтесь этого, хотя слишком много изменений может быть либо великой вещью, либо худшей вещью.

iPhone был совершенно другим способом использования наших телефонов. Стив и другие видели, с чем люди боролись - VM был ужасным интерфейсом, большинство телефонов заставляли вас перепрыгивать через обручи, чтобы синхронизировать списки контактов, текстовые сообщения были сложными, а электронная почта была тем, для чего вы использовали ноутбук. Конечно, самым важным пунктом было то, что NONE крупных поставщиков тратили ресурсы, необходимые для решения проблемы. (Да, я знаю, что Nokia, RIM и другие «работали» в то время.) Это означало, что рынок созрел для римейка; который Apple счастливо сделала. Визуальная голосовая почта, приличный почтовый клиент и фактическая синхронизация с контактами на рабочем столе являются главными причинами успеха.

Были ли у Apple и другие попытки решить проблемы, которых у людей просто не было? Да. Разве Apple и другие решали проблемы, но неутешительно? Да. «Сетевые компьютеры», такие как Pin пипса, были одной из идей, которые наблюдатели в отрасли в то время думали о взлете, но люди, которые обращают внимание, не знали - мы уже отошли от глухих терминалов, зачем возвращаться?

Evil Closet Monkey перечислил ряд отказов Apple; и да, в качестве отдельных продуктов каждый из них был неудачами. Одна вещь, которую я хотел бы отметить, состоит в том, что каждая неудача была итерацией по теме, которая в конечном итоге привела их к iPhone, а затем iPad. Ньютон пытался решить, стоит ли в кармане стоящее вычислительное устройство. Мышь с одной кнопкой пыталась упростить вычисления. То же самое для mac mini. Когда эти идеи были применены к телефонии и в сочетании с новыми технологическими усовершенствованиями (то есть: относительно дешевыми сенсорными экранами и более быстрыми, меньшими, менее энергоемкими процессорами), тогда у вас есть победитель.

ответил NotMe 17 MaramMon, 17 Mar 2014 01:25:45 +04002014-03-17T01:25:45+04:0001 2014, 01:25:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132