Miksi tekoäly rikkoo tuotesuunnittelun putket – ja miten tiimit korjaavat tilanteen

Tasapäistävätkö tekoälytyökalusi huomaamatta tuotteesi UX:n tai palvelun laadun? Kun otat tekoälyn käyttöön tuotteen työnkuluissa, suurin riski ei ole se, että tekoäly rikkoo suunnittelusi. Se voi kuitenkin vähitellen tasoittaa sen keskinkertaiseksi.

Annoin neljälle huippumallille esimerkin Google Labsin DESIGN.md-tiedostosta ja pyysin niitä luomaan ”seuraava”-nuolen koossa 44 × 44 ja 88 × 88 px. Kaikki neljä noudattivat jokaista määrittelyn tokenia: väriä, viivan paksuutta, päätteitä, liitoksia, piirtoaluetta ja täytteen puuttumista. Ne olivat myös yhtä mieltä kahdesta asiasta, joita määrittely ei koskaan maininnut: nuolenkärjen kulmasta ja viivan päiden käsittelystä.

Katso Google julkaisema DESIGN.md, suunnittelusääntöjen muoto.

Tämä ei ole vertailutesti, mutta se havainnollistaa ongelmaa: määrittely voi olla riittävän kattava läpäisemään vaatimustenmukaisuustestit ja silti jättää mallin täyttämään aukot. Mallit täyttävät ne kaiken koulutusdatassaan näkemänsä keskiarvolla.

Miksi tekoälyohjattua UX-ajautumista on vaikea havaita

Kuvakekoe oli osa omaa projektiani, jossa testasin oman UX-materiaalini luomista ja käsittelyä. Asetin itselleni tiukat UX- ja palvelumuotoilutavoitteet, joita en saanut suunnitella pois – aivan kuten et voisi suunnitella pois asiakkaan keskeisiä vaatimuksia. Lisäsin siihen tarkoituksella epätavallisia vuorovaikutusmalleja: kolme päällekkäistä navigointimallia, hallintaelementtejä, jotka ilmestyvät vasta tiettyjen tapahtumien jälkeen, sekä edestakaisin liikkumista, joka muuttuu kontekstin mukaan – asioita, jotka eivät oletukseni mukaan esiinny koulutusdatassa kovin hyvin.

Oletin, että erikoiset mallit olisivat vaikeita toteuttaa tekoälyn avulla. Ne eivät olleet, mutta niiden säilyttäminen ennallaan oli lähes mahdotonta.

Muutamassa viikossa epätavalliset mallit muuttuivat huomaamatta tavanomaisiksi. Perusteella valitsemaani sanamuotoa ”parannettiin” irrallisen virheenkorjauksen yhteydessä. Kollega törmäsi samaan ilmiöön toisesta suunnasta: aiemmin toimineen design systemin uudelleenkäyttö alkoi tuottaa pikselipoikkeamia, outoa sijoittelua ja hienovaraisia muutoksia äänensävyyn.

Mikään tästä ei näkynyt testeissä, koska mikään ei ollut rikki. Kaikki vain liikkui muutaman asteen kohti keskiarvoa.

Mekanismi ei ole mysteeri. Tekoäly koulutetaan tavanomaisilla asioilla, joita koulutusmateriaalissa on runsaasti. Teknisessä työssä se on useimmiten lahja – mutta tuotesuunnittelussa lähes päinvastoin. Suurin osa siitä, mikä tekee tuotteesta rahoittamisen arvoisen, on se osa, joka ei ole vielä tavanomaista eikä varmasti saatavilla koulutusdatassa laajassa mittakaavassa.

Miksi ihmisen tekemä tarkastus ei havaitse tekoälyn aiheuttamaa ajautumista

Tässä on kohta, jota en mieluiten kirjoittaisi. Tämä ei tapahtunut selkäni takana. Työkalu näytti minulle diff-näkymän jokaisesta muutoksesta ja pyysi lupaa. Luin ne. Hyväksyin ne kaikki.

Tätä kannattaa pysähtyä pohtimaan, sillä vakiovastaus kaikkeen edellä mainittuun on: ”Ei ongelmaa, ihminen tarkastaa tuotoksen ja kantaa vastuun.” Minä olin se ihminen, tunsin tavoitteeni ja tarkastin muutokset – pitäisikö minun ehkä erottaa itseni testiprojektistani? Vai onko asiaan muita näkökulmia?

Diff on erinomainen väline, eikä sitä pidä syyttää tästä. Diff toimii parhaiten, kun muutoksen laajuus on rajattu tai hyvin määritelty: vaikutukset ovat enimmäkseen paikallisia, ja ei-paikalliset vaikutukset tehdään näkyviksi koodauskäytännöllä tai epäonnistuvalla testillä. Myös koodin ja ohjelmistokehitystyön ympärillä oleva työskentelysilmukka on hyvin tiivis. Nämä tekijät selittävät, miksi kehittäjät omaksuivat tekoälyavun niin nopeasti.

Muutos tuotteeseen liittyvään oletukseen ei ole samalla tavalla paikallinen. Muuta yksi virke positiointidokumentin alussa, ja kaiken sen alapuolella olevan merkitys voi muuttua, vaikka teksti pysyy samana. Muuta palvelun työnkulun sääntöä, ja seuraus tulee näkyviin kolme vaihetta myöhemmin – jonkun toisen asiakaspolussa. Meiltä puuttuvat työkalut ja käytännöt, joilla tämänkaltaiset tekoälyn tekemät muutokset havaitaan.

En siis ehkä lukenut huolimattomasti. Etsin oikeaa kohdetta, mutta väärässä muodossa. Luin sanat, mutta en huomannut merkitystä. Muutosten määrä hoitaa loput.

Olemme toteuttaneet tämän kokeen monta kertaa ilman tekoälyä, ja tiedämme, miten siinä käy. Varhaiset virustorjuntaohjelmat ilmoittivat kaikesta tekemästään, koska käyttäjien ”piti tietää, että tietoturva toimii”. Käyttäjät oppivat sen sijaan reagoimaan automaattisesti sulkemalla valintaikkunat – myös sen poikkeavan, joka olisi ollut tärkeä. Verkkomainonta opetti saman asian käänteisesti: kun jokin on bannerin muotoinen, ihmiset lakkaavat näkemästä sitä. Inhimillisiä tekijöitä käsittelevä tutkimuskirjallisuus on sanonut tämän automaatiosta jo vuosien ajan – Parasuraman ja Manzey havaitsivat, että automaatioharha ja liiallinen luottamus automaatioon riippuvat ihmisestä, tilanteesta ja järjestelmästä, eivätkä ohjeet ja koulutus yksin poista niitä. NISTin tekoälyriskiohjeistus pyytääkin tiimejä tarkastelemaan, miten tuotokset *esitetään*, ja hyödyntämään inhimillisten tekijöiden asiantuntemusta.

Lähteet:

Parasuraman & Manzey: Complacency and Bias in Human Use of Automation: An Attentional Integration

NISTin tekoälyriskiohjeistus

Mikään tästä ei tarkoita, että ihmiset olisivat huolimattomia tai että tarkastus epäonnistui ja heidät pitäisi kouluttaa uudelleen. Tehtävä oli sen sijaan suunniteltu erilaiselle sisällölle ja ammattiryhmälle.

Miten design-toimistot työskentelevät tekoälyn kanssa

Havaintoni ei ole yksittäistapaus. Suuret design-yritykset ovat pitkälti lopettaneet väittelyn siitä, onko generoinnista hyötyä tuotesuunnittelussa ja tietotyön tehtävissä. Ne ovat siirtyneet juuri tälle uudelle alueelle. Designit rakensi Repsolille jaetun tekoälykokemuksen viitekehyksen, jossa vuorovaikutusperiaatteet muutetaan uudelleenkäytettäviksi ihmisen ja tekoälyn välisiksi malleiksi, jotta ”tiimien ei enää tarvitse aloittaa alusta”. frogin agenttipohjaisen tekoälyn pelikirja määrittelee suojakaiteet, varmennuspisteet, eskalointisäännöt, agentit, joilla on ”tehtävän suorittamiseen vaadittava vähimmäisvaltuus”, sekä jatkuvan arvioinnin kertaluonteisen arvioinnin sijaan. IDEO puolestaan on julkaissut artikkelin The case against AI-generated users, joka varoittaa pinnallisen, geneerisen ja tunteettoman ”datan” päätymisestä asiakasymmärrykseen.

Koodaa siis kontekstisi, hallitse silmukkaa ja lopeta promptien laskeminen. Olen heidän kanssaan samaa mieltä, mutta näen yhden puuttuvan näkökulman: päivittäisen työn sekä työnkulkuun tarvittavat muutokset, joilla haluttu suunta säilyy.

Viitteet: Designitin rakentama Repsol ja frogin agenttipohjaisen tekoälyn pelikirja

Lähteet: IDEO: Perustelut tekoälyn luomia käyttäjiä vastaan

Suunnittelijoille: Dokumentoi tekoälyä varten, mikä ei saa muuttua

Hyödyllinen lähtökohtainen kokonaisuus on pieni: suunnittelu- ja tuotesääntöjen, myös niiden tilanteiden, joissa ne *eivät* päde, tulisi olla aina tehtävää hoitavan agentin saatavilla. Käyttäjäpolun taustalla olevat oletukset tulisi yhdistää niistä riippuvaisiin näkymiin ja toimintoihin, samoin esimerkit hyväksyttävistä ja ei-hyväksyttävistä lopputuloksista sekä kaikki muu olennainen, joka ennen jäi uimaratakaavioiden väliin.

Tämä ei ole yhden promptin tehtävä. Agentti noudattaa vanhentunutta tarkoitusta yhtä luottavaisesti kuin tuoretta. Yksi suuri tiedosto on väärä ratkaisu, sillä brändillä, tuotevisiolla, palvelupoluilla, sisällöllä ja vuorovaikutusmalleilla on eri omistajat, ja ne muuttuvat eri tahtiin. Kaiken lähettäminen jokaisella LLM-kutsulla kuluttaa tokeneita ja hautaa alleen tärkeimmän ohjeen.

Kokeilen sen sijaan indeksiä, joka ohjaa agentin tarvittaessa polkua "widgetit → painikkeet → kytkin" pitkin, mutta ei ennen sitä. Rakennetta tärkeämpää on periaate: pienin olennainen tarkoitus juuri silloin, kun sitä tarvitaan. Varaus? Tätä on ylläpidettävä, joten sinun on osallistuttava Confluencen ja Jiran suunnittelutyöhön sekä tehtävä GitHubissa tarvittavat muutokset kehitysvaiheen aikana.

Esihenkilöille: Suunnittele ihmisen työ yhtä huolellisesti kuin prompt

Tuotteen tarkoituksen kirjaaminen vähentää ajautumista, ja tarkoituksen vaikutuksen seuranta auttaa pitämään tavoitteet ennallaan. Ajautumien arviointiin tarvitaan kuitenkin arviointinäkymä, joka on suunniteltu arviointia tekevälle ammattiryhmälle.

Suunnittelijan on oltava osa tuotetiimiä. Hänen on nähtävä visuaalisen mallin ja palvelumallin muutokset omassa kontekstissaan. Näytä palvelumuotoilijalle muuttunut oletus ja siihen liittyvät palvelupolut. Näytä tuoteomistajalle tavoite, näyttö ja kompromissi.

Anna ympäristön valvoa rutiininomaisia teknisiä rajoja itsenäisesti – suunnittelijan pyytäminen hyväksymään hänelle vieras shell-komento ei tee hänestä tietoturvan arvioijaa. Se on kuormittavaa hälyä, joka väsyttää ja vie huomion muualle. Tuotepäällikön pyytäminen hyväksymään tekstidiffi ei tarkoita, että hän olisi hyväksynyt tuotteen muutoksen.

Tämä on suunnittelu-, kehitys- ja alustatiimien yhteinen tehtävä, ja se edellyttää yhtä asiaa putkesta vastaavalta: muidenkin kuin kehittäjäroolissa toimivien on päästävä käyttämään todellista tekoälyavusteista työnkulkua pelkän lopputuloksen sijaan, ja heillä on oltava valtuudet säätää, pysäyttää tai hylätä se.

Valitse yksi työnkulku, jossa ihmiset hyväksyvät, rekonstruoivat tai korjaavat tekoälyn tuottamaa sisältöä toistuvasti. Kysy jokaiselta arvioijalta, mitä hänen on todella ymmärrettävä voidakseen hyväksyä sen. Rakenna arviointi tämän vastauksen ympärille ja mittaa, havaitseeko se mitään.

Tekoäly kehittyy jatkuvasti työn tuottamisessa. Kunkin roolin työkalujen pitäminen kehityksen tahdissa ei ole suunnittelijan ongelma, vaan putken ongelma. Tekoälyn aiheuttaman ajautumisen korjaamiseksi \[Platform Engineering -tiimien\](https://www.eficode.com/software-tooling/platform-engineering) on rakennettava arviointinäkymiä, joiden avulla tuoteomistajat näkevät tekoälyn tekemät muutokset kontekstissaan eivätkä vain tekstidiffeinä.