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

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

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

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

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

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

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

ошибки

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

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

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

Mis-связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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