Hvad ændrer sig i det daglige arbejde?
Det får teamet ud af det
Opgaver, brugeren kan løse selv
Brugeren finder et dokument, tjekker forløbet eller supplerer manglende oplysninger i den rette sammenhæng. Det kræver ikke kendskab til virksomhedens organisationsstruktur.
Skærmbilleder tilpasset opgaven
Kunder, operatører og administratorer kan have forskellige visninger, selv om de arbejder med de samme oplysninger.
Adgang i forskellige arbejdssituationer
Designet tager højde for skrivebord, telefon og de enheder, der faktisk bruges på arbejdet. De vigtigste handlinger er også overskuelige på en mindre skærm.
Hvert skærmbillede skal have et klart formål.
En B2B-portal behøver ikke starte med et omfattende dashboard. Hvis kunden oftest henter dokumenter og tjekker status, skal de opgaver stå forrest. I et internt værktøj kan en kø af sager, der kræver handling, være vigtigere end en graf over hele historikken.
Før vi designer grænsefladen, fastlægger vi de vigtigste brugerforløb. Vi undersøger, hvilke oplysninger en beslutning kræver, hvad der kan vises senere, og hvordan resultatet af en handling forklares. Vi designer også tomme lister, fejl, manglende adgang og ventetilstande.
- Kundeportaler med ordrer, filer og sagshistorik.
- Partnerportaler og B2B-processer.
- Opgaveværktøjer, formularer og håndtering af henvendelser.
- Driftsværktøjer med filtrering, søgning og rapportering.
En gennemtænkt grænseflade bygger på velorganiserede data.
Bag skærmen ligger regler, API’er og en database. Vi aftaler, hvem der ejer oplysningerne, hvordan brugeren identificeres, og hvilke handlinger vedkommende må udføre. Adgangsstyring omfatter både data og handlinger på serveren; en skjult knap erstatter ikke rettigheder.
En portal til flere virksomheder skal holde deres data adskilt. Ved bilag skal der være grænser, tilladte filtyper og adgangsregler. Når flere personer ændrer noget samtidig, skal konflikter kunne opdages, så en ubemærket opdatering ikke sletter andres arbejde.
En telefon er en anden arbejdssituation, ikke en mindre computer.
På en computer er det nemt at sammenligne mange poster. På en telefon er det ofte vigtigere hurtigt at finde en sag, tage et billede eller bekræfte en handling. Vi tilpasser informationshierarki, kontrolelementer og formularer til disse situationer. Vi kontrollerer tastaturbetjening, beskeder og tydelige markeringer.
Adgang via browseren betyder ikke automatisk, at løsningen virker uden internet. Hvis applikationen skal bruges i en hal med dårlig dækning, aftaler vi et særskilt omfang for lokal lagring, synkronisering og løsning af konflikter. Det samme gælder integration med scanner, printer eller andet udstyr.
En prototype afprøver idéen før den fulde udvikling.
Det er værd at gennemgå det vigtigste forløb med en kommende bruger fra begyndelsen. Er betegnelserne forståelige? Kan brugeren finde sin sag? Er statussens betydning tydelig? Den afprøvning afslører problemer, som en funktionsbeskrivelse alene ikke viser.
- Beskriv, hvem der skal bruge applikationen, og under hvilke forhold.
- Udpeg brugerens tre hyppigste opgaver.
- Forbered eksempler på data, formularer og dokumenter.
- Angiv, hvilke systemer der skal levere eller modtage oplysninger.
Fra den første samtale til idriftsættelsen
Brugerforløb
Vi beskriver de vigtigste opgaver, roller og arbejdssituationer. Vi vælger det forløb, den første brugbare version skal dække.
Grænseflade og logik
Vi forbinder skærmdesign med systemregler, data og integrationer. Vi kontrollerer både det normale forløb og undtagelserne.
Lancering og observation
Vi afprøver applikationen på de aftalte enheder. Efter lanceringen samler vi henvendelser og brugernes kommende behov.
Spørgsmål, der er værd at stille
Hvad er forskellen på en webapplikation og et website?
Et website præsenterer først og fremmest oplysninger. En applikation gør det muligt at arbejde med data: oprette sager, godkende, søge eller ændre status. Den kan have login, roller og særskilte visninger til forskellige brugere.
Skal vi have en app i App Store eller Google Play?
Ikke for at få adgang via browseren. Hvis der er behov for enhedsfunktioner, notifikationer eller offlinearbejde, undersøger vi muligheder og begrænsninger. Først derefter vurderer vi, om browseren er tilstrækkelig.
Kan portalen bruges af kunder fra forskellige virksomheder?
Ja, hvis organisationsstruktur, rettigheder og adskillelse af data er gennemtænkt. Det skal også aftales, hvem der inviterer brugere, fjerner adgang og har ansvaret for konti hos kunden.
Kan vi begynde med en prototype?
Ja. Prototypen bruges til at afprøve opbygningen og arbejdsgangen. Den må ikke forveksles med et færdigt system: produktionsdata, adgangsstyring, integrationer og vedligeholdelse kræver en særskilt implementering.
