På denne siden
Et system for kundestøtte foreslår å refundere en ordre. Skjermen sier «høy konfidens», men medarbeideren kan ikke se hvilken ordre, hvilken versjon av reglene eller om en erstatningsforsendelse allerede er sendt. Forslaget kan være riktig. Medarbeideren har ingen måte å vite det på. Dette er et tenkt støttescenario, ikke en rapportert hendelse.
En demonstrasjon av beslutningsstøtte viser et mønster som er lettere å undersøke: En kontrollør kan se delmålinger og åpne den underliggende undersøkelsen i stedet for å få bare et sluttforslag. Demonstrasjonen kommer fra helseområdet, der uavhengig validering er særlig viktig. Den beviser ikke klinisk nøyaktighet. Prinsippet for utforming kan brukes i mindre følsomt arbeid uten å låne leverandørens påstander om resultater.
En konklusjon presser bevisene sammen
Sammenfatning er nyttig. En person som spør om en ordre bør refunderes, vil ikke lese hver hendelse i en logg. Et forslag kan gjøre en lang historikk om til en neste handling. Men sammenfatningen fjerner detaljer, også dem som kunne snu beslutningen.
Se på en tenkt ordrehistorikk. En kunde melder at en pakke mangler. Modellen ser «ikke levert» i transportørens data og foreslår refusjon. En annen post sier at en erstatningsvare ble sendt i morges. Hvis forslaget skjuler den posten, kan medarbeideren gi to løsninger for ett problem. Hvis begge fakta og tidspunktene vises, kan vedkommende ta et opplyst valg.
Grensesnittet bør svare på fire spørsmål før det inviterer til handling: Hva ble observert? Hvor kom det fra? Hvor oppdatert er det? Hva kunne gjøre forslaget feil? En forklaring i prosa er bare en del av svaret.
Kildeobservasjoner og en kontrollør er knyttet sammen av et forslag som viser opphav og usikkerhet, slik at den opprinnelige posten kan undersøkes.
«Refunder fordi levering feilet» kan lyde overbevisende mens statusen fra transportøren er gammel.
| Det som vises | Hva kontrolløren kan teste |
|---|---|
| Forslag og planlagt handling | Om handlingen passer til oppgaven |
| Kildeobservasjoner med tidsstempler | Om fakta er oppdaterte og fullstendige |
| Manglende eller motstridende bevis | Om saken bør stoppe eller undersøkes |
| Lenke til opprinnelig post | Om sammendraget utelot en avgjørende detalj |
| Resultat og spor av rettelser | Om lignende forslag feiler igjen og igjen |
Dette er en tenkt sjekkliste for et grensesnitt, ikke en påstand om at et bestemt dashboard gir bedre beslutninger.
Legg usikkerheten inn i arbeidet, ikke i det med liten skrift
Et system kan være usikkert av flere grunner. En kilde svarte ikke. To identifikatorer kan vise til samme ordre. En regel kan ha endret seg siden siste indeksering. Modellen kan være usikker på hvordan en fritekstklage skal tolkes. Dette er ulike feil og bør vises forskjellig.
«Lav konfidens» er ikke nok når medarbeideren kan avklare et konkret manglende faktum. Vis «transportørdata ble sist oppdatert i går» eller «posten om erstatningsforsendelsen kunne ikke hentes». Hvis systemet ikke har grunnlag for en score, ikke mal en presis prosent på skjermen. Målet er at kontrolløren skal vite hva som må sjekkes videre.
Den samme strukturen betyr noe i en datasynkronisering. Hvis målsystemet får en ny kundestatus, behold ID-en til kildehendelsen, tidspunktet og regelen som skapte endringen. Når noen spør hvorfor en kampanje tok med en kunde, kan teamet følge beslutningen bakover. En kopiert verdi uten forklaring er en konklusjon uten bevis.
Denne foreslåtte Tajo-visningen skiller mellom det aktivitetsloggen rapporterer og det som fortsatt er ubevist. Skrivingen vises som utført, men målkontrollen venter fortsatt. Tajos eksisterende aktivitetslogg viser resultater og rå hendelser; det ekstra panelet illustrerer hvordan denne grensen kan bli tydeligere.
En fullført skriving trenger fortsatt bevis
Ble kundesynkroniseringen fullført?
Skriving utført. Verifisering venter.
Tilstanden i målsystemet er ikke kontrollert ennå.
Synkroniseringsaktivitet
- Forespørsel godtatt
- Oppdatering utført
- Målkontroll venter
Eksempelkjøring · 14:32 UTC
Det vi vet
- Leverandørens svar
- Godtatt
- Skriveresultat
- Utført
- Tilbakelesing fra målsystemet
- Venter
Et vellykket kall beviser ikke sluttilstanden.
Foreslått utforming inspirert av Tajos aktivitetslogg. Illustrasjonen legger til en verifiseringstilstand; den hevder ikke at tilbakelesing fra målsystemet allerede er implementert.
Gjør gjennomgang nyttig uten å vise alt
De fleste rutinehandlinger bør ikke kreve at noen åpner en hel sak. Et godt grensesnitt kan holde forslaget kort og gjøre bevisene tilgjengelige ett steg unna. Det kan også løfte frem bare avvikene som kunne endre valget. Det er noe annet enn å skjule grunnlaget helt.
Det er en virkelig personvernkostnad ved å vise mer data. En kontrollør bør bare se feltene som trengs for denne beslutningen, under de samme tilgangsreglene som gjelder den underliggende posten. Synlige bevis er ikke en generell tillatelse til å vise hele kundehistorikken. Lagring og revisjonslogger trenger også en eier.
En annen bekymring er automatiseringsskjevhet: Et synlig forslag kan fortsatt lede personen som vurderer det. Test om kontrollører oppdager motsigelser som bevisst er lagt inn, og om de kan velge «ikke nok bevis» uten å kjempe mot grensesnittet. Mål rettelser og omgjøringer etter lansering. En tiltalende forklaring er ikke målet for resultatet.
Et grensesnitt for gjennomgang trenger også et sted å registrere uenighet. Hvis medarbeideren avviser refusjonsforslaget, be om en grunn som er smal nok til å forbedre systemet: feil ordrematch, gammel status fra transportøren, manglende post om erstatningsforsendelsen eller unntak fra reglene. Ikke gjør hver uenighet til et krav om lang prosa. Samle årsakene og undersøk om én kilde stadig skaper problemer. Slik går veien fra gjennomgang av enkeltsaker til retting av systemet. Guiden til å oppdage den faktiske arbeidsflyten hjelper med å finne den virkelige veien for unntak før et forslag bygges. Bevis ved siden av konklusjonen hjelper kontrolløren i dag; data om rettelser kan forbedre morgendagens beslutningsvei.
For handlinger med vesentlige konsekvenser bør gjennomgangen være en del av produktets kontrakt. Systemet foreslår, viser kildene det brukte, navngir det det ikke kunne sjekke, og registrerer resultatet. Når bevisene ikke støtter et valg, kan den nyttigste konklusjonen være «vent».
Ofte Stilte Spørsmål
Gjør en forklaring et forslag pålitelig?
Nei. En plausibel forklaring kan følge et feil resultat. Den som gjennomgår saken, trenger tilgang til kildeobservasjoner, opprinnelse, usikkerhet og utfall, ikke bare en selvsikker setning.
Hvilke bevis bør vises ved et automatisk forslag?
Vis de konkrete observasjonene som ble brukt, kilde og tidspunkt, manglende inndata, versjon av regel eller modell når det er relevant, og en vei til den opprinnelige posten.
Når bør et menneske gjennomgå resultatet?
Når konsekvensen går utover systemets tillatte omfang, eller bevisene er ufullstendige, gamle eller omstridte. Den som gjennomgår, må ha en reell mulighet til å være uenig og stoppe handlingen.