Kuka varmistaa asiakaskokemuksen laadun, kun AI-agentit tuottavat koodia vauhdilla?

Järjestimme eilen webinaarin aiheesta “Miten UX/UI-suunnittelusi pysyy AI:n vauhdissa?”, ja linjoilla olikin aamuvarhain peräti 136 henkeä. Kiitos kaikille osallistujille ja erityisesti Q&A-osuudessa kysymyksiä esittäneille! Osallistujamäärä ja palaute webinaarin jälkeen kertovat, että tämä teema on monessa organisaatiossa nyt pöydällä. Kokosin tähän webinaarin pääviestit niille, jotka eivät päässeet mukaan, ja niille, jotka haluavat viedä keskustelun omaan johtoryhmäänsä.

DesignOps-työkalupakkimme avulla olemme viimeisen viiden vuoden aikana olleet kehittämässä design-toiminnan malleja erilaisissa organisaatioissa: kansainvälisistä teknologiakorporaatioista pienempiin SaaS-tuotetaloihin, startupeista usean miljardin euron arvoiseen ohjelmistoyksisarviseen, tarkoituksena kasvattaa sisäisen design-työn vaikutusta yrityksen liiketoimintaan. Parin viime vuoden aikana useassa näistä yrityksistä on noussut esiin tarve saada design-työ tehokkaammin kytkettyä AI-avusteisesti jo jollain tasolla tapahtuvaan ohjelmistokehitykseen.

Näistä kokemuksista ja opeista kokosimme webinaariin ajatuksia tuotejohtajille ja tuotekehityksen vetäjille. UX/UI designereitakin oli mukana useita kymmeniä, vaikka webinaari ei ollutkaan varsinaisesti mikään AI-design-työkalujen masterclass. Design on monessa tuoteyrityksessä edelleen liiketoiminnan kasvattamisen näkökulmasta alihyödynnetty funktio. Nyt kun tapa suunnitella ja rakentaa ohjelmistoja on AI:n myötä muuttumassa nopeasti, design-tekemisenkin malleja kannattaa miettiä uudelleen.

Voit katsoa webinaarin tallenteen täältä.

Koodi syntyy jo puoliksi agenteilla

Tämän vuoden kehittäjätutkimusten luvut ovat selviä. JetBrainsin mukaan noin 47 prosenttia koodista on jo agenttien kirjoittamaa. Stack Overflow’n kyselyssä agentteja päivittäin käyttävien kehittäjien osuus nousi vuodessa 14 prosentista 37 prosenttiin. Alueelliset erot ovat suuria: Itä-Aasiassa noin joka kolmas kehittäjä tuottaa yli 80 prosenttia koodistaan agenteilla, Euroopassa vain noin joka kuudes.

Kiinnostavin luku on kuitenkin tämä: Sonarin tutkimuksen mukaan 96 prosenttia kehittäjistä ei luota AI:n tuottamaan koodiin täysin. Koodia syntyy valtavasti lisää, ja lähes kaikki sen tekijät sanovat, että se tulee tarkistaa. Ohjelmistokehityksessä tähän on vuosikymmenten käytännöt: testit, katselmoinnit ja julkaisuputket.

Samat agentit alkavat nyt tuottaa myös käyttöliittymiä, tekstejä ja kaikkea muuta, minkä asiakas näkee ja kokee. Mitkä ovat vastaavat käytännöt hyvän asiakaskokemuksen kehittämisen puolella? Useimmissa organisaatioissa niitä ei vielä ole.

Kysymys ei siis ole enää se, käytetäänkö AI:ta. Kysymys on, kuka varmistaa asiakaskokemuksen laadun, käytettävyyden ja brändin.

Mitä asiakkaamme kertovat

Kuulemme samansuuntaisia huolia tai pohdintoja viikoittain. Ne voi niputtaa kolmeen ryhmään.

1. Suunta. Kun koodi valmistuu päivissä, perinteinen UX/UI designin tekeminen saattaa alkaa tuntua hidasteelta, joten se saatetaan ohittaa. Asiakkaiden kuuntelu jää väliin, koska tuntuu nopeammalta vain rakentaa. Lopputuloksena väärää asiaa rakennetaan nopeammin kuin koskaan.
2. Yhtenäisyys. Kehittäjien AI-agentit eivät tunne design systeemiä eivätkä brändiohjetta, ellei näitä ole niille opetettu ja käsketty noudattaa. Jokainen tiimi tuottaa omannäköistään jälkeä yrityksen tuotteista ja palveluista verkkosivuihin ja myyntiesityksiin. Sama koskee saavutettavuutta, joka on monella alalla lakisääteinen vaatimus.
3. Omistajuus. Kun tuotepäällikkö, kehittäjä ja markkinoija voivat kohta kaikki tuottaa käyttöliittymiä, asiakkaan päästä-päähän polku jää usein ilman omistajaa. Näkymiä syntyy enemmän kuin kukaan ehtii niiden laatua arvioida, ja koska uusien ominaisuuksien synnyttäminen on halpaa, niitä on helppo tehdä liikaa. Lasku tulee tukipyyntöinä ja asiakaspoistumana.

Yksikään näistä asioista ei johdu siitä, että AI olisi huono kehityskulku. Ne johtuvat siitä, että ohjelmistojen kehitystyö on nopeutumassa, mutta asiakaskokemuksen rakentamisen ohjaus, perusta ja vastuut ovat jääneet entiselleen.

Viisi tasoa — missä sinun organisaatiosi on?

Käytämme asiakasorganisaatioiden design-toimintojen ja -vaikuttavuuden kehittämisen asiakastyössä DesignOps-maturiteettimalliamme, jonka jokin aika sitten päivitimme AI-natiiviin aikaan. Ensimmäisellä tasolla design systeemi on designerien Figmaan rakentama tyyliopas designereille, ja ohjelmistokehittäjä toteuttaa sen avulla suunnitellun käyttöliittymän uudelleen käsin. Ylimmällä tasolla AI-agentit tuottavat käyttöliittymäkoodia itsenäisesti, design systeemi on agenteille sääntö eikä suositus, ja design lead omistaa käyttökokemuksen laadun samaan tapaan kuin arkkitehti omistaa ohjelmiston teknisen laadun. Eri organisaatiot sijoittuvat kypsyysmallin eri tasoille, ja eri yksiköt tai tiimit ison organisaation sisällä samaten. Useimmat asiakkaamme ovat tasoilla yhdestä kolmeen, ja osa tiimeistä kokeilee jo tasoa neljä.

Ylin taso ei realistisesti ole kaikkien tavoite. Jos yrityksellä on tuoteportfoliossaan paljon vanhaa ohjelmistoriippuvuutta tai se toimii tiukasti reguloidussa ympäristössä, ylimmälle tasolle ei päästä lyhyellä aikavälillä, eikä tarvitsekaan. Olennaista on tietää oma taso ja seuraava askel.

Nopeus syntyy virtauksessa, laatu perustassa

Toimivassa AI-avusteisessa design-mallissa työ etenee viiden vaiheen virtauksena: asiakasymmärrys > prototypointi suoraan koodissa > validointi oikeilla käyttäjillä > toteutus tuotantoon > mittaaminen. Opit työvaiheista palaavat seuraavaan kierrokseen. Ajatus on tuttu jo Lean Startupin Build, Measure, Learn -mallista, mutta uutta usean organisaation nykytilaan verrattuna on se, että kierros kestää päiviä eikä kuukausia.

Moni saattaa ajatella, että hyvä asiakaskokemus syntyy antamalla ohjelmistokehittäjille tarpeeksi AI-tokeneita. Ei synny. Kollegani Heikki Salo vertasi webinaarissa AI-agentteja armeijaan kyvykkäitä harjoittelijoita, jotka eivät tiedä sinusta ja kontekstistasi juuri mitään. Pyydät heitä rakentamaan mökin, ja aluksi kaikki näyttää hyvältä. Sitten huomaat, että katolle kaadetaan betonia, yksi ryhmä on aloittanut pilvenpiirtäjän rakentamisen lisäsiipeen, eikä takaovea ole lainkaan.

Siksi virtauksen alla tarvitaan yhteinen perusta, jossa on kolme osaa:

1. Koneluettava design systeemi: tokenit ja komponentit muodossa, jota agentti osaa käyttää.
2. Agenttien design-ohjeistus: brändi, sisältö ja saavutettavuus kirjoitettuina säännöiksi.
3. Guardrailit ja tarkistuspisteet: kuka hyväksyy mitä ja missä vaiheessa.

Kun harjoittelijoilla on käytössään talonrakennuksen säännöt, jokaisen uuden aloituksen ei tarvitse olla arpapeliä. Brändiohje PDF:nä palvelee ihmisiä. Tokeneina ja sääntöinä se palvelee myös agentteja.

Kokeile halvalla, toteuta hallitusti

Käytännössä näemme kaksi toimivaa mallia UX/UI designin viemiseen AI-natiiviin aikaan. Näitä soveltamalla organisaation, tuoteportfolion ja teknologiastacki(e)n reunaehtojen puitteissa on mahdollista pystyttää selkeä ja tehokas AI-yhteensopiva hyvän käyttökokemuksen suunnittelun ja rakentamisen prosessi. Ensimmäisessä designereilla on oma protoiluympäristö, joka on täysin irrallaan tuotantokoodista. Siellä kokeillaan vaihtoehtoja nopeasti realistisella mutta keksityllä datalla, ja vasta käyttäjillä validoitu ratkaisu siirtyy tuotantoketjuun. Malli sopii erityisesti organisaatioille, joissa tuotantokoodi on riskialtista, kuten esim. tietoturvayhtiöille.

Toisessa mallissa design-muutokset tehdään suoraan tuotantokoodiin, erillisessä työhaarassa ja turvarajojen sisällä. Se edellyttää luotettua ja testattua kehitysympäristöä, ja iterointi on hitaampaa laajemman laadunvarmistuksen vuoksi. Kummassakin mallissa sama periaate pätee: tuotantokoodiin tasolle edetään vasta, kun ratkaisu on validoitu.

Kun rakentaminen on halpaa, kallein virhe on rakentaa väärä asia

Nokian design-yksikön filosofia 20 vuoden takaa kuului: ensin havainnoidaan, sitten suunnitellaan (first we observe, then we design). Se pätee nyt paremmin kuin koskaan. AI litteroi haastattelut, ryhmittelee palautteet ja rakentaa testattavan prototyypin päivässä. Se ei kuitenkaan ole koskaan nähnyt, kun käyttäjä epäröi painikkeen kohdalla. Sen näkee vain kokenut ihminen, joka istuu vieressä. Asiakasymmärys ei kerry eikä sitä hyödynnetä, jos johtoryhmä olettaa designin tekemisen tarkoittavan vain käyttöliittymä-näkymien tuottamista koodauksen AI-promptauksen sivutuotteena. Designia ja designerin osaamista tarvitaan.

Synteettisiä käyttäjiä tarjotaan nyt oikotieksi käyttäjien ymmärtämisessä. Ne kertovat vain sen, mikä jo tiedetään. Yllätykset löytyvät oikeita asiakkaita ja käyttäjiä havainnoimalla, ja juuri yllätyksistä voi syntyä seuraava kilpailuetu.

Nostan pari esimerkkiä omista viimeaikaisista asiakasprojekteistamme. Yhdessä tavoitteena oli, että yrityksen B2B-myyjä pystyy rakentamaan riittävän hyviä prototyyppejä asiakkaan toivomuksia vastaan, esitelläkseen niitä omissa asiakastapaamisissaan. Toisessa designerimme rakensi itselleen AI-agentin, joka visualisoi uusien palveluiden asiakaspolkuja sarjakuvina. Polkujen tuottaminen nopeutui, ja niistä keskusteleminen organisaation sisällä helpottui selvästi.

Huomaa, että kummassakaan designerin tarve ei kadonnut. Hänen roolinsa muuttui: hän suunnitteli ja rakensi välineet, joilla muut pääsevät näkemään ja tekemään, ja omisti sen, että lopputulos palvelee asiakasta. Asiakas ei näe organisaatiokaaviotanne eikä ole siitä kiinnostunut. Hän näkee ja kokee yhden asiakaspolun, joka kulkee markkinoinnin, myynnin, tuotteen ja asiakaspalvelun läpi, ja jonkun pitää omistaa se kokonaisuutena.

Mitä mitata

Kun agentit tuottavat enemmän kuin kukaan ehtii katselmoida, laatua on mitattava. Suosittelemme yhtä mittaria kullekin kolmelle tasolle: virtaukselle esimerkiksi läpimenoaika ideasta käyttäjätestiin, perustan laadulle design systeemin komponenttien käyttöaste koodissa ja vaikutukselle käyttäjän tehtävän onnistumisaste tai asiakkailta tulevien tukipyyntöjen määrä. Kolme lukua, joita johtoryhmä oikeasti seuraa, on enemmän kuin kolmekymmentä, joita ei katso kukaan.

Muutama varoituksen sana: AI:lla tuotettujen näkymien määrää ei kannata mitata, koska enemmän ei enää kerro paremmuudesta. Ja muistakaa mitata lähtötaso ennen muutosta, sillä muuten puolen vuoden päästä kukaan ei pysty osoittamaan, mitä AI-investointi tuotti.

Kolme kysymystä johtoryhmälle

Designereita ei tarvita vähemmän, mutta heiltä tarvitaan eri asioita AI-työkalujen aikakaudella. Suunnittelutyön painopiste siirtyy käyttöliittymien näkymien piirtämisestä asiakasymmärryksen keräämiseen eri lähteistä ja sen analysointiin, tuotesuunnittelun teknisen perustan rakentamiseen esim. koneluettavan design systeemin muodossa ja laadunvarmistukseen. Tämä muuttaa sen, millaisella profiililla rekrytoitte designereita, miten organisoitte designin ja mitä mittaatte.

Jätimme webinaarin osallistujille kolme kysymystä, ja jätän ne myös sinulle:

1. Kuka teillä omistaa design systeemin ja AI-agenttien design-ohjeistuksen?
2. Kuka hyväksyy agentin tuottaman käyttöliittymän ennen tuotantoon menoa?
3. Miten juniorinne kasvavat senioreiksi, kun rutiinityö siirtyy AI:lle?

Jos johonkin näistä ei löydy nimeä tai vastausta, me voimme auttaa teitä muodostamaan teidän organisaatioonne ja liiketoimintaanne sopivan ensimmäisen käsityksen.

Tunnin maksuton AI DesignOps -konsultaatio

Tarjoamme organisaatioille tunnin maksuttoman AI DesignOps -konsultaation. Käymme läpi, miten UX/UI design -työ organisaatiossanne nyt toimii, tunnistamme maturiteettitasonne ja tekemisen kipupisteet, sekä ehdotamme seuraavat toiminnan kehittämisen askeleet. Tunnin jälkeen teillä on selkeämpi kuva, vaikka ette jatkaisi kanssamme. Eilisen webinaarin jälkeen näitä tapaamisia on buukattu jo useita loka-marraskuulle.

Lähetä viesti osoitteeseen harri.kiljander@alphadesignpartners.com tai soita 040 5060 007 ja löydetään kalentereista sopiva aika.

Harri Kiljander / Alpha Design Partners

P.S. kokosimme tuotejohtajalle, tuotekehityksen vetäjälle ja UX/UI designerille muutaman kirjan ja blogin suosituksen syysloman lukuhetkeen. Nämä mielestämme selkeästi käsittelevät relevantteja kysymyksiä ja vastauksia AI-aikakauden tuotesuunnittelun toimintamalleiksi.