Valkuilen bij het ontwikkelen van digitaal design

Vanuit gebruikersoogpunt is de keuze voor design first veel interessanter. Het maakt  gebruikers niet uit hoe een app, site of applicatie werkt. Als het maar doet wat ze willen. De keuze voor design first is in de praktijk alleen niet altijd eenvoudig. Welke keuzes moet je maken? We diepen ze uit aan de hand van 3 valkuilen.

Valkuil 1. Je redeneert vanuit techniek in plaats van de gebruiker

Veel IT-bedrijven benaderen design vanuit techniek. Zeker als ze standaardoplossingen aanbieden, want het alternatief is dat de klant bij een ander aanklopt. Begin je bij de techniek, dan hoop je dat gebruikers zich aanpassen aan de oplossing. Ze moeten als het ware in een mal geperst worden. Maar dat gebeurt zelden en leidt tot ergernissen.

Maatwerk is het alternatief voor bestaande techniek. Maatwerk is alleen niet altijd wat de naam doet vermoeden. Zo koppelen veel aanbieders bestaande systemen aan elkaar, onder het mom van maatwerk. Ze programmeren echter nog steeds niet ‘from scratch’.

Veel IT-bedrijven benaderen design vanuit techniek. Ze hopen dat gebruikers zich aanpassen aan hun oplossing.

Design gaat over meer dan kleur knopjes

Laat je het functioneel ontwerp volledig over aan developers? Dan is de kans groot dat het leidt tot een vreemde interface. Het werkt wel, maar is niet logisch ingedeeld. Bij usability komt bovendien veel meer kijken dan de kleur van een knopje. In een ideale situatie is design leidend en vult development aan. Dat levert het beste resultaat op voor eindgebruikers.

Valkuil 2. Je laat je verleiden door de standaardoplossing

Als programmeur is een standaardoplossing prettig. Je trekt hem zo uit de kast, implementeert hem snel en bent verzekerd van continuïteit. In de praktijk kan een standaardoplossing flink afbreuk doen aan het eindproduct. Dit zie je bijvoorbeeld vaak bij vacatureportals.

Een organisatie laat een functioneel ontwerp maken voor een vacaturesite. Bij de implementatie blijken er technische beperkingen te zijn en laten ze het ontwerp los. De organisatie steekt daardoor veel tijd en geld in recruitment, maar schotelt sollicitanten een rammelende site of app voor.

De organisatie steekt veel tijd en geld in recruitment, maar schotelt sollicitanten een rammelende site voor.

Bestaande technieken gebruiken is niet verkeerd

Standaardoplossingen kunnen vrij beperkt zijn, maar maatwerk is ook niet altijd nodig. Vraag je daarom altijd af:

• Wanneer is de standaard goed genoeg?
• Wanneer moet iets onderscheidend zijn?

Tijd is geld en je hebt te maken met budgetten en deadlines. Daarom hoef je niet iets te doen dat al bestaat. Het maakt een project onnodig duur en het voegt niets toe. Blijf altijd kritisch nadenken en stel de gebruiker centraal. Ontwikkel zo een goed ‘basisproduct’ en maak uitzonderingen waar ze echt meerwaarde hebben.

Valkuil 3. Je maakt een functioneel ontwerp volledig vanuit design

‘Design first, technology second’ is altijd het uitgangspunt bij Pixelpillow. Toch gaan we hier altijd pragmatisch mee om, en daar hebben we goede redenen voor. Bij ‘user centered design’ speelt techniek geen enkele rol. Je ontwerpt de ultieme oplossing voor gebruikers en techneuten zien maar hoe ze het maken. In de praktijk heb je echter te maken met onder andere:

• budgetten
• doorlooptijden
• onderhoud van systemen

Bovendien stuit je als ontwikkelaar vroeg of laat op technische belemmeringen. Betrek daarom developers zo vroeg mogelijk bij het designproces.

Designers weten ook niet alles.

Waarom designers en ontwikkelaars samen tot betere resultaten komen

Designers en ontwikkelaars werken vanuit hun eigen vakgebied en weten niet alles. Daarom is het verstandig om snel de krachten te bundelen. Dit heeft verschillende voordelen. Ontwikkelaars kunnen designers attenderen op consequenties van bepaalde keuzes. Misschien heeft een kleine concessie grote gevolgen voor de techniek en indirect de kosten. Techniek heeft vaak gevolgen voor de gebruikservaring. Een mooi voorbeeld is het implementeren van een zoekmachine.

Een extra checkbox is zo toegevoegd in een ontwerp, maar filtering kost veel rekenkracht. Dit kan de prestaties van een site of app flink vertragen. Wanneer een programmeur dit op tijd signaleert kun je er 0in de ontwerpfase rekening mee houden. Voegt de extra optie écht iets toe?

Nog een voorbeeld is Vacature alerts. Alerts zijn prettig voor gebruikers, maar ze belasten databases zwaar. Ook zit er vaak een complexe strategie achter. Wat gebeurt er bijvoorbeeld als iemand zich later aanmeldt en de alerts lopen al? Het zijn details die van grote invloed zijn op hoe iemand iets ervaart, en waar je vooraf over na wilt denken.

Vaak heeft een kleine concessie grote gevolgen voor de techniek en indirect de kosten.

Nuchtere benadering van ‘design first’ zorgt voor beste UX

Geweldige functionerende sites, applicaties en apps maken is moeilijker dan het lijkt. Je merkt vaak in de praktijk of iets echt werkt zoals je het hebt bedacht. Geef daarom de hoogste prioriteit aan user experience, ontwikkel volgens het design first-principe en sta open voor afwijkende meningen.

Je ontwikkelt op de eerste plaats voor gebruikers, dus zet hen op een voetstuk. Kijk daarna naar technische oplossingen en combineer beide disciplines. Zo bewaak je de balans, houd je grip op je budget en realiseer je oplossingen waar iedereen blij van wordt.