Vad får en AI-textchatt att kännas naturlig: skrivhastighet eller interaktionsrytm?
I en AI-textchatt beror en övertygande interaktion mindre på hur snabbt bokstäverna visas än på om varje steg i utbytet känns logiskt: användaren kan se att systemet har tagit emot meddelandet, svaret kommer i läsbara delar och det är tydligt när det är klart eller avbryts. En skrivanimation i sig kan inte skapa den rytmen. Utforma gränssnittet kring användbar återkoppling och användarkontroll, och se simulerad skrivning som en valfri visuell effekt snarare än ett bevis på att det finns en person på andra sidan.
Skrivanimation är en signal, inte själva samtalet
En pulserande ellips eller etiketten ”skriver” kan visa att ett svar förbereds. Visas riktlinjer för chattdesign beskriver skrivindikatorer som ett sätt att signalera att ett svar är på gång och skiljer dem från förloppsindikatorer som används under generativt AI-arbete. Den skillnaden är användbar: ”skriver” antyder att någon formulerar sig, medan ”arbetar” eller ”genererar” beskriver en systemprocess mer rakt på sak. För en AI-assistent bör du välja formuleringar som korrekt anger tillståndet i stället för att antyda en mänsklig identitet eller ett mänskligt skrivmönster. (Visa Product Design System: Chat)
En fast paus följd av en simulerad teckenvisning kan få gränssnittet att likna en meddelandeapp, men den berättar inte för användaren om begäran har tagits emot, om systemet fortfarande bearbetar den eller om svaret är klart. Den kan också få ett kort och enkelt svar att kännas onödigt fördröjt. Den användbara designfrågan är inte ”Hur många millisekunder ska varje tecken ta?” utan ”Vad behöver användaren veta medan hen väntar, läser eller funderar på vad hen ska göra härnäst?”
Utgå från användarens uppgift och kostnaden för väntan
Börja med att identifiera arbetet bakom meddelandet. Ett kort svar på en enkel fråga kanske bara behöver en kort signal om att bearbetning pågår och ett fullständigt svar. Ett svar som kräver en längre process, till exempel att granska ett dokument som användaren har skickat, kan vinna på en mer beskrivande status och en realistisk uppskattning om en sådan finns. Om tiden är okänd bör du använda en obestämd indikator och inte hitta på en nedräkning. Apples riktlinjer för förloppsindikatorer skiljer mellan bestämt förlopp, där tid eller framsteg kan mätas, och obestämd aktivitet. De rekommenderar korrekt återkoppling om förloppet och ett sätt att avbryta arbetet när det är möjligt. (Apple Human Interface Guidelines: Progress Indicators)
En praktisk sekvens är att bekräfta mottagandet, visa att arbetet har börjat om väntan märks och sedan visa svaret när det är klart. Det här är separata tillstånd, även om ett kompakt gränssnitt kombinerar några av dem. Tillståndet ”Skickat” bekräftar användarens handling, en aktivitetsindikator visar att användaren väntar och det genererade meddelandet innehåller resultatet. Låt inte en indikator ligga kvar på skärmen när arbetet har upphört, och ta inte bort den utan att tydliggöra att svaret är klart. Om en begäran misslyckas bör du förklara vad som hände och erbjuda ett konkret nästa steg, till exempel att försöka igen. Visas chattvägledning rekommenderar också tydliga felmeddelanden och ett alternativ för att skicka igen när ett meddelande inte går iväg. (Visa Product Design System: Chat)
Använd meddelandedelar för att underlätta läsningen
Att strömma ord eller fraser allt eftersom de blir tillgängliga kan göra svaret synligt innan hela genereringen är klar. Det skiljer sig från att animera ett färdigt svar i en konstgjord skrivhastighet: strömning återspeglar när resultatet kommer, medan en visningsanimation kan lägga till en fördröjning efter att texten redan finns. OpenAI:s referens för strömning i Responses beskriver händelser för när svar skapas, när text uppdateras och när texten är färdig. Händelserna visar en användbar skillnad i gränssnittet mellan ett pågående svar och färdig text; de föreskriver ingen universell visningshastighet eller storlek på textdelar. (OpenAI API Reference: Streaming events)
För en läsbar dialog bör du, när det är möjligt, visa sammanhängande fraser eller delar i ungefärlig meningslängd, bevara styckeindelningen och undvika att meddelandet hoppar runt medan innehållet kommer in. Det här är en designrekommendation utifrån läsuppgiften, inte en uppmätt regel för idealisk längd på textdelar. Om svaret är långt kan en kort inledning eller den första användbara delen visas tidigt, medan resten följer i en stabil layout. Dela inte upp texten så mycket att läsaren ser ett flimrande flöde av fragment, och håll inte inne ett tillgängligt, färdigt svar bara för att efterlikna mänskligt skrivande. Gör kontroller som stoppa eller generera igen lätta att hitta när gränssnittet har stöd för dem.
Gör återkopplingen under väntan korrekt och rimlig
När arbetet tar tid bör indikatorn beskriva vad systemet faktiskt vet. Använd en bestämd stapel eller procentsats endast när förloppet går att mäta på ett meningsfullt sätt. Annars visar en enkel aktivitetsindikator att arbetet fortsätter utan att låtsas kunna förutsäga när det blir klart. Apple rekommenderar att förloppsrapporter är korrekta, att man förklarar avbrott och låter användare avbryta bearbetningen när det är möjligt. Samma principer gäller i chatt: om processen stannar bör du ersätta det oändligt animerade tillståndet ”arbetar” med ett användbart meddelande, till exempel ”Svaret avbröts. Försök igen.”
Undvik att ändra statusmeddelandet om och om igen för att ge sken av aktivitet. En sekvens som ”Tänker …”, ”Tänker fortfarande …” och ”Nästan klar …” är bara användbar om varje meddelande motsvarar ett verkligt tillstånd och hjälper användaren att avgöra vad hen ska göra. Annars är en tydlig status mindre störande. Säg särskilt inte ”nästan klar” om systemet saknar tillförlitligt underlag för det påståendet. En kort och sanningsenlig signal kan kännas mer hänsynsfull än en livlig men innehållslös animation.
Behandla slutförandet som ett faktiskt tillstånd
Användaren behöver veta när svaret är klart, särskilt om hen vill kopiera det, ställa en följdfråga eller avbryta pågående utdata. Ta bort eller ersätt aktivitetsindikatorn när genereringen avslutas och se till att slutmeddelandet ligger kvar stabilt så att användaren kan läsa och interagera med det. Om utdata kan bli ofullständig eller avbrytas bör du kommunicera det tillståndet i stället för att presentera ett ofullständigt svar som färdigt. Referensen för strömnings-API:t skiljer mellan textuppdateringar och sluthändelser och påpekar att sluthändelser också kan höra samman med avbrutna eller ofullständiga svar. Gränssnittet bör därför visa det resultat som faktiskt kom in. (OpenAI API Reference: Streaming events)
Även personer som inte följer visuell animation behöver få veta att arbetet är klart. W3C:s vägledning förklarar att statusmeddelanden kan kommunicera väntan, förlopp, framgång eller fel utan att flytta användarens fokus, och att dessa uppdateringar bör kunna identifieras programmatiskt av hjälpmedelsteknik. MDN:s vägledning om live-regioner beskriver artiga meddelanden för viktiga uppdateringar som inte är brådskande och varnar för att täta, påträngande meddelanden kan avbryta användare. I praktiken bör du meddela betydelsefulla tillståndsändringar, till exempel när ett svar blir tillgängligt eller en begäran misslyckas, utan att varje token eller animationsbildruta blir ett talat meddelande. (W3C WAI: Understanding Status Messages; MDN: ARIA live regions)
Ge människor kontroll över tempot
En dialog som känns naturlig ger användaren utrymme att agera. Låt användare stoppa ett svar när det är praktiskt möjligt och gör det tydligt om stoppet avslutar genereringen eller bara pausar visningen. Om ett svar strömmas bör den synliga texten vara läsbar, och användaren ska kunna fortsätta navigera i dialogen. När ett fullständigt svar snabbt blir klart bör du undvika en teatralisk paus. När verklig bearbetning tar längre tid bör du förklara att arbetet fortfarande pågår. Målet är att stödja användarens tempo i stället för att få hen att vänta längre.
Det här bidrar också till att skilja gränssnittets samtalsstil från ett falskt påstående om vem eller vad som svarar. Ett AI-system kan använda kortfattade, vänliga formuleringar och en meddelandeliknande presentation samtidigt som det beskriver sig självt korrekt. ”Förbereder ett svar” beskriver systemets aktivitet; ”Jag skriver” kan tolkas som att en person skriver. Välj etiketter med hänsyn till hur de sannolikt kommer att uppfattas, särskilt i en produkt där användarna rimligen kan missta indikatorn för en mänsklig deltagare.
En enkel beslutsregel för att välja mönster
Använd en skrivliknande animation bara när den ger en tydlig, kort signal och inte antyder att en mänsklig person är inblandad. Använd en förloppsindikator när systemet utför arbete som tar längre tid än användarens omedelbara handling. Strömma läsbara delar av meddelandet när det underlättar uppgiften att visa tidiga resultat, och markera att svaret är klart först när det faktiskt är färdigt. Lägg till kontroller när det är möjligt och användbart att avbryta. Se till att viktiga tillståndsändringar går att uppfatta utan att förlita sig enbart på rörelse eller färg.
En snabb designgenomgång kan ställa fyra frågor: Vad har användarens handling satt igång? Vilket tillstånd befinner sig systemet faktiskt i? Vad kan användaren göra medan hen väntar? Hur får användaren veta att resultatet är klart, eller att något gick fel? Om svaren är tydliga kan interaktionen kännas responsiv utan att låtsas följa en mänsklig skrivrytm. Kvaliteten kommer från samordnad återkoppling, lättläst presentation och kontroll, inte från hur snabbt prickarna rör sig.