На тази страница
Система за поддръжка препоръчва възстановяване на парите по поръчка. Екранът пише „висока увереност“, но агентът не може да види коя поръчка, коя версия на политиката или дали вече е изпратен заместващ продукт. Препоръката може да е правилна. Агентът няма как да знае. Това е илюстративен сценарий за поддръжка, не докладван инцидент.
Демонстрация на подпомагане на решения показва по-проверим модел: оценяващият може да види съставните измервания и да отвори основното изследване, вместо да получава само крайно предложение. Демонстрацията е в медицинска среда, където независимата валидация е особено важна. Тя не установява клинична точност. Урокът за дизайн може да се пренесе в по-малко чувствителна работа, без да се заемат твърденията на доставчика за резултатите.
Крайната преценка свива доказателствата
Свиването е полезно. Човек, който пита дали да върне пари по поръчка, не иска да чете всяко събитие в регистър. Препоръка може да превърне дълъг запис в следващо действие. Но свиването изхвърля подробности, включително онези, които може да променят резултата.
Разгледайте илюстративна история на поръчка. Клиент съобщава за липсващ пакет. Моделът вижда „не е доставен“ в данните на превозвача и предлага възстановяване на парите. Друг запис казва, че тази сутрин е изпратен заместител. Ако препоръката скрие записа, агентът може да компенсира клиента два пъти за един и същ проблем. Ако покаже и двата факта с времето им, агентът може да избере информирано.
Интерфейсът трябва да отговори на четири въпроса, преди да покани към действие: Какво е наблюдавано? Откъде идва? Колко актуално е? Какво може да направи препоръката грешна? Текстово обяснение е само част от отговора.
Наблюденията от източника и проверяващият са свързани чрез препоръка с произход и несигурност, така че първоначалният запис да може да се прегледа.
„Върнете парите, защото доставката е неуспешна“ може да звучи гладко, докато статусът на превозвача е остарял.
| Видим елемент | Какво позволява да провери човекът |
|---|---|
| Препоръка и предложено действие | Дали действието съответства на задачата |
| Изходни наблюдения с времеви отметки | Дали фактите са актуални и пълни |
| Липсващи или противоречиви доказателства | Дали да спре или да изследва |
| Връзка към първоначалния запис | Дали резюмето е пропуснало решаваща подробност |
| Резултат и следа от поправките | Дали подобни препоръки се провалят повторно |
Това е концептуален списък за интерфейс, не твърдение, че определено табло постига по-добри решения.
Поставете несигурността в работата, не в дребния шрифт
Системата може да е несигурна по няколко причини. Източник не е отговорил. Два идентификатора може да сочат една и съща поръчка. Политика се е променила след последното индексиране. Самият модел може да не знае как да тълкува оплакване в свободен текст. Това са различни провали и заслужават различно показване.
„Ниска увереност“ не стига, когато операторът може да изясни конкретен липсващ факт. Покажете „данните на превозвача са обновени последно вчера“ или „записът за заместителя не може да се извлече“. Ако системата няма основание за оценка, не рисувайте точен процент на екрана. Целта е проверяващият да реши какво да провери след това.
Същата структура има значение и при синхронизация на данни. Ако целевата система получи нов клиентски статус, запазете ID-то и времето на изходното събитие и правилото, което е довело до промяната. Когато някой попита защо кампания е включила клиент, екипът може да проследи решението назад. Копирана стойност без обяснение е преценка без доказателства.
Този предложен изглед на Tajo отделя съобщеното от дневника за активност от това, което остава недоказано. Записът е показан като приложен, а проверката в целевата система предстои. Съществуващият поток на активността в Tajo показва резултати и необработени събития; добавеният панел за проверка илюстрира как тази граница може да стане по-видима.
Извършеният запис все още се нуждае от доказателство
Приключи ли синхронизацията на клиентите?
Записът е приложен. Проверката предстои.
Състоянието в целевата система още не е проверено.
Активност на синхронизацията
- Заявката е приета
- Промяната е приложена
- Проверката в целевата система предстои
Примерно изпълнение · 14:32 UTC
Какво знаем
- Отговор от доставчика
- Приета
- Резултат от записа
- Приложен
- Прочитане от целевата система
- Предстои
Успешното извикване не доказва крайното състояние.
Предложен изглед, основан на активността в Tajo. Илюстрацията добавя състояние на проверка; тя не твърди, че повторното прочитане от целевата система вече е реализирано.
Поддържайте прегледа полезен, без да излагате всичко
Повечето рутинни действия не бива да изискват отваряне на цяла преписка. Добрият интерфейс може да запази препоръката кратка и доказателствата на една стъпка разстояние. Може също да показва само несъответствията, които биха променили избора. Това се различава от пълното скриване на основанията.
Показването на повече данни има реална цена за поверителността. Проверяващият трябва да вижда само полетата, нужни за това решение, при същите правила за достъп като основния запис. Видимостта на доказателствата не е общо разрешение за излагане на клиентска история. Съхранението и одитните дневници също се нуждаят от отговорник.
Втора тревога е склонността да се следва автоматизацията: видимата препоръка пак може да насочва човека, който я проверява. Тествайте дали проверяващите откриват нарочно поставени противоречия и дали могат да изберат „недостатъчно доказателства“, без да се борят с интерфейса. Измервайте моделите на поправки и връщания след пускане. Приятното обяснение не е мярката за резултата.
Интерфейсът за преглед се нуждае и от място за записване на несъгласие. Ако агентът отхвърли препоръката за връщане на пари, поискайте причина достатъчно тясна, за да подобри системата: свързана е грешна поръчка, статусът на превозвача е стар, липсва записът за заместващ продукт или има изключение от политиката. Не превръщайте всяко несъгласие в изискване за дълго обяснение. Групирайте причините и вижте дали един източник създава проблеми многократно. Така индивидуалният преглед води към поправка на системата. Ръководството за откриване на действителния процес помага да се намери пътят на изключенията, преди да се изгради препоръка. Доказателствата до решението помагат на проверяващия днес; данните за поправки може да подобрят утрешния път.
За действия с последствия пътят за преглед трябва да е част от договора на продукта. Системата предлага, цитира използваното, назовава непровереното и записва резултата. Когато доказателствата не подкрепят избор, най-полезната преценка може да е „изчакайте“.
Често Задавани Въпроси
Прави ли обяснението препоръката надеждна?
Не. Правдоподобно обяснение може да придружава грешен резултат. Проверяващите се нуждаят от изходните наблюдения, произхода, несигурността и резултатите, не само от уверено изречение.
Кои доказателства трябва да стоят до автоматична препоръка?
Покажете точните използвани наблюдения, източника и времето им, липсващите данни, версията на правило или модел, когато е важна, и начин да се прегледа първоначалният запис.
Кога човек трябва да прегледа резултата?
Когато последицата надхвърля разрешения обхват на системата или доказателствата са непълни, остарели или оспорени. Проверяващият трябва да има реален начин да не се съгласи и да спре действието.