Wat is een wireframe?

Definitie: Een wireframe is een eenvoudige schets van een scherm, webpagina of app die de indeling en structuur laat zien: waar welke informatie, knoppen en onderdelen komen, zonder kleuren, afbeeldingen of definitieve vormgeving. Het is de bouwtekening van een interface.

In het kort

• Een wireframe richt zich op indeling, volgorde en functie, niet op uiterlijk.
• Wireframes worden vroeg in het ontwerpproces gemaakt, vóór mockups en prototypes.
• Er zijn low-fidelity wireframes, zoals schetsen op papier, en high-fidelity wireframes met meer detail.
• Bekende tools om wireframes te maken zijn Figma, Balsamiq, Miro en Lucid, maar pen en papier werken ook prima.

Wat is een wireframe?

Het woord wireframe betekent letterlijk draadmodel. Net zoals een architect eerst een plattegrond tekent voordat er over kleuren en materialen wordt gepraat, maakt een ontwerper eerst een wireframe voordat de vormgeving wordt uitgewerkt. Een wireframe toont blokken, lijnen en eenvoudige tekst: hier komt het menu, hier de zoekbalk, hier een lijst met resultaten, hier een knop om te bestellen.

Door de vormgeving weg te laten, richt het gesprek zich op de vragen die er in deze fase toe doen. Niemand begint over de kleur van een knop als die knop nog een grijs vlak is. Welke informatie heeft de gebruiker nodig? In welke volgorde? Wat is de belangrijkste actie op dit scherm? Wat gebeurt er als je op een knop drukt?

Waarom maak je een wireframe?

• Snel en goedkoop. Een wireframe is in minuten tot uren gemaakt en net zo snel aangepast.
• Focus op structuur. Zonder kleuren en beelden gaat het gesprek over indeling en inhoud.
• Gedeeld beeld. Opdrachtgever, ontwerper en ontwikkelaar zien hetzelfde, in plaats van ieder een eigen voorstelling.
• Fouten vroeg vinden. Een ontbrekende stap of verkeerde volgorde is in een wireframe makkelijk te herstellen.
• Basis voor vervolg. Mockups, prototypes en de uiteindelijke bouw gaan uit van de indeling in het wireframe.
• Inschatting van werk. Ontwikkelaars kunnen op basis van wireframes beter inschatten wat er gebouwd moet worden, wat een offerte beter onderbouwd en beter vergelijkbaar maakt.

Soorten wireframes

Waar past een wireframe in het ontwerpproces?

Een wireframe staat niet op zichzelf. Het is een stap in een reeks die van idee naar werkende software leidt:

1. Probleem en doel in kaart brengen: wat moet er beter, en voor wie?
2. Proces en gebruikers begrijpen: wie doet wat, en welke informatie is nodig?
3. Functionele eisen vastleggen: wat moet het systeem kunnen?
4. Wireframes maken: hoe vertalen die eisen zich naar schermen?
5. Mockups maken: hoe ziet het eruit?
6. Klikbaar prototype maken en testen: werkt de route voor gebruikers?
7. Bouwen van de eerste versie.

Wireframes zijn daarbij het moment waarop abstracte eisen concreet worden. Een eis als “de binnendienst moet aanvragen kunnen toewijzen” wordt in een wireframe een knop op een bepaalde plek, met een keuzelijst van medewerkers en een bevestiging na het toewijzen. Juist bij die vertaling komen vaak vragen boven die in een lijst met eisen verborgen bleven.

Gebruikersstromen en wireframes

Een wireframe van één scherm vertelt maar een deel van het verhaal. Daarom worden wireframes vaak gecombineerd met een gebruikersstroom, in het Engels user flow: een schema dat laat zien welke stappen een gebruiker zet om een taak af te ronden, en welke schermen daarbij horen. Bijvoorbeeld: inloggen, overzicht openen, aanvraag selecteren, offerte opstellen, versturen, terug naar het overzicht. Door de stroom eerst te tekenen, weet je welke schermen je moet wireframen en zie je sneller waar een stap overbodig is of juist ontbreekt.

Wireframe, mockup of prototype?

Een veelgebruikte volgorde is: eerst wireframes, dan mockups en daarna een klikbaar prototype. Bij kleinere projecten worden stappen soms gecombineerd, bijvoorbeeld door van een wireframe direct een klikbaar prototype te maken.

Wat staat er in een wireframe?

• Indeling van het scherm, zoals kop, menu, inhoud en voettekst.
• Navigatie: hoe kom je van het ene scherm naar het andere?
• Inhoudsblokken: tekst, lijsten, tabellen, kaarten, afbeeldingsvlakken.
• Interactieve onderdelen: knoppen, invoervelden, filters, keuzelijsten.
• Hiërarchie: wat is het belangrijkst, wat valt het eerst op?
• Staten: hoe ziet het scherm eruit als er nog niets is, als er een fout optreedt of als iets wordt geladen?
• Annotaties: korte toelichting op wat een onderdeel doet of waar gegevens vandaan komen.

Uitgewerkt voorbeeld: een overzicht van offerteaanvragen

Stel dat een binnendienst een scherm nodig heeft om binnenkomende offerteaanvragen te verwerken. Een wireframe van dat scherm kan er in woorden zo uitzien:

• Bovenaan een titel “Offerteaanvragen” met rechts een knop “Nieuwe aanvraag”.
• Daaronder een rij filters: status (nieuw, in behandeling, verstuurd), toegewezen medewerker en periode.
• Een zoekveld om op klantnaam of aanvraagnummer te zoeken.
• De hoofdlijst met per aanvraag: datum, klant, product, toegewezen medewerker, status en hoe lang de aanvraag al openstaat.
• Aanvragen die langer dan twee werkdagen openstaan, worden gemarkeerd.
• Rechts of bij klikken een detailpaneel met de volledige aanvraag, eerdere contactmomenten en knoppen om toe te wijzen of een offerte op te stellen.
• Een lege staat met de tekst “Er zijn geen open aanvragen” als alles is afgehandeld.

Zonder één kleur of afbeelding is nu al te bespreken of de juiste informatie zichtbaar is, of de filters kloppen en of de belangrijkste actie duidelijk is. Een medewerker uit de binnendienst kan direct aangeven: “We zoeken vaak op postcode, die mis ik”, of “De status ‘wacht op klant’ ontbreekt.” Dat soort feedback is in deze fase goud waard.

Wireframes voor websites en voor applicaties

Bij een website draait een wireframe vooral om de opbouw van pagina’s: de volgorde van secties, de plek van tekst en beeld, en de route naar contact of aankoop. Belangrijke vragen zijn: wat ziet een bezoeker eerst, en hoe vindt hij wat hij zoekt?

Bij een applicatie gaat het meer om taken en gegevens. Een wireframe laat zien hoe een gebruiker een taak afrondt, welke gegevens hij daarvoor nodig heeft en welke acties hij kan uitvoeren. Vaak zijn er meerdere rollen, zoals een medewerker en een beheerder, met elk andere schermen of rechten. Daarom zijn wireframes van applicaties meestal uitgebreider, met meer aandacht voor lijsten, formulieren, statussen en uitzonderingen.

Wireframes voor mobiel

Op een smartphone is minder ruimte, en mensen gebruiken de applicatie vaak onderweg en met één hand. Een wireframe voor mobiel is daarom geen verkleinde versie van de desktop, maar een eigen afweging: welke informatie is op dit moment het belangrijkst, wat kan in een tweede scherm, en waar staat de belangrijkste knop zodat hij makkelijk bereikbaar is? Veel ontwerpers beginnen bewust met de mobiele versie, omdat die dwingt tot keuzes. De desktopversie krijgt daarna meer ruimte voor extra informatie.

Annotaties en documentatie

Een wireframe wordt veel waardevoller met korte toelichtingen. Denk aan notities als “deze lijst toont alleen aanvragen van de eigen vestiging”, “deze knop is alleen zichtbaar voor beheerders” of “na opslaan gaat de gebruiker terug naar het overzicht”. Zulke annotaties maken het verband tussen het scherm en de functionele eisen zichtbaar, en voorkomen dat ontwikkelaars moeten raden. Houd ze kort en concreet, en plaats ze direct naast het onderdeel waar ze over gaan.

Waar komt de term vandaan?

De term wireframe komt oorspronkelijk uit de computergraphics en het technisch tekenen, waar een draadmodel de contouren van een driedimensionaal object toont zonder oppervlak of kleur. In webdesign en softwareontwerp werd het woord overgenomen voor schetsen die alleen de structuur van een scherm tonen. Het idee is hetzelfde gebleven: eerst het skelet, dan de afwerking.

Zo maak je een wireframe

1. Begin bij het doel. Wat moet de gebruiker op dit scherm kunnen doen?
2. Maak een lijst van de inhoud. Welke informatie en acties horen erbij?
3. Schets ruw. Op papier of in een eenvoudige tool, zonder je druk te maken over details.
4. Bepaal de hiërarchie. Wat komt bovenaan, wat is de belangrijkste knop?
5. Werk de route uit. Maak wireframes van de schermen die bij één taak horen, van begin tot eind.
6. Voeg annotaties toe waar iets niet vanzelf spreekt.
7. Bespreek en test. Laat het wireframe zien aan gebruikers en belanghebbenden, en pas aan.
8. Detailleer stap voor stap zodra de structuur staat.

Principes voor een goed wireframe

• Eén hoofdactie per scherm. Maak duidelijk wat de gebruiker hier vooral moet doen, en laat die actie visueel opvallen.
• Belangrijkste informatie bovenaan. Mensen scannen een scherm van boven naar beneden en van links naar rechts.
• Consistente plaatsing. Zet vergelijkbare onderdelen op elk scherm op dezelfde plek, zoals de navigatie en de knop om op te slaan.
• Groepeer wat bij elkaar hoort. Velden over de klant bij elkaar, velden over de levering bij elkaar.
• Gebruik herkenbare patronen. Een zoekbalk bovenaan, een menu links of bovenaan, een bevestiging na een actie. Gebruikers hoeven dan niet te leren hoe het werkt.
• Denk aan de volgende stap. Wat ziet een gebruiker nadat hij een actie heeft uitgevoerd?
• Laat ruimte voor groei. Een lijst met drie items ziet er anders uit dan een lijst met driehonderd. Ontwerp ook voor de drukke situatie.

Wireframes en toegankelijkheid

Toegankelijkheid begint al in het wireframe. Een logische volgorde van koppen en onderdelen maakt een scherm beter bruikbaar met een schermlezer en met het toetsenbord. Duidelijke labels bij invoervelden, voldoende ruimte rond knoppen en een heldere plek voor foutmeldingen zijn keuzes die je in deze fase al maakt. Door daar vroeg aan te denken, voorkom je dat toegankelijkheid later als losse correctie moet worden toegevoegd. Voor diensten die onder de European Accessibility Act vallen, is dat bovendien een wettelijke eis.

Tools om wireframes te maken

• Pen en papier of een whiteboard: snel en laagdrempelig, ideaal voor de eerste ideeën.
• Balsamiq: bewust schetsmatig, zodat de focus op structuur blijft.
• Figma: veelgebruikt voor wireframes, mockups en prototypes in één omgeving.
• Miro: online whiteboard, handig om samen te schetsen.
• Lucid: diagrammen en wireframes, met sjablonen.
• Penpot: open source ontwerptool in de browser.

De keuze voor een tool is minder belangrijk dan het doel. Voor een eerste verkenning is papier vaak het snelst. Voor wireframes die je deelt met een team of die later worden uitgewerkt tot mockups en prototypes, is een digitale tool handiger, omdat je daar in kunt voortbouwen.

Van wireframe naar bouw

Als de wireframes zijn besproken en aangepast, zijn ze een waardevolle basis voor de bouw. Ontwikkelaars zien welke schermen er zijn, welke gegevens op welk scherm staan en welke acties mogelijk zijn. Combineer de wireframes met de functionele eisen en een beschrijving van de route, zodat duidelijk is hoe alles samenhangt. Spreek ook af welke onderdelen bewust nog niet zijn uitgewerkt, zodat die niet ongemerkt worden ingevuld met aannames. Hoe beter de wireframes de werkelijke taak weerspiegelen, hoe minder vragen er tijdens de bouw ontstaan en hoe kleiner de kans op herbouw.

Wireframes testen met gebruikers

Je kunt een wireframe al testen voordat er een mockup of prototype is. Leg het voor aan een paar mensen uit de doelgroep en geef een opdracht, zoals “waar zou je klikken om een aanvraag aan jezelf toe te wijzen?” Vraag ze hardop te denken. Zo zie je of de indeling logisch is, of labels begrijpelijk zijn en of er informatie ontbreekt. Met papieren wireframes kun je zelfs een eenvoudige simulatie doen: je legt het volgende scherm neer zodra de testpersoon op een knop wijst. Het voelt wat onwennig, maar levert verrassend veel inzicht op.

Wireframes en AI

Steeds meer ontwerptools bieden AI-functies die op basis van een beschrijving een eerste wireframe genereren. Ook AI app builders maken in korte tijd een werkende interface. Dat versnelt het begin, maar vervangt het denkwerk niet. Een gegenereerd wireframe laat zien hoe een scherm er gebruikelijk uitziet, maar weet niet welke informatie jouw gebruikers nodig hebben, welke uitzonderingen zich voordoen of welke stap in jouw proces het lastigst is. Gebruik AI dus als startpunt, en toets de uitkomst aan het echte werk.

Hoeveel tijd kost een wireframe?

Een ruwe schets van een scherm kost minuten. Een set digitale wireframes voor de belangrijkste route van een applicatie, met annotaties, kost eerder enkele uren tot een paar dagen, afhankelijk van het aantal schermen en de complexiteit. Die tijd verdient zich bijna altijd terug: elke wijziging in een wireframe is vele malen goedkoper dan dezelfde wijziging in een gebouwde applicatie.

Wie maakt wireframes?

Wireframes worden meestal gemaakt door een UX-ontwerper of een ontwikkelaar met oog voor gebruikerservaring. Maar iedereen kan een eerste schets maken. Een opdrachtgever die zelf schetst hoe hij een scherm voor zich ziet, maakt in één keer duidelijk wat hij belangrijk vindt. Ook gebruikers kunnen meeschetsen. Het mooiste resultaat ontstaat vaak in een korte sessie waarin de mensen die het werk doen en degene die het ontwerpt samen tekenen.

Veelgemaakte fouten

• Te snel te mooi. Kleuren en beelden leiden de aandacht af van de structuur.
• Losse schermen in plaats van een route. Een wireframe van één scherm zegt weinig over hoe een taak verloopt.
• Opvultekst. Echte koppen en labels laten veel beter zien of een scherm begrijpelijk is.
• Lege en foutstaten vergeten. Wat ziet een gebruiker als er nog geen gegevens zijn of als iets misgaat?
• Alleen voor desktop. Als de applicatie ook op mobiel wordt gebruikt, hoort daar een eigen indeling bij.
• Geen gebruikers betrekken. Een wireframe dat alleen intern is besproken, mist vaak de uitzonderingen uit de praktijk.
• Het wireframe niet bijwerken. Als keuzes later veranderen, moet het wireframe mee veranderen, anders werkt iedereen met een verouderd beeld.

Wat betekent dit voor jouw project?

In mijn werkwijze maken schermschetsen deel uit van de betaalde blauwdruk, samen met het afgebakende proces, de afhankelijkheden en een voorstel voor de eerste versie. Die schetsen zijn in feite wireframes: ze laten zien welke informatie op welk scherm staat en hoe een gebruiker door de belangrijkste taak gaat.

Als ik naar een proces kijk, vraag ik wat er binnenkomt, wie ermee verder moet en welke informatie die persoon nodig heeft. Een wireframe is de manier om dat antwoord zichtbaar te maken, voordat er een regel code is geschreven.

Wil je je idee zichtbaar maken in een paar heldere schetsen? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap.

Veelgestelde vragen over wireframes

Wat is een wireframe?

Een wireframe is een eenvoudige schets van een scherm, webpagina of app die de indeling en structuur laat zien, zonder kleuren, afbeeldingen of definitieve vormgeving. Het is de bouwtekening van een interface.

Hoe maak je een wireframe?

Je begint bij het doel van het scherm, maakt een lijst van de inhoud en acties, en schetst de indeling op papier of in een tool zoals Figma of Balsamiq. Daarna werk je de hele route uit, bespreek je de schetsen en detailleer je stap voor stap.

Wat is het verschil tussen een wireframe en een mockup?

Een wireframe toont de indeling en structuur met eenvoudige blokken. Een mockup voegt de vormgeving toe, zoals kleuren, typografie en afbeeldingen, en laat zien hoe het eindproduct eruitziet.

Verwante termen

Mockup · Klikbaar prototype · Prototype · UX design · Functioneel ontwerp · Discovery-fase