Ga naar hoofdinhoud

Selectiefase

In het kort

In de selectiefase bepaalt het kernteam of een Candidate component klaar is om Hall of Fame te worden. Je controleert of de component in templates en productie wordt gebruikt, voert een toegankelijkheidsaudit uit, en verwerkt community feedback. Het resultaat is een component die bewezen heeft geschikt te zijn voor breed hergebruik met garanties op kwaliteit.

Wat doe je in deze fase?

  • Verifiëren dat component in templates wordt gebruikt
  • Bevestigen van productie gebruik bij minimaal 2 organisaties
  • Toegankelijkheidsaudit uitvoeren in templates
  • API stabiliteit evalueren
  • Documentatie testen met gebruikers
  • Community feedback verzamelen en verwerken
  • Candidate component verbeteren op basis van feedback

Component gebruikt in templates

Doel: Bevestigen dat de component werkt in realistische templates die door de community zijn gemaakt.

Waarom belangrijk? Templates tonen hoe componenten in echte scenario's worden gecombineerd en gebruikt. Dit zijn de perfecte testomgevingen voor toegankelijkheidsaudits.

Acties

  1. Check welke templates de component gebruiken:

    • Bekijk Community Sprints
    • Check GitHub repositories van templates
    • Vraag in Slack welke templates de component bevatten

  2. Evalueer template geschiktheid voor audit:

    • Bevat de template verschillende varianten van de component?
    • Wordt de component in verschillende contexten gebruikt?
    • Is de template representatief voor echt gebruik?

  3. Minimaal vereist:

    • Component wordt gebruikt in minimaal 1 community template
    • Template bevat meerdere use cases van de component
    • Template is publiek beschikbaar

  4. Documenteer template gebruik:

    ## Templates die {component-naam} gebruiken


- **Template naam**: {naam}
  - Repository: {url}
  - Gebruikt varianten: {lijst}
  - Contexten: {beschrijving}

🚩 Checkpoint: Template gebruik geverifieerd

Component gebruikt in productie bij minimaal 2 organisaties

Doel: Bevestigen dat de component breed bruikbaar is en niet alleen voor één specifieke situatie werkt.

Waarom belangrijk? Gebruik in productie bewijst dat de component geschikt is voor echte projecten en dat organisaties er vertrouwen in hebben.

Acties

  1. Inventariseer productie gebruik:

    • Check welke organisaties de Candidate component gebruiken
    • Vraag in Slack en Open Hours naar productie implementaties
    • Bekijk GitHub Discussions voor meldingen van gebruik

  2. Verifieer productie status:

    • Is de component live op een publieke website?
    • Wordt de component actief door eindgebruikers gebruikt?
    • Is de implementatie representatief (niet alleen één pagina)?

  3. Documenteer productie gebruik:

    • Organisatie naam
    • URL waar component gebruikt wordt
    • Welke varianten worden gebruikt
    • Hoe lang al in productie
    • Contact persoon voor vervolgvragen

  4. Check diversiteit:

    • Zijn het echt 2+ verschillende organisaties (niet 2 projecten van dezelfde organisatie)?
    • Verschillen de use cases (verschillende contexten, verschillende huisstijlen)?

🚩 Checkpoint: Productie gebruik geverifieerd

Toegankelijkheidsaudit in community templates

Doel: Garanderen dat de component toegankelijk is in realistische templates die door de community beschikbaar zijn gesteld.

Waarom belangrijk? Door templates te gebruiken hoeven we geen toestemming te vragen aan externe organisaties en kunnen we de component testen in verschillende realistische contexten.

Acties

  1. Selecteer template(s) voor audit:

    • Gebruik de templates uit de vorige checkpoint
    • Kies template(s) waar component het meest divers wordt gebruikt
    • Bij voorkeur meerdere templates om verschillende contexten te testen

  2. Voer WCAG-EM audit uit op templates:

    • Volg de WCAG-EM methodologie
    • Focus op de component binnen de template context
    • Test op WCAG 2.2 niveau AA
    • Test in verschillende browsers en met verschillende hulpmiddelen:
      • Screenreaders (NVDA, JAWS, VoiceOver)
      • Toetsenbordnavigatie
      • Zoom tot 200%
      • Forced-colors mode

  3. Documenteer audit resultaten:

    ## Hall of Fame toegankelijkheidsaudit


**Audit uitgevoerd door**: {naam toegankelijkheidsspecialist}
**Datum**: {datum}
**Template(s)**: {naam template(s)}
**URLs**: {urls van templates}
**WCAG versie**: 2.2 Level AA


### Scope


- Templates: {lijst van geteste templates}
- Component varianten: {lijst}
- Browsers: {lijst}
- Hulpmiddelen: {lijst}


### Resultaten


- ✅ Succescriteria die voldoen: {aantal}/XX
- ⚠️ Issues gevonden: {aantal}
- 🔧 Issues opgelost: {aantal}


### Kritieke issues


{Beschrijving van eventuele kritieke toegankelijkheidsproblemen}


### Aanbevelingen


{Aanbevelingen voor verbetering}

  4. Los kritieke issues op:

    • Maak GitHub issues voor gevonden problemen
    • Fix in Candidate component
    • Publiceer update
    • Update templates en retest

  5. Verkrijg audit certificaat/rapport:

    • Officieel rapport van de audit
    • Bewijs dat component in templates aan WCAG 2.2 AA voldoet

🚩 Checkpoint: Toegankelijkheidsaudit succesvol

Stabiele API zonder breaking changes verwacht

Doel: Garanderen dat teams de component veilig kunnen updaten zonder onverwachte problemen.

Waarom belangrijk? Hall of Fame componenten moeten betrouwbaar zijn. Teams moeten er op kunnen vertrouwen dat updates veilig zijn.

Acties

  1. Evalueer API stabiliteit:

    • Zijn er nog bekende problemen met de API?
    • Zijn er feature requests die breaking changes vereisen?
    • Zijn prop/class namen consistent met andere Hall of Fame componenten?

  2. Check feedback van gebruikers:

    • Zijn er klachten over de API?
    • Missen gebruikers essentiële features?
    • Zijn er verwarringen over hoe de component te gebruiken?

  3. Besluit over API finalisatie:

    • Moeten er nog last-minute breaking changes worden doorgevoerd?
    • Zo ja: doe dit NU, voordat component Hall of Fame wordt
    • Documenteer waarom de API klaar is

  4. Commit aan semantic versioning:

    • Van nu af aan: alleen breaking changes in major releases
    • Feature toevoegingen in minor releases
    • Bugfixes in patch releases

🚩 Checkpoint: API stabiel

Documentatie compleet en getest

Doel: Garanderen dat gebruikers de component correct kunnen implementeren zonder hulp.

Waarom belangrijk? Incomplete of onduidelijke documentatie leidt tot verkeerd gebruik en frustratie.

Acties

  1. Review documentatie volledigheid:

    • ✅ "Wanneer wel/niet gebruiken" is helder
    • ✅ Code voorbeelden voor React, HTML/CSS
    • ✅ Alle props/variants gedocumenteerd
    • ✅ Toegankelijkheidscriteria met WCAG referenties
    • ✅ Design tokens uitgelegd
    • ✅ Do's and don'ts met visuals
    • ✅ Praktische voorbeelden voor alle doelgroepen

  2. Test documentatie met echte gebruikers:

    • Laat iemand die component niet kent hem implementeren
    • Kunnen ze het zonder extra hulp?
    • Welke vragen komen op?
    • Wat mist er?

  3. Verbeter op basis van feedback:

    • Voeg missende informatie toe
    • Verduidelijk verwarrende secties
    • Voeg meer voorbeelden toe waar nodig

🚩 Checkpoint: Documentatie compleet

Community feedback verzameld

Doel: Garanderen dat de community akkoord is met promotie naar Hall of Fame.

Waarom belangrijk? De community is de gebruiker - hun feedback bepaalt of de component klaar is.

Acties

  1. Kondig aan dat component overwogen wordt voor Hall of Fame:

    Post in Slack:

    📣 We overwegen {component-naam} te promoveren naar Hall of Fame!


De component wordt gebruikt door {organisatie-1} en {organisatie-2} in productie en heeft een toegankelijkheidsaudit doorlopen.


**Laatste kans voor feedback!**


- Mis je features?
- Heb je issues gevonden?
- Zou je iets anders willen zien?


Laat het ons weten in de [GitHub Discussion]({url}) vóór {deadline}.

  2. Wacht 2 weken op feedback

  3. Verwerk feedback:

    • Kritieke issues: moeten opgelost worden vóór promotie
    • Feature requests: evalueer of dit nu moet of later kan
    • Nice-to-haves: voeg toe aan backlog voor toekomstige releases

  4. Besluit of component klaar is:

    • Zijn alle kritieke issues opgelost?
    • Is de community tevreden?
    • Zijn er geen blokkerende bezwaren?

🚩 Checkpoint: Community feedback verwerkt

Verbeter Candidate component op basis van feedback

Doel: Verwerk alle feedback en verbeteringen voordat de component Hall of Fame wordt.

Waarom belangrijk? Dit is de laatste kans om breaking changes door te voeren voordat we naar versie 1.0.0 gaan. Na Hall of Fame promotie moeten breaking changes wachten tot een major release.

Acties

  1. Prioriteer feedback:

    • Must-have: Kritieke bugs, toegankelijkheidsproblemen, API inconsistenties
    • Should-have: Belangrijke features, grote verbeteringen
    • Nice-to-have: Kleine verbeteringen, optimalisaties

  2. Implementeer must-have verbeteringen:

    • Fix kritieke bugs
    • Los toegankelijkheidsproblemen op
    • Maak API consistent met andere Hall of Fame componenten
    • Implementeer essentiële features

  3. Evalueer should-have verbeteringen:

    • Overleg met kernteam: implementeren nu of later?
    • Als later: voeg toe aan backlog voor toekomstige minor releases
    • Als nu: implementeer voordat je doorgaat

  4. Publiceer updates als nieuwe Candidate versie:

    npx changeset
    • Kies minor voor features, patch voor bugfixes
    • Schrijf duidelijke changelog
    • Merge Version Packages PR

  5. Informeer gebruikers over updates: Post in Slack:

    📦 {component-naam} Candidate update!


We hebben feedback verwerkt en de component verbeterd:


- ✅ [Belangrijkste verbetering 1]
- ✅ [Belangrijkste verbetering 2]
- ✅ [Belangrijkste verbetering 3]


**Breaking changes?** {Ja/Nee}
{Als ja: beschrijf migratiestappen}


Update: `npm install @nl-design-system-candidate/{component-name}@latest`


We gaan nu verder met de Hall of Fame promotie!

  6. Wacht op bevestiging:

    • Geef gebruikers 1 week om te testen
    • Los eventuele nieuwe issues op
    • Bevestig dat er geen blokkerende problemen zijn

  7. Documenteer finale state:

    ## Candidate component verbeterd voor Hall of Fame


**Versie**: {versienummer}
**Datum**: {datum}


### Verbeteringen doorgevoerd:


- {Lijst van alle wijzigingen}


### Breaking changes:


- {Lijst, of "Geen"}


### Bekende beperkingen:


- {Lijst, of "Geen"}


De component is nu klaar voor Hall of Fame promotie.

🚩 Checkpoint: Candidate component verbeterd

Volgende stap

Ga door naar de Promotiefase.

Vragen?

Heb je een vraag over de Selectiefase?