Anapus ažiotažo: ką dirbtinis intelektas iš tikrųjų gali duoti produkto dizainui

Šiais laikais lengva rasti kuruojamus DI įrankių sąrašus dizaineriams, sugeneruotų iliustracijų galerijas ir begalę užklausų (angl. prompt) bibliotekų. Tačiau kur kas sunkiau rasti aiškų vaizdą, kaip DI yra iš tikrųjų integruojamas į kasdienę produkto dizainerio darbo eigą – ne eksperimentams, o realiems, prasmingiems rezultatams pasiekti.

Patys praėjome šį kelią: išbandėme DI visuose pagrindiniuose dizaino proceso etapuose, nuo idėjų generavimo ir prototipų kūrimo iki vizualinio dizaino ir vartotojų tyrimų. Eidami šiuo keliu, sukūrėme paprastą, pakartojamą darbo eigą, kuri ženkliai padidina mūsų produktyvumą.

Šiame straipsnyje pasidalinsime tuo, kas jau veikia, ir aptarsime dažniausius prieštaravimus, su kuriais susidūrėme – daugelį iš jų patyrėme ir asmeniškai.

1 etapas: Idėjų generavimas be klišių

Prieštaravimas: „Kai tik paprašau DI pasiūlyti idėjų, gaunu sąrašą klišių. Jis negali sukurti tokio kūrybiško mąstymo, kokio tikimasi iš produkto dizainerio.“

Tai pagrįsta pastaba. DI nežino jūsų produkto specifikos, viso užduoties konteksto ar daugybės kitų svarbių niuansų. Akivaizdžiausias sprendimas – „sumaitinti“ jam visą turimą dokumentaciją. Tačiau tai yra dažna klaida, nes dažnai lemia dar prastesnius rezultatus: kontekstas užtvindomas nereikšminga informacija, o DI atsakymai tampa neaiškūs ir nekonkretūs.

Dabartinės kartos modeliai techniškai gali apdoroti tūkstančius žodžių, tačiau kuo ilgesnė įvestis, tuo didesnė rizika praleisti ką nors svarbaus, ypač turinį, paslėptą viduryje. Tai žinoma kaip „pamesta viduryje“ (angl. lost in the middle) problema.

Kad gautumėte prasmingus rezultatus, DI reikia ne tik daugiau informacijos – jam reikia tinkamos informacijos, pateiktos tinkamu būdu. Čia ir praverčia RAG (angl. Retrieval-Augmented Generation) metodas.

Kaip veikia RAG?

Įsivaizduokite RAG kaip išmanųjį asistentą, dirbantį su jūsų asmenine dokumentų biblioteka. Jūs įkeliate savo failus, o asistentas perskaito kiekvieną iš jų, sukurdamas trumpą santrauką – žymių rinkinį (semantines žymes), apimantį pagrindines temas, terminus, scenarijus ir sąvokas. Šios santraukos saugomos tam tikroje „kortelių kartotekoje“, vadinamoje vektorine duomenų baze.

Kai užduodate klausimą, asistentas neperskaito kiekvieno dokumento nuo pradžios iki galo. Vietoj to, jis palygina jūsų užklausą su žymėmis, paima tik pačius svarbiausius fragmentus (angl. chunks) ir siunčia juos kalbos modeliui, kad šis sugeneruotų galutinį atsakymą.

Kuo tai skiriasi nuo paprasto dokumento įmetimo į pokalbių langą?

Paaiškinkime išsamiau:

Įprasta sąveika pokalbių lange

‍Tai panašu į prašymą asistentui kiekvieną kartą, kai turite klausimą, perskaityti 100 puslapių knygą nuo pradžios iki galo. Techniškai visa informacija yra „prieš akis“, bet lengva ką nors praleisti, ypač jei tai yra viduryje. Būtent tai ir yra „pamesta viduryje“ problema.

RAG metodas

‍Jūs užduodate klausimą savo išmaniajam asistentui, o jis paima tik atitinkamus puslapius (fragmentus) iš skirtingų dokumentų. Tai greičiau ir tiksliau, tačiau atsiranda kelios naujos rizikos:

• Dviprasmiškas klausimas. Jūs klausiate: „Kaip galime padaryti projektą saugesnį?“, o asistentas atneša jums dokumentus apie kibernetinį saugumą, o ne apie finansus.
• Sumaišyti fragmentai. Viename fragmente gali būti sumaišyti rinkodaros, dizaino ir inžinerijos užrašai. Tai išblukina prasmę, todėl asistentas negali nustatyti pagrindinės temos.
• Semantinis atotrūkis. Jūs klausiate: „Kaip galime paspartinti programėlę?“, bet dokumente rašoma: „Optimizuoti API atsako laiką.“ Žmogui akivaizdu, kad tai susiję. Mašinai – ne visada.

Tai nėra priežastys vengti RAG ar DI apskritai. Daugumos jų galima išvengti geriau paruošus savo žinių bazę ir pateikus tikslesnes užklausas. Taigi, nuo ko pradėti?

Pradėkite nuo trijų trumpų, konkrečių dokumentų

Šie trys trumpi dokumentai suteiks jūsų DI asistentui pakankamai konteksto, kad jis būtų išties naudingas:

1. Produkto apžvalga ir scenarijai. Trumpa santrauka apie tai, ką jūsų produktas daro, ir pagrindiniai vartotojų scenarijai.
2. Tikslinė auditorija. Jūsų pagrindiniai vartotojų segmentai ir jų esminiai poreikiai ar tikslai.
3. Tyrimai ir eksperimentai. Pagrindinės įžvalgos iš interviu, apklausų, vartotojų testavimo ar produkto analizės.

Kiekvienas dokumentas turėtų būti skirtas vienai temai ir idealiu atveju neviršyti 300–500 žodžių. Taip lengviau ieškoti ir užtikrinti, kad kiekvienas gautas fragmentas būtų semantiškai švarus ir labai aktualus.

Kalba yra svarbi

Praktikoje RAG veikia geriausiai, kai tiek užklausa, tiek žinių bazė yra anglų kalba. Atlikome nedidelį eksperimentą, kad patikrintume šią prielaidą, išbandydami kelis skirtingus derinius

• Angliška užklausa + angliški dokumentai: Nuosekliai tikslūs ir aktualūs rezultatai.
• Ne angliška užklausa + angliški dokumentai: Kokybė smarkiai krito. DI sunkiai suderino užklausą su tinkamu turiniu.‍
• Ne angliška užklausa + ne angliški dokumentai: Silpniausias rezultatas. Nors didieji kalbos modeliai techniškai palaiko kelias kalbas, jų vidiniai semantiniai žemėlapiai dažniausiai yra apmokyti anglų kalba. Vektorinė paieška kitomis kalbomis yra kur kas mažiau patikima.

Išvada: jei norite, kad jūsų DI asistentas pateiktų tikslius, prasmingus atsakymus, visą RAG darbą atlikite anglų kalba – tiek duomenis, tiek užklausas. Šis patarimas taikomas būtent RAG sistemoms. Įprastoms sąveikoms pokalbių lange galite laisvai naudoti kitas kalbas. Šis iššūkis taip pat pabrėžiamas 2024 m. atliktame daugiakalbės informacijos paieškos tyrime.

Iš pašaliečio į komandos narį: suteikite DI reikiamą kontekstą

Kai jūsų DI asistentas gauna tinkamą kontekstą, jis nustoja elgtis kaip pašalietis ir pradeda elgtis labiau kaip komandos narys, kuris tikrai supranta jūsų produktą. Su gerai struktūrizuota įvestimi jis gali padėti pastebėti akląsias jūsų mąstymo vietas, kvestionuoti prielaidas ir sustiprinti jūsų idėjas – taip, kaip tai darytų vidutinio ar aukštesnio lygio dizaineris.

Štai užklausos pavyzdys, kuris mums puikiai tinka

Jūsų užduotis – atlikti lyginamąją dviejų funkcijų analizę: „Grupiniai dovanų įnašai“ (aprašyta group_goals.txt) ir „Asmeniniai taupymo tikslai“ (aprašyta personal_goals.txt).

Tikslas – nustatyti galimus logikos, architektūros ir vartotojų scenarijų konfliktus ir pasiūlyti vizualinius bei konceptualius būdus, kaip aiškiai atskirti šias dvi funkcijas vartotojo sąsajoje, kad vartotojai galėtų lengvai suprasti skirtumą realaus naudojimo metu.

Prašome įtraukti:

• Jei naudinga, įtraukite palyginimo lentelę su pagrindiniais parametrais, tokiais kaip tikslas, iniciatorius, auditorija, įnašo metodas, laikas, prieigos teisės ir pan
• Galimus vartotojų tikslų, veiksmų ar scenarijų sutapimus;
• Galimą painiavą, jei abi funkcijos bus paleistos tuo pačiu metu;
• Bet kokius architektūrinius ar verslo lygmens konfliktus (pvz., rolės, pranešimai, prieigos teisės, finansinė logika);
• Pasiūlymus dėl vizualinio ir konceptualaus atskyrimo: pavadinimai, spalvinis kodavimas, atskiros skiltys ar kitos UI/UX technikos;
• Supažindinimo ekranus ar aiškinamuosius elementus, kurie padėtų vartotojams suprasti abi funkcijas.

DI reikia konteksto, o ne tik užklausų

Jei norite, kad DI pateiktų daugiau nei paviršutiniškus pasiūlymus ir taptų tikru dizaino partneriu, jam reikia tinkamo konteksto. Ne tik daugiau informacijos, bet geresnės, labiau struktūrizuotos informacijos.

Sukurti naudingą žinių bazę nėra sunku. Ir jums nereikia visavertės RAG sistemos, kad pradėtumėte. Daugelis šių principų veikia net įprastame pokalbių lange: gerai sutvarkytas turinys ir aiškus klausimas gali dramatiškai pagerinti DI atsakymų naudingumą ir aktualumą. Tai jūsų pirmas žingsnis paverčiant DI iš naujovės į praktišką įrankį jūsų produkto dizaino darbo eigoje.

2 etapas: Prototipų kūrimas ir vizualiniai eksperimentai

Prieštaravimas: „DI generuoja tik akivaizdžius sprendimus ir net negali sukurti tinkamos vartotojo kelionės. Greičiau tai padaryti rankiniu būdu.“

Tai pagrįstas susirūpinimas. DI vis dar prastai sekasi kurti išbaigtas, tinkamas naudoti ekranų sekas. Tačiau kuriant atskirus elementus, ypač ieškant naujų sąveikos modelių ar vizualinių idėjų, jis gali būti stebėtinai efektyvus.

Pavyzdžiui, mums reikėjo sukurti suažaidybinto elemento prototipą riboto laiko akcijai. Idėja – suteikti vartotojams loterijos bilietą, kurį jie gali „apversti“ ir atskleisti prizą. Mums nepavyko atkurti 3D animacijos, kurią įsivaizdavome, „Figmoje“ nei rankiniu būdu, nei naudojant prieinamus įskiepius. Taigi, aprašėme idėją „Claude 4“ per „Figma Make“ ir per kelias minutes, neparašę nė vienos kodo eilutės, gavome būtent tai, ko reikėjo.

Prototipų kūrimo etape DI gali būti stiprus kūrybinis partneris dviejose srityse:

1. UI elementų idėjų generavimas. Jis gali sugeneruoti dešimtis interaktyvių modelių, įskaitant tuos, apie kuriuos galbūt patys nepagalvotumėte.
2. Mikroanimacijų generavimas. Jis gali greitai sukurti nugludintas animacijas, kurios suteikia koncepcijai realumo jausmą, o tai puikiai tinka pristatymams suinteresuotosioms šalims arba kaip nuoroda inžinieriams.

DI taip pat galima taikyti kelių ekranų prototipams, tačiau tai nėra taip paprasta, kaip įmesti maketų rinkinį ir gauti visiškai veikiančią seką. Kuo didesnis ir sudėtingesnis projektas, tuo daugiau reikia tikslinimo ir rankinių pataisymų. Ten, kur DI jau veikia puikiai, yra sutelktos užduotys – atskiri ekranai, elementai ar animacijos – kur jis gali pradėti mąstymo procesą ir sutaupyti valandų valandas bandymų ir klaidų.

Greitas suažaidybintos reklaminės juostos vartotojo sąsajos prototipas, sukurtas su „Claude 4“ per „Figma Make“. Nereikėjo kodo ar įskiepių.

Štai dar vienas vertingas būdas naudoti DI dizaine – kaip testavimo „atšiauriomis sąlygomis“ įrankį. Dar 2023 m. „Google Research“ pristatė PromptInfuser – vidinį „Figma“ įskiepį, leidžiantį dizaineriams pridėti užklausas tiesiai prie vartotojo sąsajos elementų ir imituoti pusiau funkcionalias sąveikas realiuose maketuose. Jų tikslas nebuvo generuoti naują vartotojo sąsają, o patikrinti, kaip gerai DI gali veikti viduje esamų maketų – įdėti turinį į konkrečius konteinerius, tvarkyti kraštutinius atvejus ir anksti atskleisti logikos spragas.

Rezultatai buvo stulbinantys: dizaineriai, naudojantys „PromptInfuser“, iki 40 % efektyviau pastebėjo vartotojo sąsajos problemas ir suderino sąsają su realaus pasaulio įvestimi – tai akivaizdus dizaino tikslumo, o ne tik greičio, padidėjimas.

Tai labai atspindi mūsų patirtį su „Claude 4“ ir „Figma Make“: kai DI veikia realioje sąsajos struktūroje, o ne pradeda nuo tuščio lapo, jis tampa kur kas patikimesniu partneriu. Jis padeda išbandyti jūsų idėjas, o ne tik jas generuoti.

3 etapas: Sąsajos ir vizualinio stiliaus finalizavimas

Prieštaravimas: „DI negali atitikti mūsų vizualinio stiliaus. Lengviau tiesiog tai padaryti rankiniu būdu.“

Tai vienas dažniausių nusivylimų naudojant DI dizaine. Net jei įkeliate savo spalvų paletę, šriftus ir komponentus, rezultatai dažnai neatrodo priklausantys jūsų produktui. Jie linkę būti arba pernelyg dekoratyvūs, arba pernelyg supaprastinti.

Ir tai yra realus apribojimas. Mūsų patirtis rodo, kad šiandieniniai modeliai vis dar sunkiai sugeba patikimai pritaikyti dizaino sistemą, net jei pateikiate komponentų struktūrą ar JSON failus su savo stiliais. Išbandėme kelis metodus:

1. Tiesioginė integracija su komponentų biblioteka. Naudojome „Figma Make“ (su „Claude“) ir prijungėme savo biblioteką. Tai buvo mažiausiai efektyvus metodas: nors DI bandė naudoti komponentus, maketai dažnai buvo sugadinti, o vizualizacijos – pernelyg konservatyvios. Kiti dizaineriai susidūrė su panašiomis problemomis, pažymėdami, kad bibliotekų palaikymas „Figma Make“ vis dar ribotas ir dažnai nestabilus.
2. Stilių įkėlimas kaip JSON. Užuot naudoję visą komponentų biblioteką, bandėme įkelti tik eksportuotus stilius – spalvas, šriftus – JSON formatu. Rezultatai pagerėjo: maketai atrodė modernesni, tačiau DI vis tiek darė klaidų taikydamas stilius.
3. Dviejų žingsnių metodas: pirma struktūra, po to stilius. Geriausiai suveikė proceso atskyrimas. Pirmiausia paprašėme DI sugeneruoti maketą ir kompoziciją be jokio stiliaus. Kai turėjome tvirtą struktūrą, pateikėme kitą užklausą – pritaikyti teisingus stilius iš to paties JSON failo. Tai davė naudingiausią rezultatą – nors vis dar toli gražu ne tobulą iki pikselio.

Taigi taip, DI vis dar negali padėti jums finalizuoti vartotojo sąsajos. Jis nepakeičia rankų darbo dizaino. Bet jis labai naudingas kitais būdais:

• Greitai sukurti vizualinę koncepciją diskusijai.
• Generuoti „o kas, jeigu“ alternatyvas esamiems maketams.
• Išnagrinėti, kaip jūsų sąsaja galėtų atrodyti kitokiu stiliumi ar kryptimi.
• Veikti kaip antra akių pora, teikiant grįžtamąjį ryšį, atkreipiant dėmesį į neatitikimus ar praleistas problemas, kurias galite pražiūrėti būdami pavargę ar per daug įsigilinę į darbą.

DI nesutaupys jums penkių valandų aukštos kokybės dizaino laiko, nes tikriausiai tiek pat laiko praleisite taisydami jo rezultatą. Tačiau kaip vizualinis sparingo partneris jis jau yra stiprus. Jei laikysite jį alternatyvų ir naujų perspektyvų šaltiniu, jis taps vertingu kūrybiniu bendradarbiu.

4 etapas: Produkto grįžtamasis ryšys ir analizė: DI kaip mąstymo egzoskeletas

Produkto dizaineriai nuėjo ilgą kelią. Anksčiau kūrėme sąsajas „Photoshop“ programoje pagal iš anksto nustatytas specifikacijas. Vėliau gilinomės į vartotojo patirtį (UX), braižydami vartotojų kelius, atlikdami interviu ir suprasdami vartotojų elgseną. Dabar, su DI, gauname prieigą prie dar vieno lygio: duomenų analizės, kuri anksčiau buvo išskirtinė produktų vadovų ir analitikų sritis.

Kaip teisingai pastebėjo Vitaly Friedmanas vienoje iš savo skilčių, bandymas pakeisti realius UX interviu dirbtiniu intelektu gali privesti prie klaidingų išvadų, nes modeliai linkę generuoti vidutinę, o ne realią patirtį. DI stiprybė – ne duomenų išradinėjimas, o jų apdorojimas dideliu mastu.

Pateiksime realų pavyzdį. Paleidome išėjimo apklausą vartotojams, kurie paliko mūsų paslaugą. Per savaitę surinkome daugiau nei 30 000 atsakymų septyniomis kalbomis.

Vien suskaičiuoti procentus kiekvienai iš penkių iš anksto nustatytų priežasčių nepakako. Norėjome sužinoti:

• Ar yra konkretus paros metas, kai vartotojai dažniau išeina?
• Ar priežastys skiriasi pagal regioną?
• Ar yra ryšys tarp vartotojų išėjimų ir sistemos apkrovos?

Tikrasis iššūkis buvo... išsiaiškinti, kokius pjūvius ir kampus apskritai verta tirti. Visą techninį procesą, nuo analizės iki vizualizacijų, „už mus“ atliko „Gemini“, veikiantis „Google Sheets“. Ši užduotis mums iš viso užtruko apie dvi valandas. Be DI ne tik būtų užtrukę daug ilgiau, bet tikriausiai apskritai nebūtume galėję pasiekti tokio lygio įžvalgų

DI leidžia dirbti su dideliais duomenų rinkiniais beveik realiuoju laiku. Bet svarbiausia, jis atlaisvina jūsų laiką ir energiją tam, kas tikrai vertinga: teisingų klausimų kėlimui.

Keletas praktinių pastabų: Darbas su dideliais duomenų rinkiniais vis dar yra iššūkis modeliams be stiprių mąstymo gebėjimų. Savo eksperimentuose naudojome „Gemini“, integruotą į „Google Sheets“, ir tikrinome rezultatus naudodami „ChatGPT o3“. Kiti modeliai, įskaitant atskirą „Gemini 2.5 Pro“, dažnai pateikdavo neteisingus rezultatus arba tiesiog atsisakydavo atlikti užduotį.

DI yra ne autopilotas, o antrasis pilotas

DI dizaine yra tiek geras, kiek geri yra jūsų užduodami klausimai. Jis neatlieka darbo už jus. Jis nepakeičia jūsų mąstymo. Bet jis padeda judėti greičiau, ištirti daugiau galimybių, patvirtinti idėjas ir sutelkti dėmesį į sudėtingas dalis, užuot eikvojus laiką pasikartojantiems veiksmams. Kartais vis dar greičiau kurti dizainą rankiniu būdu. Kartais prasmingiau deleguoti užduotį jaunesniajam dizaineriui.

Tačiau vis dažniau DI tampa tuo, kuris siūlo, tobulina ir pagreitina. Nelaukite, kol sukursite tobulą DI darbo eigą. Pradėkite nuo mažų dalykų. Ir tai gali būti pirmas realus žingsnis paverčiant DI iš įdomybės į patikimą įrankį jūsų produkto dizaino procese.

Apibendrinkime

• Jei tiesiog įklijuosite visą dokumentą į pokalbių langą, modelis dažnai praleis svarbius dalykus, ypač tuos, kurie paslėpti viduryje. Tai „pamesta viduryje“ problema.
• RAG metodas padeda, ištraukdamas tik aktualiausius fragmentus iš jūsų dokumentų. Taigi atsakymai yra greitesni, tikslesni ir pagrįsti realiu kontekstu.
• Aiškios, konkrečios užklausos veikia geriau. Susiaurinkite apimtį, apibrėžkite rezultatą ir naudokite pažįstamus terminus, kad padėtumėte modeliui išlikti kelyje.
• Gerai struktūrizuota žinių bazė daro didelį skirtumą. Turinio organizavimas į trumpus, konkrečios temos dokumentus padeda sumažinti triukšmą ir išlaikyti atsakymų aštrumą.
• Naudokite anglų kalbą tiek užklausoms, tiek dokumentams. Net daugiakalbiai modeliai yra patikimiausi dirbdami anglų kalba, ypač informacijos paieškos atveju.
• Svarbiausia: žiūrėkite į DI kaip į kūrybinį partnerį. Jis nepakeis jūsų įgūdžių, bet gali įžiebti idėjų, pastebėti problemas ir pagreitinti nuobodžias dalis.