Prototype

Projektets prototype og den efterfølgende testning i Test-fasen har til formål at afprøve konkrete designidéer i praksis. Fundamentet for projektets prototype bygger på brugerinvolveringen fra Ideate-fasens idéworkshops samt de efterfølgende etablerede designprincipper #2.

På nedenstående knap kan projektets Miro tilgås, indeholdende et grafisk indblik i Prototype-fasen samt dets kobling til de resterende delfaser.

Projektets prototype er skabt ved hjælp af den digitale teknologi Figma. På nedenstående billede kan prototypen ses, i et ikke-interaktionsbart format.

På nedenstående knap kan prototypen afprøves i Figma. Prøv den gerne af og smid en kommentar i kommentarsporet i bunden af bloggen!

Prototype 1.0 og graden af fidelty

Vores prototype 1.0 er udviklet i Figma med udgangspunkt i projektets designprincipper om tilgængelighed af varer, overblik og navigation i supermarkedet. Prototypen er udformet som en interaktiv digital løsning, hvor brugeren kan tilgå et varekatalog, undersøge aktuelle lagerstatusser samt navigere til varers placering i butikken. Derudover indeholder prototypen funktioner som push-notifikationer, indkøbsliste og alternative produkter ved manglende lagerstatus. I relation til (Lim et al., 2008) forståelse af prototypers manifestation dimensions kan prototype 1.0 karakteriseres som en prototype, der befinder sig mellem en high fidelity og low fidelity-prototype. Dette kommer til udtryk ved, at prototypen indeholder konkrete funktioner og visuelle elementer, som giver brugerne mulighed for at interagere med løsningen i en praksisnær kontekst. Formålet med denne grad af fidelity har været at skabe en realistisk brugeroplevelse og dermed styrke brugernes forudsætninger for at evaluere løsningens funktionalitet og anvendelighed gennem prototype-testen (Lim et al., 2008). Det er dog væsentligt at bemærke, at prototype 1.0 primært har fokus på funktionalitet frem for visuel æstetik og “appearance”, da formålet ikke har været at udvikle et færdigt visuelt design, men derimod at understøtte brugernes mulighed for at afprøve og evaluere de centrale funktioner i løsningen. Prototype 1.0 skal derfor ikke forstås som en færdig løsning, men som første iteration af projektets designløsning, udviklet med henblik på at undersøge og kvalificere designprincipperne gennem brugerfeedback og iterative tilpasninger.

Visualisering af prototypens anatomi

Prototype-test og brugerfeedback gennem MoSCoW-metoden

I vores prototypefase har vi arbejdet med at teste og videreudvikle vores første designløsning gennem brugerfeedback. Til dette anvendte vi MoSCoW-metoden som et prioriteringsværktøj, hvor brugerne vurderede forskellige funktioner som henholdsvis Must Have, Should Have, Could Have og Won’t Have (Miranda, 2022). Formålet med testen var ikke længere at generere nye idéer, men derimod at undersøge hvilke funktioner brugerne oplevede som mest centrale for løsningens anvendelighed. Gennem testen fik vi indblik i brugernes oplevelser af funktioner som varekatalog, lagerstatus og navigation i supermarkedet, hvilket gav os et konkret grundlag for de videre iterationer og refleksioner i designprocessen.

Skema over fordelingen på vores brugerfeedback ved hjælp af MoSCoW-metoden

Hvad dækker vores funktioner over

Som nævnt før er vores prototype 1.0 placeret et sted mellem low og high fidelty, så flere af de ovennævnte funktioner er lavet færdig, men giver brugeren en ide om hvad de skal kunne:

Varekatalog: Oversigt over butikkens varer og informationer om produkterne.

Lagerstatus: Visning af om varer er på lager eller udsolgt.

Navigationsfunktion: Hjælp til at finde varer i butikken. AR-navigation i beta.

Push-notifikationer: Beskeder og opdateringer sendt direkte til brugeren. I prototypen er det mere et tænkt eksempel.

Indkøbsliste: Funktion til at oprette og gemme varer til indkøb.

Alternative produkter: Forslag til lignende varer som erstatning for et produkt.

Resultater fra brugerevalueringen

Resultaterne viser, at testpersonerne var mest enige om funktionerne: varekatalog og lagerstatus. Begge funktioner blev vurderet som Must Have af alle fire deltagere, hvilket peger på, at de opfattes som centrale funktioner i løsningen. Navigationsfunktionen blev vurderet lidt mere forskelligt blandt deltagerne, hvor to vurderede den som Must Have og to som Should Have. Funktionen anses dog generelt som vigtig og værdiskabende, men ikke nødvendigvis som helt afgørende for alle brugerne. Indkøbslisten blev også vurderet positivt af testpersonerne. En deltager placerede den som Must Have, to som Should Have og én som Could Have. Besvarelserne er lidt mere tvetydig, men viser, at funktionen generelt opfattes som nyttig og relevant af størstedelen af deltagerne. Alternative produkter blev af tre testpersoner vurderet som Should Have, mens én vurderede funktionen som Won’t Have. Flere deltagere fremhævede, at forslagene til alternative produkter skal være relevante for at give værdi. Push-notifikationer var den funktion, hvor vurderingerne var mest delte. En deltager vurderede funktionen som Must Have, to som Could Have og én som Won’t Have. Flere testpersoner nævnte desuden, at de havde svært ved at få øje på funktionen i prototypen, og at de forbandt notifikationerne med reklamer, hvilket påvirkede deres vurdering negativt.

Hvad savner/ønsker testpersonerne sig?

Testpersonernes ønsker var særligt på navigation, lagerstatus, alternative varer, indkøbslister og tidsoptimering som centrale temaer. Flere fremhævede behovet for en hurtig og overskuelig brugerflade, hvor det er nemt at finde rundt mellem funktionerne. Derudover blev muligheden for at se lagerstatus og få relevante alternative varer fremhævet som vigtigt i forbindelse med indkøbssituationen. Indkøbslisten spillede også en central rolle i besvarelserne, hvor der bl.a. blev lagt vægt på fleksibilitet, overblik og muligheden for at dele lister med andre brugere. Samtidig pegede flere på funktioner, der kunne optimere indkøbstiden, eksempelvis effektive ruter gennem butikken og indsigt i travlhed.I besvarelserne blev der desuden peget på, at notifikationer og adviseringer bør balanceres, så de understøtter brugeroplevelsen uden at opleves som forstyrrende eller kommercielle.

Litteratur

Lim, Y.-K., Stolterman, E., & Tenenberg, J. (2008). The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Transactions on Computer-Human Interaction, 15(2), Article 7. https://doi.org/10.1145/1375761.1375762 

Miranda, E. (2022). Moscow rules: A quantitative exposé. I Agile Processes in Software Engineering and Extreme Programming (s. xx–xx). Springer. https://doi.org/xxxxx