Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

'Doet het ding wat ik wil'

 

'Veel softwareproducten sluiten matig aan op de gebruikers doordat ontwerpers vanaf het begin vaak denken in termen van oplossingen zonder daarbij het probleem goed te kennen', stelt Gerard van Os.

Als eigenaar/onderzoeker/ontwerper van een onderneming met diensten als gebruiksonderzoek en het ontwerpen van gebruiksgerichte/gebruiksvriendelijke bedieningen mag deze reactie misschien wat eigenaardig zijn, maar ik onderschrijf volledig de uitspraak van Frans van der Ven als hij zegt dat (software)bureaus het meeste voordeel halen als de eigen werknemers gebruiksonderzoek doen ('Zelf testen niet serieus genomen', Computable, 21 mei 2004, p. 12).
Ik wil wel wat toevoegen waardoor misschien een nog betere beslissing omtrent inhuren of zelf doen te nemen valt. Het ontwerpen van een gebruikersinterface en de daaraan gekoppelde 'evaluatie van gebruiksvriendelijkheid' om de kwaliteit daarvan te verbeteren is geen alleenstaande activiteit, maar volgt op een fase waarbij gekeken wordt wie de gebruikers zijn, hoe ze werken en wat hun eisen en wensen zijn ten aanzien van het te creëren product. Deze analysefase blijkt essentieel te zijn voor de gebruiksgerichtheid en daarmee gebruiksvriendelijkheid van het product. In deze fase komt boven tafel welke gebruikerscategorieën er zijn en wat hun kenmerken zijn. Vervolgens wordt beslist voor welke gebruikerscategorieën en kenmerken interfaces ontworpen worden.

Zwarte doos

Omdat het niet goed mogelijk is in één keer naar een voor gebruikers werkbare interface te komen, zijn een aantal stappen noodzakelijk. Deze stappen zijn gebaseerd op een elementair productmodel, waarbij aan de ene kant een gebruiker staat die een doel moet bereiken middels een aantal opdrachten, uit te voeren met het product, en aan de andere kant een 'zwarte doos' waarin alle magie van dat product verborgen zit. Hier tussenin staat de gebruikersinterface, die de taken van de gebruiker vertaalt naar wat de zwarte doos nodig heeft en die de resultaten van zwarte doos op een door de gebruiker verwachte manier weergeeft.
De gebruiker beoordeelt de kwaliteit van het product als volgt: 'doet het ding wat ik wil of moet ik doen wat dat ding wil'. Dat is een andere manier van kijken dan die van de opdrachtgever; die is vaak alleen geïnteresseerd in wat het product toevoegt aan het bedrijfsproces en baseert de kwaliteit daarom meer op geboden functionaliteit en mogelijkheden dan op gebruiksvriendelijkheid. Er zijn blijkbaar meerdere 'kwaliteitsnormen', afhankelijk van hoe iemand in relatie staat tot het product. Je dit realiseren is een belangrijk winstpunt in het creëren van gebruiksvriendelijke producten.
Welke stappen zijn er te doorlopen vanaf het eerste begin tot het moment waarop 'de beitel in het staal gaat' of 'de vingers op het toetsenbord gaan'? Onderstaande stappen lijken elkaar op te volgen, maar in de praktijk zit er veel iteratie tussen. Bovendien zullen veel van deze stappen ook nu al doorlopen worden, maar wordt hier vooral de gerichtheid van de stap op gebruik en gebruiker toegelicht en vastgelegd. Gedurende dit hele traject kan je al beginnen met het specificeren en bouwen van de zwarte doos.

Stappen

De eerste stap betreft gebruiksonderzoek, waarbij je gebruikerscategorieën identificeert en beschrijft, en inzicht verkrijgt in de werkwijze, eisen en wensen van de diverse categorieën. Met gebruiksonderzoek vergaar je ook de domeinkennis die nodig is om in de volgende stappen de goede beslissingen te kunnen nemen.
De tweede stap omvat het opstellen van het programma van eisen voor de interactie tussen mens en product, en van de gebruikersinterface die dat tot gevolg heeft. Hier wordt onder andere bepaald voor welke gebruikerscategorieën een interface zal worden geboden en welke eisen aan die interfaces verbonden zijn. Voorbeelden van eisen zijn de door Van der Ven genoemde snelheid in gebruik, leerbaarheid en foutondersteuning. Met het vastleggen ervan worden ze toetsbaar gedurende de gebruikerssessies.
De derde stap betreft het ontwerpen van een aantal interfaceconcepten die de te bieden functionaliteit beschikbaar maken voor de gebruikers. In deze stap komen de eisen en wensen van gebruikers samen met de te bieden functionaliteit. Hoewel dat niet de eerste keer is, is het wel voor het eerst dat een en ander zinvol gevisualiseerd wordt. Overigens betekent een eis als 'gegevens moeten opgeslagen worden' niet meteen dat er ook een 'bewaren'-knop moet komen.

Soepeler

Het evalueren van de gebruiksvriendelijkheid door gebruikers de concepten te laten bekijken en te gebruiken is de vierde stap. Dit heeft twee resultaten. De domein- en gebruikskennis van de ontwerper wordt getoetst en aangevuld. Bovendien ontstaat in iteratie met stap drie een interface waarmee vooral de beoogde gebruikerscategorie goed uit de voeten kan en die in de volgende stappen verder uitgewerkt en gebouwd wordt. Dit lijkt een zwaktebod; de ontwerper weet blijkbaar niet wat goed en fout is en vraagt de gebruiker hiernaar, maar deze evaluaties beïnvloeden de kwaliteit van de interface en dus het product altijd positief. Deze stap beïnvloedt ook de acceptatie van het uiteindelijke product positief, want dat wordt mede gebaseerd op de realiteit en niet louter op de eigen denkwereld van de bouwers.
De vijfde stap is de specificatie van de interface, de productstijlgids, de te bieden functionaliteit enzovoort op een dusdanig niveau dat de interface werkelijk te bouwen valt. Deze stap is belangrijk omdat hierna de interface werkelijk gebouwd gaat worden. De oorspronkelijke ontwerper is dan niet altijd meer bereikbaar (werkt aan een andere opdracht, was ingehuurd). Toch zullen eventuele wijzigingen of toevoegingen in overeenstemming moeten zijn met de interfacefilosofie die is vertaald in de stijlgids. Over de mate van detail moeten afspraken gemaakt worden: een stijlgids die bijvoorbeeld tot op de pixel vastlegt hoe knoppen eruit moeten zien gaat misschien te ver, maar het zal wel duidelijk moeten zijn wanneer er gekozen moet worden voor 'radioknoppen' of vinkjes.
Stap zes betreft het implementeren, evalueren, testen en in gebruik nemen van de interface en het totale product. Door al het voorwerk in de vorige stappen zal deze stap soepeler en sneller verlopen. De interface wordt nu ontwikkeld parallel aan de andere delen van het product, waardoor je eerder kunt beginnen met ondersteunende activiteiten als marketing, handleidingen, helpschermen, trainingen en vertalingen.

Afgerekend

Zonder te stellen dat het een minderwaardig is aan het ander, kun je zeggen dat van mensen die aan de stappen één, twee en vier werken iets anders gevraagd wordt dan van degenen die in de stappen drie, vijf, zes en verder werkzaam zijn. Bij de eerste groep is het van belang dat je in staat bent te observeren, te luisteren en het geleerde te vertalen naar functionaliteit en 'beeldtaal' die de tweede groep kan omzetten in echte ontwerpen en implementatie. Anders gezegd: de eerste groep moet in staat zijn om orde te scheppen in de veelheid van vergaarde informatie, om daarmee de probleemstelling vergaand detailleren, terwijl de tweede groep de uiteindelijke probleemstelling oppakt en vertaalt naar een interfaceoplossing, die vervolgens wordt geïmplementeerd, getest en in gebruik genomen.
In dit onderscheid zit een oorzaak verborgen van het feit dat veel producten matig aansluiten op de gebruikers. Ontwerpers denken vanaf het begin vaak in termen van oplossingen zonder daarbij het probleem goed te kennen. Dat is hun niet te verwijten: ze worden afgerekend op het afleveren van producten volgens gegeven specificaties. Het pleit er wel voor dat één of meerdere personen in een organisatie zich primair richten op het gebruikersaspect zonder direct te denken in termen van oplossingen. Voor veel organisaties is dit economisch niet haalbaar, bijvoorbeeld omdat er maar weinig producten tegelijk in ontwikkeling zijn of omdat het te veel overhead met5 zich mee zou brengen.
In die gevallen is het inhuren van iemand die dat onderdeel voor zijn rekening neemt zinvol. Door hem 'fysiek' op te nemen in het team en de uit te voeren onderzoeken en evaluaties open te stellen voor alle projectleden, wordt automatisch kennis over gebruik en gebruiker overgedragen naar de eigen organisatie. Ook wordt nu beter zichtbaar wat de toegevoegde waarde is van een persoon of team met gebruiksgericht ontwerpen als kerntaak voor de organisatie en valt beter te bekijken of en hoe dat een volgende keer intern is op te lossen.< BR>
 
Gerard van Os, Glacimonto

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1329078). © Jaarbeurs IT Media.

?


Lees meer over


 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×