Designprincipper

Visibility (synlighed)

Beskrivelse: Alle brugerens muligheder i systemet skal så vidt muligt være så synlige som muligt. Hvis der eksempelvis er mere end 2 klik til en vigtig funktion, så er der tale om lav synlighed. Hvis der er langt flere knapper på skærmen end brugerne kan overskue og at de derfor ikke forstår alle deres muligheder, så er der også tale om lav synlighed.

Tommelfingerregel: Hvis man hurtigt kan se de vigtigste funktioner, så er der god synlighed. 

Feedback

Beskrivelse: Når brugeren anvender en af systemets funktioner, som når de skriver deres navn eller klikker på en knap, så skal de have feedback. Dvs. at de skal vide at det de gjorde virkede. Navnet skal komme frem på skærmen, knappen skal lyse op etc.. Det er kun ved hjælp af feedback at brugeren ved at det de laver har en effekt. 

Når man skriver sit brugernavn for at logge ind og så ser på skærmen at der ikke sker noget, så ved man at der er noget galt. Det der er galt er at man ikke får den feedback man leder efter. Ligeledes kan man i dårlige systemer opleve at man får en anden feedback end den man regnede med.

Tommelfingerregel: Når brugeren gør noget skal systemet fortælle brugeren hvad de har gjort, det er god feedback. 

Affordance (forståelig beskaffenhed)

Beskrivelse: Man skal kunne se på tingene hvordan de skal bruges. Hvis der er en indkøbskurv oppe i højre hjørne af skærmen, så forventer brugeren at den fungerer som en indkøbskurv. Det er den affordance indkøbskurven har, som ikon.  Ligeledes er det internationale ikon for at "gemme", et billede af en diskette. En menu er ofte tre linjer over hinanden. 

Hvis man går ud på en hjemmeside og ser en masse knapper placeret ved siden af hinanden i toppen af skærmen eller ude i siden, så forventer man at det er en menu man kigger på og at man derfor kan trykke på knapperne for at komme andre steder hen på siden. Hvis det viser sig at der rent faktisk ikke er tale om en menu bliver brugeren skuffet og så kan man tale om dårlig "affordance". 

Tommelfingerregel: Brugeren skal kunne se på systemets knapper hvad de skal bruges til. Ikoner er generelt gode eksempler. f.eks. "indkøbskurven" eller "den lille person" som betyder "profil".

Mapping (kortlægning)

Beskrivelse: Sammenhængen mellem en knap og dens effekt (det den gør) kan ses som et spørgsmål om "kortlægning"/"mapping". Hvis man drejer til venstre med rettet i sin bil, så drejer bilen også til venstre. Det er god mapping. Dårlig mapping ville være hvis bilen i stedet drejede til højre. Hvis det var tilfældet ville bilens bruger hele tiden skulle tænke over hvilken side de ville til, før de drejede på rettet. Det ville være mentalt hårdt arbejde. En af årsagerne til at mange har svært ved at parallelparkere er at bilens mapping er omvendt når man kører baglæns.  

I et IT-system skal den måde som diverse knapper og kontroller bruges på,  minde om den effekt de har. Når man vil se hvad der er længere nede på skærmen så skal man scrolle nedad og ikke omvendt. Hvis man derimod bruger mobil og swiper med fingeren, så skal man swipe opad for at se hvad  der er længere nede, fordi det skal føles som om at man trækker i "papiret" med fingeren. Dermed fungerer kontrollen på samme måde som den ønskede effekt og derfor kan vi sige at der er god mapping.

Mapping og feedback hænger tæt sammen. Hvis vi ville swipe nedad på en side og skærmen bevægede sig i den modsatte retning, så ville vi kalde det dårlig mapping, men fordi vi hurtigt opdager at der er noget galt, kunne vi samtidig sige at der er god feedback. Dårlig feedback ville være hvis vi blev i tvivl om hvad der egentlig skete og om vores handling overhovedet havde en effekt.

Tommelfingerregel: God mapping er når brugerens forventninger bliver mødt. Dvs. de får den rigtige "feedback". Hvis brugeren tror at den knap der ligner en indkøbskurv leder til indkøbskurven, så skal den lede til indkøbskurven!

Constraints (begrænsninger)

Beskrivelse: Constraint kan oversættes til "begrænsning" og vedrører de begrænsninger der er i et design. F.eks. er skærmens størrelse en naturlig begrænsning, eller måske er der en begrænsning på hvor langt man kan scrolle på siden. Ligeledes kan en menu ikke have uendeligt mange knapper. Alle designs har nogle naturlige begrænsninger som ikke kan undgås. Udover det skal man som designer også overveje om det nogle gange kan være en fordel at begrænse nogle af brugerens mulighed for at opnå en større brugervenlighed. Det er dejligt at have mange muligheder, men hvis der er for mange bliver systemet ofte uoverskueligt. 

Et eksempel er sværhedsgraderne i computerspil. Normalt er der tre: let, mellem og svær. Men der er jo mange forskellige ting i et spil som kan gøres lettere eller sværere. I princippet kunne brugeren blive præsenteret for over hundrede knapper med forskellige indstillinger der påvirkede sværhedsgraden. Det er de færreste brugere som gider det. Derfor har man valgt at lave den constraint at inddele alle mulighederne i kun tre kategorier: let, mellem og svær. 

Tommelfingerregel: Begræns brugerens muligheder så de ikke skal tage stilling til for meget. Det leder ofte også til synlighed.

Consistency (konsistens)

Beskrivelse: Tilbage-knappen skal være det samme sted på alle skærme og fungere på samme måde når man trykker på den. Det samme gælder for alle knapper og funktioner som brugeren skal bruge flere gange. Hvis feedbacken som brugeren får ved at trykke på en knap er at knappen lyser op, så bør det gælde for alle knapper i systemet. Hvis feedbacken ændrer sig på et af systemets skærme (f.eks. hvis knapperne ikke længere lyser op, men i stedet bliver runde) så kan brugeren blive forvirret og være usikker på om knapperne stadig gør sådan som brugeren forventer.

Hertil bør et IT-system, som ikke har kunstneriske ambitioner, også være konsistent i sin brug af farver og former. Det skaber for det meste bare forvirring hos brugeren hvis ikke skærmene i systemet ligner hinanden. Brugeren kan blive i tvivl om de stadig er i samme system.

Tommelfingerregel: Hvis dit IT-system minder om andre IT-systemer, så er der større sandsynlighed for at brugeren kan finde ud af at bruge det. 

Se videogennemgange af desginbegreberne

Eksempler på dårligt design:

Her kan du se eksempler på dårligt UI (User Interface) design.

• Brug fagets begreber i din beskrivelse

  • • Designprincipper længere oppe på denne side.

    • Brugervenlighedsprincipper (se link til bog længere oppe).

    • Gestaltlove (se link til bog længere oppe).

• Giv eksempler fra jeres app (gerne screenshots)

  • • Nogle eksempler på eksempler:

    • "Vi har placeret indkøbskurven i øverste højre hjørne fordi det er sådan andre apps gør og derfor er det noget brugeren forventer og det er konsistent (consistency)"

    • "Vores app hjælper folk i haven og vores målgruppe er folk med grønne fingre, derfor har vi satset på en kombination af blå gul og grøn, hvor grøn er mest dominerende. Til vores knapper bruger vi en særlig mørkegrøn for at fremhæve dem fra baggrunden. Det skal gøre knapperne mere tydelige og hænger derfor sammen med appens overordnede visibility i det at brugeren hurtigere kan få overblik over knapperne".

    • "Vi har valgt at have navigationen i toppen af skærmene, hvor alle knapper ligner hinanden og afgrænsede i en lille kasse. På den måde bruger vi loven om lighed og loven om lukkethed så brugeren hurtigt ser at knapperne hænger sammen. På grund af forventninger fra andre apps (consistency) vil brugeren forhåbentlig også hurtigt indse at det må være navigationen de kigger. Den knap i navigationen der leder tilbage til forsiden tænkte vi at brugeren ofte kan få brug for og derfor har vi givet den en anden farve. Således bryder vi med loven om lighed for at få brugeren til hurtigt at se netop den knap".