Wat is het?
User Experience, of UX in het kort, is de wetenschap over hoe een persoon een systeem ervaart en gebruikt. In dit artikel richt ik mij voornamelijk op UX van software applicaties. Dit varieert van mobiele applicaties tot tablet-, desktop- en webapplicaties. Als je het vervolgens over User Experience Design hebt, of UXD in het kort, dan ga je actief nadenken over wat de best mogelijke manier is om die applicatie door de eindgebruiker te laten “ervaren”.
UX designers zijn voortgekomen uit verschillende rollen uit de 80er jaren. Destijds waren het voornamelijk mensen met een achtergrond die niet in de techniek lag, met bijvoorbeeld de naam Usability Engineers. In de loop der jaren zijn deze rollen geëvolueerd en is het meerdere specialisaties gaan kennen. Grafisch en interactie-ontwerpers, bouwers van prototypen, mensen die gespecialiseerd zijn in het testen met eindgebruikers, integratiespecialisten en de meer recent verschenen “Persuasion Architect”. Ze houden zich onder andere bezig met ergonomie, informatiedichtheid, navigatie, schermopbouw en de werkomgeving van de gebruikers.
Helaas is het in veel projectmethoden nog steeds niet gestandaardiseerd. Maar dit is aan het veranderen. Er zijn steeds meer bedrijven die hiervoor ondersteuning bieden. Maar wat in de meeste situaties gebeurt is dat opdrachtgevers van het gebruik van UXD afzien, omdat niemand ze het voordeel van de “investering” heeft vertelt. Daarom is het tijd om aan te geven waarom je dit nou juist wel wilt.
Waarom wil je het?
De voordelen van het gebruik van UXD zal ik uitleggen aan de hand van de Application Lifecycle Management cirkel. Dit iteratief proces is onderverdeeld in drie delen. De eerste is “Business”, waar de functionaliteiten worden bepaald. Daarna komt “Development” waarbij de applicatie gebouwd en getest wordt. Als laatste is er “Operations”. Hier wordt o.a. de applicatie ondersteund in het gebruik. Van het laatste onderdeel kan vervolgens de applicatie worden uitgefaseerd, of er wordt teruggegaan naar “Business” om de cirkel te herhalen.
Fig.:1 Application Lifecycle management
Hieronder staan 4 argumenten waarom je als opdrachtgever UXD wilt.
1. Business - Verbeterde requirements
Als je UX wilt gebruiken in je project, is het verstandig dit te doen vanaf de eerste stap, door het toevoegen van wireframes, interface design, interaction design, rapid prototyping en eindgebruikerstesten. Er wordt een betere dienst aan de opdrachtgever geleverd omdat je nu kunt laten zien wat ze kunnen verwachten. Het is inderdaad een extra investering en zal vermoedelijk de business periode verlengen. Maar wanneer dit goed wordt geïmplementeerd zal de toegevoegde waarde direct zichtbaar worden bij de volgende fase van het project. De ontwikkeltijd wordt verkort en daarmee de ontwikkelkosten.
2. Development - Versnelde “Time-to-market”
Omdat de kwaliteit van de documentatie en specificaties is verbeterd, wordt de ontwikkeltijd gereduceerd. Er zullen minder wijzigingen op de het laatste moment nodig zijn en de kans dat er onvoorziene fouten worden gemaakt is een stuk kleiner. Testen zal sneller en beter gaan, vanwege de duidelijke specificatie die al vooraf beschikbaar was.
Door dit alles kun je sneller een applicatie uitbrengen. Sterker nog, naar mate het projectteam meer ervaring krijgt, wordt de extra tijd in de requirementsfase gecompenseerd door de snellere ontwikkeltijd.
3. Operations - Toegevoegde waarde per gebruiker
Wanneer de applicatie is uitgerold, zullen de gebruikers beter en sneller kunnen werken en daarbij minder fouten maken. De applicatie is speciaal ontworpen en opgezet voor hun behoeften en hun manier van werken. Nieuwe medewerkers zullen minder tijd nodig hebben om de applicatie te leren, omdat een applicatie met een intuïtieve User Experience zichzelf uitlegt. Over het algemeen kun je zeggen dat het geleverde werk per gebruiker toeneemt.
4. Operations - Verlengde levensduur applicatie
De levensduur van een applicatie neemt toe wanneer deze perfect aansluit op de werkmethoden van de gebruiker. Deze zal dan minder snel klagen, minder workarounds hoeven te gebruiken en daardoor minder snel aansturen op vervanging.
Naast de argumenten voor de opdrachtgever, staat hieronder waarom het binnen het projectteam ook toegevoegde waarde heeft.
1. UXD bij ontwikkeling
Door het verbeterde functioneel en technisch ontwerp zullen er in de architectuur minder wijzigingen en fouten voorkomen. Hiermee verkort je de volledige ontwikkeltijd. Het ontwikkelteam werkt met duidelijke en getoetste specificaties waardoor er een beter beeld is waarnaar wordt gewerkt. Technisch wordt er een betere kwaliteit gehaald en onduidelijkheden zijn al in een vroeg stadium weggenomen.
UXD in de ontwikkelfase werkt het best met de volgende drie rollen; de designer, de ontwikkelaar en iemand die daartussen staat, een zogenaamde integrator. De designer zorgt voor de interactie en interfaces. De ontwikkelaar maakt de interne werking van het systeem. De integrator kent beide kanten van de applicatie en kan zodoende het proces sturen zodat het werk van de designer en ontwikkelaar goed op elkaar aansluit.
2. Visuele terugkoppeling opdrachtgever
Één van de belangrijkste zaken is hoe je communiceert met de opdrachtgever. Met UXD kun je naast tekst ook met beelden de wensen en eisen omschrijven. Het biedt de mogelijkheid te zien wat het wordt voordat het klaar is. Door het tekenen van wireframes, het maken van een interactie- en interface-ontwerp, en bouwen van prototypen met de voorgestelde functionaliteit, is er de mogelijkheid om een betere indruk te geven dan wat met tekst alleen mogelijk is. Daarbij bied je een handvat aan de opdrachtgever om duidelijker eventuele wijzigingen door te geven. Het is makkelijker aan te geven hoe, waarom en waar iets moet worden veranderd. En als er daarbij gebruik wordt gemaakt van prototypen, kunnen alle vooraf ontstane aannames worden voorkomen. Daarbij wordt ook gelijk getest of het voorgestelde idee werkt in de praktijk.
Fig.2: Interaction Design
Fig.3: Wireframe example
Wanneer gebruik je het?
User Experience Design wordt toegepast op het moment dat er direct of indirect gebruikers bij het eindproduct betrokken zijn. Voor het beste resultaat zul je voor elke mens-machine interactie actief moeten nadenken hoe dit gebeurt en hoe je het kunt optimaliseren. Met de huidige technieken zijn er weinig restricties om zo’n mens-machine interactie zodanig uit te ontwikkelen dat het perfect kan aansluiten bij de werkzaamheden van zijn eindgebruikers.
Uiteraard moet je een gezonde afweging maken in de mate van het toepassen. Voor kleinere projecten met relatief weinig eindgebruikers is de toegevoegde waarde van een uitgebreid onderzoek ook een stuk minder. Hierbij kun je er voor kiezen om alleen op basis van feedback van een uitgerolde applicatie verbetering aan te brengen. Initieel een zo’n goed mogelijk product opleveren, maar waarbij je uitgaat dat er regelmatig nieuwe versies worden gelanceerd.
Op het moment dat het product door veel mensen gebruikt gaat worden, en waarbij de beschikbare tijd van de eindgebruiker van belang is, is het ‘t absoluut waard om UXD vanaf het begin toe te passen in het project.
UXD is de toegevoegde waarde bij applicatieontwikkeling dat het verschil gaat maken in de nabije toekomst
Wat is het niet?
Waarschijnlijk doen veel mensen onbewust aan UXD. Ze denken na over een product dat goed aansluit bij de wensen van de gebruikers. Echter doordat ze hier niet bewust mee bezig zijn of omdat ze ook vaak een andere agenda hebben, komt het UXD gedeelte nooit volledig tot zijn recht. Voor een stukje bewustwording gebruik ik de 10 meest voorkomende misvattingen over UXD dat Whitney Hess (User Experience Designer in New York) heeft samengesteld.
1. UXD is niet alleen User Interface Design
Alhoewel de User Interface (of UI) het meest herkenbare is van de gebruikerservaring, is het slechts een onderdeel van UXD. Hoe informatie getoond wordt en hoe mensen ermee communiceren is ongelofelijk belangrijk, maar UXD gaat veel dieper. Het is de basis voor de gehele applicatie en daarmee ook de UI.
2. UXD is niet één stap in het proces
Het is iets waar je continue mee bezig moet blijven. Bij iedere iteratie neem je de ervaringen mee, en wordt er opnieuw gekeken waar en of je kunt verbeteren. UXD is niet een stap die je kunt afronden, het moet samenvallen in alles wat je in het project doet.
3. UXD gaat niet over techniek
User Experience gaat niet over techniek, maar over hoe mensen leven, werken, hun dingen doen en alles wat daarmee te maken heeft. Techniek is daarbij een middel, maar geen doel.
Net zoals schilders hun verf gebruiken om te communiceren, gebruiken User Experience Designers beschikbare techniek om mensen te helpen hun doel te bereiken. Het primaire doel is dan ook om mensen te helpen en niet om de beste, mooiste of laatste techniek te gebruiken.
Fig.4: Honeycomb
4. UXD gaat niet alleen over bruikbaarheid
De bruikbaarheid van een product verhogen is erg belangrijk, maar UXD gaat ook over gedrag. Je gebruikers moeten het product willen gebruiken. Het moet aantrekkelijk zijn en rekening houden met leerbaarheid en emoties. Een goede manier om deze aspecten weer te geven is Peter Morville’s UX honeycomb.
5. UXD gaat niet alleen over de gebruiker
De U van UXD staat voor “User”. Het staat centraal in deze methodologie. Maar deze eindgebruiker is niet het enige waar rekening mee gehouden moet worden. UXD gaat namelijk over de zoektocht naar de beste combinatie van gebruikerservaring mét de business doelstellingen. Het is namelijk wel de bedoeling dat de applicatie bedoeld is om werk mee te verrichten. Daarnaast moet er ook rekening gehouden worden met bedrijfsspecifieke onderdelen zoals bijvoorbeeld de interne werkprocessen en de huisstijl.
6. UXD is niet prijzig
Het gebruiken van UXD in je project hoeft niet veel te kosten. Elke project is afhankelijk van beschikbare mensen, mogelijkheden, tijd en geld. Daarop moet worden aangesloten en bepaald worden in hoeverre je UXD kunt gaan toepassen. Het is onverstandig om er direct bij het eerste project volledig voor te gaan. Probeer het stapsgewijs in te voeren, zodat op gegeven moment het een standaard in de projecten wordt.
7. UXD is niet makkelijk
Helaas is het niet zo dat één methode alle antwoorden biedt voor het ontwerp. De grootste valkuilen zijn dat je aannames doet over hoe je eindgebruiker werkt. Het kost tijd om ze te leren kennen. Samen kun je vervolgens, op iteratieve wijze, komen tot het beste ontwerp. Daarbij wil je de juiste mensen gebruiken om die behoeftes te faciliteren.
8. UXD is niet de rol van één persoon of afdeling
Binnen een project is het niet aan één specifieke persoon of een bepaalde groep om met UXD het product succesvol te maken. Iedereen moet hier aan meewerken.
Echter omdat rollen en methodes nog niet gestandaardiseerd zijn, is het nu lastig hier volledig vorm aan te geven. Als je het niet kunt benoemen wordt het moeilijk hiervoor expertise aan te trekken. Er komt hier echter wel meer duidelijkheid in. Meer rollen worden algemeen erkend en krijgen daarmee ook de verantwoordelijkheden binnen het UX ontwerp. Maar voor een succesvol product, zal elk projectlid mee moeten doen met User Experience Design.
9. UXD is niet één discipline
Afhankelijk van het product zijn er meerdere expertises nodig. Dit is ook van toepassing op UXD. Voor een webshop werk je naar een totaal andere gebruikerservaring dan bij een systeem voor een helpdesk. Hiervoor heb je ook mensen met andere expertises nodig. Net als dat je voor een gebroken voet niet naar de cardioloog gaat. Je kunt niet verwachten dat alle UXD professionals voor alle expertises een antwoord hebben.
10.UXD is niet een keuze
Ik kan het me niet voorstellen dat een bedrijf bewust kiest voor een slecht UX ontwerp. Maar het gebeurt onbewust. Het is een risico. Daarbij beschouwen helaas nog steeds veel bedrijven UXD als een toevoeging, niet als een basisbehoefte. Wanneer je het verschil moet maken met de concurrentie, is UXD essentieel. Techniek zal op den duur het verschil niet meer maken, aangezien elk bedrijf kwalitatief op hetzelfde niveau komt door de continue ontwikkelingen van de frameworks. Het is daarom essentieel om nu te gaan werken om UXD binnen de projecten te krijgen om straks het verschil te maken.
Conclusie
User Experience Design is niet de rol van één persoon of afdeling. Het is een bewustwording dat het volledige team ondersteund voor een optimaal functionerend resultaat voor opdrachtgever en eindgebruikers. Je zorgt voor volledigere en getoetste requirements waarmee beter wordt gecommuniceerd, waardoor ontwikkeltijd wordt verkort, waar de applicatie meer oplevert tijdens operatie, en waarbij er een verlengde levensduur is voordat het uitgefaseerd kan worden.
UXD is de toegevoegde waarde bij applicatieontwikkeling dat het verschil gaat maken in de nabije toekomst.
Referenties