Являются ли «ошибки» в дизайне плохим знаком?

29

Является ли это плохим признаком, если пользователи отправляют отчеты об ошибках для вещей, которые разработаны?

Означает ли это, что приложение сбивает с толку или неясно, или я должен просто объяснить это единственной ошибкой пользователя, если не указано иное?

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

Maxpm
источник
19
Возможно, некоторые программисты в Lotus Notes захотят это прокомментировать, поскольку стандартный ответ - «это не ошибка, а функция, которую вы не понимаете».
Джеймс Андерсон
5
Это говорит мне о том, что пользовательские требования, предъявляемые разработчикам, не соответствуют ожиданиям пользователей.
temptar
7
@temptar "Это то, что я просил, но это не то, что я хотел."
StuperUser
5
Недавно мне был присвоен рабочий элемент «ошибка» для поведения, которое в точности соответствовало тому, что было четко указано в спецификации (и которое обсуждалось на этапе спецификации). Хотя поведение вполне может быть неожиданным с точки зрения пользователя (особая настройка, на которую было обращено внимание в другом месте, игнорируется), если в спецификации буквально сказано «давайте проигнорируем это, чтобы сэкономить время», тогда для меня это не ошибка, а запрос на изменение. Конечно, можно было бы привести веские доводы в пользу того, чтобы это изменилось, но не называйте это ошибкой .
CVn
7
@Dunk: Я внедрил систему, которая предполагала 24 часа в сутки, потому что мы не смогли убедить клиента в существовании летнего времени. Они просто не поверили бы, что есть дни с 25 часами. Это ошибка в программе?
MSalters

Ответы:

54

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

Когда люди отправляют мне какие-либо отзывы, я пытаюсь отфильтровать их по трем категориям:

  • ошибки
  • Запросы функций
  • Mis-связи

ошибки

Ошибки возникают, когда что-то явно не работает так, как вы ожидаете, так и так, как ожидал бы пользователь . Мол, меня спросили, как меня зовут, я вошел в «Скотт», нажал «Enter» и сказал: «Привет, Джо!»

Запросы функций

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

Mis-связи

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

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

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

Скотт Уитлок
источник
3
Неправильное общение также включает в себя неправильное запоминание (или простое забывание) ожиданий, которые были сообщены и согласованы.
Питер Тейлор
1
Большие различия, но я все еще думаю, что приложение должно попытаться объяснить неправильное сообщение, если оно может. При наличии нескольких человек с одинаковыми именами приложение может сказать: «У нас уже есть 3 Джона Смита, вы уверены, что это не один из них» с опцией «Нет, я уверен, что это новый Джон Смит».
Алексей Андронов
@ Алекс Андронов - недопонимание не означает, что не нужно предпринимать никаких действий: либо изменить документацию, всплывающие подсказки и т. Д., Либо обновить учебный материал, либо, возможно, просто краткое объяснение и двигаться дальше.
Скотт Уитлок
7

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

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

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

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

maple_shaft
источник
2
+1, но, пожалуйста, посмотрите на разницу между сложным и сложным ... Программное обеспечение вообще не должно быть сложным, но зачастую оно бывает очень сложным.
Марьян Венема
Это очень верно. Самым распространенным случаем, с которым я сталкиваюсь, являются пользователи, не осознающие разницу между отношениями «многие к одному» и «многие ко многим». Распространенный запрос, который я получаю: «Вы можете заставить отчет показывать номер заказа в заголовке?» и я должен объяснить, что, хотя примерно в 95% случаев в материалах, над которыми они работают, присутствует только один номер заказа, во многих случаях запрос может включать данные по нескольким заказам. Затем я должен спросить, хотите ли вы, чтобы я перечислил все номера заказов в заголовке, разделенные запятыми, или вы хотите, чтобы номер заказа находился в каждой подробной строке в отчете?
Скотт Уитлок
@ ScottWhitlock Да, это то же самое. Хороший разработчик или бизнес-аналитик должен не просто делать то, что просит клиент, но и пытаться раскрыть основную проблему, с которой он сталкивается, для чего он вообще сделал такой запрос. Как только вы определите их проблему, вы сможете найти правильное решение и написать соответствующие требования или истории пользователей.
maple_shaft
5

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

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

JeffO
источник
1
Там нет единого ответа, то, я полагаю. Это следует оценивать в каждом конкретном случае. Я понял, как много.
Макс.
5

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

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

Тим Виллискрофт
источник
5

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

Йорис Тиммерманс
источник
3
Или, что есть разделенная группа пользователей. Например, допустим, ваше веб-приложение имитирует рабочий стол. Ожидаете ли вы, что закрытие окна закрывает программу? Да для пользователей Windows, Нет для пользователей Mac.
Keppla
1
@Keppla - вы делаете хорошее замечание. Вы не можете угодить всем, поэтому в случае «ошибок», подобных упомянутым здесь, необходимо провести расследование, чтобы убедиться, что вы не получите больше отчетов об ошибках после «исправления», чем раньше.
Йорис Тиммерманс
1
возможно, но гораздо мощнее привести данные о том, что "сотни людей подали ошибки по этому поводу!" чем то, что несколько бешеных пользователей говорят вам, что вы нарушили их личную интерпретацию Магического Принципа Наименьшего Изумления, и они удивлены. Я немного устал от последнего, так как «изумление» одного человека - «прямолинейность» другого человека.
Джефф Этвуд
@Джефф Этвуд - как говорится, «одна ласточка не делает лето», «один отчет об ошибке не подразумевает ошибки проектирования». Отдельный отчет об ошибке в чем-то, что является функцией, не является причиной для редизайна, и даже несколько отчетов об общей функции не обязательно означают, что большинство ваших пользователей не будут счастливее без «исправления». Особенно, если ваш оригинальный релиз уже популярен, и люди привыкли использовать его «таким образом».
Йорис Тиммерманс
2

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

Карл Билефельдт
источник
2

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

(Изменить - добавил мой комментарий к ответу согласно предложению @Marjan Venema.

Джеймс Маклеод
источник
Я не вижу, чтобы это было отмечено как сообщение об ошибке. Больше похоже на предложение или функцию запроса. (Хотя в некоторых системах отслеживания ошибок он все равно может считаться одним.)
Maxpm
1
Я согласен, в большинстве случаев, но это может означать упущение (ошибку) в дизайне, или серую область в спецификациях, или другой набор предположений, сделанных разработчиком и пользователем.
Джеймс Маклеод
1
Джеймс, если ты добавишь этот комментарий к своему ответу, весь ответ станет лучше.
Марьян Венема
1

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

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

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

18bytes
источник
1

Я хотел бы добавить к ответу maple_shaft о "невежестве" пользователей. Вы также должны помнить, что 90% пользователей будут заботиться только о своем опыте и способах использования системы. Они не заботятся о других пользователях, почему они должны? Наша работа как дизайнеров / разработчиков заключается в том, чтобы учесть мнения всех пользователей и сделать то, что подходит каждому как можно лучше. В большинстве случаев вы не можете сделать решение оптимальным для всех.

Но, конечно, вам нужно прочитать и оценить отзывы ваших пользователей! В конце концов, это те, кто использует ваше творение!

AndSoYouCode
источник
0

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

Я обнаружил, что проблема часто является признаком того, что BA или PM получают требования только от менеджеров, а не от реальных пользователей. То, что менеджеры ожидают от системы, часто сильно отличается от того, что действительно нужно людям, вводящим данные. Меня учили собирать данные непосредственно от реальных пользователей, но большинство БА, с которыми я сталкивался в последнее время, общаются только с менеджерами (и вообще с относительно старшими менеджерами).

HLGEM
источник