Как вы узнаете, чего на самом деле хотят пользователи?[закрыто]
https://stackoverflow.com/questions/415260
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я где-то читал (извините, забыл источник - кажется, в блоге разработчика MS Office?), Что когда вы проводите опрос пользователей, спрашивая их о том, какие функции они хотели бы видеть в вашем программном обеспечении / веб-сайте, они чаще всего говорят, что им нужны все до мелочей, тогда как собранные показатели показывают, что в итоге большинство людей не используют 99% этих функций.Общий посыл записи в блоге заключался в том, что вы не должны спрашивать людей, что они используют, вы должны отслеживать это сами.
Это приводит к неудачной ситуации с курицей и яйцом при попытке выяснить, какую новую функцию добавить следующей.Без этой функции, которая уже установлена, я не могу измерить, насколько она используется на самом деле.Имея ограниченные (и сильно растянутые) ресурсы, я также не могу позволить себе добавить все функции, а затем удалить неиспользуемые.
Как вы узнаете, что будет полезно вашим пользователям? Если опрос является единственным вариантом, нужно ли вам определенным образом структурировать свои вопросы (например:не показывать список возможных функций, так как это привело бы к их появлению)?
Решение
Вопреки распространенному мнению, вы не спрашиваете их. Ну, вы не слушаете их, когда они говорят вам, что они хотят. Вы смотрите их, пока они используют то, что имеют прямо сейчас. Если у них ничего нет, вы слушаете их достаточно, чтобы дать им прототип, а затем смотрите, как они это используют. То, как человек на самом деле использует программное обеспечение, говорит вам гораздо больше, чем, на самом деле, он хочет сказать. Посмотрите, что они делают, чтобы узнать, что им действительно нужно.
Другие советы
Дайте им варианты, и пусть они упорядочат их в порядке важности. Как вы сказали, пользователи будут хотеть всего, но это позволит вам сказать, чего они хотят больше всего.
Вы говорите им. Тогда вы оба знаете.
(Нет, ваши пользователи не скажут вам, чего они хотят. Это работа. Если бы пользователи хотели больше работы, они бы не искали программное обеспечение, которое бы выполняло за них свою работу.)
Анекдот из прошлой жизни:
Мы планировали выпуск новой версии и хотели добавить некоторые новые функции в приложение. Мы собрали пользователей и провели мозговой штурм о том, что они хотят видеть в системе, разместив каждую «функцию» на желтой липкой на белой доске. Затем мы сгруппировали похожие запросы и удалили дубликаты или почти дуплисы.
Затем мы положили каждую липкую на стол с чашкой перед ним. Каждый пользователь получил 10 копеек за «голосование» на функции, которые они хотели. Они могли положить столько пенни в каждую чашку, сколько они хотели, вплоть до всех своих пенни в одну чашку, если они того пожелали. Затем мы подсчитали количество копеек в каждой чашке и решили использовать 5 лучших получателей голосов в порядке голосования.
Было удивительно видеть, как люди, увлеченные какой-либо функцией, при мозговом штурме и категоризации поворачиваются и не голосуют за эту функцию (или голосуют за нее несерьезно).
Конечно, такая техника будет работать, только если у вас есть готовый доступ к вашей базе пользователей (это было для корпоративной системы, которую мы разработали внутри компании).
Вы спрашиваете их.
(Нет, вы не знаете, чего хотят ваши пользователи лучше, чем они. Да, вы получите много глупых ответов. Избегайте опросов с несколькими вариантами ответов и вместо этого выбирайте просмотр ответов в свободной форме. Собранная вами информация будет быть бесценным.)
Конечно & # 8212; вы всегда можете позволить своим пользователям голосовать , какие функции им нравятся больше всего ...
Пользователи знают, чего они не хотят, лучше, чем они знают, чего хотят.
Мы привлекли команду, которая занимается реализацией Oracle eBusiness Suite. Они выбрали интересный подход, который работал очень хорошо для них в прошлом. Но это было феноменально в нашей среде.
У нас были культурные проблемы, которые означали, что никто из пользователей не собирался высовывать шею, чтобы сказать, что они хотят. У меня была история с пользователями из прошлого. Попытка получить требования от них была как попытка получить кровь из камня. Но как только ты уйдешь в живых, начнется сучка.
В любом случае, команда разработчиков установила Oracle eBusiness Suite прямо из коробки. Дайте пользователям базовое обучение. Затем каждые 4 недели в течение следующих 6 месяцев они настраивали базовую установку для удовлетворения жалоб.
Я бы рекомендовал не показывать им варианты; как вы указываете, если это доступно, то люди будут хотеть это только ради того, чтобы иметь это. Часто пользователи не знают о дополнительных затратах на разработку конкретной функции, и просто хотят ее, потому что вы упомянули возможность ее использования.
Другой вариант - показать список всех функций, которые вы могли бы добавить, а затем назначить цену каждой из них, а затем спросить пользователей, будет ли стоить $ X, чтобы иметь функцию Y, или, сколько дополнительных Вы готовы платить за функцию Y?
Старайтесь максимально использовать приложение, которое вы пишете сами. Тогда вы узнаете, как вы можете улучшить свое приложение.
Согласно книге 37 Signals - Getting Real , вы ничего не делаете, вы не делаете даже записывать, что они хотят, вы просто удаляете почту после одного чтения без каких-либо действий.
Когда дело доходит до реализации / исправления вещей, вы будете помнить самые важные вещи, которые ваши пользователи хотят из головы. Очевидно, это требует немного пользовательской базы.
Необходимо привязать функции к стоимости. Каждый хочет, чтобы функции, но не каждая функция стоит платить. Спросите, какие функции наиболее важны, за что готовы платить ваши пользователи? Разрабатывайте функции на основе приоритетов, предоставляемых пользователями, и останавливайтесь, когда они больше не готовы платить за них Получите продукт в свои руки как можно быстрее, чтобы вы могли получить реальную обратную связь о том, что не работает и что нужно добавить. Когда пользователи получают доступ к реальному программному обеспечению, вы получаете гораздо более качественную информацию. Это работает лучше всего, когда вы разрабатываете специально для конкретного клиента. Если у вас нет доступа к реальным клиентам, рассмотрите возможность бесплатной рассылки вашего продукта людям (вы можете сказать, публичную бета-версию?), Чтобы получить более качественную обратную связь.
Пользователи не знают, какие функции они хотят. Вы не знаете, какие функции им могут быть предложены. & Quot; Особенности & Quot; ничего не значат за исключением того, что они помогают им выполнять задачи и достигать целей. И это то, с чего вам следует начать, потому что у них будет очень несовершенное понимание того, как они связаны.
Есть одна вещь, которую они знают, может быть, намного лучше, чем ты. И вот как сделать свою работу.
Как только понятия о компьютерах и программном обеспечении и терминология начинают просачиваться в дискуссию между пользователями и дизайнерами, вы сходите с ума.
Очень часто пользователи фокусируют свои требования на том, что не так или может быть улучшено в отношении программного обеспечения, которое они используют в настоящее время. Со временем даже они теряют различие между своей работой и программным обеспечением, которое они используют для своей работы.
Это очень сложная, критически важная проблема для вас.
Единственный способ узнать, что пользователи "на самом деле" нужно "быть" Пользователь. Его программирование уровня черного пояса кунг-фу.
" Будь как вода, пробивающаяся сквозь трещины. Не будьте напористыми, но приспособьтесь к объекту, и вы найдете обходной путь или через него. Если ничто внутри вас не остается жестким, внешние вещи раскроются. Освободи свой разум, будь бесформенным. Бесформенный, как вода. Если вы положите воду в чашку, она станет чашей. Вы кладете воду в бутылку, и она становится бутылкой. Вы кладете его в чайник, он становится чайником. Теперь вода может течь или она может разбиться. Будь водой, мой друг.
Когда вы будете водой / клиентом, вы будете сейчас.
Я думаю, что Брюс Ли был бы хорошим программистом.
Я очень серьезен. Так я работаю. Я не могу делать то, чего не понимаю, поэтому я должен понять, прежде чем что-то делать. Когда я понимаю, и мои клиенты знают, что я понимаю, тогда я могу сделать хорошую работу. Без понимания будут недоразумения. Вы единственный человек, который знает, когда у вас есть правильный уровень понимания, вы также являетесь лицом, ответственным за получение этих знаний.
Оракул в Delphi
Плюсы: точность превосходна Минусы: если вы можете интерпретировать сообщения, что многие люди не могут сделать (часто видя то, что они хотят видеть). Также требуется прошение, которое может привести к беспорядку (вопреки распространенному мнению, ваша гекатомба не обязательно должна быть из одного и того же вида домашнего скота).
Плюсы: с точностью до точки.
Минусы: редко. Склонен к психической нестабильности, очень уязвим к существам, страдающим от пожаров, и может привлекать к себе нежелательное внимание. Кроме того, требуется опыт, чтобы разобраться в тайне человеческого разума, чтобы получить желаемую информацию. И иногда вам все еще нужно исследовать предметы, когда они на самом деле делают то, что им нужно, потому что пользователи лгут.
Посади крота
Плюсы: новые гаджеты. Новые яды! Планы в планах в планах. Детка, это странное шоу. Вы можете изучать все виды интересных вещей в дополнение к информации, которая вам нужна, чтобы помочь пользователю.
Минусы: дорого. Скорее всего, агент включит вас или не сможет научиться чему-то, чему вы не научились бы проще. В случае обнаружения организация, скорее всего, обернется или ликвидирует актив, что представляет собой огромные вложения ресурсов. Организация может ответить взаимностью.
Угадайте
Плюсы: возьмите группу людей со средним и большим воображением и навыками решения проблем, дайте им немного выпить и вдохновите их цитатами из «Охотников за привидениями», «Больших проблем в Маленьком Китае» или «Большого Левовски». Кто знает, куда это пойдет, но это будет весело, и они могут произвести что-то интересное / полезное.
Минусы: вероятность удовлетворения потребностей пользователя выше, чем вы думаете, но не так уж и высока.
Спросите пользователя
Плюсы: пользователи чувствуют себя уполномоченными как часть процесса.
минусы: до тех пор, пока они не решат что-либо, и в этот момент вы сами. Если пользователь не очень опытный пользователь, в этом случае они, вероятно, имеют хорошее представление о том, чего хотят. Хотя на планете всего 4 опытных пользователя, и никто никогда не знает никого, кто мог бы сделать для них работу. Это могут быть мифические звери.
Представьте, что вы заботитесь и спросите пользователя (даже если вы на самом деле этого не делаете), а затем понаблюдайте, как он выполняет любой ключевой рабочий процесс / процесс / и т. д., и обратите внимание на то, что он делает.
Плюсы: вы обманываете пользователей, думая, что их мнение имеет значение, что расширяет их возможности, но не доставляет никакого другого багажа. Поскольку пользователи лгут - не намеренно или злонамеренно - вы на самом деле можете увидеть их в действии и лучше понять, в чем заключается проблема, тем самым предоставляя вам лучшую основу для выработки решения. Кроме того, вы избегаете психического пути и, следовательно, избегаете длинного и извилистого пути, который начинается с обещания, но заканчивается тем, что вы и экстрасенс съедены какой-то чудовищной, невыразимой вещью, которая не принадлежит этому миру. Наблюдение за процессом похоже на полностью Zen, что хорошо для вашего разработчика Mystique.
Минусы: нет поездки в Oracle (это будет EPIC). Шпионы намного сексуальнее; птенцы роют шпионов. Охотники за привидениями | Большие проблемы в Маленьком Китае | Большие Левбоски, вероятно, не причастны. Чувствуется больше как работа, чем остальные варианты.
Запрашивая у пользователей информацию о функциях, они попросят их рассказать о них.
Если вы хотите узнать, чего действительно хотят пользователи , вы говорите о понимании их целей и мотивов. Я обнаружил, что самый простой способ начать это - это собеседования с пользователями, но не о функциях, а о том, как пользователи используют ваш продукт и подобные ему продукты, почему они его используют и как он вписывается в их жизнь.
Как только вы поймете, что ваши пользователи пытаются сделать с вашим продуктом и почему они хотят это делать, вы можете сделать обоснованное суждение о том, действительно ли запрашиваемые функции нужны именно им.
В идеале, я думаю, что ваша проблема в том, чтобы понять пользователей, а не просто слушать их запросы.
Это старый вопрос, на который уже есть много хороших ответов, но я подумал, что просто добавлю немного личного опыта ради людей, которые окажутся здесь в будущем благодаря поиску, как я.
Если вашему проекту не нужно набирать аудиторию как можно быстрее, чтобы добиться успеха (например, в веб-приложении), если речь идет о внутреннем проекте или продукте, предназначенном для постоянного клиента или типа клиента, тогда я Полагаю, что вам лучше всего идти по пути 37 сигналов: предоставьте своим пользователям абсолютный минимум , который им нужен для выполнения самых основных задач самого основного цикла работы, а затем слушайте, что они говорят это объективно отсутствует , чтобы они могли правильно выполнять свою работу. Не то, что они хотят или хотели бы иметь, а то, что им действительно нужно . И единственный способ узнать наверняка, что вам действительно нужно, - это когда у вас его нет.
Я работал дизайнером в команде разработчиков «сердца компании» на основе интрасети; приложение, которое следовало этой стратегии, и результаты были замечательными. Первая неделя: все были в бешенстве. Когда все закончилось, 90% + одобрения, и приложение было еще простым и красивым. И большинство людей, которые не были полностью удовлетворены, казалось, понимали, почему это не могло быть так, как они хотели, и главная задача почти каждого состояла в том, чтобы, что бы мы ни делали, сделать приложение простым.
Опять же, если вы работаете над продуктом или веб-сайтом, который должен привлекать людей в первую очередь, это может быть неосуществимо или сильно откладывать. Но если у вас есть некоторый контроль или свобода действий над пользовательской базой, я определенно рекомендую этот подход.
Вы не запрашиваете функции. Вы спрашиваете о проблемах. Болевые точки. Узнайте, что они ненавидят в своем текущем решении. Узнайте, что съедает их время.
Когда вы знаете, что им не нравится, вы создаете решение этих проблем.
Когда вы решаете реальные проблемы, вы создаете реальные продукты, за которые люди с радостью дадут вам деньги.
Но также важно уважать их на этапе исследования. Опросы по-прежнему хороши для проведения исследований, но если вы зададите им дюжину вопросов, они вас ненавидят. Вам необходимо уважать их время и использовать инструмент для проведения опросов , который привлекает их и оставляет отличное впечатление.
Это доказанный факт, что пользователи не знают, чего хотят. Вам нужно спросить их, что не так с тем, что есть сейчас - какие проблемы у них с вашим программным обеспечением? почему они не используют функцию x и контроль y? почему взаимодействие х сработало для них, а взаимодействие у заставило их попытаться оценить свои глаза?
Конечно, чтобы задать эти вопросы, вам нужно провести некоторое практическое исследование и посмотреть, какие функции используются, какие шаблоны демонстрируют ваши пользователи, и проанализировать эти данные. Этот анализ даст вам основу для гораздо более конкретных вопросов, на которые пользователи смогут ответить решительно и точно.
Если вы настроены серьезно, вы снимаете их работу на видео, а затем рассказываете, чего они пытаются достичь и как ваш продукт может им помочь.Это часть целой дисциплины, называемой юзабилити-инжиниринг.Хорошим введением в технику является книга Якоба Нильсена Разработка юзабилити.До того, как стать бесстыдным торгашом, Якоб был очень хорошим ученым и много узнал о дешевых способах определения потребностей пользователей.Особенно хорошо, если у вас ограниченный бюджет.Что впечатлило меня больше всего, так это использование бумажные прототипы;это отличный способ создать макет программного обеспечения, которое вы еще не создали, и поможет ответить на ваш вопрос о том, что создавать дальше.Пока я не увидел эту технику в действии, я не мог поверить, насколько эффективной она может быть.
P.S.Один из примеров того, что произойдет, если вы просто спрашивай Люди:90% запросов на функции для Microsoft Office 2007 были направлены на функции, которые уже были в Microsoft Office 2003.В этом случае пользователям нужны были лучшие способы поиска того, что уже было там.Жаль, что я не могу найти, где я читал об этом...извините, что у меня нет рекомендации.
Я предполагаю, исходя из вашей формулировки, что вы создаете продукт для продажи, а не создаете что-то для заказа для конкретного клиента.
В этом контексте я бы сказал, что вы должны начать с того, чтобы стать самим пользователем и создавать нужные вам функции так, как вы этого хотите. По мере развития продукта вам понадобятся отзывы других пользователей, но это, по крайней мере, поможет вам начать работу и нарушит цикл куриного яйца.
Что касается измерения фактического использования функций, вы можете настроить дискуссионный форум, чтобы получать отзывы о добавленных вами функциях ... вам не нужно ничего сложного, если вы ограничены во времени.
Мне лично нравится невмешательство клиентов. Они дают вам требования высокого уровня, а вы обеспечиваете реализацию. Предполагается, что ваша команда разработчиков программного обеспечения / компания / подразделение являются экспертами. Конечно, вы допустите некоторые ошибки, если клиент ужасно потрудится и вы исправите его, но, как правило, решение проблемы решается вами и вашими разработчиками.
Исследования, исследования, исследования. Учитесь у других дизайнеров, а затем создайте свой собственный дизайн. Не легко, но опять же, они не платят разработчикам большие деньги ни за что.
Это хороший вопрос.
Если вы создаете FPS-игру, вам действительно нужно знать, что именно должно быть включено, потому что 99% ваших пользователей никогда не свяжутся с вами, чтобы сказать "Я бы хотел, чтобы в вашей игре только что был X". Опытная команда бета-тестирования может помочь здесь.
Если вы пишете бухгалтерское приложение, вам необходимо понять отрасль и то, что пользователи пытаются достичь, когда они используют ваш продукт, и попытаться сфокусировать свой набор функций на этих целях.
Если вы пишете пользовательское приложение для 100 пользователей в одном бизнесе, вы можете поговорить с дюжиной или около того самых заядлых пользователей программного обеспечения. Это те, кто знает все формы задом наперед, обнаружил все недокументированные сочетания клавиш, а также выяснил, как обойти многие из ваших правил проверки данных.
Представь, что ты их
Примеры использования.
Что они сделают делай с такой функцией?
Это работает примерно так.
Люди предпринимают действия.Мы создаем программное обеспечение, которое помогает им предпринимать действия
Для того чтобы совершить какое-либо действие, человек должен принять решение.Мы создаем программное обеспечение, которое помогает им принимать решения.
Для того чтобы принять решение совершить какое-либо действие, человеку нужна информация.Мы создаем программное обеспечение для сбора и представления информации.
Каждая функция должна быть Действием, Решением или Информацией.И лучше бы связь была прямой.Информация, которая не ведет к принятию решения или действию, даже не "приятна для обладания" - это мусор.
Пользователи говорят много чего.Что они делают делай?Что решения делают ли они?Что Информация нужны ли они?
Редактировать
Обратите внимание, что не все хороши в описании вариантов использования.У некоторых людей нет видения, и они просто расскажут вам, чем они занимаются сегодня, не понимая, как они создают ценность для бизнеса (или личную).Возможно, они на самом деле не знают, какие решения они должны принимать, и расплывчато представляют необходимую им информацию.
Другие пользователи знают, какую ценность они создают и почему, и могут хорошо обсудить варианты использования.Они могут представить альтернативные способы создания ценности;они могут четко сформулировать варианты своих действий.Решения не имеют большого количества альтернативных реализаций (решения принимают люди, а не программное обеспечение), и требуемая информация также не сильно меняется.
Основанный на принципах:
- Пользователи знают, чего они хотят, но они не знают, чего они на самом деле хотят. потребность.
- У вас НИКОГДА не получится сделать это правильно с первого раза.
Это похоже на проблему курицы и яйца.Очень похоже на вычисление PageRank.Рейтинг страницы зависит от рейтинга других страниц, ссылающихся на эту страницу.Одним из способов вычисления PageRank является итерация.
Итерация - это ключ к успеху!
A.Голосование
Соберите полный список функций, которые нужны всем пользователям (заставьте их перечислить каждую функцию, которую они хотят).
Затем попросите их просмотреть список и разрешить им проголосовать за функции.Скажем, дайте им 100 баллов для распределения по функциям.Они могут дать более 1 балла за функцию.
B.Анализ
Проанализируйте бизнес-модель, перечислите функции, которые, по вашему мнению, необходимы.Это необходимо, потому что:
- иногда пользователи не получают большой изображение
- у вас есть ДЕЙСТВИТЕЛЬНО отличная идея, до которой пользователи не додумаются и через баджиллион лет.
C.Реализовать
Проанализируйте список из A и B, объедините, удалите несколько, улучшать некоторые.Реализовать.
D.Тест
Протестируйте это на пользователях.Выслушайте их жалобы.Посмотрите на - функции, которые они часто используют - вещи, на которых они застревают - и т.д. и т.п.
E.Повторять
Обычно пользователи не всегда знают, чего они хотят и хотят ли они чего-нибудь.В нашей компании продавцы идут к существующим и потенциальным клиентам, показывают им наш продукт и объясняют, почему они отчаянно этого хотят.
В мое время в университете нас учили чему-то, что называлось "разработка, ориентированная на пользователя".Здесь вам действительно нужно подойти к заказчику, понаблюдать, как там работают люди, какие инструменты они используют, и попытаться выяснить, что могло бы облегчить их жизнь.Затем вы создаете макет, снова идете к заказчику, представляете его пользователям, получаете их отзывы и затем приступаете к улучшению своего макета.Когда все более или менее согласны с планом действий, вы приступаете к реализации, регулярно показывая клиенту, что у вас есть, стараясь получить обратную связь по корректировке как можно раньше.
Важно разговаривать не с менеджерами, которым нужен продукт, а с пользователями, которые будут пользоваться продуктом.Иначе вся пьеса ничего вам не принесет.
P.S.Прямой вопрос "Чего вы хотите?" может быть опасным...Вавилон 5 - Чего ты хочешь?
Это называется Исследование рынка.
Нет, это не было копью парня, это действительно то, о чем это. Конечно, есть множество методов, которые люди UCD используют в полевых условиях для получения требований пользователей, но они точно такие же инструменты, которые используются исследователями рынка. Сортировка карт, списки приоритетов и т. Д. - все это термины исследования рынка.
