|
| 1 | +--- |
| 2 | +name: ontwerprichtlijnen |
| 3 | +description: "Een verzameling ontwerprichtlijnen en interface-principes. Gebruik deze skill wanneer er iets ontworpen, gebouwd of beoordeeld wordt aan een interface — websites, apps, dashboards, forms, componenten, mockups — zodat de keuzes aansluiten bij deze voorkeuren. Trigger ook bij vragen over \"hoe zou je dit vormgeven\", interactie-design, microcopy, of het reviewen van bestaande UI." |
| 4 | +user-invocable: true |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- |
| 8 | + GEGENEREERD BESTAND — niet handmatig bewerken. |
| 9 | + Bron: src/docs/design-guidelines.mdx (Storybook "Docs/Ontwerprichtlijnen"). |
| 10 | + Hergenereren: npm run generate:skill-docs |
| 11 | +--> |
| 12 | + |
| 13 | +# Ontwerprichtlijnen |
| 14 | + |
| 15 | +Een verzameling ontwerprichtlijnen en interface-principes. Gebruik deze skill wanneer er iets ontworpen, gebouwd of beoordeeld wordt aan een interface — websites, apps, dashboards, forms, componenten, mockups — zodat de keuzes aansluiten bij deze voorkeuren. Trigger ook bij vragen over "hoe zou je dit vormgeven", interactie-design, microcopy, of het reviewen van bestaande UI. |
| 16 | + |
| 17 | +## Invoer en formulieren |
| 18 | + |
| 19 | +- **Vermijd disabled knoppen.** Laat de gebruiker de actie uitvoeren en geef daarna feedback — in de huidige view of op de volgende — over wat er mis is en hoe het op te lossen. Disabled knoppen verbergen de reden en frustreren. |
| 20 | +- **Vermijd destructieve knop naast een bevestigende knop.** Plaats acties als "Annuleer", "Verwijder" of "Reset" niet pal naast "Bewaar" of "Bevestig". Geef ze visuele en fysieke afstand om misklikken te voorkomen. Bijvoorbeeld: "Annuleer" rechtsboven in de title bar en "Bewaar" als primaire knop onderaan. Hetzelfde geldt voor een "Terug"-knop pal naast "Volgende stap" in een multi-page progress-flow: een misklik gooit de gebruiker een stap terug en kost ingevulde voortgang, dus geef ook daar de terug-actie afstand van de primaire vooruit-knop. |
| 21 | +- **Markeer optionele velden, niet verplichte.** Label alleen wat optioneel is, niet wat verplicht is met een asterisk. Zet daarvoor het `optional`-attribuut op `nldd-form-field` — dat toont automatisch een "Optioneel"-badge bij het label (aanpasbaar via `optional-label`); je schrijft de tekst dus niet zelf. Een formulier hoort zo klein mogelijk te zijn, dus optionele velden zouden in de minderheid moeten zijn — en dan is het efficiënter om die uitzonderingen te markeren dan de regel. |
| 22 | +- **Volgorde van vragen volgt het gedachteproces van de gebruiker, niet de database.** Vraag eerst waar de gebruiker mee zit (bericht, betaalwijze, productvoorkeur) en bewaar verplichte contactgegevens voor het eind. Zo verlaag je de cognitieve last vroeg en bouw je commitment op. Bij een contactformulier dus eerst het berichtveld tonen, daarna pas naam en e-mail — niet andersom, zoals de meeste formulieren doen. |
| 23 | +- **Volledige naam in één veld, niet voornaam/tussenvoegsel/achternaam apart.** Vraag aanspreeknaam apart als optioneel veld met een label als "Hoe wil je dat we je aanspreken?". Uit onderzoek bij een klant bleek 68% met voornaam aangesproken te willen worden — dat beslis je niet voor de gebruiker. |
| 24 | +- **Groepeer velden met dezelfde interactievorm, waar dat logisch kan.** Alle text-inputs bij elkaar, alle checkboxes bij elkaar. Voorkomt onnodig wisselen tussen toetsenbord en muis (desktop) of tussen verschillende input-types (mobiel). Niet forceren als de inhoudelijke volgorde belangrijker is. |
| 25 | +- **Zet "Onthoud mij" / "Stay signed in" standaard aan.** Tegenwoordig is dit de juiste default — gebruikers verwachten het, en wie het niet wil zet het zelf uit. |
| 26 | + |
| 27 | +## Navigatie en structuur |
| 28 | + |
| 29 | +- **Vermijd FAQ's, gebruik inline help.** Plaats uitleg op de plek waar de vraag ontstaat in plaats van die te verbannen naar een aparte FAQ-pagina. Een losse FAQ dwingt de gebruiker te zoeken en duidt vaak op een interface die zichzelf niet uitlegt; inline help lost de twijfel op precies waar die opkomt. |
| 30 | +- **Vermijd expand/collapse.** Als content uitklapt verschuift de pagina en raakt de gebruiker zijn oriëntatie kwijt, waardoor hij ondersteunende taken moet uitvoeren zoals terugscrollen — werk dat niets met zijn eigenlijke doel te maken heeft. Toon liever weinig informatie direct, of presenteer veel informatie los van de hoofdpagina — in een sheet of op een losse pagina. |
| 31 | +- **Verwerk UI en navigatie zoveel mogelijk in de content.** Verminder de hoeveelheid en focus op UI buiten de content. Hetzelfde geldt voor het menu — laat de homepage zelf het menu zijn in plaats van een rijtje woorden in de header. |
| 32 | +- **Geen carrousels, tenzij de items samen één doel dragen.** Carrousels op homepages worden vrijwel niet geklikt. Acceptabel is een carrousel met items die gezamenlijk hetzelfde doel hebben (vakantiefoto's, portfoliowerk, één productlijn). |
| 33 | +- **Geen megamenu's.** Inflexibel (één dimensie terwijl content meerdere heeft), creëren onzekerheid (de website accepteert de keuze van de gebruiker niet maar opent weer een menu), werken slecht op touch en mobiel. Vervangen door overzicht op een landingspagina gaf in IBM-onderzoek 219% meer engagement. |
| 34 | +- **Geen wizards.** Een wizard is een symptoom van een slechte onderliggende UI. Maak die UI goed in plaats van er een procesomweg omheen te bouwen. Als een stap-voor-stap proces de juiste interface is (bijv. een echte werkstroom), noem het dan ook geen wizard — het *is* de interface. |
| 35 | +- **Kruimelpaden als ondersteunende interactie, niet als dominante navigatie.** Een breadcrumb in de footer is prima als orientatiehulp. Bovenaan de pagina als hoofdnavigatie werkt 'm averechts: kruimelpaden laten zien waar je *bent*, niet waar je naartoe *wilt*, terwijl gebruikersgedachten niet lineair-hiërarchisch zijn. |
| 36 | +- **Geen vage container-begrippen.** Vermijd "informatie", "documenten", "downloads", "service", "folders", "algemeen". Beschrijf het onderwerp of doel ("Ondersteuning" i.p.v. "Service"; "Printbare promotie" i.p.v. "Downloads"). De gebruiker mag niet hoeven gokken wat erachter zit. |
| 37 | + |
| 38 | +## Feedback en state |
| 39 | + |
| 40 | +- **Eén optie is geen optie.** Bied geen modal dialog met maar één knop aan. Als er niets te kiezen valt, hoeft de gebruiker niet onderbroken te worden met een dialoog die hij toch alleen maar kan wegklikken — gebruik dan een minder opdringerige melding (toast, inline bericht) of laat de onderbreking helemaal weg. |
| 41 | +- **Undo boven confirm.** Een actie ongedaan kunnen maken is bijna altijd beter dan vooraf bevestigen. Mensen klikken op autopilot "OK", dus confirm-dialogen vangen weinig fouten. Autosave + versies > "wil je opslaan?". Modals alleen als er écht geen weg terug is. |
| 42 | +- **Liever een contextueel-window dan een modal.** Een contextueel-window zit visueel aan de actie vast (zoals een popover bij een knop) en dekt de onderliggende pagina niet af. Het forceert geen keuze: wegkijken = annuleren. Bij een echte modal verdwijnt vaak juist de informatie die de gebruiker nodig heeft om te beslissen. |
| 43 | +- **In een bevestigingsmodal voor een destructieve actie is "Behoud" de primary, niet "Verwijder".** Toon de niet-destructieve uitweg ("Behoud document") als primary actie en de destructieve actie als secondary. De primary knop is waar de gebruiker op autopilot naartoe gaat — dat hoort de veilige uitweg te zijn, niet de onomkeerbare actie. |
| 44 | +- **Statische skeleton loading, geen shimmer-animatie.** Een shimmer — en animatie in het algemeen — trekt te veel aandacht en verlegt die naar het wachten zelf in plaats van naar de opbouw van de interface, en vertraagt zo de beleving onnodig; hou de skeleton daarom statisch. Toon een statische skeleton die direct de uiteindelijke structuur van het scherm weerspiegelt: de vormen, content en interface-elementen die ook in het eindresultaat aanwezig zijn, of een blurred versie van de uiteindelijke image. Dat geeft de gebruiker meteen context over wat er laadt en richt de aandacht op wat er gaat verschijnen. Doordat enkel de definitieve vormen alvast getoond worden, ontstaat een vloeiende overgang van leeg naar volledig geladen — elementen verschijnen niet eerst in een voorlopige staat om daarna nog te veranderen of te verdwijnen, waardoor de interface consistenter en voorspelbaarder aanvoelt. |
| 45 | +- **Duurt het laden langer dan één seconde, toon dan een activity indicator over het geheel.** Geef expliciet aan dat het laden langer duurt dan verwacht. De reeds ingeladen content wordt daarbij gedeeltelijk gedimd of vervaagd achter de indicator, zodat duidelijk is dat het proces nog gaande is. |
| 46 | + |
| 47 | +## Microcopy en toon |
| 48 | + |
| 49 | +- **Directe actie = gebiedende wijs, indirecte actie = volledig werkwoord.** Een knop die de actie meteen uitvoert krijgt de gebiedende wijs ("Log in" submit het formulier). Een knop die ergens naartoe leidt waar de actie nog moet gebeuren krijgt het hele werkwoord ("Inloggen" → opent het inlogscherm). Zo voelt de gebruiker het verschil tussen "nu gebeurt het" en "ik ga ergens heen". |
| 50 | +- **Knoplabels beschrijven de actie, gebruik geen "OK".** "Bewaar", "Verwijder account", "Verder naar overzicht" — dan begrijpt de gebruiker wat een knop doet zonder de begeleidende tekst te lezen. "OK" en "Annuleren" dwingen tot lezen en zijn dubbelzinnig. |
| 51 | +- **Begin knoppen en titels met een betekenisvol woord.** Niet "de"/"het"/"een" of een vulwoord — gebruikers scannen de eerste woorden. Plaats het beschrijvende zelfstandig naamwoord of werkwoord vooraan. |
| 52 | +- **Geen ALL-CAPS in knoppen of labels.** Verzwakt het woordbeeld en maakt scannen lastiger. "Menu", niet "MENU". |
| 53 | + |
| 54 | +## Visueel en layout |
| 55 | + |
| 56 | +- **Tekst heeft voorkeur boven iconen.** Een tekstlabel is ondubbelzinnig; een icoon vraagt om interpretatie en wordt vaak verkeerd begrepen. Gebruik tekst als primaire drager van betekenis, en iconen hooguit ter ondersteuning ernaast. Uitzondering: iconen die al universeel zijn aangeleerd (zoals navigatiepijltjes vorige/volgende). |
| 57 | +- **Hiërarchie primair via lichtsterkte, ondersteund door saturatie — niet via kleurtoon.** Twee tabs in andere kleurtonen lezen als "gelijkwaardig anders"; een verschil in lichtsterkte (en in mindere mate saturatie) leest als hiërarchie. Bijkomend voordeel: kleurenblinde gebruikers zien het onderscheid ook. Test je UI in grijstinten om te checken of de hiërarchie nog werkt. |
| 58 | +- **Plaats primaire actieknoppen in lijn met de oogbeweging.** Onder het laatste inputveld, niet rechts uitgelijnd ergens waar de gebruiker eerst moet zoeken. De ogen verwachten de volgende actie in het verlengde van wat ze net gedaan hebben. |
| 59 | +- **`cursor: pointer` alleen voor links, niet voor buttons.** Wees een goed system citizen: respecteer het native gedrag waarbij de pointer navigatie aankondigt. Dat de hele industrie pointer óók op buttons zet is een slechte norm — links (zeker die in een nieuwe tab openen) zijn daardoor niet meer herkenbaar, terwijl gebruikers het onderscheid tussen "binnen de browser" en "buiten de browser" wél nodig hebben. Een link navigeert, een knop doet iets; de cursor hoort dat verschil te bewaren. Een knop is een knop. |
| 60 | + |
| 61 | +## Strategie en proces |
| 62 | + |
| 63 | +- **Ontwerp voor doelen, niet voor doelgroepen of persona's.** Persona's zijn nuttig om ideeën aan te toetsen, maar slecht om vanuit te ontwerpen — ze leiden tot modi (verschillende UI per doelgroep) en onhoudbare interfaces voor gebruikers die tussen doelgroepen wisselen. Een doel is stabiel; een doelgroep niet. |
| 64 | +- **Ontwerp voor effectiviteit en efficiëntie, geen korte-termijntrucs.** Banner-blindness omzeilen door dingen te verschuiven werkt één keer, dan ontwikkelen gebruikers nieuwe blindheid en zit je gevangen in een kat-en-muis-spel. Ontwerp op effectiviteit en efficiëntie voor de lange termijn; gebruikers zijn niet achterlijk en passen zich aan een serieuze UI aan. |
| 65 | +- **Minder of simpeler ogende controls is niet altijd beter.** Eenvoud is een middel, geen doel. Een control die de taak nodig heeft weghalen of versimpelen om het beeld op te ruimen, verschuift de complexiteit alleen — naar verborgen modi, extra stappen of giswerk — en maakt de taak niet eenvoudiger. Stem het aantal en de zichtbaarheid van controls af op wat de taak vraagt, niet op hoe opgeruimd het oogt. (Jef Raskin, *The Humane Interface*, 2004, p. 54: "Fewer buttons and simpler-looking controls are not always better. The lesson applies to screen design as well as to instruments and appliances.") |
| 66 | +- **A/B-test pas binnen een theoretisch kader.** Zonder kader "bewijs" je significant onzin, want statistiek vertelt je niet *waarom*. Stel een hypothese op basis van bestaande kennis, test om die te toetsen — niet om 'm te vinden. (Klassiek voorbeeld: de hamburger-icoon A/B-tests die elkaar tegenspraken omdat affordance niet als variabele werd meegenomen.) |
| 67 | + |
| 68 | +## Overig |
| 69 | + |
| 70 | +_(nog leeg)_ |
0 commit comments