På denne side
Et supportsystem anbefaler at refundere en ordre. Skærmen siger »høj sikkerhed«, men medarbejderen kan ikke se, hvilken ordre eller version af politikken der ligger bag, eller om en erstatningsvare allerede er sendt. Anbefalingen kan være rigtig. Medarbejderen kan ikke vide det. Det er et tænkt supporttilfælde, ikke en rapporteret hændelse.
En demonstration af beslutningsstøtte viser et mønster, der er lettere at undersøge: Den ansvarlige kan se de enkelte målinger bag vurderingen og åbne den underliggende undersøgelse i stedet for kun at få det endelige forslag. Demonstrationen er fra sundhedsområdet, hvor uafhængig validering er særlig vigtig. Den beviser ikke klinisk nøjagtighed. Læren om design kan bruges i mindre følsomt arbejde uden at overtage leverandørens påstande om resultater.
En anbefaling sammenfatter beviset
Sammenfatning er nyttig. En person, der skal beslutte, om en ordre skal refunderes, vil ikke læse hver hændelse i et register. En anbefaling kan gøre en lang post til næste handling. Men den udelader detaljer, også dem der kan vende resultatet.
Se en tænkt ordrehistorik. En kunde melder en pakke væk. Modellen ser »ikke leveret« i fragtfirmaets oplysninger og foreslår refusion. En anden post siger, at en erstatningsvare blev sendt i morges. Hvis anbefalingen skjuler posten, kan medarbejderen give to løsninger på ét problem. Hvis begge fakta og deres tidspunkter vises, kan medarbejderen træffe et informeret valg.
Brugerfladen bør besvare fire spørgsmål, før den lægger op til handling: Hvad blev observeret? Hvor kom det fra? Hvor aktuelt er det? Hvad kunne gøre anbefalingen forkert? En forklaring i tekst er kun en del af svaret.
Observationer fra kilden og den ansvarlige forbindes af en anbefaling med ophav og usikkerhed, så den oprindelige post kan undersøges.
»Refundér, fordi leveringen fejlede« kan lyde overbevisende, selvom fragtstatus er forældet.
| Synligt element | Hvad det lader den ansvarlige teste |
|---|---|
| Anbefaling og foreslået handling | Om handlingen passer til opgaven |
| Observationer fra kilden med tidspunkter | Om fakta er aktuelle og komplette |
| Manglende eller modstridende beviser | Om der skal ventes eller undersøges |
| Link til den oprindelige post | Om resuméet udelod en afgørende detalje |
| Spor af resultater og rettelser | Om lignende forslag fejler gentagne gange |
Det er en begrebsmæssig tjekliste for en brugerflade, ikke en påstand om, at et bestemt dashboard giver bedre beslutninger.
Lad usikkerheden indgå i arbejdet, ikke i det med småt
Et system kan være usikkert af flere grunde. En kilde svarede ikke. To id’er kan henvise til samme ordre. En politik er ændret siden sidste indeksering. Modellen kan være usikker på en klage skrevet i fritekst. Det er forskellige fejltyper, som bør vises forskelligt.
»Lav sikkerhed« er ikke nok, når medarbejderen kunne afklare en manglende oplysning. Vis »fragtdata blev sidst opdateret i går« eller »posten om erstatningsforsendelsen kunne ikke hentes«. Har systemet ikke et grundlag for en score, så vis ikke en præcis procent. Målet er at hjælpe den ansvarlige med at vælge, hvad der skal kontrolleres næste gang.
Den samme struktur betyder noget i en datasynkronisering. Hvis destinationen får en ny kundestatus, så bevar hændelses-id, tidspunkt og regel fra kilden, der skabte ændringen. Når nogen spørger, hvorfor en kampagne omfattede en kunde, kan teamet følge beslutningen baglæns. En kopieret værdi uden forklaring er en anbefaling uden bevis.
Denne foreslåede Tajo-visning skelner mellem det, aktivitetsloggen rapporterer, og det, der fortsat er ubevist. Skrivningen vises som anvendt, mens destinationskontrollen stadig afventer. Tajos eksisterende aktivitetslog viser resultater og rå hændelser; det ekstra panel illustrerer, hvordan den grænse kunne gøres tydeligere.
En afsluttet skrivning kræver stadig bevis
Blev kundesynkroniseringen færdig?
Skrivning anvendt. Verifikation afventer.
Destinationens tilstand er endnu ikke kontrolleret.
Synkroniseringsaktivitet
- Anmodning accepteret
- Opdatering anvendt
- Destinationskontrol afventer
Eksempelkørsel · 14:32 UTC
Det ved vi
- Udbyderens svar
- Accepteret
- Skriveresultat
- Anvendt
- Tilbagelæsning fra destination
- Afventer
Et vellykket kald beviser ikke sluttilstanden.
Foreslået layout inspireret af Tajos aktivitetslog. Illustrationen tilføjer en verifikationstilstand; den påstår ikke, at tilbagelæsning fra destinationen allerede er implementeret.
Gør gennemgang nyttig uden at vise alt
De fleste rutinehandlinger kræver ikke, at en hel sag åbnes. En god brugerflade kan holde anbefalingen kort og lade beviset være ét trin væk. Den kan også fremhæve kun de forskelle, der kan ændre valget. Det er noget andet end at skjule grundlaget helt.
Der er en reel pris for privatlivet ved at vise mere data. Den ansvarlige bør kun se felter, der er nødvendige for beslutningen, under de samme adgangsregler som for den underliggende post. At beviset kan ses, er ikke en generel tilladelse til at åbne hele kundens historik. Opbevaring og revisionslogs skal også have en ansvarlig.
En anden risiko er tilbøjeligheden til at følge automatiseringen: En synlig anbefaling kan stadig styre den, der gennemgår den. Test, om folk fanger indlagte modsigelser og kan vælge »beviset er utilstrækkeligt« uden at kæmpe med brugerfladen. Mål mønstre i rettelser og omgørelser efter lancering. En behagelig forklaring er ikke målet for resultatet.
Brugerfladen skal også have et sted at registrere uenighed. Hvis medarbejderen afviser forslaget om refusion, så bed om en grund, der er præcis nok til at forbedre systemet: forkert ordrematch, gammel fragtstatus, manglende post om erstatningsforsendelsen eller en undtagelse fra politikken. Gør ikke hver uenighed til krav om lang prosa. Saml grundene, og undersøg, om én kilde igen og igen skaber problemer. Så kan en enkelt gennemgang føre til reparation af systemet. Guiden til at opdage arbejdsgange hjælper med at finde den virkelige vej for undtagelser, før der bygges et forslag. Bevis ved siden af anbefalingen hjælper den ansvarlige i dag; data om rettelser kan forbedre beslutningsvejen i morgen.
Ved handlinger med konsekvenser bør vejen til gennemgang være en del af produktets aftale. Systemet foreslår, henviser til det, det brugte, nævner hvad det ikke kunne kontrollere, og registrerer resultatet. Når beviset ikke støtter et valg, kan den mest nyttige anbefaling være »vent«.
Ofte Stillede Spørgsmål
Gør en forklaring en anbefaling pålidelig?
Nej. En plausibel forklaring kan ledsage et forkert resultat. Den, der gennemgår det, har brug for adgang til observationer fra kilden, deres ophav, usikkerhed og resultater, ikke kun en sikker formulering.
Hvilket bevis skal stå ved siden af et automatisk forslag?
Vis de konkrete observationer, som blev brugt, deres kilde og tidspunkt, manglende input, relevant version af regel eller model og en måde at undersøge den oprindelige post.
Hvornår skal et menneske gennemgå resultatet?
Når konsekvensen går ud over systemets tilladte omfang, eller beviset er ufuldstændigt, forældet eller omstridt. Den ansvarlige skal reelt kunne være uenig og stoppe handlingen.