Ik denk niet dat er veel dingen zijn die ik leutiger vind dan door een toepassing (of een dienst, of een proces, of een procedure) gaan en zien waar het kapot gaat, en te zeggen hoe het eventueel te vermijden is dat het kapot gaat.

Ik heb dat bij wijze van concurrentievervalsende vriendendienst nog eens voor niets gedaan, deze week.

Het zijn altijd dezelfde klassiekers:

• accessibility: kleurcontrast en toetsenbordnavigatie en dingen (idealiter ook allerlei ARIA-zaken, maar da’s al voor gevorderden die het echt goed willen doen)
• informatiearchitectuur en navigatie: onduidelijke hiërarchie, te complex, verkeerde prioriteiten, gebrek aan consistentie, of vaak de klassieker van alles in te delen in termen van uw interne organisatie / uw businessobjecten / uw databasetabellen
• naamgeving en labels
• formulieren die niet goed omgaan met al dan niet dirty, impliciete volgordes die niet goed zitten, verkeerde controls voor verkeerde zaken, validatie die niet doet wat ze moet doen — niet nakijken of de einddatum wel na de begindatum is of niet minstens een sanity check op data doen genre een opleiding die 1 seconde kan duren
• feedback: te veel, te weinig, op de verkeerde manier, op de verkeerde plaats, etc.
• niet nagedacht hebben over user journeys of typische use cases of toptaken
• enzoverder
• enzoverder
• enzoverder

Het allerbeste natuurlijk is dat zo’n problemen niet naar boven moeten komen als iets al gemaakt is, en dat het op voorhand goed ontworpen en getest en gevalideerd is, maar oh wat is het leutig om een niet-echt-evidente toepassing te doorploeteren en te zien waar er allerlei zou kunnen rechtgetrokken worden.