At AIMMS, we are working on WebUI: an application that lets app developers build applications themselves. A toolbox for creating new tools. That may sound abstract, but it has very concrete consequences for how we design. In a classic UX project, you usually design directly for the end user. With WebUI, however, we mainly design for the app developers. In turn, they create something for their own users. This layered setup brings challenges that we rarely encounter in this form in our work. In this article, we’ll walk you through three of those challenges.
Ontwerpen voor twee lagen gebruikers
Het meest fundamentele verschil met andere projecten is dat we bij WebUI ontwerpen voor twee lagen gebruikers. Aan de ene kant zijn er de app-developers, de directe gebruikers van WebUI. Aan de andere kant de eindgebruikers van de applicaties die de app-developers bouwen.
Binnen AIMMS komt dat tot uiting in twee ontwikkelteams. Het WebUI-team ontwikkelt het platform, en een ander team gebruikt dat platform om Supply Chain Navigator (SCN) te bouwen: een tool waarmee bedrijven hun toeleveringsketen optimaliseren. De app-developers die aan SCN werken zijn dus tegelijk gebruiker én maker.
En daar zit de uitdaging. Als ontwerper heb je nauwelijks invloed op de uiteindelijke gebruikerservaring van de eindgebruiker. Die ervaring wordt vormgegeven door de app-developer, vaak zonder diepgaande kennis van UX. Het is aan ons om WebUI zo te ontwerpen dat het gebruik ervan intuïtief en richtinggevend is, zónder te veel op te leggen.
Met andere woorden, we ontwerpen tooling die richting geeft, maar ook vrijheid laat. Een platform dat niet alleen functioneel is voor de makers, maar indirect ook de eindgebruiker helpt. Dat vraagt om een andere manier van denken.
Vrijheid vs. voorspelbaarheid
Omdat WebUI gebruikt wordt om allerlei soorten applicaties te bouwen, moet het platform extreem generiek zijn. App developers willen er supply chain tools mee maken, maar ook dashboards, configurators en alles daartussenin. Dat betekent dat wij als ontwerpers functionaliteiten ontwikkelen met een open einde: componenten die flexibel zijn en op verschillende manieren kunnen worden ingezet.
Op papier klinkt dat goed. Alles is mogelijk. In de praktijk betekent het dat elke app-developer een functionaliteit net even anders toepast. De één gebruikt een datagrid als interactieve tabel, de ander als inputformulier. Dat leidt niet alleen tot een breed scala aan implementaties, maar ook tot onverwachte bugs, UX-inconsistenties en feature requests die elkaar soms tegenspreken.
Het is balanceren. Te veel vrijheid en je verliest grip op de gebruikerservaring. Te veel restricties en je belemmert de creativiteit van de makers. We proberen daarin bewuste keuzes te maken: heldere defaults, slimme beperkingen en visuele kaders die richting geven zonder te dicteren.
Het ontwerpen van WebUI is daarmee niet het ontwerpen van een eindproduct, maar van een systeem. Een set bouwstenen die stevig genoeg zijn om op te vertrouwen, en flexibel genoeg om ruimte te laten voor interpretatie.
Het verschil met klassieke UX-projecten
Bij de meeste projecten ontwerpen we direct voor de eindgebruiker. We spreken gebruikers, begrijpen hun context, en stemmen het product af op hun specifieke behoeften. Functionaliteiten hebben dan een duidelijk doel: één knop, één taak, één gewenste uitkomst.
Bij WebUI werkt dat fundamenteel anders. We ontwerpen geen eindproducten, maar een platform waarmee anderen producten maken. De app-developers zijn de gebruikers, maar hun output (de apps die zij bouwen) bepaalt hoe de eindgebruikers WebUI indirect ervaren.
Een goede vergelijking: bij een klassiek project ontwerp je de stoel. Bij dit project ontwerp je de hamer, de zaag en de handleiding, in de hoop dat de stoel stevig en comfortabel wordt. Je denkt als UX-designer niet alleen na over gebruiksgemak, maar ook over misbruik. Over flexibiliteit zonder verwarring. Over hoeveel verschillende mensen met verschillende doelen toch binnen hetzelfde systeem succesvol kunnen werken.
Dat is wat WebUI uniek maakt onder de projecten waar we aan werken. De complexiteit wordt niet gevormd door de omvang of de techniek, maar door de gelaagdheid. En daarmee de indirecte controle op de ervaring van de eindgebruiker.
Ontwerpen in complexiteit
WebUI dwingt je om anders te denken. Niet over één gebruiker, maar over meerdere lagen tegelijk. Niet over een afgerond product, maar over een systeem dat anderen in staat stelt hun eigen producten te maken.
Dat vraagt om keuzes die je bij andere projecten zelden hoeft te maken. Wanneer geef je vrijheid, en wanneer stel je grenzen? Hoe ontwerp je voor gebruik dat je niet kunt voorzien? En hoe zorg je dat de eindgebruiker, die jouw ontwerp nooit direct ziet, toch een goede ervaring heeft?
Voor ons als UX-designers is WebUI daardoor misschien wel een van de meest complexe, maar ook meest leerzame projecten. Het vraagt om scherpe keuzes, samenwerking met verschillende soorten stakeholders, en het vermogen om los te laten wat je normaal gesproken vanzelfsprekend vindt.
En precies daar zit ook de kracht van Okapion: ontwerpen in complexiteit, zonder de (eind)gebruiker uit het oog te verliezen.
Werkt jouw platform óók voor de makers?
Werk je aan een digitaal product dat door andere mensen gebruikt wordt om zelf dingen te maken of te regelen? En loop je tegen grenzen aan in gebruiksvriendelijkheid, schaalbaarheid of structuur? We helpen je graag om daar scherpte in te brengen, vanuit UX-ontwerp en strategie.
