Prototyper för idéer som vill bli verklighet

Du skannar en streckkod, men livsmedlet finns inte i appen. Innan det går att logga behöver någon lägga in namn, näringsvärden och andra uppgifter. Det som skulle gå snabbt blir ett arbete med att fylla på databasen.

För en hälsoapp som Kalorima är det ett viktigt problem att lösa. Bra data behövs för att appen ska vara användbar. Samtidigt ska användaren kunna ägna sig åt sitt ärende utan att behöva göra en massa manuellt arbete.

Här fanns en möjlighet att undersöka med AI. Tekniken skulle kunna läsa in uppgifterna och hjälpa till att skapa livsmedlet i bakgrunden. Men först behövde det gå att prova hur väl det faktiskt fungerade.

AI utan ett extra samtal

Utgångspunkten var att AI skulle hjälpa till i det befintliga flödet. Användaren skulle inte behöva öppna en chatt, formulera en fråga eller förstå hur tekniken arbetade.

Prototypens flöde började med att skanna en streckkod. Om livsmedlet saknades i databasen kunde bilder av produkten och näringsdeklarationen skickas till en motor med AI. Där analyserades materialet för att samla in uppgifter, kategorisera och skapa livsmedlet.

Resultat som motorn markerade som osäkra gick vidare till manuell kontroll. Annars kunde livsmedlet bli tillgängligt så snart bearbetningen var klar. I försöken behövdes manuell kontroll relativt sällan.

Det blev också tydligt att arbetet behövde ske asynkront: materialet skickades iväg och bearbetades i bakgrunden, medan resultatet kunde komma senare.

Den insikten påverkade mer än datainsamlingen. Den lade en grund för hur loggningen i Kalorima skulle behöva fungera. Hur visar appen att något bearbetas? Vad händer när livsmedlet blir tillgängligt? Hur håller upplevelsen ihop när allt inte blir klart direkt?

Prova grunden först

En prototyp ger en idé tillräckligt med form för att något viktigt ska gå att undersöka. Den kan vara en skiss, ett klickbart flöde eller en fungerande teknisk del. Vad som behövs beror på frågan som försöket ska hjälpa till att besvara. GOV.UK:s vägledning om prototyper beskriver samma bredd, från papper till interaktiva lösningar byggda i kod.

I Kalorima var frågan större än hur en skanning skulle se ut på skärmen. Det behövde finnas ett fungerande flöde för att läsa in material och skapa användbara uppgifter.

Därför fick själva datainsamlingen fokus. Kaloriräkning och övrig loggning kunde vänta. Det viktiga var att undersöka om insamlingen gick att göra effektiv och tillförlitlig nog att bygga vidare på.

En intressant del var möjligheten att använda öppna modeller som kunde köras på vanliga grafikkort. Prototypen gav bra resultat med den lösningen. Det skapade möjlighet att köra motorn själv och minskade beroendet av externa tjänster för AI.

Försöket gav därmed bättre förståelse för både flödet och den teknik som kunde bära det.

Begränsa försöket, behåll nyfikenheten

När något börjar fungera är det lätt att vilja fortsätta. En ny vy, fler inställningar och några funktioner som ändå kommer att behövas senare.

En tydlig avgränsning hjälper till att hålla uppmärksamheten på det som fortfarande är osäkert. För Kalorimas första prototyp var det datainsamlingen. En genomarbetad loggning skulle inte göra det lättare att bedöma hur väl motorn läste en näringsdeklaration.

Samtidigt kan försöket väcka idéer utanför den ursprungliga frågan.

Portionsuppgifter blev ett sådant spår. Många livsmedel beskriver en portion på olika sätt. Det väckte frågan om hur AI kunde använda den informationen för att förenkla loggningen senare.

Vad brukar användaren faktiskt vilja logga av just det livsmedlet? Om portionsuppgifterna går att tolka kan de hjälpa appen att erbjuda ett enkelt val som passar situationen. Då kan samma information som behövs i databasen också minska arbetet för användaren.

Prototypen undersökte alltså en teknisk grund, men gav också tankar om den framtida upplevelsen. Det som kom fram behövde inte byggas direkt. Det kunde bli underlag för nästa försök.

Olika idéer behöver olika prototyper

Lumo började med andra frågor. Där behövde det undersökas hur väl stora mängder bilder kunde skalas om på användarens egen enhet, direkt i webbläsaren.

För att få svar behövde bildbearbetningen fungera på riktigt. En klickbar skiss skulle kunna visa ett tänkt arbetsflöde, men inte hur effektivt webbläsaren klarade själva arbetet.

Kalorima och Lumo behövde därför undersöka olika saker. I det ena fallet stod insamling och tolkning av data i centrum. I det andra handlade det om bearbetning av bilder. Båda försöken skulle ge underlag för att bedöma vad som gick att bygga vidare på och hur det kunde bli bra att använda.

Vad behöver vara klart efteråt?

En prototyp behöver inte avslutas med en färdig plan för hela produkten. Målet kan vara att förstå möjligheten bättre, upptäcka ett hinder eller få en känsla för något som tidigare bara gick att beskriva.

Resultatet behöver också bedömas utifrån vad som faktiskt provades. Att ett flöde fungerar i ett försök besvarar inte alla frågor om fler variationer, fel eller framtida användning. Däremot kan det göra nästa steg tydligare.

I Kalorima gav prototypen både en lovande grund för datainsamlingen och en bättre förståelse för hur arbetet skulle behöva fortsätta i appen. En fråga om att läsa in livsmedel blev också frågor om väntan, återkoppling och enklare sätt att logga.

Det var mer än vad en färdig skiss av skanningsvyn hade kunnat berätta.