Begynd med én virkelig opgave
Jeg begynder med én virkelig opgave, ikke en lang funktionsliste. En idé til en app kan indeholde login, dashboard, beskeder og kalender. Før jeg bygger, afklarer jeg, hvem der skal gøre hvad, og hvad der står i vejen.
Et eksempel kunne være en medarbejder, som hver morgen leder efter status på en ordre i tre forskellige systemer. Problemet er ikke nødvendigvis, at virksomheden mangler et dashboard. Problemet er, at informationen ikke er let at finde, eller at ingen ved, hvilken status der gælder.
Beskriv opgaven med tre spørgsmål: Hvem gør hvad? Hvad står i vejen i dag? Hvordan kan man se, at det er blevet bedre? Hvis de svar ikke er tydelige, er der brug for mere afklaring — ikke mere kode.
Afgræns den første version
Den første version skal kunne løse opgaven fra begyndelse til slutning. Det er bedre med ét sammenhængende forløb end fem halvfærdige funktioner. I ordreeksemplet kan første version være et enkelt overblik med ansvarlig person, aktuel status og tidspunkt for sidste ændring.
En god prioritering skelner mellem nødvendige funktioner og muligheder til senere. Adgang til oplysninger og beskyttelse af data er nødvendige, hvis løsningen bruger følsomme oplysninger. En avanceret rapportfunktion er måske ikke nødvendig for at lære, om selve overblikket fungerer.
Gør forløbet synligt
Før en løsning bliver stor, skal man kunne vise dens vigtigste skærmbilleder og forklare sammenhængen mellem dem. Hvad ser brugeren først? Hvad kan vedkommende vælge? Hvad sker der efter et valg? Og hvordan får brugeren hjælp, hvis noget går galt?
Brug realistiske eksempler. En tom prototype kan se nem ud, men skjule problemer med lange navne, manglende information eller mange samtidige opgaver. Test derfor et almindeligt forløb, et tilfælde med manglende data og en situation, hvor brugeren vil rette en fejl.
Afklar data, adgang og drift
En virksomhedsapp er også et spørgsmål om ansvar. Hvem må se oplysningerne? Hvem må ændre dem? Hvad skal gemmes, og hvor længe? Hvem hjælper, hvis en arbejdsgang stopper?
Hvis løsningen skal bruge eksisterende systemer, er det vigtigt at forstå, hvor de oprindelige oplysninger findes. To steder med hver sin sandhed skaber sjældent et bedre overblik. Beslut derfor, hvilket system der ejer hvilke data, og hvordan ændringer bliver synlige.
Personoplysninger og adgangsstyring skal vurderes ud fra den konkrete løsning. En generel guide kan ikke erstatte en teknisk eller juridisk vurdering af virksomhedens behov.
Vælg kode og værktøjer efter opgaven
Jeg arbejder med Lovable, Cursor, React/TypeScript, Python og Supabase. Værktøjerne har forskellige roller, og det er ikke nødvendigt at bruge dem alle i hvert projekt.
Lovable kan gøre en idé til en første webapp. Cursor bruges i arbejdet med kodebasen. React organiserer brugerfladen i komponenter, mens TypeScript beskriver de data og funktioner, komponenterne arbejder med. En kundesag kan for eksempel have et ID, en ansvarlig medarbejder og en afgrænset liste af statusværdier.
Supabase kan bruges til en PostgreSQL-database, login og adgang til data. Python kan håndtere databehandling, automatisering eller serverlogik, hvis den konkrete opgave kræver det. Vigtige valg handler også om, hvem der må ændre oplysninger, hvor adgangsnøgler opbevares, og hvordan løsningen håndterer fejl.
Forbind systemer uden at skabe flere sandheder
Et CRM, en webshop og et økonomisystem kan allerede have oplysninger, som appen har brug for. En API-forbindelse gør det muligt at hente eller opdatere dem. En webhook gør det muligt at reagere, når et system melder om en hændelse.
Mulige integrationsmål kan være Shopify, WooCommerce, HubSpot, Pipedrive, e-conomic, Dinero, Microsoft 365 eller Google Workspace. Det er eksempler, ikke en liste over dokumenterede kundeleverancer. Den faktiske integration afhænger af systemets API og den adgang, kunden kan stille til rådighed.
Hvis en ny webshopordre skal vises i et internt dashboard, skal løsningen kende ordre-ID'et, hvilke oplysninger der må kopieres, og hvilket system der ejer ordrestatus. Den bør også kunne genkende en besked, som allerede er behandlet, så samme ordre ikke oprettes to gange. Fejl og eventuelle genforsøg skal være en del af designet, ikke en senere overraskelse.
Se kode og teknologi på forsiden og eksemplet på en sammenhængende ordreproces.
Afprøv med rigtige arbejdsopgaver
Bed brugeren om at løse en konkret opgave uden at forklare hvert klik. Se, hvor vedkommende tøver, misforstår information eller forlader forløbet. Den slags observationer er mere brugbare end spørgsmålet: »Synes du, det ser godt ud?«
Feedback behøver ikke blive til en ny funktion. Måske skal en tekst være tydeligere. Måske mangler en status. Måske løser appen et problem, som allerede burde være afklaret i arbejdsgangen uden for skærmen.
Byg næste version ud fra erfaring
Vælg få tegn på, om løsningen hjælper: Hvor let er det at finde informationen? Hvor mange spørgsmål opstår stadig? Kan opgaven gennemføres uden hjælp? Det er ikke nødvendigt at opfinde store effektmål, før man har set reel brug.
Den næste version bør svare på det, man har lært. Når behovet ændrer sig, kan løsningen ændre sig med det. Målet er ikke at have den længste funktionsliste, men en app, som passer til virksomhedens hverdag.
Se også perspektivet på e-handel og digitale værktøjer, eller gå tilbage til metoden på forsiden.