Alle artikels
UX

Object-Oriented UX (OOUX): wat is het en wat kan een KMO ermee?

Illustration to accompany a blogpost about "Object-Oriented UX"

Vraag in een KMO welke concepten er nu precies bestaan in het bedrijf, en je krijgt zelden één antwoord. Sales heeft het over een dossier. Productie zegt order. De boekhouding noemt het een opdracht. Alle drie bedoelen ze hetzelfde ding, alleen heeft niemand dat ooit uitgesproken.

Zolang het bij vergaderingen blijft, is dat vooral vervelend. Van zodra er software in het spel komt, wordt het duur. Want de vraag wat een order nu precies is, en wat er allemaal bij hoort, moet dan een antwoord krijgen. En meestal geeft de leverancier dat antwoord, niet jij.

Mensen denken in dingen, niet in stappen

Er bestaat een ontwerpwijze die daar rechtstreeks op inspeelt: object oriented UX, of kortweg OOUX. De aanpak komt van de Amerikaanse designer Sophia Prater, en het idee erachter is simpel. Begin niet bij de schermen, maar bij de concepten die je gebruikers kennen.

Zo werkt het hoofd van je medewerkers namelijk wel degelijk. Een planner denkt niet in "stap 3 van de invoerwizard". Hij denkt in een werf, een monteur, een interventie. Die dingen noemen we objecten. Een object is iets dat je kan benoemen, kan terugvinden, en waarvan er meerdere bestaan. Het heeft attributen (een adres, een datum, een status), relaties met andere objecten, en acties die je erop kan uitvoeren.

Een installatiebedrijf beheert bijvoorbeeld Klanten, Werven, Toestellen, Onderhoudscontracten, Interventies en Facturen. Zes woorden. Zet ze op een rij, trek de lijnen tussen wat bij wat hoort, en je hebt in een half uur meer structuur op tafel dan met een map vol procedures.

Drie dingen die dat oplevert

Je hebt plots één woordenboek. Dat klinkt banaal, maar het is veruit de grootste winst. Zolang dossier, order en opdracht naast elkaar bestaan, gaat elk gesprek over software half over het ding zelf en half over wat je ermee bedoelt. Eén gedeelde term per object maakt daar een einde aan. Intern, en tegenover je leverancier.

Het is de beste context die je kan meegeven. Ga je software kopen of laten bouwen, dan is een objectmodel veel bruikbaarder dan een lijst met wensen. Een wensenlijst zegt wat je wil kunnen doen. Je objecten zeggen wat je bedrijf effectief beheert. Dat eerste verschilt per pakket en per leverancier. Dat tweede blijft overeind, ook als je over vijf jaar iets anders kiest.

Dubbel werk komt bovendrijven. Schrijf per object uit welke acties erop bestaan en wie ze mag uitvoeren, en de rare plekken springen eruit. Hetzelfde adres dat op drie plaatsen wordt ingetypt. Een status die iemand elke ochtend manueel van het ene systeem naar het andere overzet. Een goedkeuring die officieel bij de zaakvoerder ligt, maar die niemand in de praktijk nog geeft.

Waar de methode te zwaar wordt

Eerlijk: de volledige methodiek van OOUX is niets voor een KMO. Ze bestaat uit vier lagen (objecten, relaties, acties en eigenschappen) met matrices en meerdere iteraties, en dat is al snel een traject van weken. Daar is noch budget noch geduld voor. De vaktermen helpen ook niet mee: niemand aan de keukentafel wordt warm van een "nested object matrix".

Wat overblijft is wel bruikbaar, en dat is de kern: objecten, relaties, en wie wat mag doen. De eigenschappen per object werk je pas uit op het moment dat je effectief iets bouwt. Eén sessie van een halve dag met de zaakvoerder en twee sleutelmedewerkers, resultaat op één A3. Geen rapport van veertig pagina's.

Van een A3 naar iets dat blijft staan

Die A3 heeft wel een zwakke plek: het is een momentopname. Over zes maanden hangt het in een map en klopt het niet meer.

Daarom werken we bij Tandem met een contextmodel: één duurzame beschrijving van hoe je bedrijf werkt. Journeys tonen hoe een proces van begin tot eind loopt. Events leggen vast wat er onderweg gebeurt. Schermen zeggen waar mensen dat zien en aanpassen. De objecten vormen daarin de structuurlaag: de dingen waar die journeys en events over gaan.

Die laag is geen luxe. AI-devtools kunnen vandaag verrassend veel zelf bouwen, maar ze hebben de objecten en hun onderlinge relaties nodig om iets samenhangends af te leveren. Geef je dat niet mee, dan vindt elke prompt opnieuw uit hoe je bedrijf in elkaar zit, en elke keer een beetje anders.

Wat je hiermee doet

Neem het proces waar het vandaag het meest misloopt en onderstreep in de beschrijving elk zelfstandig naamwoord. Gooi de synoniemen samen. Kies per ding één woord, en spreek af dat iedereen dat woord gebruikt.

Meestal is dat het eerste gesprek waarin blijkt dat drie mensen drie verschillende dingen bedoelden. Dat alleen al is de moeite.

Benieuwd wat dit voor jouw bedrijf zou betekenen? Stuur ons een bericht.

Gepubliceerd op 17 sep 2026
Profile picture of cofounder Maxime
UX Design
Maxime De Roeck

Brengt processen en pijnpunten in kaart, en vertaalt die naar oplossingen die mensen graag gebruiken.