De kunst van het weglaten. over het gebruik van User Experience Design binnen de Oracle Wereld. Auteur Ton Dumans

Transcriptie

1 AMIS Edisonbaan 15 Postbus AA Nieuwegein T +31(0) E info@amis.nl I amis.nl BTW nummer NL B69 KvK nummer Statutair gevestigd te Enschede De kunst van het weglaten over het gebruik van User Experience Design binnen de Oracle Wereld Auteur Ton Dumans

2 De kracht van het weglaten Als IT consultant kom ik veel in aanraking met verschillende applicaties. Vaak ziijn dit business to business systemen of systemen die binnen een organisaite worden gebruikt. Deze systemen zijn geschreven in verschillende talen en hebben een wisselend gebruiksgemak. Vaak komen IT managers of functioneel beheerders naar me toe met de opmerking dat het systeem er wel is, maar dat de gebruikers er niet goed mee overweg kunnen. Het systeem heeft een hoge leercurve is de verklaring. Vaak wordt de oorzaak gezocht in de complexiteit van de achterliggende materie. Mijn reactie is vaak Heeft u zelf wel eens met het systeem gewerkt? En wat was uw eerste indruk?. Deze vragen leveren vaak interessante reacties op. Bij het ontwerp en de bouw van een systeem besteedt men enorm veel aandacht aan juistheid en volledigheid. Ook alle denkbare uitzonderingssituaties, hoe onwaarschijnlijk ook, moeten in het systeem verwerk zijn. Zeker wanneer het systeem al een tijd in onderhoud is kan dit uitmonden in een veelkoppig userinterface-monster. Deze werkwijze zorgt voor drukke, volle schermen waarin alle alle velden en knoppen schreeuwen om aandacht en daarmee de écht belangrijke gegevens laten verdwijnen onder vinkjes, tabjes, sliders en andere componenten. Bij publieke web applicaties is er sprake van survival of the fittest, applicaties met een lage gebruiksvriendelijkheid worden niet gebruikt en verdwijnen daardoor vanzelf. In een afgeschermde bedrijfsapplicaite is dit principe minder van toepassing (hoewel er ook af en toe een gerbuikersstaking in een lokale kantoorapplicaite is gesignaleerd). Stel hierbij de vraag aan de gebruikers wat gebruik je nu in de dagelijkse praktijk het meest, waar ben je 80% van je tijd mee bezig etc... Er zit vaak geen interface filosofie of richtlijnen achter het ontwerp van het systeem. De huisstijl zegt in veel gevallen iets over keur en fonts maar niets over user experience. Een goede interface ontwerper heeft het lef om zaken weg te laten en het systeem zo vorm te geven dat informatie en functies zichtbaar worden als je ze nodig hebt, maar niet op andere momenten. Een gebruiker zou het systeem direct, zonder uitgebreide instructie moeten kunnen gebruiken. Durf terug te gaan naar de essentie. De term user experience werd al eerder genoemd, maar wat is dit nu eigenlijk precies? Afbeelding 1: Een overblijfsel van een Command Line Interface? 2/9

3 Afbeelding 2: Hoewel het product voor kleine kinderen is bedoelt, kan men zich afvragen of inkopers en marketing managers (de daadwerkelijke doelgroep van deze pagina) gebaat zijn bij dit ontwerp? Afbeelding 3: Onaantrekkelijke kleuren, pop-ups, technische schermen, onduidelijke iconen. Gelukkig wordt de 10g versie van BLAF niet veel meer gebruikt. Wat is ux? De term User Experience (UX) wordt veel gebruikt, maar lang niet iedereen bedoelt hier hetzelfde mee. Hoewel UX in de meest brede zin kan worden uitgelegd als alle aspecten van de interactie van een eindgebruiker of klant met een bedrijf en haar producten en diensten (definitie vrij naar Nielsen), wordt de term in de IT vaak gebruikt als synoniem voor usability en user interface design. In dit white paper zal ook worden geconcentreerd op wat wij noemen software ergonomie. 3/9

4 Bruikbaarheid is ook voor opdrachtgevers van groot belang. Er zijn talloze voorbeelden beschreven waardoor het voorkomt dat er met een systeem niet de beoogde voordelen of besparingen worden behaald. Dit komt in zulke gevallen niet doordat het systeem niet de functionaliteit biedt die gebruikers nodig hebben, maar omdat de interface niet goed werkt waardoor functionaliteit onzichtbaar blijft. Hoewel de term UX de afgelopen paar jaar steeds vaker wordt gebruikt en daardoor soms wordt ervaren als een buzz-word, schreef Peter Morville, auteur van het boek Ambient Findability, acht jaar geleden al over het begrip User Experience en vatte dit begrip samen in een honingraat met zeven onderdelen useful, usable, findable, credible, desirable, accessible & valuable. Een pragmatische definitie zou kunnen zijn: UX is de ervaring van een gebruiker met een (IT) systeem. Een systeem met een goede UX werkt zoals de gebruiker verwacht dat het werkt en laat in het beste geval de gebruiker vergeten dat het systeem gedesigned is. Een goede UX designer heeft dan ook weinig eer van zijn werk omdat de gebruikers zijn inspaning niet opmerken. Alleen op de plekken waar hij weinig aandacht heeft besteed valt het gebrek aan zijn aandacht de gebruiker op. Bij een slecht of niet doordacht ontwerp zullen gebruikers achteraan moeten aansluiten om hun klachten in te kunnen dienen. Bij een goed ontwerp blijven ze stil, omdat ze hun tijd besteden door met de applicatie in kwestie te werken. *Zie Waarom is ux zo belangrijk? Een goed doordacht UX ontwerp voor een applicatie vergt een investering die zowel doorlooptijd als budget behoorlijk kunnen beïnvloeden. Omdat niet voor iedereen op slag duidelijk is wat UX ontwerp eigenlijk is, laat staat wat de noodzaak ervan is, kan het aantrekkelijk lijken om hier op te kunnen bezuinigen. Waarom is dit echter alles behalve verstandig? Die vraag laat zich beantwoorden wanneer men kijkt naar de mate waarin een (software) product wordt geaccepteerd en gebruikt door de eindgebruikers. Wanneer IT projecten falen, is het lang niet altijd zo dat er niets wordt opgeleverd, of dat er niet binnen de gestelde termijn wordt opgeleverd. Een helaas zeer reëel scenario is dat er wel degelijk iets op tijd wordt opgeleverd, maar dat het eindresultaat op een virtuele plank beland. Is er dan niet goed genoeg naar de wensen van de klant geluisterd? Uiteraard is dit een mogelijkheid, maar zelfs wanneer dit wel gedaan is kan het alsnog misgaan. Blijkbaar is het op tijd opleveren van een applicatie die op papier aan de wensen van de opdrachtgever voldoet, nog geen garantie voor een succesvolle acceptatie. Als men voorafgaand aan de bouw, maar ook tijdens het bouwen zelf, geen aandacht heeft besteed aan de User Experience, is de kans dat een product niet wordt gebruikt vrij groot. Hoe behulpzaam (want dat is uiteindelijk toch het generieke doel van een applicatie) is een programma dat weliswaar alle gewenste functionaliteit biedt, maar deze zo ver verstopt zit in een ondoorgrondelijke menu-structuur dat deze simpelweg niet gevonden wordt? Het antwoord laat zich raden. Hoewel het niet gebruikt worden van de gebouwde software voor de bouwer in eerste instantie misschien nog geen financiële strop lijkt, er is immers voor de bouw betaald, zal een pakket dat op de plank stof ligt te happen over het algemeen zelden voor nieuwe klanten of positieve publiciteit zorgen. Wanneer er echter wél vanaf het eerste moment aandacht aan de UX wordt besteed, kan dit diverse voordelen hebben. De voordelen voor de eindgebruikers zijn evident, die krijgt namelijk een pakket dat zijn werk faciliteert 4/9

5 en waarmee hij prettig kan werken. De voordelen voor de bouwer lijken in eerste instantie misschien minder duidelijk. Hij heeft immers meer moeten uitgeven om, op papier, dezelfde applicatie op te leveren. Toch is ook de bouwer zeer waarschijnlijk gebaat bij deze investering. Zo zal de accepatatie vlotter verlopen en zullen er minder fouten worden gemaakt. Een plezierig werkend systeem zal door gebruikers eerder worden aanbevolen aan anderen, zelfs als het hier en daar wat complexe functionaliteit mist. Waarom zijn er nog steeds systemen met een ondoordachte ux? Ondanks dat de eerder genoemde voordelen van een goed doordacht UX design voor zich spreken, of in elk geval zouden moeten spreken, worden er in de praktijk toch nog heel veel systemen met een niet goed doordachte UX opgeleverd. Hoe dit kan gebeuren, bekijken we aan de hand van een aantal voorbeelden. Geen geld - Quick en dirty Het aloude even snel een applicatie in elkaar flansen. Het moet gisteren af en mag niets kosten. Vanzelfsprekend moeten er in deze situatie compromissen worden gesloten om enigszins aan deze onrealistische eisen te kunnen voldoen. Helaas wordt in deze situaties maar al te vaak gedacht in termen van lijstjes met op te leveren functionaliteit. Wanneer een applicatie meer functionaliteit bevat, is dit een betere applicatie. Wanneer deze functionaliteit echter onbegrijpelijk danwel onvindbaar is geworden door een slechte interface, heeft de beoogde eindgebruiker hier helemaal niets aan. Ook in deze situatie doet men er goed aan om juist zeer kritisch te blijven op de user experience, en als gevolg van het beperkte budget misschien minder functionaliteit op te leveren die wel geschikt is om daadwerkelijk te worden gebruikt. Dominante rol van functioneel analist Iets wat ik helaas ook in de praktijk meer dan eens ben tegengekomen, is het verschijnsel van de dominante functioneel analist. Deze lijkt op een haast onuitputtelijke manier nieuwe functionaliteit te bedenken. Het gevaar zit hier in het bedenken. Wanneer functionaliteit niet voortkomt uit een wens van een (potentiële) gebruiker is voorzichtigheid geboden. Bij het bedenken en ontwikkelen van een geheel nieuw product is het risico het grootst. Bij gebrek aan grote aantallen daadwerkelijke gebruikers, lijkt het aantrekkelijk om de functionele analisten deze rol tijdelijk te laten vervullen. Als deze echter voldoening krijgt uit het creëren van zoveel mogelijk functionaliteit, zonder de toegevoegde waarde hiervan te (kunnen) polsen of mensen die het systeem ook daadwerkelijk moeten gaan gebruiken, ligt een user experience nachtmerrie op de loer. De bedachte functionaliteit wordt immers allemaal aan de applicatie toegevoegd. Omdat nog niet precies bekend is wat de user story nu eigenlijk precies is, wordt meer gekeken waar nog wat ruimte is in de interface, dan wat een logische plek zou zijn. Als dit proces zich een paar keer herhaalt, is de kans aanzienlijk dat de kern-functionaliteit van de applicatie niet meer gevonden of begrepen wordt, doordat de gebruiker veel wordt afgeleid van zijn daadwerkelijke doel. Te veel focus op details Een ander vaak voorkomend verschijnsel, is het te lang concentreren op de kleinste details. Soms op bijna obsessieve wijze worden alle denkbare uitzonderingssituaties in kaart gebracht. Elke afwijking van de happy flow wordt tot in het kleinste detail uitgeschreven, om hier vervolgens in de interface rekening mee te kunnen houden. Hoewel het vanzelfsprekend verstandig is om niet zonder meer uit te gaan van het feit dat een proces altijd zo verloopt als bedoelt, ligt ook hier weer een risico op de loer. Door voor iedere denkbare uitzondering knoppen, instellingen en alternatieve paden door de applicatie op te nemen, zullen gebruikers hier ook vaak mee worden lastig gevallen wanneer alles wél via de happy flow verloopt. En bij een goed doordacht product mag men best de aanname doen dat de kans op een gunstig doorlopen van het proces groter is dan de kans op catastrofaal falen. Een ander voorbeeld van hoe te veel detail kan leiden tot een lagere acceptatie van een product, is terug te vinden in een bekend intranet pakket. Bij het toevoegen van documenten aan deze omgeving, wordt de gebruiker om allerlei metadata gevraagd. Deze data zal later, mogelijkerwijs, worden gebruikt om snel en accuraat te 5/9

6 kunnen zoeken binnen de enorme hoeveelheid toegevoegde documenten. Echter, doordat het toevoegen van documenten zo veel moeite kost vanwege het verplicht invullen van deze metadata, zal de situatie waarbij er zeer veel documenten beschikbaar zijn welke snel moeten kunnen worden doorzocht, nooit ontstaan. Bijknutselen Er wordt een systeem bedacht en gemaakt volgens gangbare methodieken. Tot zover niets aan de hand. Het systeem zou zelfs wel eens over een prettige user experience kunnen beschikken. Het systeem wordt geaccepteerd door de opdrachtgever, en het oorspronkelijke team van functionele ontwerpers, UI experts en programmeurs gaat verder met de volgende opdracht. Tot nu toe lijkt het een succesverhaal, maar dan komt het moment waarop de opdrachtgever bedankt wat hij of zij nu eigenlijk echt wil doen met de applicatie. Er komt een MOSCOW lijst met nieuwe wensen. Het oorspronkelijke team zit midden in een nieuw project, en is dus niet meer beschikbaar om dit te doen. Om de klant de gewenste wijzigingen te kunnen bieden, wordt een nieuw team samengesteld. Wanneer in deze situatie haast is geboden, wordt het nieuwe team wat minder zorgvuldig samengesteld. En geld voor een UI expert is er niet meer. Op dit moment gaat er aan een in de basis goede applicatie worden bijgeknutseld. Het zal niet als verrassing komen, dat deze werkwijze niet alleen desastreuse gevolgen kan hebben voor de kwaliteit van de code, maar ook voor die van de UX. De originele denkwijze achter de flow van de applicatie en de indeling van menu s en schermen is immers niet meer in het team aanwezig. Hoewel het nieuwe team een best effort zal doen om de nieuwe functionaliteit zo dicht mogelijk aan te laten sluiten bij de huidige applicatie, is de kans dat dit naadloos aansluit klein. Uiteraard is dit probleem deels te ondervangen middels goede documentatie, maar de methodieken en denkwijzen van de UI designer zullen toch altijd in meer of mindere mate enkel in zijn of haar hoofd zijn vastgelegd. Het risico bestaat dus altijd dat de consistentie van de user interface wordt gecompromitteerd als deze persoon niet meer bij het project betrokken is. Door framework gegenereerde interface Tot slot loont het de moeite om stil te staan bij de user experience van zogeheten generatie frameworks. Een voorbeeld hiervan is bijvoorbeeld JHeadstart voor het Oracle ADF framework. Oracle heeft in 2004 veel moeite gestoken in het opstellen van de BLAF (Browser Look and Feel, zie richtlijnen. De BLAF richtlijnen zijn op zeer wetenschappelijke wijze ontwikkeld, hetgeen tot gevolg heeft dat de contrasten weliswaar de leesbaarheid voor slechtzienden verhogen, en de HTML pagina s over het algemeen zonder moeite door de (oudere) W3C webrichtlijnen heenkomen. Dit zijn allemaal kwantificeerbare aspecten die op papier goed klinken, echter, de eerste persoon die een van standaard BLAF uiterlijk voorziene applicatie mooi en prettig vind werken, moet ik nog tegenkomen. Gelukkig biedt Oracle uitvoerige mogelijkheden tot het aanpassen van het standaard uiterlijk middels skinning. Het is hierbij echter wel raadzaam om verder te gaan dan een basis kleur en een steunkleur te kiezen, vooral wanneer de beoogde applicatie verder af staat van het gebruikelijke CRUD (create retrieve update delete) model dat Oracle in gedachte had bij het samenstellen van zowel BLAF als JHeadstart. In de nieuwere versies van ADF en JHeadstart is hier een enorme sprong richting betere gebruikersinterface gemaakt. Ook andere GUI generate frameworks leiden in veel gevallen niet tot een goede gebruikersinterface. Men kan er nog steeds niet blind van uitgaan dat gegenereerde applicaties automatisch een goede interface hebben. Hoe wél een geode ux bereiken De eerder genoemde potentiële valkuilen in acht nemende, is het minstens net zo interessant om te bekijken hoe men juist wél een goede User Experience kan ontwikkelen. Hoewel het tegenovergestelde doen van deze valkuilen een goed begin is, is er meer waar men rekening mee kan houden. 6/9

7 Stel een heldere visie op, en houd je hier gedurende het hele traject aan Denk aan simpele doelen om de gebruikerservaring zo soepel mogelijk te laten verlopen, zoals een lijst opstellen van kernfunctionaliteiten die met zo min mogelijk acties van de gebruiker kunnen worden uitgevoerd. Acties die minder vaak gebruikt worden, of alleen het kernproces ondersteunen, worden niet continue getoond om zodoende de gebruiker niet af te leiden. Het opstellen en vastleggen van afspraken, regels en templates omtrent het gebruik van kleuren, navigatie componenten, knoppen et cetera in een zogenaamde style guide voorkomt het onbewust introduceren van inconsistenties in de User Experience. Twee dezelfde acties, op een andere plaats in het systeem zouden zonder goede reden niet anders moeten werken. Als hier wel een goede reden voor is, dient deze te worden vastgelegd in de style guide. Communiceer de richtlijnen en train ontwikkelaars en ontwerpers hierop Deel de richtlijnen met een zo groot mogelijke groep betrokken stakeholders van het product. Zo kan er in een vroeg stadium van een functionele wens al in lijn met de UX standaarden gedacht worden. Train de betrokkenen in het nadenken over goed design en verklaar de keuzen die gemaakt zijn in de UX standaarden. Hierdoor wordt goed interfacedesign niet meer het speeltje van het reclamebureau of de desingstudio, maar staat het ten diensten van het gebruiksgemak van de eindgebruiker. Verzamel feedback van gebruikers, ook na productiename Hoewel het voor velen waarschijnlijk voor zich spreekt, is het bereiken van een optimale User Experience alleen mogelijk door veel feedback van de (beoogde) gebruikers te verzamelen. Hoe eerder hier mee wordt gestart, hoe waardevoller de input is, omdat er nog alle ruimte is om het systeem zodanig te ontwerpen of aan te passen dat het naadloos aansluit bij de werkwijze van de doelgroep. Hoe later deze feedback wordt verzameld, hoe meer aannames er al zijn gedaan omtrent de werkwijze, hoe duurder het is om hier nog veranderingen in aan te brengen. Ondanks het feit dat idealiter zo vroeg mogelijk wordt begonnen met het verzamelen van feedback, betekent dit niet dat hiermee kan worden gestopt zodra het product in gebruikt wordt genomen. Hoewel tijdens de ontwikkeling met de grootst mogelijke zorg om is gegaan met de verzamelde feedback, zal er na productiename nog veel meer data kunnen worden verzameld doordat er een nog grotere en meer diverse groep gebruikers om feedback kan worden gevraagd. Het bovenstaande in acht nemende, kan het raadzaam zijn om de ontwikkeling van User Interface, die in grote mate afhankelijk is voor de totale User Experience, als een iteratief proces op te pakken. Een groot deel van de eerder beschreven valkuilen kan hiermee worden voorkomen. Door niet eerst de hele interface tot in de kleinste details uit te werken, en pas dan aan de beoogde gebruiker te laten zien, maar juist deze feedback al in de ontwerpfase mee te nemen, kunnen dure en tijdrovende herbouw trajecten worden voorkomen. 7/9

8 Conclusie Samenvattend kunnen we stellen dat het loont om tijd en moeite te stoppen in het ontwikkelen van een product of applicatie met een prettige User Experience. Om dit te bereiken, moet hier zo vroeg mogelijk in het proces mee gestart worden. Dit neemt echter niet weg dat ook na productiename continue feedback verzameld moet worden om indien mogelijk de UX bij te kunnen stellen. Dat gezegd hebbende is het niet verstandig om overhaast en zonder duidelijk plan aan de slag te gaan. Bezint eer ge begint. Stel richtlijnen op en zie er op toe dat deze gedurende het gehele traject worden nageleefd. Hoewel het raadzaam is om zo spoedig mogelijk aan te vangen met de werkzaamheden om een goede UX te garanderen, is het uiteraard ook in zekere mate nog mogelijk om bij een reeds bestaand product of een reeds gestart traject verbeteringen op het gebied van de User Experience te behalen. Tot slot, een simpele maar goede tussentijdse test om de gebruiksvriendelijkheid te beoordelen: vraag eens aan iemand met enige kennis van het domein waar de applicatie gebruikt zal worden, of hij of zij met de software kan werken. Houd pen en papier bij de hand om waardevolle feedback te noteren.het gebruik van mobiele toestellen is niet meer weg te denken in het dagelijks handelen in het moderne bedrijfsleven. Afgelopen jaren zijn er diverse platforms gecreëerd die het mogelijk maken om bedrijfsdata mobiel toegankelijk te maken. Door de hoge omloopsnelheid van mobiele devices en de achterliggende technologieën is het lastig om te kiezen welk platform en welke oplossing goed past. 8/9

9 AMIS Know-why AMIS is the leading Oracle technology partner in the Netherlands. AMIS consultants are involved in every major Oracle implementation in the Netherlands and various ground-breaking projects worldwide. Based on solid business cases, we bring the latest technology into actual production with customers. Know-how At AMIS, expertise is key. This manifests itself in a profound knowledge of complete Oracle technology stack. Seasoned experts who know what they are doing and assess today s technology in the context of the future. Professionals who won t take unconsidered decisions that might haunt you for years. Expertise also implies an aim for quality. We won t stop until Oracle technology delivers it s promise. It's that simple. Know-why To make Oracle technology work, we venture beyond technological expertise. We need to understand you. What is it exactly you want to achieve with your project? What is its purpose, what are your true priorities and which are the preconditions? Only within the context of a customer can Oracle technology truly shine. More Information Please contact us at: AMIS T +31(0) E info@amis.nl I amis.nl 9/9