Как вы узнаете, чего действительно хотят пользователи?

Ответ 1

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

Ответ 2

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

Ответ 3

Скажите им. Тогда вы оба знаете.

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

Ответ 4

Анекдот предыдущей жизни:

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

Затем мы положили каждую липкую на стол с чашкой перед ней. Каждый пользователь получил 10 пенни, чтобы "проголосовать" за те функции, которые они хотели. Они могли положить столько копейки в каждую чашку, сколько они хотели, до всех своих грошей в одной чашке, если они того пожелали. Затем мы подсчитали количество пенни в каждом кубке и решили реализовать топ-5 голосов в порядке голоса.

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

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

Ответ 5

Вы спрашиваете их.

(Нет, вы не знаете, что ваши пользователи хотят лучше, чем они. Да, вы получите много глупых ответов. Избегайте опросов с множественным выбором и вместо этого выбирайте ответы на бесплатные ответы. быть неоценимым.)

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

Ответ 6

Пользователи знают, чего они не хотят лучше, чем они знают, чего они хотят.

Мы внедрили команду, выполнив реализацию Oracle eBusiness Suite. Они взяли интересный подход, который в прошлом очень хорошо работал для них. Но это было феноменально в нашей среде.

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

В любом случае команда разработчиков установила Oracle eBusiness Suite прямо из коробки. Дайте пользователям базовую подготовку. Затем примерно каждые 4 недели в течение следующих 6 месяцев они настраивали базовую установку для удовлетворения жалоб.

Ответ 7

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

Другой вариант - показать список всех функций, которые вы могли бы добавить, а затем привязать цену к каждому, а затем спросить пользователей, стоило бы $X иметь функцию Y, или, сколько дополнительно вы согласитесь заплатить за функцию Y?

Ответ 8

Ешьте свою собачью еду

Попробуйте использовать приложение, которое вы пишете как можно больше. Затем вы узнаете, как улучшить свое приложение.

Ответ 9

Согласно 37 Signals - Getting Real, вы ничего не делаете, вы даже не записываете то, что хотите, вы просто удалите письма после одного чтения без каких-либо действий.

Когда дело доходит до внедрения/исправления, вы будете помнить самые важные вещи, которые ваши пользователи хотят от головы. Очевидно, для этого требуется небольшая база пользователей.

Ответ 10

Вам нужно привязать функции к стоимости. Все хотят возможности, но не каждая функция стоит платить. Спросите, какие функции наиболее важны, на что ваши пользователи будут готовы платить? Разработка функций, основанных на приоритетах, предоставляемых пользователями, и прекращение, когда они больше не желают платить. Получите продукт в свои руки как можно быстрее, чтобы вы могли получить реальную обратную связь о том, что не работает и что нужно добавить. Когда пользователи имеют доступ к реальному программному обеспечению, вы получаете гораздо лучшую информацию. Это лучше всего работает, когда вы разрабатываете специально для конкретного клиента. Если у вас нет доступа к реальным клиентам, попробуйте посеять свой продукт с людьми (вы можете сказать, публичная бета?) Бесплатно, чтобы получить лучшую обратную связь.

Ответ 11

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

"Будьте похожи на воду, пробивающуюся сквозь трещины. Не будьте настойчивы, но приспосабливайтесь к объекту, и вы найдете путь вокруг него или через него. Если ничто внутри вас не останется твердым, наружные вещи раскрываются. Освободи свой разум, будь бесформенным. Безжизненный, как вода. Если вы положите воду в чашку, она станет чашкой. Вы кладете воду в бутылку, и она становится бутылкой. Вы кладете его в чайник, он становится чайником. Теперь вода может течь или она может упасть. Будь водой мой друг.

Когда вы будете водой/клиентом, вы теперь будете.

Я думаю, что Брюс Ли будет хорошим программистом.

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

Ответ 12

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

Есть одна вещь, которую они знают, может быть, намного лучше, чем вы. И это как сделать свою работу.

Как только компьютерные/программные концепции и терминология начнут течь в дискуссию между пользователями и дизайнерами, вы отключены от рельсов.

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

Это очень тяжелая, критически важная проблема для вас, чтобы решить эту проблему.

Ответ 13

• Oracle at Delphi

  Плюсы: точность превосходна Минусы: если вы можете интерпретировать сообщения, которые многие люди не могут сделать (часто видя то, что они хотят видеть). Также требуется мольба, которая может стать беспорядочной (вопреки распространенному мнению, ваша гекатомба не должна быть 100 одного вида домашнего скота).

• Экстрасенсы

  Плюсы: с точностью до точки.

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

• Поставить моль

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

  Минусы: Дорого. Шансы остаются, что агент включит вас, или не сможет узнать все, что вы не могли бы узнать более просто. Если обнаружено, организация, скорее всего, превратит или ликвидирует актив, что представляет собой огромную инвестицию ресурсов. Организация может отвечать взаимностью.

• Угадайте

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

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

• Спросите пользователя

  Плюсы: пользователи чувствуют себя уполномоченными как часть процесса.

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

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

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

  Минусы: нет поездки в Oracle (это будет EPIC). Шпионы намного сексуальнее; цыплят разыскивают шпионов. "Большие неприятности в маленьком Китае". Большой Льюбоски, вероятно, не участвуют. Чувствуется больше, чем работа, чем остальные варианты.

Ответ 14

Запрос пользователей о функциях подскажет им поговорить с вами о функциях.

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

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

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

Ответ 15

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

Если вашему проекту не нужно привлекать аудиторию как можно скорее, чтобы добиться успеха (например, webapp), если это больше внутреннего проекта или продукта для продажи для фиксированного клиента или типа клиента, тогда я верьте, что лучше всего пойти по пути 37signals: дать своим пользователям абсолютный минимум, необходимый им, чтобы сначала выполнить основные задачи самого элементарного цикла работы, затем послушать, что они говорят объективно отсутствует, чтобы они могли нормально работать. Не то, что они хотят или хотели бы иметь, а то, что им действительно нужно . И единственный способ, которым вы точно знаете, что вам действительно нужно, - это когда у вас его нет.

Я работал дизайнером в команде разработчиков приложения, основанного на интрасете "сердце-компании", которое следовало этой стратегии, и результаты были замечательными. Первая неделя: все были злы. Когда все было кончено, 90% + одобрения, и приложение все еще было простым и красивым. И большинство людей, которые были не совсем удовлетворены, по-видимому, понимали, почему это не может быть так, как они хотели, и основная просьба почти всех заключалась в том, чтобы все, что бы мы ни делали, упрощало приложение.

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

Ответ 16

Вы не запрашиваете функции. Вы просите о проблемах. Болевые точки. Узнайте, что они ненавидят относительно своего текущего решения. Узнайте, что ест в свое время.

Когда вы знаете, что им не нравится, вы строите решение этих проблем.

Когда вы решаете реальные проблемы, вы создаете реальные продукты, которые люди с радостью дадут вам деньги.

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

Ответ 17

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

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

Ответ 18

Используйте случаи.

Что они будут делать с этой функцией?

Он работает следующим образом.

• Люди принимают меры. Мы создаем программное обеспечение, чтобы помочь им предпринять действия.

• Чтобы принять решение, лицо должно принять решение. Мы создаем программное обеспечение, чтобы помочь им принимать решения.

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

Каждая функция должна быть действием, решением или информацией. И связь должна быть прямой. Информация, которая не приводит к решению или действию, даже не "приятно иметь" - это мусор.

Пользователи говорят много чего. Что они делают? Какие решения они делают? Какая информация нужна им?

Изменить

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

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

Ответ 19

Если вы серьезно, вы снимаете на видеокассету их работу, а затем вы нарушаете то, что они пытаются выполнить, и как ваш продукт может им помочь. Это часть всей дисциплины, называемой инженерией юзабилити. Хорошим введением в технику является книга Якоба Нильсена Юзабилити Инжиниринг. Еще до того, как он стал бесстыдным huckster, Якоб был очень хорошим ученым, и он много узнал о дешевых способах выяснить, что нужно пользователям. Особенно хорошо, если у вас бюджет. Больше всего меня поразило использование прототипов ; это отличный способ для макета программного обеспечения, которое вы еще не создали, и помогает ответить на ваш вопрос о том, что строить дальше. Пока я не увидел эту технику в действии, я не мог поверить, насколько она эффективна.

P.S. Один пример того, что произойдет, если вы просто спросите людей: 90% запросов функций для Microsoft Office 2007 предназначались для функций, которые уже были в Microsoft Office 2003. В этом случае пользователям нужны были лучшие способы найти то, что уже было. Мне жаль, что я не могу найти, где я читал об этом... извините, чтобы не иметь ссылки.

Ответ 20

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

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

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

Ответ 21

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

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

Ответ 22

Это хороший вопрос.

Если вы строите игру FPS, вам действительно нужно знать, что должно быть включено, потому что 99% ваших пользователей никогда не свяжутся с вами, чтобы сказать: "Я бы хотел, чтобы в вашей игре был только X". Здесь может помочь опытная команда по тестированию бета-тестирования.

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

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

Ответ 23

Представьте, что вы их

Ответ 24

• Наблюдайте за ними.
• Определите узкие места в своей работе.
• Создайте что-то, что разрешит узким местом в элегантном стиле.
• Пусть они используют его
• Повторяйте, пока все не будут счастливы.

Ответ 25

Основываясь на принципах:

• Пользователи знают, чего хотят, но они не знаю, что им действительно нужно .
• Вы ARE НИКОГДА не вернемся первый раз.

Кажется, проблема с курицей и яйцом. Очень похоже на вычисление PageRank. Ранг страницы страницы зависит от PageRank других страниц, ссылающихся на эту страницу. Одним из способов вычисления PageRank является итерация.

Итерация - это ключ!

а. Голосование

• Соберите список функций, которые все пользователи хотят (чтобы они перечисляли каждую функцию, которую они хотят).

• Затем попросите их просмотреть список и позволить им проголосовать за функции. Скажем, дайте им 100 баллов для распространения по функциям. Они могут дать более 1 балла функции.

В. Анализ

Анализ бизнес-модели, список функций, которые, по вашему мнению, необходимы. Это необходимо, потому что:

• пользователи иногда не получают больших изображение
• У вас это ДЕЙСТВИТЕЛЬНО здорово идея, о которой пользователи не будут думать в bajillion лет.

С. Реализовать

Проанализировать список из A и B, слить, удалить несколько, улучшить некоторые. Реализовать.

Д. Тест

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

E. Итерация

Ответ 26

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

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

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

P.S. Прямо спросить их: "Чего вы хотите?" может быть опасным вопросом... Babylon 5 - Что вам нужно?

Ответ 27

Он назвал исследование рынка.

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