Veel bedrijven ontwikkelen met low-code applicaties die aansluiten op hun unieke bedrijfsprocessen. De uniekheid van die processen zit zelden in de manier waarop ze hun financiële administratie voeren of hoe ze inkopen, maar raken des te meer aan processen die dicht tegen de klant aan zitten en worden uitgevoerd door medewerkers op de werkvloer, door servicemonteurs, wijkverpleegkundigen of vergunningcontroleurs. En soms door de klanten zelf. Dit zijn werknemers die in de regel weinig affiniteit hebben met it, maar die prima overweg kunnen met de apps op hun telefoon. Dat betekent dat een zichzelf wijzende ux (user experience)-design het uitgangspunt moet zijn voor het ontwerp van bedrijfsapplicaties.
Dat klinkt logisch, maar is het in de it allerminst. Veel systemen stellen het bedrijfsproces centraal in plaats van de gebruiker. Denk aan de complexe erp-applicaties, waar je een uitgebreide training voor moet volgen om een beetje te snappen wat je waar kunt vinden.
Wat er gebeurt als je verschillende gebruikersgroepen met verschillende werkwijzes en behoeften allemaal in dezelfde mal probeert te stoppen, zag je een jaar of toen, vijftien geleden in ziekenhuizen met de intrede van het Elektronisch Patiëntendossier (EPD). EPD’s waren ontworpen om de declaratieprocessen te ondersteunen. Artsen herkenden de processen niet, wisten niet wat ze waar moesten vastleggen en moesten onnodig vaak klikken. Het gevolg: iedereen gebruikte het systeem anders, zelfs artsen binnen één specialisme en maatschap. Ziekenhuizen haalden daardoor bij lange na niet de waarde eruit die leveranciers hen voorhielden. Vervolgens werden jarenlang dure consultants ingehuurd om met her-implementaties en trainingen de schade te herstellen, wat in de meeste ziekenhuizen nog altijd niet is gelukt.
Perspectief van de gebruiker
Het grote voordeel van het ontwikkelen van taakgerichte applicaties met behulp van low-code, is dat je die taken een centrale plek kunt geven in de applicatie. Neem het proces van de medewerker als uitgangspunt, en niet het achterliggende administratieve proces dat nodig is om de bewuste transactie te verwerken.
Daarvoor gebruik je bijvoorbeeld user stories, beschrijvingen van wat de applicatie moet doen vanuit het perspectief van de gebruiker. Hoe moeten de workflows lopen? Welke stappen in het proces moeten volgtijdelijk worden gezet en welke zijn flexibeler in te plannen? Maar ook: op wat voor device werken gebruikers en wat betekent dit voor de look-and-feel van de applicatie? Een buitendienstmedewerker die primair een tablet of smartphone gebruikt, stelt andere eisen dan een binnendienstmedewerker die met twee monitors werkt.
Een user story bestaat altijd uit drie onderdelen:
- Een beschrijving van de user story in de vorm van: ‘Als [verantwoordelijkheid] wil ik [functionaliteit] zodat ik [reden]’.
- Gesprek over de user story om de details te bespreken. Deze worden vastgelegd in een sprintplanning.
- De testdetails in de vorm van de acceptatiecriteria en de ‘definition of done’.
Vervolgens is het de kunst de user stories te vertalen in een goed ux-design. Een design dat voor zich spreekt, dat geen toelichting behoeft en wat zo is ontworpen dat medewerkers (of klanten) met een minimumaantal muisklikken precies dat kunnen doen wat ze beogen.
Geef UX-design een belangrijke plek in je DevOps-team
Wil jij in jouw organisatie de onderscheidende processen écht onderscheidend laten zijn en kies je daarom voor low-code? Zet dan ook meteen de volgende stap en stel het ux-design centraal. Denk niet: de business is toch vertegenwoordigd in het devops-team en dat denkt nu toch mee? Natuurlijk, dat is een belangrijke voorwaarde voor succes, maar geen garantie. Wil je dat jouw low-code-applicaties écht aansluiten bij wat de gebruiker ervan verlangt, trek dan ook een ux-designer aan.
(Auteur Marcel Antons is director strategy & innovation bij MyBrand.)
