Projekt 5 – Grocott Fysioterapi

Eksamensprojekt · 2. Semester · Forår 2026 · UCL · Seebladsgade · Odense · Klient: Grocott Fysioterapi

Et semester som UX-designer, AI-strateg og projektleder på én gang

Projekt 5 er det største projekt, jeg nogensinde har arbejdet på som studerende. Et eksamensprojekt på 2. semester med en rigtig klient — Grocott Fysioterapi i Odense — og kun Louise og mig til at løfte det.

Format

Eksamensprojekt · 2-personers gruppe · 4 sprints

Klient

Grocott Fysioterapi · Nicolai Grocott · Odense

Output

Desk research · persona · prototype · JavaScript · video · midtvejspitch · klientpitch · klientrapport · contentprodukter · procesvideo

Periode

April–maj 2026

01
Kickoff
Strukturen der holdt os oppe
Et Scrum-board vi byggede selv — og hvad det egentlig krævede
Screenshot

Vi startede med at bygge et Scrum-board i Notion. Ikke en template. Et tilpasset setup, som Louise og jeg selv designede til præcis vores måde at arbejde på.

Det tog lang tid. Jeg måtte iterere igen og igen — og undervejs lærte jeg faktisk Notion bedre, end jeg nogensinde har gjort fra en YouTube-tutorial, fordi jeg var nødt til at tage stilling til, hvad vi egentlig havde brug for. Hvornår et kort skulle flyttes. Hvad en “done”-definition er for os to. Hvad der hørte til en sprint, og hvad der bare var støj.

Vi er to i gruppen. Det lyder enkelt, og det er det på mange måder: kommunikationen er direkte, beslutningerne er hurtige, og der er ingen at gemme sig bag. Men det er også to mennesker til at løfte det, der normalt ville kræve fire. Det mærkede jeg fra dag ét — og det mærkede jeg igen og igen gennem hele forløbet.

“Da boardet endelig lå der, gav det mig en ro i maven, jeg ikke har haft i tidligere projekter. Ikke fordi alt var planlagt — men fordi vi havde en ramme at navigere ud fra.”


02
Metode · AI-brug
AI som designpartner
Kontrol, kildekritik og et etisk valg

Jeg vil ikke kalde det “vi brugte AI”. Det er en for nem fortælling.

Det præcise er: jeg har bygget en arbejdsmetode, der gør AI til en del af min designproces — på mine præmisser, med mine beslutninger og min kildekritik som filter. Det startede med desk research. Mængden af materiale var enorm, og her er AI’s styrke åbenlys: den kan processere og strukturere information, der ville have taget uger at håndtere manuelt. Men det kræver, at man er skarp. Jeg har promptet i én tråd, bedt den iterere på sit eget output i en anden, og hele vejen igennem taget stilling til, hvad der kunne bruges, og hvad der var hallucination eller dårlig kilde.

“Go”-
princippet
AI må ikke sætte noget i gang, uden at jeg har godkendt planen. Den beder om lov. Jeg siger go, når jeg er klar — og tager én sektion af gangen. Det har gjort, at jeg har haft kontrol hele vejen og faktisk forstår, hvad der er blevet produceret.
Kilde-
kritik
Jo mere præcis prompten er, jo bedre kvalitet. Og jo mere opmærksom man er på hallucination. Research-delen skulle have fylde, fordi den er grundstenen — men det er stadig mig, der bestemmer, hvad der er godt nok til at bygge videre på.
Iterations-
metode
Prompt i én tråd — bed den iterere på sit eget output i en anden. Det er en arbejdsform, der giver markant bedre resultater end at køre alt i samme samtale, og som tvinger én til at tage stilling undervejs.
Etisk
valg
Jeg bruger Anthropic — ikke OpenAI, ikke Grok. Det er et aktivt valg. Anthropic er den eneste af de store aktører, der tager et etisk standpunkt og holder fast i det, selv når det koster noget. Det er vigtigt for mig, at det ikke er de forkerte aktører, der ender med at sidde med den magt, AI kommer til at give.
Refleksion · AI og læring
Min oplevelse er, at AI er et værktøj, der gør, at man kan eksekvere processer hurtigere. Men det kan også holde fremdrift på et projekt, som ellers ville stoppe af rigtig mange ting. Det handler ikke om at gøre det nemmere for sig selv — det handler om at gøre produktet bedre. Og dermed også læringen bedre. Jeg føler enormt meget, at jeg lærer af mine fejl undervejs i det her projekt, mere end jeg gør ved at sidde og gøre det manuelt.

03
Research · brugerforståelse
Det der ikke kan genereres
Desk research, brugertest og den forskel det gør

Den bedste beslutning, vi tog i projektet, var at lade brugertest styre iterationerne — ikke bare desk research. Det lyder selvfølgeligt, men er i praksis svært at holde fast i, når man har en stor researchodatabase liggende og en deadline, der nærmer sig. Det er fristende at tage personaen fra research og kalde den for valideret. Det er den ikke.

Vores persona, empathy map og value proposition er itereret på bagkant af brugertestene — ikke på bagkant af, hvad AI mente om Grocotts målgruppe. Den forskel mærkes, når man skal forklare sine designvalg. Den primære empiri er vores. Observationerne er vores. AI strukturerede og analyserede — men den kan ikke sidde overfor et menneske og se, hvor de hakker.

01
Brugertest runde 1
Afdækkede den første version af brugerforståelsen — og pegede direkte på, hvad vi skulle iterere på i persona og empathy map.
02
Brugertest runde 2
Validerede prototypen og gav konkrete designændringer — herunder justeringer i designsystemet, som Nicolai ikke selv havde ønsket.

Vi lærte i sprint 3 og 4, at brugertest kræver planlægning langt tidligere end vi havde regnet med. Det er svært at finde brugere. Man ender med at genbruge sit netværk. Næste projekt: aftal datoer for brugertest allerede, når sprint-strukturen lægges.


04
Design · Figma · prototype
To bookingflows og en designbeslutning der stødte mod klientens ønsker
Hvad det vil sige at bygge noget rigtigt frem for at skitsere

Figma-prototypen er det, jeg er mest stolt af i dette projekt. Ikke fordi den er perfekt — men fordi den er rigtig. Vi byggede et design system fra bunden: komponenter, farvevariabler, typografi, spacing. Desktop og mobil.

Det centrale i prototypen er de to komplette bookingflows: ét for nye klienter i fem trin og ét for eksisterende klienter i fire trin med login. Begge er klikbare og fungerer som en rigtig prototype. Det kræver en helt anden designdisciplin end wireframes — man skal tage stilling til kantsituationer, fejlstater og overgange, ikke bare “den gode vej”.

Bookingflow 1
Ny klient · 5 trin
Behandlingsvalg → dato/tid → personlige oplysninger → bekræftelse → kvittering. Designet til første gang — ingen forudgående relation til klinikken.
Bookingflow 2
Eksisterende klient · 4 trin + login
Login → behandlingsvalg → dato/tid → bekræftelse. Kortere flow med genkendelse og forudfyldte oplysninger som præmis.

Den interessante beslutning kom efter brugertest runde 2. Testresultaterne viste klart, at Nicolais eksisterende farvevalg og logo skabte forvirring og lavede rod i den visuelle hierarki. Vores anbefalinger pegede på en designmæssig justering.

“Nicolai ville gerne beholde tingene, som de var. Vi valgte alligevel at anbefale ændringerne — og begrundede dem med data fra brugertestene. Man skylder ikke klienten at give dem, hvad de vil have. Man skylder dem det, der virker for deres brugere.”


05
Kode · samarbejde
Handoff, JavaScript og det der gik skævt
Det mest konkrete læringsmoment i hele projektet

Vi nåede kodedelen, og her opstod det mest konkrete læringsmoment i hele projektet. Handoff-dokumentet, jeg gav Louise, var ikke godt nok. Enten formulerede jeg det uklart, eller det var svært at læse — sandsynligvis begge dele. Resultatet: Louise lavede JavaScript til en side, vi ikke skulle bruge.

Det betød, at jeg i stedet for at sidde med ny funktionalitet, sad med merge-konflikter og skulle finde ud af, hvordan vi integrerede det hun havde lavet, uden at det gik til spilde. Det er ikke sjovt — men det er der, man lærer branches. Rigtigt.

Vi endte med at lave en UX-ændring for at tilpasse os Louises JavaScript. På grund af tidsnød. Det er en kompromisafgørelse, jeg ikke er fuldt ud tilfreds med — men vi tog den med åbne øjne, og vores brugertest kan efterfølgende vise, om vi skal rulle det tilbage.

Refleksion · handoff
Handoff er ikke en mail. Det er en aftale, der kræver fælles forståelse. Det næste projekt starter med en handoff-standard — et format Louise og jeg definerer sammen inden vi overhovedet begynder at kode.

Samlet refleksion
Hvad der faktisk var svært
Og hvad jeg tager med videre

Det er nemt at beskrive et projekt som “stort og lærerigt”. Det her var begge dele. Men det svære var ikke Figma, ikke AI, ikke klienten.

Det svære var hverdagen. At balancere eksamensprojekt med Amundsen Ink, moderskab og at holde øje med sin studiemakker — det er den version af projektet, der ikke vises i prototype-screenshottet. Men det er den, der satte de reelle begrænsninger. Det har gjort mig bedre til at prioritere. Jeg er begyndt at skelne mellem det, der skal være godt, og det der bare skal være færdigt. Det er ikke det samme — og det er ikke en kapitulation, det er et fagligt valg.

Det jeg konkret tager med: “go”-princippet virker. Planlæg brugertest fra dag ét. Handoff er en aftale, ikke et dokument. Og AI er et værktøj, der gør dig bedre — men kun hvis du er villig til at forstå det, den producerer.

“AI er ikke en genvej. Det er en forstærker — af det du ved, af det du beslutter, og af det du er villig til at forstå.”

Scroll to Top