maandag 25 mei 2009

Andere Factoren


Het voorkomen van geschillen

Hoewel software bedrijven niet aansprakelijk lijken te zijn voor dezelfde soort geschillen als pakweg een fabrikant van medische apparatuur, kan een gebrek aan usability toch het onderwerp zijn van een rechtszaak. American Airlines heeft bijvoorbeeld Budget Rent-A-Car en Hilton Hotels gedagvaard en dit omdat een $165 miljoen kostende applicatie volledig de mist in ging.

De belangrijkste oorzaken van de implosie van het project waren:
  • Een onvolledig overzicht van de gebruikersvereisten.
  • Gebruikers werden niet betrokken bij het project.
  • Een voortdurend wijzigen van vereisten en specificaties.
Dit zijn allemaal zaken die in de invloedssfeer liggen van usability (Standish).
Twee onafhankelijke studies tonen aan kop-staart ongelukken gevoelig kunnen vermeden worden door het toepassen van goede usability: het plaatsen van een centraal remlicht aan de bovenkant van de achterruit zorgt ervoor dat autobestuurders dit beter en eerder opmerken. Het ligt immers meer in hun blikveld en het is een bijkomende stimuli. Het resultaat is 54% minder van dit soort ongelukken (Chapanis).

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Het Verbeteren van de Efficiëntie

Home > Basis > Enkele Feiten over Usability > Het Verbeteren van de Efficiëntie

Verhogen van de succes ratio’s en het reduceren van gebruikersfouten

NCR heeft na het herontwerpen van enkele interface schermen gemerkt dat de gebruikers hun taak 25% sneller klaarden en 25% minder fouten maakten (Gallaway).
In een usability studie werd gevraagd aan mensen, de plattegrond op de website van www.disney.com te gebruiken en dit om attracties terug te vinden. Ongeveer 20% verloor de weg en sommige hadden dit niet eens door (Kalin).
Zona Research heeft een studie uitgevoerd, waaruit bleek dat 62% van de web shoppers, het online kopen moesten onderbreken omdat ze niet vonden wat ze zochten (Nielsen).
In een andere studie van Jared Spool, over de 15 grootste commerciële websites wereldwijd, bleek dat de gebruikers in 42% van de tijd de gezochte informatie niet kon terugvinden. Nochtans werden ze eerst naar de juiste pagina gebracht! (Nielsen).

Verhogen van het gebruikersplezier

De Gartner Group heeft in een studie aangetoond dat usability engineering de gebruikersvoldoening met 40% kan verhogen (Harrison).
Het IFE (In Flight Entertainment systeem) in gebruik op de lange vluchten van een luchtvaartmaatschappij was zo frustrerend om te gebruiken dat stewardessen massaal een aanvraag indienden om op korte vluchten gestationeerd te worden. Op deze manier voorkwamen ze dat ze een moeilijk en vervelend systeem moesten aanleren en gebruiken. Nochtans zijn langeafstandsvluchten het meest gewaardeerd onder stewardessen (Cooper).

Verhogen van de werkvoldoening en verlagen van het personeelsverloop

Humantech Inc., heeft de kantoor ergonomie en productiviteit bestudeerd van 4000 mensen. Het bleek dat de mensen die veel met software werkten tweemaal zoveel schouder- en nekklachten hadden en 3 maal zoveel oogproblemen. Het ziekteverzuim was hoger, ze hadden minder werkplezier en er was 30% meer personeelsverloop (Schneider).

Verhogen van het gebruikscomfort

Rekening houden met het gebruikerscomfort in een vroeg stadium van het project is veel economischer dan het later op te lossen (IBM).

Verhogen van het leercomfort

Computer+Software News heeft gepubliceerd, dat gebruikers die nieuwe software kopen, gebruikerscomfort op de tweede plaats (6.8 op 10) zetten en leercomfort op de vierde plek plaatsen (6.4 op 10) als belangrijkste aankoop criteria. (Harrison)

Verlagen van de kosten voor ondersteuning

Enkele jaren geleden had Microsoft enorme problemen met de Print Merge functionaliteit van MS Word. Men had nagelaten een gebruikerstest uit te voeren met een bepaalde printer driver.

Het resultaat?

50.000 gebruikers belde ELKE maand naar Microsoft! Het kostte het bedrijf maandelijks bijna $500,000 om deze gesprekken op te vangen.

Men heeft nog eens $900,000 extra mogen uitgeven om brieven met excuses en een patch te versturen naar alle gedupeerden.

Dit probleem had kunnen opgelost worden aan de fractie van deze kosten, als men op voorhand een eenvoudige usability test had uitgevoerd. (Mauro)

Verlagen van de kosten voor training en documentatie

In een ander bedrijf hadden managers becijferd dat een goed ontworpen gebruikersinterface zou resulteren in een terugverdien effect van 32%. Zo’n 35% werd gerealiseerd via minder nood aan training en 30% vermindering in supervisie en verbeterde productiviteit. Buiten deze cijfers waren er nog andere positieve factoren. (Dray en Karat)
Nadat een systeem een usability kuur had ondergaan, was nog maar 1 uur training nodig om het systeem aan te leren. Ervoor was dit een volledige week. Bij AT&T hebben ze $2.500.000 bespaard door usability verbeteringen. (Harrison)

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Het Verhogen van Inkomsten

Home > Basis > Enkele Feiten over Usability > Het Verhogen van Inkomsten

Verhogen van de trafiek en verkopen

Onderzoek heeft aangetoond dat een verhoging van 225% in verkopen mogelijk is door het toepassen van usability technieken. (User Interface Engineering).
Een case studie over een software applicatie heeft aangetoond dat de verkoop van het product met 80% steeg, nadat de nodige usability verbeteringen waren doorgevoerd (Wixon en Jones).
www.move.com heeft, na de aanbevelingen van een usability bedrijf, gemerkt dat gebruikers 62% tot soms 98% meer kans hadden hun gewenste huis te vinden, de verkoop steeg met meer dan 150% (Vividence).
De impact van usability verbeteringen is doorgaans hoog. Dit is geen zaak van een paar procenten. Het is gebruikelijk dat na usability studies de resultaten of verkopen en trafiek stijgt met 100% of meer (Nielsen).
Slecht ontworpen E-commerce sites kunnen soms de helft van hun potentiële verkopen mislopen (Kalin).
De IBM online winkel noteerde, na usability verbeteringen, een verhoging van 120% meer trafiek en 400% meer verkoop (Battey).
129% meer verkeer op www.homeportfolio.com, na de nodige usability werken (Interaction Design Inc.).

Behouden van Klanten

Meer dan 83% van de Internetgebruikers verlaat een website als ze menen dat ze te veel muisklikken moeten maken om te vinden wat ze zoeken (Arthur Andersen).
Een slecht ontwerp kan een website 40% kosten aan terugkerend verkeer. Een goed ontwerp zorgt ervoor dat ze terugkomen (Kalin).

Het aantrekken van meer klanten

www.staples.com heeft na gebruikersstudies, heuristische evaluaties en usability testing de volgende resultaten geboekt:
  • 67% meer terugkerende klanten
  • 31-45% minder klanten die het bestelproces verlaten
  • 10% betere winkelervaring bij de gebruikers
  • 80% verhoogde trafiek
  • Een significante verhoging in de verkoop
(Human Factors International)
In een studie onder internetgebruikers werd gevraagd naar de belangrijkste redenen om over te gaan tot het kopen van een product op een website. Hoewel lage prijzen er zeker toe bijdroegen dat ze dit deden, stond dit maar op de derde plaats. Op de eerste plaats (83% van de gebruikers) kwam een usability item: het maken van een bestelling op een eenvoudige manier (Nielsen).

Het verhogen van het marktaandeel

Voor E-Commerce sites is usability een heel belangrijke factor. Gemiddeld bekeken, jagen dit soort sites de helft van hun oude klanten weg, door ze het niet gemakkelijk te maken informatie te vinden die ze zoeken (Manning).
Terugkerende klanten zijn de meest waardevolle. Nieuwe klanten spenderen gemiddeld $127 per aankoop, terwijl de terugkerende klanten bijna 2 maal zoveel uitgeven, met een gemiddelde van $251 (Nielsen)

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

zondag 24 mei 2009

Reduceren van Ontwikkelingskosten

Home > Basis > Enkele Feiten over Usability > Reduceren van Ontwikkelingskosten

Algemene Besparing op Ontwikkelingskosten

Als een usability wijziging in de ontwerpfase 1 Euro kost, dan kost een identieke wijziging in de ontwikkelfase 10 Euro en zelfs 100 Euro na de oplevering van het systeem. (Gilb)
De gemiddelde gebruikersinterface heeft ongeveer 40 problemen (en websites zelfs meer).
Het verbeteren van de 20 eenvoudigste problemen, resulteert in een gemiddelde usability verbetering van 50%.
Maar de grootste winst wordt gerealiseerd wanneer usability is uitgevoerd in het begin van een project. Dit kan resulteren in efficiëntie verbeteringen van 700% en meer. (Landauer)
In de ontwerpfase kunnen meerdere alternatieven geëxploreerd worden tegen een lage kost. Tijdens de opleveringfase is dit niet mogelijk, wegens de hoge kostprijs. (Bias en Mayhew)

Grafiek die aangeeft dat in de beginfase meerdere alternatieven kunnen bedacht worden aan een minimale kost, terwijl in de eindefase dit omgekeerd is
American Airlines maakt gebruik van usability technieken en slaagt er in usability problemen nog in de ontwerpfase te detecteren. Dit vertaalt zich in een kostenbesparing van 60-90% op dit soort problemen. (Harrison)
63% van de grotere projecten overschrijden het budget. Van de 24 oorzaken bestaat de top 4 uit zaken gerelateerd aan een gebrek aan usability engineering (Lederer en Prasad)

Top 4 oorzaken van budgetoverschrijding:
  • Frequente wijzigingen op vraag van de gebruikers
  • Niet genoteerde requirements van de gebruikers
  • Gebruikers die hun eigen requirements niet kennen of begrijpen
  • Gebrekkige communicatie en wederzijds onbegrip tussen gebruikers en analisten
Een financieel dienstverlenend bedrijf diende een volledige applicatie uit dienst te nemen die ze had ontwikkeld. Kort voor de implementatie voerde het ontwikkelteam een Gebruikers Acceptatie uit en ontdekten ze een fatale fout in hun veronderstellingen over het invoeren van gegevens. Het was te laat om de onderliggende structuur te wijzigen en de applicatie werd nooit in gebruik genomen (Dray)

Kortere ontwikkeltijden

Het toepassen van usability engineering vroeg in de projectfase kan de ontwikkeltijd reduceren met 30% tot 50% (Scerbo)
Usability technieken lieten toe dat een hoog technologisch bedrijf monotone ontwikkeling taken kon verminderen met 40% (Bias en Mayhew)
Bij een ander bedrijf, zorgden usability technieken ervoor dat ze de ontwikkelingtijden met 33% to 50% kon inkorten (Bosert)

Lagere Kosten voor Onderhoud

Een bekende studie heeft aangetoond dat 80% van de kosten van een software project plaats hebben na de opleveringsfase. De meeste van deze kosten waren gerelateerd met ‘onbekende en onvoorziene’ gebruikers vereisten en andere usability problemen (Pressman)
Martin en McClure hebben analyses uitgevoerd op de onderhoudsfase van softwareprojecten en hebben ontdekt dat deze, gemiddeld 167% meer tijd vergen dan de ‘officieel’ gedeclareerde onderhoudsuren. Interne ontwikkelorganisaties spenderen de meerderheid van hun middelen aan onderhoudsactiviteiten en kunnen dus niet ingezet worden bij de ontwikkeling van strategisch belangrijke nieuwe systemen. (Martin en McClure).

Besparing op herontwerpkosten

Sun Microsystems heeft $20.000 uitgegeven aan usability in een vroege fase van een project en hiermee $152.000.000 bespaart (Rhodes).

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Enkele Feiten over Usability

Home > Basis > Enkele Feiten over Usability

Usability zorgt voor tal van voordelen en hier is ook empirisch bewijs over terug te vinden. Talloze projecten en studies leggen de feiten bloot: usability werkt!

We kunnen deze feiten indelen als volgt:
Deze feiten zijn afkomstig van goed gedocumenteerde en betrouwbare bronnen en kunnen gebruikt worden als leidraad bij het creëren van een Kosten/Baten Analyse.

Ook kan je ze gebruiken om klanten, collega's of je chef te helpen overtuigen dat usability effectief werkt.

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

dinsdag 19 mei 2009

Usability Doelen

Home > Methodologie > Fusion Usability Recept > Gebruikers Context > Usability Doelen

Fusion Usability Recept Fase
Business Context
Gebruikers Context
Gebruikers Ervaring
Installatie

Doel

Bijna alle engineering processen houden in dat je een specifiek objectief en meetbaar doel, in een vroeg stadium van het project, vastlegt en daar naar toe werkt in een iteratieve manier. Usability engineering en het Fusion Usability Recept in het bijzonder, verschilt op dit vlak niet.

Het vastleggen van usability doelen heeft nut om 3 redenen:
  • Ze sturen alle beslissingen wat betreft de gebruikers interface.
  • Ze stroomlijnen en verkorten het ontwikkel proces
  • Ze dienen als acceptatie criteria tijden de usability evaluaties en sturen deze dus.
Ze sturen alle beslissingen wat betreft de gebruikers interface

Het geeft alle mensen, betrokken bij een project, iets concreet om naar toe te werken en iets concreet om hun ontwerpen tegenover te evalueren. Wanneer bijvoorbeeld, in een willekeurig project, iedereen begrijpt en aanvaard dat gebruikscomfort belangrijker is voor ervaren gebruikers dan leercomfort voor de beginners dan kunnen alle inspanningen van het team gefocusseerd worden op alternatieven die gebruikscomfort ondersteunen (bijvoorbeeld snelheid en efficiëntie).

De usability doelen sturen dus alle beslissingen wat betreft de gebruikers interface. Wanneer je geen duidelijke doelen vastlegt, dan werk je eigenlijk op goed geluk.

Ze stroomlijnen en verkorten het ontwikkel proces

Usability doelen stroomlijnen en verkorten het ontwikkel proces.

De meeste mensen, betrokken bij het ontwikkelen van software, kennen de eindeloze vergaderingen, over de gebruikersinterface, waar de aanwezigen verhitte argumenten bovenhalen om hun ontwerp idee door te drukken. Als er geen overeengekomen usability doelen zijn vastgelegd, die het ontwerp proces sturen, dan kunnen deze vergaderingen urenlang (en soms zelfs maandenlang) doorgaan. De aanwezige mensen op die meetings, gebruiken argumenten vanuit het perspectief van een bestgekende of favoriete gebruiker en soms zelfs creëren ze een fictieve persoon. Ook al zijn er meerdere soorten gebruikers die uiteindelijk het product horen te gaan gebruiken. Wanneer iedereen zijn ontwerpidee baseert op zijn ‘persoonlijke’ gebruiker, dan kan niemand een consensus bereiken. Veel tijd wordt hierdoor verloren en de meest verbaal agressieve persoon zal de discussie winnen. Het maakt niet uit of zijn idee goed of slecht is voor de gehele gebruikers populatie.

Het kost beduidend minder tijd en energie om een goede beslissing te bereiken, wanneer iedereen een gemeenschappelijk en accuraat beeld heeft van de totale gebruikerspopulatie (welke afkomstig is van het Gebruikers Profiel), de gebruiker zijn taken en zijn werkomgeving (welke afgeleid kan worden uit het Taak en Omgeving Profiel). Wanneer men weet wie exact de gebruikers zijn en hoe deze hun taken uitvoeren in hun specifieke omgeving, dan kan men duidelijke en reële doelen vastleggen.

Ze dienen als acceptatie criteria tijden de usability evaluaties en sturen deze dus

Het vastleggen van usability doelen kan ook dienen als acceptatie criteria tijdens de usability evaluaties, in het bijzonder deze op het einde van het ontwikkelproces. Usability doelen sturen dus ook het evaluatie proces.

Rode Vlag

Wanneer de projectmanager of het team geen usability doelen wil vastleggen, dan kan je dit interpreteren als een rode vlag of een indicatie dat er een fundamenteel gebrek is aan steun voor Usability Engineering. In zulke situaties, tenminste als je de keuze hebt, dan zou je moeten overwegen om uw diensten elders aan te bieden, je kan immers beter je tijd en energie aanwenden aan een ander project waar je wel een impact kunt maken.

Omschrijving

Usability doelen kunnen achterhaald worden uit het Gebruikers, Taak en Omgeving Profiel, maar ook vanuit de algemene business doelen. Sommige doelen kunnen geschikt zijn voor de ene groep gebruikers, maar niet voor een andere. Bijvoorbeeld leercomfort doelen zullen geen hoge prioriteit krijgen voor complexe producten, die door goede getrainde en hoogopgeleide gebruikers frequent gebruikt worden, zoals bijvoorbeeld spaceshuttle software of luchtverkeer systemen. Voor deze producten zullen gebruikscomfort doelen eerder de prioriteit krijgen. Omgekeerd, zullen leercomfort doelen belangrijk zijn voor gebruikers die geen training krijgen en de applicatie weinig gebruiken, zoals informatie kiosken in hotels. Usability doelen kan je ook bekomen via het marketing departement, competitieve analyses en technische ondersteuning groepen.

Usability doelen kun je indelen in 2 grote groepen:
  • Kwalitatieve Doelen
  • Kwantitatieve doelen
Deze laatste kan dan nog verder uitgesplitst worden in leercomfort- en gebruikscomfort doelen. Merk op, dat binnen deze brede categorieën van doelen, nog meer verfijning mogelijk is.

Kwalitatieve Doelen

De usability doelen die niet gekwantificeerd kunnen worden, zijn de kwalitatieve doelen, zoals:
  • Het ontwerp moet gebruikers ondersteunen, die veel onderbroken worden. Dit kan door gebruik te maken van veel contextuele informatie op het scherm, om de gebruikers te herinneren waar ze zijn, nadat ze zijn afgeleidt.
  • Het ontwerp moet gebruikers ondersteunen die een complex systeem weinig gebruiken. De applicatie moet zichzelf uitleggen en het leercomfort ondersteunen. Het moet zoveel mogelijk business regels en procedures bevatten en de gebruikers moeten bij het handje gehouden worden tijdens hun taak, zodat ze niet de details moeten onthouden van de juiste procedures.
Kwalitatieve doelen zijn extreem bruikbaar om het initiële ontwerp te sturen. In de bovenstaande twee voorbeelden, kunnen de doelen onmiddellijk afgeleid worden van het Gebruikers- en Taak Profiel.

Kwalitatieve doelen zijn zeer nuttig, maar het is moeilijk om te bepalen of ze behaald zijn in het definitieve ontwerp en dit omdat ze juist breed bepaald worden en niet gekwantificeerd. Ze kunnen dus niet gebruikt worden als acceptatie criteria tijdens de usability evaluaties.

Kwantitatieve Doelen

Kwantitatieve doelen zijn wel objectief en meetbaar, zij kunnen dus wel als acceptatie criteria dienen voor usability evaluaties. Voorbeelden van kwantitatieve doelen zijn:
  • Ervaren gebruikers (mensen die de transactie minstens 5 keer hebben uitgevoerd tijdens trainingsessies) moeten binnen de twee minuten gegevens van een formulier invoeren in een bepaald elektronisch invulscherm.
  • Nieuwe gebruikers (mensen die het systeem nog nooit hebben gebruikt) moeten binnen de drie minuten gegevens van een formulier invoeren in een bepaald elektronisch invulscherm.
Merk op, dat in bovenstaande voorbeelden, niet alleen de invoer tijd wordt gekwantificeerd, maar dat ook het type gebruiker (ervaren of onervaren) gedefinieerd is. Het eerste voorbeeld is tevens een gebruikerscomfort doel, het tweede voorbeeld is een leercomfort doel.

Gebruikscomfort doelen leggen de focus op het gebruik van de applicatie door ervaren gebruikers, die getraind zijn in de applicatie en het voldoende gebruikt hebben om een voldoende expert performantie te leveren. Gebruikscomfort wordt meestal gequoteerd door te kijken welke snelheid, efficiëntie en flexibiliteit een interface biedt aan een ervaren gebruiker.


Leercomfort doelen richten zich dan weer eerder op het gebruik van de applicatie door ‘maagdelijke’ gebruikers die nog in een opleiding fase zitten, of gebruikers die een training hebben genoten maar de applicatie zo weinig gebruiken dat ze vergeten zijn hoe deze te hanteren. Leercomfort kan je min of meer quoteren aan de hand van de duur en moeilijkheidsgraad van de leercurve voor gebruikers die nog niet aanzien worden als experts.

Alle kwantitatieve doelen kunnen geformuleerd worden als absolute en relatieve doelen.

Absolute doelen kan je beoordelen op een absolute manier, bijvoorbeeld ‘in aantal seconden of minuten per taak’ of ‘in een specifiek aantal fouten per taak’.


Relatieve doelen refereren naar ervaringen met het product onder ontwikkeling ten op zichtte van ervaringen met producten van concurrenten, vorige versies of de manuele procedures van dezelfde taak.

Alle kwantitatieve doelen kunnen ook geformuleerd worden als performantie en preferentie/satisfactie doelen

Performantie doelen kwantificeren actuele gebruikers performantie terwijl ze een applicatie gebruiken om een taak uit te voeren. Als meetinstrument gebruikt men meestal de tijd (om een taak te vervolledigen of aan te leren) of fouten (zowel aantal als soort).

Wixon en Wilson menen dat performantie op verschillende manieren kan gemeten worden:
  • De tijd om een taak te vervolledigen
  • De tijd om een taak te vervolledigen, nadat de gebruiker een gespecificeerde tijd verwijderd was van de applicatie.
  • Aantal en soort fouten per taak
  • Aantal fouten per tijdseenheid
  • Aantal navigatie bewegingen naar de online help of handleidingen
  • Aantal gebruikers die een bepaalde fout maken
  • Aantal gebruikers die een taak succesvol vervolledigen
Preferentie/satisfactie doelen zijn ook kwantificeerbaar.

Preferentie doelen meten de gebruiker zijn duidelijke voorkeur voor een bepaalde interface waar hij enige ervaring mee heeft.

Satisfactie doelen meten dan weer een zeker niveau van tevredenheid bij een bepaalde interface.

Alhoewel deze doelen eerder subjectieve reacties meten, i.p.v. een objectieve performantie, kunnen ze toch gekwantificeerd worden. Preferentie is duidelijk kwantificeerbaar – de gebruiker maakt gewoon een keuze. Satisfactie kan gemeten worden door middel van een schaal (bijvoorbeeld van 1-Totaal niet tevreden tot 5-Bijzonder tevreden)

Whiteside, Bennet en Holtzblatt suggereren dat kwantitatieve doelen kunnen uitgedrukt worden in 4 niveaus:

Niveau van Performantie of Satisfactie
Omschrijving
Huidig niveau
Bekomt men door het manuele proces, een ouder versie of een competitief product te meten.

Minimum Acceptabel niveau
Dit gebruikt men tijdens de iteratieve ontwikkeling en evaluatie om te bepalen wanneer de iteratie moet eindigen.

Vooropgesteld niveau
Wordt gebruikt om de ontwikkel inspanningen te sturen en focussen.

Optimaal niveau
Dit is het niveau dat men wil halen op lange termijn, na verschillende versies van de applicatie of wat mogelijk zou kunnen zijn indien tijd, geld en andere conflicterende agenda’s geen rol zouden spelen


Keuze en Prioriteiten van Doelen

Doelen kunnen refereren naar de performantie of tevredenheid van een nauw gedefinieerde applicatie functie of ze kunnen ruim gedefinieerd worden en refereren naar iets zoals het volbrengen van een complexe taak die bestaat uit meerdere stappen. Wanneer je werkt aan een compleet nieuw product dan zullen doorgaans ruim gedefinieerde doelen het beste werken. Wanneer je werkt aan een verbetering in een product, dan zullen nauw kwantificeerbaar georiënteerde doelen eerder de beste keuze zijn.

Het kiezen van de juiste kwantitatieve doelen is niet eenvoudig. Wixon en Wilson stellen dat er een groot risico is om ambitieus onuitvoerbare of nutteloze doelen te kiezen. Het is een soort kunst die een zekere ervaring vereist om onder de knie te krijgen. Ze stellen ook dat het kiezen van usability doelen een gezamenlijke inspanning vraagt van alle stakeholders, inclusief de gebruikers, management en project teamleden. Op die manier bekom je een globale aanvaarding van de usability doelen en een verzekering dat de balans gevonden wordt tussen wat belangrijk is voor een succesvol applicatie en wat technisch haalbaar is.

Usability doelen moeten, wanneer deze geformuleerd zijn, een prioriteit krijgen. Het komt er op neer dat je identificeert welke doelen het meest bijdragen tot het succes van een applicatie en dat je deze dus de hoogste prioriteit te geeft. Doelen met een lage prioriteit kunnen geïdentificeerd en eventueel opgelost worden, maar niet ten koste van de doelen met een hoge prioriteit en niet wanneer ze op een excessieve manier de tijd en kosten van het project verlengen of verhogen.

Wanneer je usability engineering technieken introduceert in een organisatie, dan is het verstandig om enkele duidelijke doelen te definiëren, die eenvoudig te evalueren zijn en kunnen behaald worden met relatief weinig inspanning. Dit om de stakeholders en teamleden vertrouwd te maken met deze taak.

Het formuleren van teveel doelen, kan ervoor zorgen dat het testen te complex zal worden of te lang zal duren en dus onpraktisch uit te voeren is. Het is dus aangewezen om uw doelen te beperken. Een goede vuistregel is, om voor een willekeurig project kwantitatieve doelen te destilleren vanuit een kleine groep kwalitatieve doelen met een hoge prioriteit.

Procedures

Fusion Usability Recept Fase
Business Context
Gebruikers Context
Gebruikers Ervaring
Installatie

Procedures Usability Doelen

Bekijk ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Aanwenden Usability Richtlijnen

Home > Methodologie > Fusion Usability Recept > Gebruikers Context > Aanwenden Usability Richtlijnen

Fusion Usability Recept Fase
Business Context
Gebruikers Context
Gebruikers Ervaring
Installatie

Doel

Het doel van het aanwenden van Usability Richtlijnen is te identificeren en na te kijken welke algemene user interface ontwerp principes en richtlijnen geschikt kunnen zijn om een interface te ontwerpen in de Gebruikers Ervaring fase. Deze richtlijnen zijn geen vervanging van de specifieke product vereisten analyse en de iteratieve usability evaluaties. Ze werken er eerder met samen om richting te geven aan het ontwikkelen van een interface in de Gebruikers Ervaring fase.

Je hoort dus de Gebruikers, de Taak en Omgeving Profiel te combineren met usability richtlijnen om het meest optimale resultaat te bereiken.

Omschrijving

In deze fase zal je dus usability richtlijnen zoeken die bruikbaar zijn voor uw project. Je kan verschillende bronnen raadplegen om een lijst met richtlijnen samen te stellen:

Guidelines:

Je kan verschillende links naar guidelines raadplegen.

Boeken over dit onderwerp, zoals:
  • The Design of Everyday Things van Donald Norman
  • Designing User Interface for International Use van Jakob Nielsen
  • Developing User Interfaces van Deborah Hix en H. Rex Hartson
  • Envisioning Information and Visual Explanations van Edward Tufte
  • The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques van Wilbert Galitz
  • The GUI Style Guide van Susan Fowler en Victor Stanwick
  • The Icon Book van William Horton
  • Principles and Guidelines in Software User Interface Design door Deborah J. Mayhew
  • Readings in Human-Computer Interaction: Toward the year 2000 van Ronald Baecker, Jonathan Grudin, William Buxton en Saul Greenberg.
Vakliteratuur, zoals:
  • Human Factors (Human Factors and Ergonomics Society)
  • Behaviour and Information Technology (Taylor en Francis)
  • Interacting with Computers (Lawrence Erlbaum Associates Publishers)
  • Human-Computer Interaction (Butterworth-Heinemann)
  • Interactions (ACM SIGCHI)
  • Ergonomics in Design (Human Factors and Ergonomics Society)
  • Common Ground (Usability Professionals’ Association)
  • SIGCHI Bulletin (ACM SIGCHI)
Conferenties:
  • ACM SIGCHI Annual Conference
  • Human Factors and Ergonomics Annual Meeting
  • Interact (jaarlijkse conferentie, gesponsord door de IFIP)
  • Annual Conference of the Usability Professionals’ Association
Er zijn nog andere bronnen zoals cursus materiaal, rapporten van case studies, interne richtlijnen, etc.

Procedures

Fusion Usability Recept Fase
Business Context
Gebruikers Context
Gebruikers Ervaring
Installatie

Procedures Aanwenden Usability Richtlijnen

Bekijk ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Mozilla wil tabs weg in browser

HomeNieuws > Mozilla wil tabs weg in browser

Mozilla Labs heeft een ontwerpwedstrijd gelanceerd die gericht is op het vinden van een alternatief voor het surfen met tabbladen.

"Tabs werkten goed op tragere machines op een ‘licht’ internet waar tien browsersessies veel browsersessies zijn”, beweert Mozilla op haar Design Challenge website.

Mozilla wil tabs weg in browser

"Vandaag zijn 20 of meer parallelle sessies vrij algemeen, de browser is meer een besturingssysteem dan een data display toepassing, we gebruiken het om het internet te beheren als een soort gedeelde harde schijf. Wanneer je echter meer dan zeven of acht tabbladen opent dan zijn deze vrijwel nutteloos."

Aza Raskin, hoofd van de user experience bij Mozilla Labs, heeft al geopperd over de mogelijkheid van het verplaatsen van de tabbladen naar de zijkant van de browser met tabbladen gegroepeerd volgens het soort activiteit (applicaties, werk ruimtes, etc…).

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

maandag 18 mei 2009

Organisatorische Structuren

Home > Basis > Usability Hindernissen > Organisatorische Structuren

Soms creëren de structuren van een organisatie of bedrijf ongewild hindernissen die het invoeren van een usability methodologie bemoeilijken of zelfs onmogelijk maken.

Soms kan je aan het ontwerp van een interface zien hoe een organisatie of bedrijf is gestructureerd.

Binnen een groot bedrijf zijn er diverse groepen mensen in verschillende departementen bezig met het ontwikkelen van software. Al deze entiteiten leven meestal letterlijk op een eiland naast elkaar en niet met elkaar.

Ze hebben allen hun eigen idee van het ontwerpen van interfaces, waardoor gebruikers het lastiger hebben om deze aan te leren en te gebruiken en dit door het gebrek aan consistentie en product comptabiliteit.

Soms is er zelfs een gebrek aan consistentie tussen de verschillende applicaties gecreëerd door hetzelfde team ontwikkelaars. Dit kun je bijvoorbeeld merken aan iets relatief eenvoudig zoals de structuur van het helpsysteem bij applicaties.

Het opstellen van globale richtlijnen en in werking stellen van gespecialiseerde teams kan dit gevoelig verbeteren.

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Vastgeroeste Praktijken

Home > Basis > Usability Hindernissen > Vastgeroeste Praktijken

Vastgeroeste praktijken kunnen usability soms negatief benaderen.

De gebruikers mogen geen contact hebben met de ontwerpers

Meestal is het ontwerpteam geïsoleerd en ‘beschermd’ van de gebruikers.

Men heeft blijkbaar schrik dat wanneer ze wel veel contact hebben met elkaar, dat het ontwikkelteam de budgetten en planningen niet meer kan respecteren, dat gebruikers gevoed zullen worden met valse verwachtingen of dat bepaalde bedrijfsgeheimen of -strategieën van een nieuw product prematuur worden vrijgegeven.

Men gaat er zelfs gratuit vanuit dat gebruikers op geen enkele manier eeen positieve bijdrage kunnen leveren.

Het gebruik van verouderde ontwikkel methodologieën

In veel bedrijven zijn de diverse aspecten (zoals hardware, software, documentatie, training, marketing, ...) die komen kijken bij het ontwerpen van software, gescheiden van elkaar in afzonderlijke departementen.

Om de werkmiddelen te coördineren met elkaar zal men vaak een Waterfall-achtig model gebruiken, waarbij elke fase (analyse, architectuur, ontwikkeling en testing) eerst volledig wordt afgewerkt en daarna wordt vastgevroren.

Iteratieve methodologieën brengen in zulke organisaties niet alleen een cultuurschok met zich mee, het zal ook praktisch en organisatorisch heel wat werk met zich meebrengen, om veranderingen teweeg te brengen.

Een gebrek of afwezigheid aan goede tools

Ze hebben nooit gewerkt met prototype tools of streaming screen capture software. Ze kennen het niet en kunnen het ook niet naar waarde schatten. Wat men niet kent, wijst men dan ook gemakkelijk af.

Traditionele focus op een functionele aanpak

De focus op functionaliteit en features is misschien wel de belangrijkste oorzaak waarom zoveel interfaces falen. Beter zou zijn dat men meer aandacht zou hebben voor de werkelijke taken van de gebruiker.

De aangeboren gewoonte om analogieën te gebruiken

Op zich is dit geen slecht idee, mensen denken nu eenmaal in analogieën. Het gebruik van metaforen wordt juist aangemoedigd door mezelf, maar niet tegen elke prijs. Wanneer de analogie te ver gezocht is of de kracht van de computer niet helemaal wordt benut, dan hoor je metaforen te vermijden.

In een oud terminal programma van Microsoft diende je een telefoonnummer in te voeren via een scherm dat een telefoon als metafoor gebruikte. Op het eerste zicht lijkt dit een goed concept, maar je hoorde wel deze nummers in te voeren door te klikken met de muis op een telefoonachtige layout in het scherm. Dit ging tergend langzaam en het herstellen van fouten was niet eenvoudig.

Dit is een voorbeeld van een minder goed gebruikt metafoor. Terloops, Microsoft heeft dit tegenwoordig aangepast.

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Bedrijfscultuur

Home > Basis > Usability Hindernissen > Bedrijfscultuur

Waarom zou de manager van het ontwikkelteam alle kosten moeten dragen, terwijl een andere business unit alle voordelen realiseren?
Zelfs met goede en gedetailleerde kosten/baten analyses kan het gebeuren dat men niet van usability wil weten. Veelal worden projectmanagers afgemeten op het respecteren van de geplande timing en budget of het op tijd leveren van de overeengekomen functionaliteit. Hun bonussen en promotiekansen zijn gerelateerd met dit.

Projectleiders zijn veelal niet verantwoordelijk voor zaken zoals gebruikersproductiviteit, verkoopsresultaten of training en ondersteuning. Daar gaan weer andere mensen over.

Wanneer het bedrijf zo gestructureerd is, dat het ontwikkelteam, marketing en de mensen die de software (intern) gebruiken, ingedeeld zijn in afzonderlijke business units met afzonderlijke budgetten dan is het eenvoudig om te begrijpen waarom ze usability niet willen invoeren.

Waarom zou de manager van het ontwikkelteam alle kosten moeten dragen, terwijl een andere business unit (productie, marketing, training en support) alle voordelen realiseren?

Het is niet dat ze de voordelen van usability niet begrijpen, maar de cultuur van het bedrijf maakt het moeilijk om usability aan te wenden.

Afweging tussen persoonlijk voordeel en usability
Afweging tussen persoonlijk voordeel en usability

Veel bedrijven zijn zo gestructureerd dat een individuele projectmanager moet kiezen tussen zijn eigen persoonlijk financieel voordeel en usability.

Echter, dit is een misvatting:
  • Wanneer er totaal geen usability zou zijn, dan verliest hij of zij vroeg of laat zijn werk. 
  • Wanneer hij of zij usability toelaat dan schept dit ook persoonlijk (financieel) voordeel voor de projectmanager. Doorgaans zal, onder andere, de tijd die nodig is om software te ontwikkelen juist korter zijn.
Grudin heeft in een studie aangetoond dat mensen in bedrijven nog andere, typisch menselijke, hindernissen neerleggen die kunnen conflicteren met usability:
  • Het verlangen om ‘koninkrijkjes’ te verzamelen en te behouden. Wanneer ze met veel moeite een ivoren toren hebben gecreëerd dan staan ze de toegang niet gemakkelijk meer af.
  • Het verlangen om nieuwe technologie te gebruiken, puur om de eigen vaardigheden te onderhouden en niet omdat ze geschikt zou zijn voor de vooropgestelde gebruiker.
  • Het verlangen om goed overeen te komen met elkaar, welke dikwijls leiden naar ontwerp compromissen die reflecteren naar goede onderhandelingspraktijken, maar usability negatief kunnen beïnvloeden.
Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Mythen, geloof en vooroordelen

Home > Basis > Usability Hindernissen > Mythen, geloof en vooroordelen

In de wereld van de softwareontwikkeling en webdesign hechten deze culturen zich vast aan een aantal mythen, overtuigingen en vooroordelen t.o.v. usability en dit om weerstand te bieden tegen verandering. Soms neemt dit bijna religieuze proporties aan. Het is belangrijk om te weten wat deze zijn, zodoende kan men deze ontzenuwen en usability binnen de organisatie of het bedrijf positief verwelkomen.

De kwaliteit van de gebruikersinterface doet er niet echt toe

In de jaren 60, 70 en zelfs 80 was dit een veel gehoorde mening van managers en softwareontwikkelaars.

Tot op een zekere hoogte hadden ze nog gelijk ook. Tot eind jaren 70 waren de programmeurs veelal de enige gebruikers van softwaresystemen op mainframes en minicomputers. Mensen vroegen een taak aan, de programmeurs ontwikkelde de software, gebruikte de applicatie en gaven een resultaat terug aan degene die er om vroeg. De software was geschreven op maat van de gebruiker (de programmeur zelf) en vanuit hun standpunt dus altijd gebruiksvriendelijk.

Met de komst van de eerste personal computers in de jaren 80, veranderde het gebruikerspubliek weliswaar, maar door het gebrek aan concurrentie, was wederom de interface niet belangrijk. Usability deed pas zijn intrede wanneer er een kritische massa werd bereikt, dit in zowel de aanbieders als afnemers van software.

Het Internet heeft dit nog versneld.

Vandaag zijn er nog altijd veel mensen die geloven dat de gebruikersinterface er niet toe doet.

Wanneer ontwerpers vertrouwd zijn met usability guidelines, dan zullen ze ook goede interfaces ontwikkelen

Dit is een andere mythe onder veel software- en website ontwerpers. Deze guidelines helpen uiteraard, maar Usability Engineering is, net zoals software engineering, een proces dat gecoördineerd moet worden.

Richtlijnen op zich, voldoen niet. Immers, veel richtlijnen kunnen verkeerd uitpakken bij een bepaald gebruikerspubliek of situatie. Weten wie die gebruiker is, hoe en waar deze zijn taak inricht, is niet te vervatten in richtlijnen. Dit kan men wel bekomen door een beroep te doen op bepaalde procedures en een elementaire kennis van cognitieve psychologie.

De interface ontwikkelen doen we best laat in het development proces

Veel software en webdesign specialisten geloven dat een interface ontwerpen, niet meer is dan maar wat knoppen en tekstboxen op de juiste plek plaatsen. Het lijkt een eenvoudige taak en als ze al merken dat er iets grondig fout is, dan is het dikwijls te laat om het te herstellen. Het project zit immers in een eindfase en de interface herontwerpen kost tijd, wat tot een vertraging van het project zal leiden.

In het beste geval doet het functioneel wat het moet doen, de manier waarop is een ander zijn probleem.

Toch zien ze geen redenen om nieuwe technieken en methodes te introduceren in een vroeg stadium van het ontwerpen van software.

Gebruiksvriendelijkheid is een kwestie van smaak

Deze mythe is misschien wel de belangrijkste veroorzaker van weerstand t.o.v. usability.

Veel mensen begrijpen gewoon niet dat usability weinig te maken heeft met gezond verstand, esthetica en subjectieve opinies.

Zij beseffen niet altijd dat usability zich uitermate leent voor een engineering aanpak en daarom weten ze niet hoe ze hun eigen methodologie kunnen aanpassen om usability te omarmen.

De interface kan gewoon gemaakt worden tijdens het coderen van de source code

Deze mythe sluit aan bij de vorige en spruit voort uit het geloof van de software engineer, dat usability subjectief is en een kwestie is van gezond verstand.

Ze zijn zich niet bewust van o.a. de technieken die gebruikt worden in experimentele psychologie, welke objectief de performantie van de interacties tussen mens en computer meten.

Software ontwikkelaars geloven dat het gewoon een eenvoudige keuze is gebaseerd op gezond verstand en zien het niet als een engineering proces dat gestoeld is op de vertrouwde fases zoals het definiëren van doelen, iteratief ontwikkelen en testen.

Usability is duur en niet haalbaar voor onze organisatie

Usability labo’s met spiegelglas, eye-tracking en video apparatuur, het inzetten van gespecialiseerde etnografen, antropologen en psychologen zorgen er voor dat er effectief een prijzig kaartje kan hangen aan usability.

Wanneer mensen over usability filosoferen, dan denken ze doorgaans aan deze dure zaken.

Maar usability is meer dan dit. Er zijn tal van disciplines binnen het usability gebeuren die weinig geld kosten en misschien wel een grotere impact hebben.

Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

Usability Hindernissen

Home > Basis > Usability Hindernissen

Wanneer mensen usability gaan promoten binnen een organisatie, dan zullen ze vlug merken dat er onzichtbare krachten aanwezig zijn, die uit zijn op het behouden van de status-quo. Deze krachten kunnen ingedeeld worden in de volgende categorieën:
Bekijk Ook:

Vond je dit artikel interessant? Doe dan het volgende:
    Huur mij knop

mei 2009