Suunnittelu autonomisille toimijoille aiheuttaa ainutlaatuista turhautumista. Annamme monimutkaisen tehtävän tekoälylle, se katoaa 30 sekunniksi (tai 30 minuutiksi) ja palaa sitten tuloksen kera. Tuijotamme näyttöä. Toimiiko se? Oliko se hallusinaatioita? Tarkistiko se vaatimustenmukaisuustietokannan vai ohittiko se vaiheen? Vastaamme tyypillisesti tähän ahdistukseen yhdellä kahdesta ääripäästä. Pidämme järjestelmän joko mustana laatikona, piilottaen kaiken yksinkertaisuuden säilyttämiseksi, tai panikoimme ja tarjoamme Data Dumpin, joka suoratoistaa jokaisen lokirivin ja API-kutsun käyttäjälle. Kumpikaan lähestymistapa ei käsittele suoraan vivahteita, joita tarvitaan tarjoamaan käyttäjille ihanteellinen läpinäkyvyys. Black Box jättää käyttäjät voimattomaksi. Data Dump luo ilmoitussokeuden, mikä tuhoaa agentin luvanneen tehokkuuden. Käyttäjät jättävät huomioimatta jatkuvan tietovirran, kunnes jokin hajoaa, jolloin heiltä puuttuu konteksti sen korjaamiseen. Tarvitsemme organisoidun tavan löytää tasapaino. Edellisessä artikkelissani "Designing For Agentic AI" tarkastelimme luottamusta rakentavia käyttöliittymäelementtejä, kuten tekoälyn aiotun toiminnan näyttämistä etukäteen (Intent Previews) ja käyttäjien hallintaa sen suhteen, kuinka paljon tekoäly tekee itsestään (Autonomy Dials). Mutta tieto siitä, mitä elementtejä tulee käyttää, on vain osa haastetta. Suunnittelijoiden vaikeampi kysymys on tietää, milloin niitä käytetään. Mistä tiedät, mikä hetki 30 sekunnin työnkulussa vaatii Intent Previewin ja mikä voidaan käsitellä yksinkertaisella lokimerkinnällä? Tämä artikkeli tarjoaa menetelmän vastata tähän kysymykseen. Käymme läpi päätössolmun tarkastuksen. Tämä prosessi saa suunnittelijat ja insinöörit samaan huoneeseen yhdistämään taustalogiikan käyttöliittymään. Opit tunnistamaan tarkat hetket, jolloin käyttäjä tarvitsee päivityksen tekoälyn toiminnasta. Käsittelemme myös vaikutus-/riskimatriisin, joka auttaa priorisoimaan, mitkä päätössolmut näkyvät ja mitkä niihin liittyvät suunnittelumallit liitetään tähän päätökseen. Läpinäkyvyyshetket: esimerkki tapaustutkimuksesta Harkitse Meridiania (ei oikealla nimellä), vakuutusyhtiötä, joka käyttää agenttia tekoälyä käsittelemään alkuperäisiä onnettomuuskorvauksia. Käyttäjä lataa kuvia ajoneuvovaurioista ja poliisiraportista. Agentti katoaa sitten minuutiksi ennen kuin palaa riskiarvioinnin ja ehdotetun maksualueen kanssa. Aluksi Meridianin käyttöliittymä näytti yksinkertaisesti Lasketaan korvausvaatimustila. Käyttäjät turhautuivat. He olivat toimittaneet useita yksityiskohtaisia asiakirjoja ja olivat epävarmoja siitä, oliko tekoäly edes tarkistanut poliisin raporttia, joka sisälsi lieventäviä seikkoja. Musta laatikko loi epäluottamusta. Tämän korjaamiseksi suunnittelutiimi suoritti päätössolmutarkastuksen. He havaitsivat, että tekoäly suoritti kolme erillistä, todennäköisyyksiin perustuvaa vaihetta, joihin oli upotettu useita pienempiä vaiheita:
Kuva-analyysiAgentti vertasi vauriokuvia tyypillisten kolariskenaarioiden tietokantaan korjatakseen korjauskustannukset. Tämä sisälsi luottamuspisteen. Textual ReviewIt skannasi poliisiraportista vastuuseen vaikuttavia avainsanoja (esim. vika, sääolosuhteet, raittius). Tähän sisältyi oikeustoimivaltuuden todennäköisyysarviointi. Policy Cross ReferenceIt täsmäsi vaatimuksen tiedot käyttäjän erityisiin käytäntöehtoihin etsimällä poikkeuksia tai kattavuusrajoja. Tämä sisälsi myös todennäköisyyspohjaisen vastaavuuden.
Tiimi muutti nämä vaiheet läpinäkyvyyden hetkiksi. Käyttöliittymäjärjestys päivitettiin seuraavaksi:
Vahinkokuvien arvioiminen: Vertaamalla 500 ajoneuvon törmäysprofiiliin. Poliisiraportin tarkistaminen: vastuun avainsanojen ja oikeudellisen ennakkotapauksen analysointi. Käytännön kattavuuden tarkistaminen: Tarkista, onko suunnitelmassasi tiettyjä poissulkemisia.
Järjestelmä vei silti saman verran aikaa, mutta selkeä viestintä agentin sisäisestä toiminnasta palautti käyttäjien luottamuksen. Käyttäjät ymmärsivät, että tekoäly suoritti monimutkaisen tehtävän, johon se oli suunniteltu, ja he tiesivät tarkalleen, mihin keskittyä, jos lopullinen arvio näytti epätarkalta. Tämä suunnitteluvalinta muutti ahdistuksen hetken hetkeksi yhteyden käyttäjään. Vaikutus/riskimatriisin soveltaminen: mitä valitsimme piilottaa Useimmissa tekoälykokemuksissa ei ole pulaa tapahtumista ja päätössolmuista, jotka voidaan mahdollisesti näyttää käsittelyn aikana. Yksi tarkastuksen kriittisimmistä tuloksista oli päättää, mitä pitää näkymättömänä. Meridian-esimerkissä taustalokit loivat yli 50 tapahtumaa vaatimusta kohden. Olisimme voineet näyttää oletuksena jokaisen tapahtuman, kun ne käsiteltiin osana käyttöliittymää. Sen sijaan sovelsimme riskimatriisia niiden karsimiseen:
Lokitapahtuma: Pinging ServerWest-2 redundanssitarkistusta varten. Suodattimen tuomio: Piilota. (Matalat panokset, korkea teknisyys).
Lokitapahtuma: Korjausarvion vertailu BlueBook-arvoon. Suodattimen tuomio: Näytä. (Korkeat panokset, vaikuttaa käyttäjän maksuihin).
Karsimalla pois tarpeettomat yksityiskohdat, tärkeät tiedot – kuten kattavuuden todentaminen – vaikuttivat tehokkaammin. Loimme avoimen käyttöliittymän ja suunnittelimme avoimen kokemuksen. Tämä lähestymistapa käyttää ajatusta siitä, että ihmiset tuntevat olonsa paremmaksi palvelusta, kun he näkevät työn valmistuvan. Näyttämällä tarkat vaiheet (arviointi, tarkistaminen, vahvistaminen) muutimme 30 sekunnin odotuksen huolen hetkestä ("Onko se rikki?") hetkeksi, jolloin tunnemme, että jotain arvokasta luodaan ("Se on ajattelua"). Katsotaanpa nyt tarkemmin, kuinka voimme tarkastella tuotteidemme päätöksentekoprosessia tunnistaaksemme selkeitä tietoja vaativat keskeiset hetket. Päätössolmun tarkastus Läpinäkyvyys epäonnistuu, kun käsittelemme sitä tyylivalintana eikä toiminnallisena vaatimuksena. Meillä on tapana kysyä: "Miltä käyttöliittymän pitäisi näyttää?" ennen kuin kysymme: "Mitä agentti todella päättää?" Päätössolmun tarkastus on suoraviivainen tapa tehdä tekoälyjärjestelmistä helpommin ymmärrettäviä. Se toimii kartoittamalla huolellisesti järjestelmän sisäisen prosessin. Päätavoitteena on löytää ja määritellä selkeästi tarkat hetket, jolloin järjestelmä lakkaa noudattamasta asetettuja sääntöjään ja tekee sen sijaan sattuman tai arvion perusteella valinnan. Kartoittamalla tämän rakenteen tekijät voivat näyttää nämä epävarmuuskohdat suoraan järjestelmää käyttäville ihmisille. Tämä muuttaa järjestelmäpäivitykset epämääräisistä lausunnoista erityisiksi, luotettaviksi raporteiksi siitä, kuinka tekoäly päätyi johtopäätökseen. Yllä olevan vakuutustapaustutkimuksen lisäksi työskentelin äskettäin hankintaagenttiryhmän kanssa. Järjestelmä tarkasteli toimittajasopimuksia ja merkitsi riskejä. Alun perin näytöllä oli yksinkertainen edistymispalkki: "Tarkastellaan sopimuksia". Käyttäjät vihasivat sitä. Tutkimuksemme osoitti, että he olivat huolissaan puuttuvan lausekkeen oikeudellisista vaikutuksista. Korjasimme tämän suorittamalla päätössolmutarkastuksen. Olen lisännyt vaiheittaisen tarkistuslistan tämän tarkastuksen suorittamista varten tämän artikkelin loppuun. Pidimme istunnon insinöörien kanssa ja esitimme, kuinka järjestelmä toimii. Tunnistimme "päätöskohdat" - hetkiä, jolloin tekoälyn oli valittava kahdesta hyvästä vaihtoehdosta. Tavallisissa tietokoneohjelmissa prosessi on selvä: jos A tapahtuu, niin B tapahtuu aina. Tekoälyjärjestelmissä prosessi perustuu usein sattumaan. Tekoälyn mielestä A on luultavasti paras valinta, mutta se voi olla vain 65 % varma. Sopimusjärjestelmästä löysimme hetken, jolloin tekoäly tarkisti vastuuehdot yhtiömme sääntöjen mukaisesti. Se oli harvoin täydellinen ottelu. Tekoälyn täytyi päättää, oliko 90-prosenttinen vastaavuus tarpeeksi hyvä. Tämä oli keskeinen päätöskohta.
Kun tunnistimme tämän solmun, paljastimme sen käyttäjälle. "Sopimusten tarkistaminen" -tekstin sijaan käyttöliittymä päivitettiin sanomaan: "Vastuulauseke poikkeaa vakiomallista. Analysoidaan riskitasoa." Tämä päivitys antoi käyttäjille luottamusta. He tiesivät, että agentti tarkisti vastuulausekkeen. He ymmärsivät syyn viivästymiseen ja saivat luottamusta siihen, että haluttu toimenpide tapahtui takapäässä. He tiesivät myös, mistä kaivautua syvemmälle, kun agentti teki sopimuksen. Jotta voit tarkistaa, kuinka tekoäly tekee päätöksiä, sinun on tehtävä tiivistä yhteistyötä insinöörien, tuotepäälliköiden, yritysanalyytikkojen ja avainhenkilöiden kanssa, jotka tekevät valintoja (usein piilossa), jotka vaikuttavat tekoälytyökalun toimintaan. Piirrä työkalun vaiheet. Merkitse jokainen paikka, jossa prosessi muuttaa suuntaa, koska todennäköisyys täyttyy. Nämä ovat paikkoja, joissa sinun tulisi keskittyä olemaan avoimempi. Kuten alla olevasta kuvasta 2 näkyy, päätössolmun tarkastus sisältää seuraavat vaiheet:
Kokoa tiimi: Tuo mukaan tuotteiden omistajat, yritysanalyytikot, suunnittelijat, keskeiset päättäjät ja tekoälyn rakentaneet insinöörit. Esimerkiksi Ajattele tuotetiimiä, joka rakentaa tekoälytyökalun, joka on suunniteltu tarkistamaan sotkuisia laillisia sopimuksia. Tiimiin kuuluu UX-suunnittelija, tuotepäällikkö, UX-tutkija, asian asiantuntijana toimiva lakimies ja tekstianalyysikoodin kirjoittanut taustainsinööri.
Piirrä koko prosessi: Dokumentoi jokainen tekoälyn vaihe käyttäjän ensimmäisestä toiminnasta lopputulokseen. Tiimi seisoo taulun ääressä ja luonnostelee koko sekvenssin keskeiselle työnkululle, jossa tekoäly etsii vastuulauseketta monimutkaisesta sopimuksesta. Lakimies lataa50-sivuinen PDF → Järjestelmä muuntaa asiakirjan luettavaksi tekstiksi. → Tekoäly etsii sivuilta vastuulausekkeita. → Käyttäjä odottaa. → Hetkeä tai minuuttia myöhemmin työkalu korostaa löydetyt kappaleet keltaisella käyttöliittymässä. He tekevät tämän monissa muissa työnkulkuissa, joihin työkalu sopii myös.
Selvitä, missä asiat ovat epäselviä: Katso prosessikartalta paikkaa, jossa tekoäly vertaa vaihtoehtoja tai syötteitä, joilla ei ole yhtä täydellistä vastinetta. Tiimi katsoo taulua havaitakseen epäselvät vaiheet. Kuvan muuntaminen tekstiksi noudattaa tiukkoja sääntöjä. Tietyn vastuulausekkeen löytäminen edellyttää arvailua. Jokainen yritys kirjoittaa nämä lausekkeet eri tavalla, joten tekoälyn on punnittava useita vaihtoehtoja ja tehtävä ennuste sen sijaan, että löydettäisiin tarkka sanavastine.
Tunnista "parhaan arvauksen" vaiheet: Tarkista jokaisen epäselvän kohdan kohdalla, käyttääkö järjestelmä luottamuspisteitä (esimerkiksi onko se 85 % varma?). Näissä kohdissa tekoäly tekee lopullisen valinnan. Järjestelmän on arvattava (anna todennäköisyys), mitkä kappaleet muistuttavat läheisesti vakiovastuulauseketta. Se antaa parhaalle arvaukselleen luottamuspisteen. Tämä arvaus on päätössolmu. Käyttöliittymän on kerrottava asianajajalle, että se korostaa mahdollista vastaavuutta sen sijaan, että se totesi löytäneensä lopullisen lausekkeen.
Tarkastele valintaa: Selvitä kunkin valintapisteen kohdalla suoritettava sisäinen matematiikka tai vertailu (esim. sopimuksen osan yhdistäminen vakuutussopimukseen tai rikkoutuneen auton kuvan vertaaminen vaurioituneiden autojen valokuvien kirjastoon). Insinööri selittää, että järjestelmä vertaa eri kappaleita aiempien yritystapausten vakiovastuulausekkeiden tietokantaan. Se laskee tekstin samankaltaisuuspisteet ja päättää osuvuuden todennäköisyyksien perusteella.
Kirjoita selkeät selitykset: Luo käyttäjälle viestejä, jotka kuvaavat selkeästi tiettyä sisäistä toimintaa, joka tapahtuu, kun tekoäly tekee valinnan. Sisällön suunnittelija kirjoittaa tietyn viestin juuri tälle hetkelle. Teksti kuuluu: Asiakirjan tekstin vertaaminen vakiolausekkeisiin mahdollisten vastuuriskien tunnistamiseksi.
Päivitä näyttö: Lisää nämä uudet selkeät selitykset käyttöliittymään ja korvaa epämääräiset viestit, kuten "Sopimusten tarkistaminen". Suunnittelutiimi poistaa yleisen Processing PDF -latauspyörän. He lisäävät uuden selityksen tilapalkkiin, joka sijaitsee aivan asiakirjan katseluohjelman yläpuolella, kun tekoäly ajattelee.
Tarkista luottamus: Varmista, että uudet näyttöviestit antavat käyttäjille yksinkertaisen syyn odotusaikaan tai tulokseen, mikä saa heidät tuntemaan olonsa itsevarmemmaksi ja luottavaisemmaksi.
Vaikutus/riskimatriisi Kun tarkastelet tekoälyn prosessia tarkasti, löydät todennäköisesti monia kohtia, joissa se tekee valinnan. Tekoäly voi tehdä kymmeniä pieniä valintoja yhtä monimutkaista tehtävää varten. Niiden kaikkien näyttäminen luo liikaa tarpeetonta tietoa. Sinun on ryhmiteltävä nämä vaihtoehdot. Voit käyttää vaikutus-/riskimatriisia lajitellaksesi nämä valinnat tekoälyn tekemien toimintotyyppien perusteella. Tässä on esimerkkejä vaikutus-/riskimatriiseista: Ensinnäkin, etsi matalapanoksisia ja vähävaikutteisia päätöksiä. Pienet panokset / pieni vaikutus
Esimerkki: Tiedostorakenteen järjestäminen tai asiakirjan uudelleennimeäminen. Läpinäkyvyyden tarve: Minimaalinen. Hienovarainen maljailmoitus tai lokimerkintä riittää. Käyttäjät voivat kumota nämä toiminnot helposti.
Tunnista sitten suuret ja vaikuttavat päätökset. Korkeat panokset / suuri vaikutus
Esimerkki: Lainahakemuksen hylkääminen tai osakekaupan toteuttaminen. Läpinäkyvyyden tarve: Suuri. Nämä toimet edellyttävät työtodistusta. Järjestelmän on osoitettava perustelut ennen toimintaa tai välittömästi sen toimiessa.
Harkitse kaupankäyntibottia, joka kohtelee kaikkia osto-/myyntimääräyksiä samalla tavalla. Se suorittaa 5 dollarin kaupan samalla läpinäkyvyydellä kuin 50 000 dollarin kauppa. Käyttäjät saattavat kyseenalaistaa, tunnistaako työkalu läpinäkyvyyden mahdollisen vaikutuksen kaupankäyntiin suurella dollarisummalla. He tarvitsevat järjestelmän pysähtymään ja näyttämään työnsä korkean panoksen kaupoissa. Ratkaisu on ottaa käyttöön Review Logic -tila jokaiselle tietyn dollarin summan ylittävälle tapahtumalle, jolloin käyttäjä voi nähdä päätöksen taustalla olevat tekijät ennen suorittamista. Solmujen yhdistäminen kuvioihin: Suunnittelukuvion valintarubriiki Kun olet tunnistanut kokemuksesi keskeiset päätössolmut, sinun on päätettävä, mikä käyttöliittymämalli koskee jokaista näytettävää solmua. Designing For Agentic AI -osiossa otimme käyttöön malleja, kuten Intent Preview (korkeiden panosten ohjaamiseen) ja Action Audit (taannehtivaan turvallisuuteen). Ratkaiseva tekijä valittaessa niiden välillä on käännettävyys. Suodatamme jokaisenpäätössolmu vaikutusmatriisin kautta oikean mallin osoittamiseksi: Korkeat panokset ja peruuttamattomat: Nämä solmut vaativat Intent-esikatselun. Koska käyttäjä ei voi helposti peruuttaa toimintoa (esim. tietokannan pysyvää poistamista), läpinäkyvyyshetken on tapahduttava ennen suoritusta. Järjestelmän on keskeytettävä, selitettävä tarkoituksensa ja vaadittava vahvistus. Korkeat panokset ja käännettävä: Nämä solmut voivat luottaa Action Audit & Undo -malliin. Jos tekoälyllä toimiva myyntiedustaja siirtää liidin toiseen putkiin, se voi tehdä sen itsenäisesti, kunhan se ilmoittaa käyttäjälle ja tarjoaa välittömän Kumoa-painikkeen. Luokittelemalla solmut tiukasti tällä tavalla vältämme "valpaavan väsymyksen". Varaamme suuren kitkan Intent Previewin vain todella peruuttamattomia hetkiä varten, kun taas luotamme Action Auditiin ylläpitämään nopeutta kaikessa muussa.
Käännettävä Peruuttamaton Pieni vaikutus Tyyppi: Auto-ExecuteUI: Passiivinen Toast / LogEx: Tiedoston uudelleennimeäminen Tyyppi: ConfirmUI: Yksinkertainen kumoamisvaihtoehtoEsim: Sähköpostin arkistointi Suuri vaikutus Tyyppi: ReviewUI: Ilmoitus + Tarkista TrailEx: Luonnoksen lähettäminen asiakkaalle Tyyppi: Intent previewUI: Modal / Explicit PermissionEx: Palvelimen poistaminen
Taulukko 1: Vaikutus- ja käännettävyysmatriisia voidaan sitten käyttää kartoittamaan läpinäkyvyyden hetkiä suunnittelumalleihin. Laadullinen validointi: "Odota, miksi?" Testaa Voit tunnistaa mahdolliset solmut taululta, mutta sinun on vahvistettava ne ihmisen käytöksellä. Sinun on tarkistettava, vastaako karttasi käyttäjän henkistä mallia. Käytän protokollaa nimeltä "Odota, miksi?" Testata. Pyydä käyttäjää katsomaan, kuinka agentti suorittaa tehtävän. Neuvo heitä puhumaan ääneen. Aina kun he kysyvät: "Odota, miksi se teki niin?" tai "Onko se jumissa?" tai "Kuuliko se minua?" - merkitset aikaleiman. Nämä kysymykset osoittavat käyttäjien hämmennystä. Käyttäjä kokee kontrollinsa karkaavan. Esimerkiksi terveydenhuollon aikatauluavustajaa koskevassa tutkimuksessa käyttäjät katselivat agentin varaavan tapaamisen. Näyttö pysyi paikallaan neljän sekunnin ajan. Osallistujat kysyivät jatkuvasti: "Tarkistaako se minun kalenteria vai lääkärin?"
Tämä kysymys paljasti puuttuvan Transparency Momentin. Järjestelmän piti jakaa tämä neljän sekunnin odotus kahteen erilliseen vaiheeseen: "Tarkistaa saatavuus" ja "Synkronoi palveluntarjoajan aikataulun kanssa". Tämä pieni muutos vähensi käyttäjien ilmaistua ahdistustasoa. Läpinäkyvyys epäonnistuu, kun se kuvaa vain järjestelmän toimintaa. Käyttöliittymän tulee yhdistää tekninen prosessi käyttäjän tiettyyn tavoitteeseen. Näyttö, jossa näkyy "Tarkistaa saatavuuttasi", kaatuu, koska sillä ei ole kontekstia. Käyttäjä ymmärtää tekoälyn katsovan kalenteria, mutta ei tiedä miksi. Meidän on yhdistettävä toiminta lopputulokseen. Järjestelmän on jaettava tämä neljän sekunnin odotus kahteen erilliseen vaiheeseen. Ensin käyttöliittymä näyttää "Tarkista kalenteristasi aukioloaikojen selvittämiseksi". Sitten se päivittyy "Synkronoidaan palveluntarjoajan aikataulun kanssa tapaamisen turvaamiseksi". Tämä perustaa teknisen prosessin käyttäjän todelliseen elämään. Harkitse tekoälyn hallintaa paikalliseen kahvilaan. Järjestelmässä on tarjontapula. Käyttöliittymä, jossa lukee "yhteydenotto toimittajaan" tai "vaihtoehtojen tarkistaminen", aiheuttaa ahdistusta. Johtaja ihmettelee, peruuttaako järjestelmä tilauksen tai ostaako kalliin vaihtoehdon. Parempi tapa on selittää aiottu tulos: "Arvioimalla vaihtoehtoisia toimittajia perjantain toimitusaikataulun säilyttämiseksi." Tämä kertoo käyttäjälle tarkalleen, mitä tekoäly yrittää saavuttaa. Tarkastuksen operatiivistaminen Olet suorittanut päätössolmutarkastuksen ja suodattanut luettelosi vaikutus- ja riskimatriisin kautta. Sinulla on nyt luettelo tärkeistä hetkistä läpinäkyvyyden kannalta. Seuraavaksi sinun on luotava ne käyttöliittymässä. Tämä vaihe vaatii tiimityötä eri osastojen kesken. Et voi suunnitella läpinäkyvyyttä itse suunnittelutyökalulla. Sinun on ymmärrettävä, miten järjestelmä toimii kulissien takana. Aloita logiikkakatsauksella. Tapaa johtava järjestelmäsuunnittelijasi. Tuo karttasi päätössolmuista. Sinun on varmistettava, että järjestelmä voi todella jakaa nämä tilat. Huomaan usein, että tekninen järjestelmä ei paljasta tarkkaa tilaa, jonka haluan näyttää. Insinööri saattaa sanoa, että järjestelmä vain palauttaa yleisen "toimivan" tilan. Sinun on vaadittava yksityiskohtaista päivitystä. Tarvitset järjestelmän lähettääksesi erityisen ilmoituksenkun se vaihtaa tekstin lukemisesta sääntöjen tarkistamiseen. Ilman tätä teknistä yhteyttä suunnitteluasi on mahdoton rakentaa. Ota seuraavaksi mukaan sisällönsuunnittelutiimi. Sinulla on tekninen syy tekoälyn toiminnalle, mutta tarvitset selkeän, ihmisystävällisen selityksen. Insinöörit tarjoavat taustalla olevan prosessin, mutta sisällön suunnittelijat tarjoavat tavan, jolla se viestitään. Älä kirjoita näitä viestejä yksin. Kehittäjä saattaa kirjoittaa "Executing function 402", joka on teknisesti oikein, mutta käyttäjälle merkityksetön. Suunnittelija saattaa kirjoittaa "Thinking", mikä on ystävällistä mutta liian epämääräistä. Sisältöstrategi löytää oikean keskitien. Ne luovat erityisiä lauseita, kuten "Vastausriskien tarkistus", jotka osoittavat, että tekoäly toimii hämmentämättä käyttäjää. Testaa lopuksi viestiesi läpinäkyvyys. Älä odota, kunnes lopullinen tuote on rakennettu nähdäksesi, toimiiko teksti. Teen vertailutestejä yksinkertaisille prototyypeille, joissa ainoa asia, joka muuttuu, on tilaviesti. Esimerkiksi näytän yhdelle ryhmälle (ryhmä A) viestin, jossa lukee "Varmistaa henkilöllisyyttä" ja toiselle ryhmälle (Ryhmä B) viestin, jossa lukee "Tarkistaa valtion tietokantoja" (nämä ovat keksittyjä esimerkkejä, mutta ymmärrät asian). Sitten kysyn heiltä, kumpi tekoäly tuntuu turvallisemmalta. Huomaat usein, että tietyt sanat aiheuttavat huolta, kun taas toiset rakentavat luottamusta. Sinun on kohdeltava sanamuotoa sellaisena, jota sinun on testattava ja osoitettava tehokkaaksi. Kuinka tämä muuttaa suunnitteluprosessia Näiden tarkastusten tekeminen voi vahvistaa ryhmän yhteistyötä. Lopetamme kiillotettujen suunnittelutiedostojen luovuttamisen. Alamme käyttää sotkuisia prototyyppejä ja jaettuja laskentataulukoita. Ydintyökalusta tulee läpinäkyvyysmatriisi. Insinöörit ja sisällönsuunnittelijat muokkaavat tätä laskentataulukkoa yhdessä. Ne yhdistävät tarkat tekniset koodit sanoihin, joita käyttäjä lukee. Joukkueet kokevat kitkaa logiikan tarkastelun aikana. Kuvittele suunnittelija, joka kysyy insinööriltä, kuinka tekoäly päättää hylätä kuluraportissa esitetyn tapahtuman. Suunnittelija saattaa sanoa, että taustaohjelma tulostaa vain yleisen tilakoodin, kuten "Virhe: Puuttuvat tiedot". Suunnittelija toteaa, että tämä ei ole näytöllä näkyvä tieto. Suunnittelija neuvottelee insinöörin kanssa tietyn teknisen koukun luomiseksi. Insinööri kirjoittaa uuden säännön, jotta järjestelmä raportoi tarkalleen, mitä puuttuu, kuten puuttuvan kuitin kuvan. Sisällön suunnittelijat toimivat kääntäjinä tässä vaiheessa. Kehittäjä saattaa kirjoittaa teknisesti tarkan merkkijonon, kuten "Toimittajan vastaavuuden luottamuskynnyksen laskeminen". Sisällön suunnittelija kääntää tämän merkkijonon lauseeksi, joka rakentaa luottamusta tiettyyn tulokseen. Strategi kirjoittaa sen uudelleen seuraavasti: "Paikallisten myyjien hintojen vertailu varmistaaksesi perjantain toimituksen." Käyttäjä ymmärtää toiminnan ja tuloksen. Koko monitoimitiimi osallistuu käyttäjien testausistuntoihin. He katsovat, kuinka todellinen henkilö reagoi erilaisiin tilaviesteihin. Kun näkee käyttäjän paniikin, koska näytössä lukee "Toteutetaan kauppa", tiimin on harkittava uudelleen lähestymistapaansa. Insinöörit ja suunnittelijat sopivat parempaan sanamuotoon. He muuttavat tekstiksi "Tarkistaa riittävästi varoja" ennen osakkeiden ostamista. Yhdessä testaaminen takaa, että lopullinen käyttöliittymä palvelee sekä järjestelmän logiikkaa että käyttäjän mielenrauhaa. Näiden lisätoimintojen sisällyttäminen joukkueen kalenteriin vie aikaa. Lopputuloksena pitäisi kuitenkin olla tiimi, joka kommunikoi avoimemmin, ja käyttäjät, jotka ymmärtävät paremmin, mitä heidän tekoälykäyttöiset työkalunsa tekevät heidän puolestaan (ja miksi). Tämä integroitu lähestymistapa on kulmakivi todella luotettavien tekoälykokemusten suunnittelussa. Luottamus on suunnittelun valinta Pidämme luottamusta usein hyvän käyttäjäkokemuksen emotionaalisena sivutuotteena. Luottamusta on helpompi nähdä ennakoitavan viestinnän mekaanisena tuloksena. Rakennamme luottamusta näyttämällä oikeaa tietoa oikeaan aikaan. Tuhoamme sen ylikuormittamalla käyttäjä tai piilottamalla koneiston kokonaan. Aloita Decision Node Auditista, erityisesti agenttien tekoälytyökalujen ja -tuotteiden osalta. Etsi hetkiä, jolloin järjestelmä tekee tuomion. Kartoita nämä hetket riskimatriisiin. Jos panokset ovat korkeat, avaa laatikko. Näytä työ. Seuraavassa artikkelissa tarkastellaan, kuinka suunnitella nämä hetket: kuinka kirjoittaa kopio, jäsentää käyttöliittymä ja käsitellä väistämättömiä virheitä, kun agentti tekee virheen. Liite: Päätössolmun tarkastuksen tarkistuslista Vaihe 1: Asennus ja kartoitus ✅ Kokoa tiimi: Tuo mukaan tuotteiden omistajat, yritysanalyytikot, suunnittelijat,tärkeimmät päättäjät ja tekoälyn rakentaneet insinöörit. Vihje: Tarvitset insinöörejä selittämään todellisen taustajärjestelmän logiikan. Älä yritä tätä vaihetta yksin. ✅ Piirrä koko prosessi: Dokumentoi jokainen tekoälyn vaihe käyttäjän ensimmäisestä toiminnasta lopputulokseen. Vihje: Fyysinen taulun istunto toimii usein parhaiten näiden alkuvaiheiden piirtämiseen. Vaihe 2: Piilotetun logiikan paikantaminen ✅ Etsi paikat, joissa asiat ovat epäselviä: Katso prosessikartalta paikkaa, jossa tekoäly vertaa vaihtoehtoja tai syötteitä, joilla ei ole yhtä täydellistä vastinetta. ✅ Tunnista parhaat arvausvaiheet: Tarkista jokaisen epäselvän kohdan kohdalla, käyttääkö järjestelmä luottamuspisteitä. Kysy esimerkiksi, onko järjestelmä 85 prosenttia varma. Näissä kohdissa tekoäly tekee lopullisen valinnan. ✅ Tarkastele valintaa: Selvitä jokaiselle valintapisteelle tietty sisäinen matematiikka tai vertailu. Esimerkkinä sopimuksen osan yhdistäminen vakuutukseen. Toinen esimerkki on rikkinäisen auton kuvan vertaaminen vaurioituneiden autojen valokuvien kirjastoon. Vaihe 3: Käyttäjäkokemuksen luominen ✅ Kirjoita selkeät selitykset: Luo käyttäjälle viestejä, jotka kuvaavat selkeästi tiettyä sisäistä toimintaa, joka tapahtuu, kun tekoäly tekee valinnan. Vihje: Maadoi viestisi konkreettiseen todellisuuteen. Jos tekoäly varaa tapaamisen asiakkaan kanssa paikallisessa kahvilassa, kerro käyttäjälle, että järjestelmä tarkistaa kahvilan varausjärjestelmää. ✅ Päivitä näyttö: Laita nämä uudet selkeät selitykset käyttöliittymään. Korvaa epämääräiset viestit, kuten sopimusten tarkistaminen, erityisillä selityksilläsi. ✅ Tarkista luottamus: Varmista, että uudet näytön viestit antavat käyttäjille yksinkertaisen syyn odotusaikaan tai tulokseen. Tämän pitäisi saada heidät tuntemaan itsevarmuutta ja luottamusta. Vihje: Testaa näitä viestejä todellisten käyttäjien kanssa varmistaaksesi, että he ymmärtävät saavutettavan tuloksen.
