Når AI bygger en app: Designfælder du skal fange

Du har bedt AI om at bygge et lille system til at følge op på tilbud. Der er kunder, beløb og datoer. Du kan oprette, rette og slette. Det hele virker.

Så tager en kollega det i brug.

Hun skriver en note, åbner en anden side og mister teksten. Hun sender dig et link til de tilbud, der mangler svar. Du får hele listen. Hun får en fejl, men kan ikke se, om tilbuddet blev sendt.

Ingen af de problemer kræver en ny farve eller en anden skrifttype. De kræver, at nogen har tænkt over, hvad der sker undervejs i arbejdet.

Det er den del af design, denne guide handler om. Du kan bruge den, hvis du bygger med en AI-agent. Du kan også bruge den, når du skal vurdere en løsning, andre har bygget for dig.

Hvad kalder vi de her mønstre?

Et designmønster er en løsning, der kan bruges igen. Det kan være en indkøbskurv, en søgning eller muligheden for at fortryde. Et antimønster er en løsning, der ser rimelig ud, men skaber problemer i brug.

Jeg bruger ordet designfælder her. Det er de steder, hvor en app opfylder kravet på papiret, men gør selve opgaven svær. UX står for brugeroplevelse. Derfor kan du også kalde dem UX-antimønstre.

Fælderne er ikke nye eller særlige for AI. Mennesker bygger dem også. Guiden måler ikke, hvor ofte de enkelte AI-modeller laver dem. Guiden er en liste over ting, du kan undersøge i dit eget produkt.

En erfaren designer spørger blandt andet: Hvad sker der, hvis jeg forlader opgaven midt i en ændring? Hvis nettet fejler? Hvis jeg gør det samme 40 gange? Hvis jeg trykker forkert?

De spørgsmål kan du lære at stille. Du behøver ikke kende navnet på en CSS-egenskab for at opdage, at en knap flytter sig, mens du prøver at ramme den.

Sådan bruger du prompterne

Under hvert mønster er en prompt, du kan åbne og kopiere. Vælg én ad gangen. Erstat teksten i kantede parenteser med din side, fil eller opgave.

Prompterne er på engelsk, så begreber som autosave, rollback og URL state står i deres gængse form. Du kan stadig tale dansk med agenten. Prompterne beder den også bevare dansk tekst i selve appen.

Giv agenten adgang til den relevante kode og en testudgave af appen. Bed den markere det, den ikke kan afprøve. En prompt er et krav til arbejdet, ikke et bevis på, at det virker.

Beskyt arbejdet, før du pynter på det

1. Gem-knappen gør brugeren til sikkerhedsnet

Forestil dig en note til et tilbud. Du skriver ti linjer. Så ringer telefonen, og du åbner kundens kontaktkort. Da du vender tilbage, er noten væk. Du glemte at trykke Gem.

Til løbende skrivearbejde giver det mening at gemme en kladde i baggrunden. Det kaldes autosave. Du skal kunne skrive videre, mens appen gemmer. Vis status uden at afbryde arbejdet, for eksempel “Gemmer”, “Gemt” eller “Ikke gemt”.

Skeln mellem at gemme en kladde og at sende den. En kladde må gerne gemmes af sig selv. At sende tilbuddet til kunden kræver et særskilt valg. “Gemt” må aldrig betyde “Sendt”.

En advarsel, når du forlader siden, kan hjælpe med tekst, der ikke er gemt. Men browseren viser den ikke i alle situationer, især på mobil. Den kan derfor ikke stå alene som værn mod tab. Det fremgår også af MDN’s beskrivelse af browserens lukkeadvarsel.

Implement non-blocking autosave for [editor or form]. Inspect the existing save flow first and reuse its components. Keep user-facing copy in Danish.

Separate saving a draft from sending or publishing it. Show saving, saved and unsaved states truthfully. Preserve input on failure and provide retry. Prevent older requests from overwriting newer edits. A beforeunload warning must not be the only protection.

Verify typing during saves, a failed request, reconnecting and reloading. Report exactly which edits survived and which cases you could not test.

Prøv selv: Skriv en note. Afbryd nettet. Skriv videre. Appen må ikke påstå, at alt er gemt. Slå nettet til igen, og genindlæs siden. Kontrollér, hvilke dele af noten der er gemt.

2. Hvert klik sætter hele siden på pause

Du markerer en intern opgave som færdig. Hele siden bliver grå, mens en cirkel snurrer. Du venter, selv om du bare vil videre til næste række.

Ved en lille ændring, som let kan fortrydes, kan appen vise resultatet med det samme. Serveren gemmer i baggrunden. Det kaldes en optimistisk opdatering.

Det kræver en plan for fejl. Hvis serveren afviser ændringen, skal appen rette visningen og forklare det. Ellers ser du en færdig opgave, som stadig er åben for dine kolleger. TanStack beskriver både den hurtige visning og håndtering af fejl.

Brug ikke samme greb til alt. Når du sender et tilbud, bør appen vise “Sender”, indtil den har fået svar. Ved et uklart svar skal den undersøge status. Et nyt klik må ikke sende det samme tilbud to gange.

Review the actions in [screen or flow] and implement optimistic updates only where success is likely and the change is reversible. Keep the existing design system and Danish UI copy.

For each optimistic action, reconcile with the server response and handle failure with rollback or a clear recovery path. Do not falsely confirm sending, payment or publishing. Prevent duplicate submissions. If an outcome is unknown, check its status before retrying.

Test success, rejection, slow responses and repeated clicks. Report the observed final state.

Prøv selv: Få en ændring til at fejle. Kontrollér, at appen ender med den rigtige status, og at et nyt forsøg ikke skaber dubletter.

3. Oprydning betyder permanent sletning

Et gammelt tilbud skal ud af din aktive liste. Appen tilbyder kun Slet. Nu skal du enten beholde gamle tilbud i listen eller slette dem og miste historikken.

Giv arkivering sit eget formål: Sagen forlader den daglige visning, men kan findes og hentes tilbage. Sletning er en anden handling. Den forskel skal være tydelig i både menuen og resultatet.

Ved handlinger, der let kan gøres om, kan Fortryd spare en række bekræftelser. Ved tab, der ikke kan gøres om, skal konsekvensen frem før handlingen. “Slet 24 tilbud permanent” fortæller mere end “Er du sikker?”.

En Fortryd-besked, der forsvinder efter få sekunder, bør ikke være eneste vej tilbage til vigtigt indhold. Et arkiv eller en papirkurv giver tid til at opdage fejlen. Det følger princippet om kontrol og en vej ud i Jakob Nielsens regler for brugervenlighed.

Improve record removal in [screen or flow]. Reuse existing components and keep UI copy in Danish.

Separate archive, restore and permanent delete. Archived records must remain discoverable and restorable. Offer undo for reversible actions, but do not make a short-lived toast the only recovery path. Confirm permanent deletion with the object name and a clear consequence before executing it.

Use disposable test records. Verify archive, undo, leaving the page, finding the archive and restoring a record with its history intact.

Prøv selv: Arkivér en sag, forlad siden, og find den igen. Kontrollér, at historik og bilag stadig er der.

4. To kolleger overskriver hinandens arbejde

Du retter en pris, mens din kollega skriver en note på samme tilbud. I trykker begge Gem. Den, der gemmer sidst, overskriver den andens ændring.

Det er et problem, selv om hver Gem-knap virker alene. Aftal, hvad der skal ske, når flere retter det samme. Appen kan opdage en nyere version og bede dig tage stilling. Den kan også låse en post under redigering eller understøtte fælles redigering.

Fælles redigering kræver mere end at vise to små profilbilleder. Selve teksten og data skal flettes eller beskyttes mod konflikt. Til et lille system kan en klar besked om en nyere version være nok som første løsning.

Prevent silent lost updates in [shared editing flow]. Inspect the current persistence model and choose the smallest suitable conflict strategy: version checks, locking or collaborative editing. Explain the tradeoff. Keep user-facing copy in Danish.

Enforce conflict detection where writes are accepted, not only in the browser. Preserve the user's unsaved work when a conflict occurs. Give them a clear way to inspect the newer version and reconcile changes.

Test two independent sessions editing the same record, then saving in reverse order. Show which values survived.

Prøv selv: Åbn samme tilbud i to sessioner. Ret noget forskelligt begge steder. Gem først i den ene session og derefter i den anden. Kontrollér, at begge ændringer er bevaret, eller at appen advarer om konflikten.

Lad appen huske, hvor du er

5. Et link glemmer den visning, du ville dele

Du har fundet tilbud med status “Afventer svar” og sorteret efter frist. Du sender adressen til en kollega. Hun åbner den og ser en helt anden liste.

Et link bør bevare de valg, der bestemmer, hvad listen viser. Det kan være fanen, filteret, rækkefølgen og sidetallet. Et eksempel er /tilbud?status=afventer&sort=frist.

Når du åbner et tilbud og går tilbage, bør du også lande samme sted i listen. Ellers skal du finde din plads efter hver sag. Vercels retningslinjer beskriver, hvordan adressen kan bevare dine valg, og hvordan du kommer tilbage til samme sted i listen.

Et delt link er dog ikke et øjebliksbillede. Data kan ændre sig. Og linket giver ikke i sig selv adgang. Del kun visningsvalg, som må stå i adressen, ikke noter, adgangsnøgler eller følsomme oplysninger.

Improve URL state and navigation in [list or screen]. Persist relevant filters, sort order, tabs and pagination in the URL. Reuse the existing router and keep UI copy in Danish.

Support direct links, refresh and browser Back/Forward. Restore the previous list position after opening a record. Validate URL parameters. Do not place sensitive values in the URL or treat a shared link as permission to access data.

Test a filtered link in another authorized session, then open a record, go back and refresh. Report any state that is lost.

Prøv selv: Del en filtreret visning med en kollega, der har adgang. Åbn en sag og gå tilbage. Kontrollér både filtrene og din plads.

6. Listen fortsætter, men opgaven har ingen afslutning

Når du leder efter inspiration, kan nye billeder godt dukke op, mens du scroller. Når du skal gennemgå 83 tilbud, vil du også vide, hvor langt du er.

Uendelig scroll er derfor et valg, som afhænger af opgaven. En billedstrøm og en liste over udestående betalinger har ikke samme behov. Sidetal giver faste steder at vende tilbage til. “Vis flere” giver brugeren kontrol over, hvornår listen vokser.

Nielsen Norman Group beskriver blandt andet problemer med at finde tilbage. De peger også på, at sidetal eller en Vis flere-knap kan passe bedre til nogle sider.

Til tilbudslisten ville jeg starte med søgning, filtre, antal resultater og sidetal. Til et galleri ville jeg afprøve løbende indlæsning. Valget skal følge arbejdet, ikke hvad der ser flot ud i en demo.

Review navigation in [list]. The user's task is [find one record, review every record, or browse for inspiration]. Compare pagination, Load more and infinite scroll for that task. Recommend one and implement it using existing components and Danish UI copy.

Preserve filters and position when returning from a detail view. Make loading, failure, result count and the end of the list understandable where applicable. Keep keyboard navigation usable.

Test finding the same record again and, for a finite review task, determining when all relevant records have been reviewed.

Prøv selv: Find en bestemt post, åbn dens detaljer, og gå tilbage til listen. Find så posten igen. Se også, om du kan afgøre, at alle relevante poster er gennemgået.

7. Hver ny side opfinder sin egen måde at virke på

Kundelisten har søgning øverst. Tilbudslisten gemmer den bag et ikon. På den ene side åbner et klik detaljerne. På den anden markerer det rækken.

Hver side kan være forståelig alene. Samlet kræver appen, at du lærer de samme ting igen.

Vælg en eksisterende side, der løser en lignende opgave godt. Bed AI om at følge både dens udseende og dens adfærd. Hvordan søger man? Hvordan vælger man flere rækker? Hvor vises fejl?

Genbrug komponenterne bag siden, hvor det giver mening. Hvis du kun kopierer udseendet, kan siderne langsomt udvikle hver sine fejl. Bevar også sproget: En kunde skal ikke pludselig hedde en kontakt i næste trin.

Use [existing reference page or component] as the reference for [new or inconsistent screen]. Inspect both the rendered behavior and the implementation. Keep Danish terminology consistent.

Reuse the project's search, filtering, row actions, selection, loading and error patterns where the tasks match. Reuse shared components rather than copying their appearance into a separate implementation. Explain any intentional differences required by this task.

Run the same representative task on both screens. Report remaining behavioral differences and verify that the reference screen still works after shared changes.

Prøv selv: Løs samme type opgave på to sider. Notér de steder, hvor dine vaner fra den ene side ikke virker på den anden.

Gør næste skridt tydeligt

8. Den tomme side siger bare “Ingen data”

En tom liste kan betyde flere ting. Du har endnu ikke oprettet et tilbud. Dit filter giver ingen resultater. Eller serveren kunne ikke hente listen.

De tre situationer kræver hver sit næste skridt. “Opret tilbud”, “Nulstil filtre” og “Prøv igen” hjælper med hver sit problem. En fejl må ikke ligne en tom konto, hvor alt er forsvundet.

En tom side er også en del af din app. Den skal vise, hvad der sker, og hjælpe dig videre. Det beskriver Nielsen Norman Group i deres guide til tomme sider.

Implement distinct states for [list or screen]: first use with no records, no matches after filtering, loading, and request failure. Reuse existing components and keep all UI copy in Danish.

Give each state the appropriate next action, such as creating a record, clearing filters or retrying. Do not show a request failure as an empty account. Keep the layout stable and announce meaningful asynchronous status changes without moving focus unnecessarily.

Use fixtures or a test environment to trigger all four states. Report the message, available action and result for each.

Prøv selv: Åbn en ny konto, søg efter noget, der ikke findes, og få hentningen til at fejle. De tre skærme skal kunne skelnes fra hinanden.

9. Fejlen fortæller ikke, hvad du kan gøre

“Noget gik galt” giver dig ingen hjælp. Blev tilbuddet sendt? Er det mailadressen, der er forkert? Skal du starte forfra?

Fortæl, hvad der fejlede, og hvad brugeren kan gøre. Hvis et felt er forkert, skal fejlen stå ved feltet. Bevar det, der allerede er skrevet. GOV.UK’s vejledning om fejl i felter beskriver netop de greb.

Hvis svaret fra serveren mangler, kender appen måske ikke udfaldet. Så skal den sige det og undersøge status. Beskeden må ikke give indtryk af, at tilbuddet er sendt, hvis appen ikke ved det.

Ved flere fejl kan en samlet liste øverst hjælpe. Gør hver fejl i listen til et link til det relevante felt. Det er mønstret i GOV.UK’s fejloversigt.

Review error handling in [form or flow] and implement clear recovery paths. Keep the UI copy in Danish and reuse the existing form components.

Distinguish field validation, service failure and an unknown operation outcome. Place field errors next to their fields, connect them accessibly and add a linked error summary when useful. Preserve all input. Never claim a draft is saved or an operation failed unless the system knows that.

Test two field errors, a service error and a missing response. Verify recovery without data loss or duplicate submissions.

Prøv selv: Lav to fejl i samme formular. Du skal kunne finde begge, rette dem og fortsætte uden at udfylde resten igen.

10. Alt på siden kæmper om din opmærksomhed

En oversigt kan få seks store tal, farvede kort, ikoner og en graf, selv om din opgave er at finde de tilbud, du skal følge op på i dag.

Start med opgaven: Hvad skal brugeren kunne se og beslutte her? På tilbudssiden kan svaret være kunde, frist, beløb og seneste kontakt. Samlet omsætning kan vises på en anden side.

Brug størrelse, placering og luft til at vise, hvad der hører sammen. Undgå en ny ramme om hver lille oplysning. Det er en af de ting, Jakub Krehels arbejde med layout sætter fokus på. Detaljer om hans bidrag står nederst i guiden.

Lad knapper sige, hvad de gør. “Send tilbud” og “Gem kladde” er to forskellige valg. Hvis begge ligner den primære handling, bliver forskellen sværere at se. GOV.UK anbefaler at undgå flere primære knapper i samme område.

Improve the visual hierarchy of [screen] for this task: [specific user goal]. Inspect the current page before changing it. Preserve the design system and Danish UI copy.

Make the information and primary action needed for that task easy to find. Explain what each metric, chart and card contributes. Remove or move elements that distract from the task, while keeping necessary functions accessible. Use grouping, spacing and type hierarchy before adding decoration.

Verify the task on desktop and mobile. Show the before/after changes and explain how each supports the stated goal.

Prøv selv: Bed en kollega finde næste tilbud, der skal følges op på. Lad være med at pege. Se, hvad personen leder efter først.

Test det, som et skærmbillede ikke viser

11. Appen virker kun med mus og godt syn

En menu åbner, når du holder musen over et ikon. Med tastaturet kan du ikke åbne den. Eller du åbner en dialog og kan ikke se, hvilken knap eller hvilket felt der er valgt.

Brug almindelige knapper, links og felter, hvor de passer til opgaven. De har allerede adfærd, som folk og hjælpemidler kender. Vis tydeligt, hvilken knap eller hvilket felt tastaturet styrer. Det kaldes synligt fokus. En status skal også have tekst, så rød og grøn ikke bærer hele betydningen.

En dialog skal have en tydelig titel og en vej ud. Når dialogen åbner, skal tastaturets fokus flyttes ind i den. Når den lukker, skal fokus normalt tilbage til den knap, der åbnede den. W3C’s dialogmønster beskriver den adfærd.

Status som “Gemt” skal også kunne formidles af en skærmlæser. Den må gerne blive læst op uden at flytte brugeren væk fra feltet. W3C beskriver dette under statusbeskeder.

Audit and fix accessibility in [complete user flow]. Prefer native buttons, links and form controls. Preserve the visual design and Danish UI copy.

Verify keyboard operation, accessible names, visible focus, logical focus order and dialog focus management. Do not convey status through color alone. Make asynchronous status messages available to assistive technology without excessive announcements. Check the flow at 200% zoom.

Use keyboard testing and an accessibility audit. Test with a screen reader if available. Report each method used and its limits; do not claim full accessibility compliance from automated checks alone.

Prøv selv: Læg musen væk. Opret og ret et tilbud med tastaturet. Zoom derefter siden til 200 procent. Kontrollér, at du stadig kan læse og betjene den.

12. Animationen er flot første gang og langsom resten af dagen

En menu glider ind. Hver række dukker op for sig. Hvert skift mellem faner får indholdet til at svæve på plads.

Det kan se fint ud i en optagelse. Prøv så at skifte mellem ti tilbud. Nu venter du på den samme bevægelse igen og igen.

Emil Kowalski bruger hyppighed og formål til at vurdere bevægelse. En effekt ved et sjældent besøg har en anden rolle end en menu, du åbner hele dagen. Det forklarer han i You Don’t Need Animations.

Bevægelse kan vise, hvor noget flyttede hen, eller bekræfte et tryk. Den bør ikke forsinke næste handling. Respektér også brugerens valg om mindre bevægelse. W3C beskriver behovet for at kunne slå unødig bevægelse fra.

Review motion in [screen or flow]. For each animation, identify its purpose and how often the user encounters it. Remove or shorten motion that delays frequent actions. Preserve meaningful feedback and the existing design system. Keep UI copy in Danish.

Respect prefers-reduced-motion. Make state changes understandable without animation. Ensure users can continue or reverse an action without waiting for decorative motion to finish.

Repeat the main task ten times, test rapid interactions, and test with reduced motion enabled. Report which animations changed and whether any action still feels blocked.

Prøv selv: Udfør samme opgave ti gange. Slå mindre bevægelse til på din enhed, og se, om appen stadig viser klart, hvad der sker.

13. Designet virker kun med pæne testdata

“Anna” passer i kundekortet. “Sønderjysk Montage og Industriservice” skubber knappen ud af boksen. Et stort beløb overlapper teksten i næste kolonne. Et tilbud uden kontaktperson får siden til at ligne en fejl.

Giv appen besværlige, men mulige data. Brug lange navne, tomme felter, store tal og mange rækker. Afprøv også en smal skærm. En tekst, der bliver kortet af, skal kunne læses et andet sted, hvis brugeren har brug for den.

Ved beløb hjælper en fast placering og ens format med at sammenligne rækker. Datoer skal være klare for dine brugere. Hvis et tilbud viser “04/05”, skal kunden ikke gætte, om det er april eller maj.

Det er konkrete ting, som går igen i arbejdet med typografi og robuste komponenter hos Jakub Krehel og Emil Kowalski. Formålet er at opdage skjult tekst og knapper, der ikke kan bruges, før appen tages i brug.

Stress-test [screen or component] with synthetic data: empty and missing values, one-character and very long names, large amounts, many rows and unusually long labels. Include unbroken strings. Keep UI copy in Danish.

Test desktop, a 320px-wide viewport and 200% zoom. Fix clipping, overlap, unreachable controls and misleading truncation. Provide access to full values where needed. Keep dates and numbers clear and consistently formatted for Danish users.

Reuse existing components. Report the cases tested, the failures found and the observed result after each fix.

Prøv selv: Sæt et langt firmanavn ind. Åbn siden på telefonen og på en stor skærm. Find det fulde navn og alle handlinger begge steder.

Giv AI en opgave, den kan kontrollere

“Gør den mere lækker” giver meget plads til at ændre farver og tilføje effekter. Beskriv i stedet den person, der bruger appen, og den opgave, der skal lykkes.

Denne prompt samler kontrollen af en hel opgave. Brug den først til at finde problemer. Vælg derefter, hvad der skal rettes, og brug de korte prompts ovenfor til de enkelte ændringer.

Review [app URL and codebase] for this workflow: [start, task and intended outcome]. The user is [role] and performs it [frequency]. Use a test environment and synthetic records. Keep proposed UI copy in Danish.

Start with a review; do not change code yet. Inspect the existing design system, open the running app and complete the workflow.

Check data preservation, autosave, optimistic updates and rollback, undo/archive/delete, concurrent edits, URL state, Back/Forward navigation, empty/loading/error states, visual hierarchy, keyboard access, reduced motion and realistic edge-case data.

For each finding, provide:
- The action that reproduces it.
- Expected behavior and observed behavior.
- User impact and supporting evidence.
- A specific fix using existing components.

Prioritize data loss, false status and blocked tasks over visual polish. Separate defects from preferences. Mark anything you could not verify. If the app cannot be run, state the limits of a code-only review.

After we select the fixes, implement them and repeat the affected workflow with slow requests, a failed request and long input. Report the checks and outcomes. Passing builds or unit tests alone do not establish that the user experience works.

Lav først én side, der virker godt. Brug den som reference, når du bygger videre. Skriv de valg ned, som skal gælde flere steder. Det kan være, at kladder gemmes løbende, og at en arkiveret sag altid kan hentes tilbage.

Gem reglerne i projektets egne instruktioner sammen med et konkret eksempel. De kan senere samles i en skill. Men reglerne skal komme fra jeres opgaver og de problemer, I har fundet.

En bestået kodetest fortæller kun noget om det, testen undersøger. Bed også agenten bruge den kørende app. Se selv en kollega løse opgaven. Hvis personen farer vild, er det et fund, selv om ingen test fejler.

Begynd med én arbejdsgang denne uge

Du behøver ikke rette hele appen på én gang. Vælg den opgave, I udfører ofte, eller den, hvor en fejl koster mest arbejde.

1. Følg opgaven fra start til slut. Skriv ned, hvor du tøver, venter eller må gentage noget.
2. Fremprovokér en fejl. Afbryd nettet, skriv en ugyldig værdi i et felt eller åbn samme post to steder.
3. Ret årsagen. Prioritér tab af arbejde og falsk status før kosmetiske ændringer.
4. Prøv igen med en kollega. Giv personen en opgave, og se, om den kan løses uden din hjælp.
5. Genbrug løsningen. Opdatér den fælles komponent og projektets instruktioner, så næste side får samme adfærd.

Når du kan lukke en sag, finde tilbage til den og rette en fejl uden at starte forfra, har du forbedret noget, folk mærker i deres arbejde. Det er et konkret mål for din næste runde med AI.

Inspiration og fagligt grundlag

Tak til Mahmoud Abdelwahab fra Railway for oplægget hos AI Engineer, som er afsættet for guiden. Han viser, hvad der skal til, før en app er rar at bruge hver dag. Blandt hans emner er autosave, fortryd, arkivering og links, der bevarer din visning.

I videoen henviser han også til designarbejde fra Jakub Krehel og Emil Kowalski. Jeg har læst relevante dele af deres materiale om layout, tekst, bevægelse og test af grænsetilfælde. Guiden omsætter principperne til egne eksempler. Den kræver ikke, at du installerer deres skills.

Materialet findes på GitHub:

• Jakub Krehels skills til design af brugerflader
• Emil Kowalskis skills til design og bevægelse

De øvrige kilder er linket ved de relevante afsnit. Tilgængelighed bygger på W3C’s vejledninger. Fejl og knapper er krydstjekket med GOV.UK. Navigation og tomme visninger er suppleret med Nielsen Norman Group og Vercel.

Eksemplerne med tilbud er opdigtede. Valg om deling, samtidige rettelser og status ved ukendte udfald er mine praktiske udvidelser. Uendelig scroll behandles som et valg ud fra opgaven, ikke som et generelt krav.