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

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

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

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

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

Если это верно, как вы это подтверждаете?

124 голоса | спросил Joel Blackmore 13 PMpMon, 13 Apr 2015 14:37:54 +030037Monday 2015, 14:37:54

18 ответов


134

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

Анекдотические данные из моего собственного недавнего опыта:

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

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

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

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

ответил Nathan Rabe 13 PMpMon, 13 Apr 2015 15:16:05 +030016Monday 2015, 15:16:05
120

Вот два примера: один онлайн и один автономный


1. Поезд прибывает

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

    введите описание изображения здесь>> </p>
</li>
<li> <p> <a href = В этой статье описывается, насколько значительны результаты, а также указывает, что пассажиры склонны переоценивать свое время ожидания, когда у них нет информации. Знаки обратного отсчета теперь развернуты на транзитных станциях по всему миру.


2. Отображение выбора продукта

  • Потребители часто будут запрашивать больше вариантов при совершении покупок, потому что они считают, что больше выбора приводит к лучшему опыту покупок.
  • Хорошо документировано, что слишком много вариантов может привести к подавляющему решению для потребителей, что может привести к отказу корзины покупок или задержке в покупке. См. парадокс выбора и волшебное число 7 , но есть много исследований, доступных по этому эффекту.
  • В результате, несмотря на стремление потребителей к большему выбору, сайты смарт-торговли фактически ограничивают количество вариантов, представленных потребителю, потому что они признают, что для меньше выбора и не более.
  • Например, Amazon использует сетки продуктов и разбиение на страницы, чтобы избежать ощущения подавляющего выбора для клиентов. Вот страница результатов продукта от Amazon, которая показывает шесть (рядом с магическим числом 7) вариантов на экран. Обратите внимание, что независимо от того, насколько сильно я изменяю размер браузера, количество представленных столбцов равно 3:

    введите описание изображения здесь>> </p>
</li>
<li> <p> Amazon использует несколько различных макетов для результатов продукта, но макеты по умолчанию часто преднамеренно уменьшают выбор на экране, чтобы избежать подавляющих клиентов. </p> </li>
</ul></body></html>

ответил tohster 13 PMpMon, 13 Apr 2015 19:52:07 +030052Monday 2015, 19:52:07
70

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

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

<p> Если компания действительно хотела сделать машину для среднего Джо, они бы приняли предложения от нескольких пользователей и взвесили выгоды, которые типичный пользователь мог бы извлечь из них, за счет их стоимости. Если вы слепо делаете то, что хотят ваши пользователи, вы получите Гомера. </p></body></html>

ответил Chase Sandmann 13 PMpMon, 13 Apr 2015 18:56:07 +030056Monday 2015, 18:56:07
41

Давайте начнем со старого от основателя Форда:

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

<p> (Хотя <a href= на самом деле нет никаких доказательств того, что Ford когда-либо сказал он . Спасибо пользователю Evil Closet Monkey за отказ от ответственности .)

Просмотр конструктора UX

Почему важно знать, почему они хотят , что они думают, что они хотят ?:
Просто потому, что в качестве дизайнера UX вы должны разработать лучшее решение, и для этого вы должны оценить все переменные UX (доступность, удобство использования, проверяемость, исследования по этому вопросу и т. Д.) и баланс между ними . Большую часть времени пользователь не может этого сделать, потому что они не знают, чего хотят, и часто не то, что им нужно.

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

Из Якоб Нильсен: Первое правило юзабилити? Не слушайте пользователей :

  

Но в конечном счете, способ получить данные пользователя сводится к основным правилам   юзабилити:

     
  • Смотрите, что на самом деле делают люди.
  •   
  • Не верьте, что говорят люди.
  •   
  • Определенно не верю, что люди предсказывают, что они могут сделать в будущем.
  •   
ответил Alejandro Veltri 13 PMpMon, 13 Apr 2015 21:31:35 +030031Monday 2015, 21:31:35
33

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

Первый известен как

Эффект Einstellung

Это отрицательное влияние шаблона на поиск оптимальных решений:

  

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

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

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

Общеизвестно как проблема XY .

  

Проблема X-Y, как ее иногда называют, представляет собой ментальный блок, который приводит к огромному количеству потраченного впустую времени и энергии, как со стороны людей, обращающихся за помощью, так и со стороны тех, кто оказывает помощь. Это часто происходит примерно так:

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

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

этот вопрос Meta Stackexchange также обсуждает проблему XY.

Способ избежать создания субоптимальных решений, которые следуют из Einstellung Effect или XY Problem, заключается в устранении проблемы с корнем или в результате запроса prima facie .

ответил Digital Chris 14 PMpTue, 14 Apr 2015 23:08:10 +030008Tuesday 2015, 23:08:10
16

Мой анекдот: Мы расширили новую версию компьютеризированной машины. Одним из требований было загрузить его через 30 секунд. Мы потерпели неудачу на порядок. Это вызвало большой протест. Мы спросили, почему и слышали, что они потеряли много времени на производство с последней версией, потому что он разбился так часто и нужно было перезагружать довольно часто. Наша новая версия была намного более стабильной, что позволило сократить время простоя.

ответил user64748 14 PMpTue, 14 Apr 2015 15:32:33 +030032Tuesday 2015, 15:32:33
9

В качестве инженеров нам был дан пример недавно открытой офисной башни. Он был оборудован 3 лифтами. Когда жильцы заполнили жалобы здания, пришли, что офисным работникам пришлось слишком долго ждать лифта. Попросите дорогостоящих консультантов пересмотреть алгоритм очередности лифтов. Никакого сокращения жалоб. Оценка качества строительства дополнительного лифта. Так не пойдет. Жалобы на ожидание слишком долго продолжаются. В конце концов парень предлагает вылечить проблему за несколько сотен фунтов. Циничные, но готовые взять пунт, они отдают ему ход. Он подходит для полноразмерных зеркал на трех сторонах вестибюля. Жалобы снижаются до нуля. Смысл? - другие пытались «быстрее навести офисных работников на свои столы», как это требовали пользователи. Этот парень решал проблему - как остановить людей, жалующихся на то, чтобы не добираться до их столов быстрее. Прилегающие зеркала позволяют девушкам стоять в вестибюле, любуясь собой в зеркалах, и ребята могут стоять в вестибюле, любуясь девушками. Никто не жаловался, что придется стоять на несколько минут дольше. Это двоюродный брат вопроса, который вы задавали, но пример решения реальной проблемы, а не проблема, которую пользователь говорит, что они хотят решить.

ответил AlanG 13 PMpMon, 13 Apr 2015 20:52:40 +030052Monday 2015, 20:52:40
8

Пользовательские запросы обычно формируются на основе того, что пользователь воспринимает как решение своей проблемы. Дело в том, что их решение может быть не лучшим решением, и на самом деле оно может даже не решить их проблему вообще. Многие вопросы в StackExchange задают вопрос о том, как исправить частичное решение, а не просить лучшего решения проблемы, которую они пытаются решить (это называется «проблема XY»). Пользователи делают это все время , и это относится и к профессионалам.

Основные примеры:

  • Предлагаемое решение пользователя фактически не решает проблему, которую они имеют. Это тревожно распространено. Обычно вы можете найти это, наблюдая, действительно ли пользователь использует то, что они «хотели» или нет, но иногда они просто вынуждают себя.
  • Есть более простое решение, которое охватывает всю проблему. Вы можете добавить знания своего домена в микс - вы, вероятно, знаете что-то, чего нет у пользователя. Возможно, пользователь считает, что их решение является самым дешевым, но вы действительно можете найти более дешевое решение, потому что вы понимаете что-то о базовой системе. Это также очень распространено.
  • Пользователю действительно не нужно решать то, что, по их мнению, является их проблемой, - они могут решить проблему проблемы. Существует довольно много случаев, когда вы можете сделать клиента более счастливым, разрешив часть своей проблемы дешевой, а не решить всю проблему с огромными ресурсами. Спросите себя, почему люди все еще работают, а не накапливают всю свою работу над роботами? В какой-то момент экономически не стоит держать на укладке решения.

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

Обратите внимание, что знаменитая цитата Генри Форда (mis-) в основном представляет собой вариант второго номера. Проблема людей на самом деле заключалась в том, что им нужно было быстрее добраться до мест. Решение, которое они выяснили, было «просто сделать быстрее лошадей». Это сработало долгое время, разумеется - мы выборочно разводили лошадей по разным признакам в течение долгого времени, так что это не глупо . Причина, по которой люди, такие как Benz и Ford, смогли показать лучшее решение, заключалась в том, что они добавили несколько моментов:

  • Становится все труднее и быстрее становиться быстрее, сильнее лошадей. Это означает, что мы достигли предела, когда абсурдно дорого получить дальнейшие результаты.
  • Легче и дешевле приобретать сталь и уголь, чем когда-либо прежде. Они могут использоваться для изготовления искусственных лошадей, которые будут дешевле и быстрее.
  • Лошади ужасно сложны. Самая простая вещь, которую мы можем иметь, - это универсал, который применяет движущую силу непосредственно к осям. Мы уже знаем, что колеса довольно аккуратные, так что давайте переместим их. О, и мы знаем о поездах! Они в основном делают то же самое. Давайте сделаем небольшие поезда!
  • Если я смогу работать поезда без рельсов и достаточно дешев для людей (вторая часть - то, что сделало Форда настолько знаменитым), люди собираются купить эти мини-поезда вместо лошадей, и все будут счастливы (за исключением лошадистов, конечно: P). О, и у нас также есть масляные двигатели, намного более практичные, чем угольные двигатели для этого!

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

Do not считают ваши пользователи глупыми . Они не. Просто в большинстве случаев вы можете привнести в микс некоторые дополнительные знания, и так же важно, вы можете игнорировать некоторые кэшированные мысли («Это всегда делается так»). Люди кэшируют много .

ответил Luaan 15 PMpWed, 15 Apr 2015 12:41:43 +030041Wednesday 2015, 12:41:43
7

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

Поскольку я делал почти все проблемы с поиском неисправностей в течение нескольких лет, и я регулярно нуждался в каком-то обзоре для отдельных учетных записей, я вскоре создал свою личную версию начального основного экрана запроса. Все, что я изменил, помещало серию, возможно, дюжины значений «0» /«1» в пустой части строки внизу.

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

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

«Подождите! Что это?»

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

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

ответил user2338816 14 AMpTue, 14 Apr 2015 05:38:44 +030038Tuesday 2015, 05:38:44
7

Я разработчик программного обеспечения и постоянно сталкиваюсь с этой проблемой.

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

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

Я могу дать вам очень реальный пример по запросу и запросу.

Недавно я получил сообщение BUG о том, что экспорт должен был использовать дружеское длинное имя с пробелами. Я ответил 3 раза, что вам нужно, так как это делается с помощью SQL XML, и я не могу использовать длинное имя, и это не ошибка, - как это было предусмотрено. У нас есть утилиты, которые анализируют этот XML. Поэтому они решили обойтись. Я указал, что они получают 100 000 строк экспорта за 40 минут - действительно нужно выбросить это, потому что имя в строке 1 должно быть отображаемым именем? Маркетинг сказал, но пользователи не знают, что означают названия. Я сказал им, но пользователи контролируют эти имена экспорта - им просто должно быть 20 символов или меньше пробелов и начать с буквы. То, что делают пользователи, - это предварительные конфигурации и просто редактирование отображаемого имени для следующего проекта и сохранение старого имени экспорта. Маркетинг был сильным, но они не изменяют название экспорта. Действительно 100 000 экспорт линии за 40 минут, и вы бы полностью переработали экспорт, потому что пользователи не хотят редактировать имя экспорта. Это больше, чем за месяц работы. Маркетинг провел фирму и сказал, что если вы не можете использовать отображаемое имя в своем XML, то, возможно, нам нужно найти того, кто лучше знает XML. Я сказал, что именно так работает XML - есть ограничения. Раньше у нас были ограничения на отображаемое имя, и 3 года назад вы сказали, что пользователь не хочет никаких ограничений, поэтому забирайте их. Компромиссом было отдельное название экспорта с ограничениями. На самом деле все это, потому что пользователь не хочет редактировать имя экспорта?

Другой жесткий запрос, который мы получили, - перейти на страницу X. Пользователи будут запускать поиск на странице X, а затем хотят прийти на следующий день и забрать, где они остановились. Но это не та же самая страница X - есть 100 других пользователей, редактирующих данные, и этот поиск не вернет те же результаты. Я сказал маркетинг, если мы отпустим их на X, они подумают, что они сломаны, если они не получат одинаковые страницы X. Хуже того, у кого-то будет задача просмотреть документы, а то, что было на странице 40, теперь на 20, и они находятся на странице 30, и этот документ не рассматривается. У нас есть функция, чтобы сохранить результаты в статическом списке - вот что им нужно использовать. Пользователь не хотел делать лишний шаг, чтобы сохранить результаты и имел ложное представление о том, что Страница X была заменой. Маркетинг сказал, что они просили. Разумеется, был выпущен документ, который не должен был быть выпущен, потому что пользователь не понимал страницу X, и клиент пошел баллистически. То, что они хотят и что им нужно, не всегда одно и то же.

ответил paparazzo 14 PMpTue, 14 Apr 2015 18:02:33 +030002Tuesday 2015, 18:02:33
6

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

Плюс это даже не работа UX, чтобы понять это.

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

 a swing

ответил icc97 16 AMpThu, 16 Apr 2015 11:32:15 +030032Thursday 2015, 11:32:15
3

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

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

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

Для получения дополнительной информации об этой теме вы должны прочитать SWEBOK (по IEEE) или любой в другой книге или статье в вики, посвященной разработке требований.

Моя любимая книга Требования-Engineering und -Management (от Chris Rupp ea) - которая доступна только на немецком языке (или, по крайней мере, я не мог найти английскую версию).

ответил Mischa 15 PMpWed, 15 Apr 2015 20:15:44 +030015Wednesday 2015, 20:15:44
2

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

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

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

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

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

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

ответил WalkingFortress 15 PMpWed, 15 Apr 2015 12:26:16 +030026Wednesday 2015, 12:26:16
2

Чтобы быть максимально кратким:

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

ответил Eman Santos 17 AMpFri, 17 Apr 2015 06:28:49 +030028Friday 2015, 06:28:49
1

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

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

Команда разработчиков специально задала вопрос о том, планировала ли Группа продуктов делать какие-либо будущие обследования. Они сказали нет.

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

Вскоре после этого группа продуктов и попросила провести еще один опрос, а затем еще один. Теперь они попросили провести 12 дополнительных обследований.

Команда Dev тратит 10 минут на каждый новый запрос опроса в результате создания динамического инструмента обследования в самом начале.

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

ответил Jason 15 PMpWed, 15 Apr 2015 19:21:27 +030021Wednesday 2015, 19:21:27
1

Клиент : Я хочу распечатать отчет с X. Затем я хочу создать веб-форму, чтобы Майк мог загрузить эти данные.

Аналитик : Это те же данные? Можем ли мы просто представить группу Майка экраном с данными X?

Клиент : Вы можете это сделать? В самом деле! Это сэкономит много работы.

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

Клиент : Вы имеете в виду, что это будет дешевле, быстрее и лучше? Отлично!

ответил borjab 20 PMpMon, 20 Apr 2015 14:36:14 +030036Monday 2015, 14:36:14
0

Я хотел бы продлить на ответ Digital Chris , в котором упоминалась проблема XY. Это фактически еще более расширилось в лингвистическую проблему.

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

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

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

ответил Cort Ammon 16 AMpThu, 16 Apr 2015 08:41:46 +030041Thursday 2015, 08:41:46
0

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

Вопрос о том, как часто что-то потребуется, - это то, что важно правильно ответить. Разумным является проектирование для общности и повторного использования, но это налагает затраты. Несколько раз я ошибался (недостаточно рылся) и поставлял сильно переработанный (следовательно, дорогостоящий и отложенный) продукт, который буквально должен был запускаться только один раз. Мой плохой.

ответил Rocker 21 AMpTue, 21 Apr 2015 00:52:10 +030052Tuesday 2015, 00:52:10

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

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

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