Kan en AI-chattbot svara senare som en vän? En guide till användarvalda fördröjda svar

I ett samtal mellan människor kan en paus uppstå av många skäl: någon går iväg, tänker efter innan hen svarar eller återkommer till samtalet senare. Ett AI-system har inte sådana personliga omständigheter. En produkt kan återskapa tidsförloppet hos en paus, men bör inte framställa pausen som tecken på en mänsklig orsak.

För en vanlig kreativ uppgift kan en användarvald fördröjning ändå vara användbar. Någon kanske ber om en skrivövning efter middagen, önskar en ny omgång berättelseidéer om en timme eller schemalägger ett nytt perspektiv till nästa morgon. Värdet ligger i den valda tidpunkten och samtalsrytmen – inte i intrycket att AI:n har ett privatliv.

Gör handlingen tydlig när den schemaläggs. Till exempel: ”Visa mig tre nya titelidéer klockan 19.00.” Bekräfta sedan: ”Schemalagt till klockan 19.00.” Den här formuleringen talar om för användaren vad systemet kommer att göra utan att hitta på en bakgrundshistoria som ”Jag är upptagen just nu.” Det här är en designrekommendation som bygger på skillnaden mellan en automatiserad schemalagd handling och en persons förklaring; den påstår inte att någon viss chattbot redan erbjuder funktionen.

Ett användbart flöde för fördröjda svar börjar med en tydlig begäran. Användaren ska kunna ange vad hen vill ha, när hen vill ha det och – när det är relevant – om svaret ska fortsätta den aktuella uppgiften eller börja på en ny. Om systemet behöver förtydliganden om tidpunkten eller uppgiften ska det fråga innan schemaläggningen bekräftas.

Visa den valda tidpunkten på ett sätt som personen kan kontrollera, inklusive relevant datum när ”senare” kan vara tvetydigt. ”Om 30 minuter” är lätt att förstå när schemat skapas, men ett datum och en lokal tid kan vara mer användbara när svaret ska komma en annan dag. Om tidszon eller enhetsinställning kan påverka leveransen ska du förklara vilken tid schemat följer i stället för att låta användaren gissa.

Apples anvisningar för schemalagda meddelanden är ett konkret exempel på schemaläggning som är synlig för användaren: meddelandet visar den schemalagda tiden, och användare kan redigera, radera, schemalägga om eller skicka det direkt före leverans. Det är ett exempel från meddelandehantering, inte ett bevis på att ett AI-svar redan har skapats eller levereras på samma sätt. En chattbot bör tydligt beskriva sitt eget beteende. Apple Support: Schemalägg ett textmeddelande på iPhone för senare leverans

Ett schemalagt svar har mer än ett statusläge. ”I kö till klockan 19.00” betyder att systemet har registrerat en framtida handling. Det betyder inte nödvändigtvis att svaret redan finns. Om systemet genererar svaret vid den schemalagda tidpunkten ska det sägas. Om svaret förbereds tidigare ska det bara markeras som klart när innehållet faktiskt finns tillgängligt. Undvik vaga statusetiketter som får en schemalagd uppgift att se ut som pågående tankeverksamhet eller framsteg.

Efter den valda tidpunkten kan systemet fortfarande behöva generera svaret. En kort status som ”Genererar ditt svar” kan skilja det arbetet från ”Klart”. Om genereringen misslyckas eller appen inte kan slutföra uppgiften ska det anges tydligt och användaren få ett rimligt nästa steg, till exempel att försöka igen eller välja en annan tid. Låt inte en inaktuell etikett som ”i kö” ligga kvar och antyda att svaret fortfarande är på väg när det inte är det.

Det här tillvägagångssättet följer etablerade riktlinjer för gränssnitt. Material Design beskriver förloppsindikatorer som ett sätt att kommunicera statusen för en pågående process och tillgängliga åtgärder. W3C:s riktlinjer definierar statusmeddelanden som information om resultatet av en åtgärd, vänteläge, förlopp eller fel, och förklarar att sådana uppdateringar ska vara tillgängliga för hjälpmedel utan att ta fokus. Dessa principer talar för specifik och tillgänglig statustext i stället för dekorativa fördröjningar eller oförklarad tystnad. Material Design: Förloppsindikatorer · W3C WAI: Förstå framgångskriterium 4.1.3, statusmeddelanden

Planer ändras. En schemalagd post bör vara synlig i konversationen eller i en lättfunnen schemalista, med ett tydligt sätt att avbryta den. Låt användaren redigera begäran eller ändra tidpunkten när det är praktiskt möjligt. Bekräfta resultatet efter varje åtgärd: ”Avbrutet; inget svar kommer att genereras” eller ”Flyttat till klockan 20.00”. Om systemet inte kan garantera att schemat avbryts när genereringen väl har börjat ska du förklara tidsgränsen innan användaren förlitar sig på det.

Gör skillnaden mellan att avbryta ett schema och att radera ett synligt svar begriplig. Om produkten kan göra det på ett tillförlitligt sätt ska avbrytandet stoppa den väntande åtgärden. Om ett svar redan har genererats ska användaren få veta om det finns kvar i chatten. Apples funktion för schemalagda meddelanden visar varför ett tydligt schemaläge och en avbrytandekontroll spelar roll: Apple uppger att om ett meddelande raderas innan den schemalagda tiden avbryts leveransen. Det exakta beteendet för ett AI-schema beror på hur systemet är byggt, så bekräftelsen bör beskriva det faktiska resultatet.

Ett schemalagt svar kan visas i chatten utan att skicka en pushavisering. Erbjud ett separat val för aviseringar och tidpunkt, till exempel ”Visa i chatten klockan 19.00” och ett valfritt ”Avisera mig när det är klart”. Då behandlas inte tillstånd att schemalägga arbete som tillstånd att avbryta användaren senare.

Om aviseringar erbjuds ska du förklara deras syfte när användaren kommer till det valet och låta den schemalagda uppgiften gå att använda även om personen tackar nej. Apple rekommenderar att man ber om tillstånd för aviseringar i rätt sammanhang så att användarna förstår vad aviseringarna är till för. Androids riktlinjer för behörigheter rekommenderar på liknande sätt att man ber om tillstånd när användaren börjar använda funktionen som behöver det, undviker att blockera flödet och hanterar avslag på ett smidigt sätt. Dessa plattformsrekommendationer stöder ett separat och välgrundat beslut om aviseringar; de kräver inte att varje produkt erbjuder pushaviseringar. Apple Developer: Be om tillstånd att använda aviseringar · Android Developers: Begär behörigheter under körning

Om användaren väljer att få aviseringar ska de stå i proportion till ett vanligt kreativt svar. Apples riktlinjer för aviseringar säger att man ska återge angelägenhetsgraden korrekt och låta människor hantera sina aviseringsval. En vanlig skrivövning ska inte märkas som brådskande eller framställas som något som kräver omedelbar uppmärksamhet. Apple Human Interface Guidelines: Hantera aviseringar

En enkel interaktion kan fungera så här: användaren ber: ”Ge mig tre namn på det här fiktiva kaféet klockan 19.00.” Systemet upprepar uppgiften och tidpunkten och frågar sedan om användaren vill få en avisering när svaret är klart. När schemat har bekräftats visar konversationen ”I kö till klockan 19.00” med kontroller för att redigera eller avbryta. Vid den angivna tiden visas ”Genererar ditt svar”, följt av idéerna, och uppgiften markeras som slutförd. Om genereringen misslyckas rapporteras felet och användaren erbjuds ett nytt försök.

Den sekvensen gör fördröjningen till en användarstyrd funktion. Texten kan kännas varm och samtalslik när svaret kommer, men gränssnittet behöver inte låtsas att en person gick iväg, blev distraherad eller bestämde sig för att vänta innan hen svarade. En enkel regel är: låt användaren välja pausen, tala om vad systemet kommer att göra och ge användaren kontroll över både det väntande svaret och eventuella aviseringar.