Чи «Помилки» задумки є поганим знаком?

Це погана ознака, якщо користувачі надсилають звіти про помилки для речей, які є задумом?

Це, як правило, означає, що додаток є заплутаним чи незрозумілим, або я повинен просто додати його до одноразової помилки користувача, якщо конкретно не зазначено?

(У мене фактично немає таких звітів. Це суто гіпотетичний запитання про те, чи є погана річ існування "помилок", призначених для проектування.)

Це поганий знак? Я думаю, що це попередження, на яке варто звернути увагу, але я також думаю, що це має відбутися.

Коли люди надсилають мені будь-який відгук, я намагаюся відфільтрувати його на три відра:

• Клопи
• Запити на функції
• Міс-спілкування

Клопи

Помилки - це коли щось очевидно не працює так, як ви очікували, ні так, як очікував би користувач . Мовляв, воно запитало мене про своє ім’я, я ввійшов до "Скотта", натиснув Enter, і він сказав: "Привіт Джо!"

Запити на функції

Це на кшталт "Я знаю, що ми ніколи про це не говорили, але чи може програма зробити висновок з моїх жестів миші про те, що я лівша, і перемістити кнопку ОК в ліву частину екрана?" Це коли поточна поведінка відповідає вашим і очікуванням користувача, але вони хочуть змінити очікування.

Міс-спілкування

Це коли ви очікуєте одного результату від сценарію, але користувач очікує іншого результату. Іноді це стає запитом на функцію, якщо вони просто не повідомили своїх очікувань, але думали, що це зробили. Іноді це стає помилкою, якщо ваші очікування виявляються помилковими.

Однак багато разів у вас є знання, яких у користувача немає. Що робити, якщо вони сказали: "На цьому екрані я можу двічі додати запис для себе з тим самим іменем та прізвищем! Очевидно, це помилка!" Ваша відповідь може бути: "У світі дуже багато людей з однаковим іменем та прізвищем, тому нам не потрібно, щоб ця комбінація була унікальною. У нас є завдання з очищення, яке виконується вночі та надсилає електронне повідомлення про можливий звіт про копії служба клієнтів, коли думає, що виявляє дублікат з подібним іменем та адресою, і просить їх перевірити вручну ".

Отже, ви повинні читати кожен звіт про помилку, але в більшості складних систем є звіти про помилки, які насправді є лише запитами про функцію або, можливо, неправильним повідомленням вимог. Нерозуміння основної складності реального світу, мабуть, є найбільшим джерелом цих питань.

Це не торкалося в попередніх відповідях до цих пір, тому додам, що це також може бути ознакою незнання користувачів. Я не вживаю слова "необізнаний" зневажливо або поблажливо, лише як спосіб висловити, що вони не мають належних знань чи освіти у своїй галузі чи складності самого програмного забезпечення.

Більшість користувачів не знають, наскільки складним програмним забезпеченням повинно бути відповідність певним вимогам. Щось досягає 80% зусиль, припадає лише на 20% функціональності (бахрома та винятки).

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

Це не хвилює, оскільки це стає кращим за допомогою чіткої та стислої документації та спілкування.

Якщо у вас є користувач, який є експертом у своїй галузі, у вас може виникнути велика проблема. Уявіть, що бухгалтер, який знаходить ваше програмне забезпечення, за дизайном, не дотримується загальних облікових процедур, або інженер, який виявить, що у вас неправильна формула. Це не повинно бути занадто важким для дослідження, щоб перевірити, чи правильно вони. Переробляйте та виправляйте, якщо потрібно - швидке.

Одну думку щодо певної функції інтерфейсу або поля, яке, на їх думку, повинно бути символом валюти чи іншим форматуванням, слід враховувати, принаймні, доки ви не отримаєте більше відгуків. Дослідити це може бути трохи складніше.

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

Коли відомі постачальники ОС кажуть, що "така поведінка є дизайном", вони, як правило, мали на увазі простоту впровадження або комерційну перевагу. Якщо це не ви, спробуйте дізнатись у своїх користувачів справжній набір навичок та відношення до вашого програмного забезпечення. Їм користуються цілий день? Для розваги ? Раз на тиждень через те, що він замінював форми TPS?

Користувальницький інтерфейс повинен дотримуватися принципу найменшого здивування - неодноразові повідомлення про помилки щодо функції, яка працює як розроблена, є свідченням того, що цей принцип не дотримувався правильно.

Існує два види помилок: функціональність не відповідає намірам програміста або функціональність не відповідає вимогам. Програмісти мають тенденцію зосереджуватися на першому на шкоду другому. Простіше кажучи, якщо ваші користувачі повідомляють про багато помилок ", - ваші вимоги не такі, як ви думаєте.

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

(Редагувати - додав мій коментар до відповіді на пропозицію @Marjan Venema.

Я вважаю, що це погана ознака, головним чином, через те, що дизайн не є загальним, а вимоги користувачів не повністю вивчені / проаналізовані.

Я бачу дві католики дизайну, - Дизайн випадково. - Дизайн за задумом.

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

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

Але звичайно вам потрібно прочитати та оцінити відгуки користувачів! Зрештою, це ті, хто використовує твоє творіння!

Користувачі, які подавали запити про помилки, як правило, не консультувались щодо дизайну, тому не дивно, що вони бачать речі як помилки, які були обдуманими дизайнерськими рішеннями. Для користувача все, що не працює, як очікувалося, - це помилка.

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