Voorbeeldcasus: PC Garage

Universiteit Utrecht, Beta-faculteit
Departement Informatica, afd. Informatiekunde
.
Versies
Jan 2006 Versie 1.0, Matthias Fabriek
Apr 2006 html conversie, aanpassingen, JHV
.
Dit document bevat een uitwerking van een project dat in het verleden is uitgevoerd bij het vak Human Computer Interaction (HCI). Het is gemaakt om een snel overzicht te geven wat er verlangd wordt bij nieuwe projecten.
In dit document worden zowel goede als slechte voorbeelden gegeven, voor het merendeel afkomstig uit oud werk van studenten aan deze casus.

Casus-omschrijving

PC Garage is een (virtuele) computershop die verkoopt aan zowel huis-tuin-en-keuken klanten als aan bedrijven. Het bedrijf hecht veel waarde hecht aan persoonlijk contact met haar klanten, zoals het samen drinken van een kopje koffie terwijl rustig naar de wensen van de klant wordt gekeken. Omdat veel winkels tegenwoordig online zijn, wil ook PC Garage op het internet PC's en onderdelen gaan verkopen. De opdracht is om voor deze winkel een online computerwinkel te ontwikkelen waarbij het persoonlijke karakter behouden blijft.
.
Voor een uitgebreidere omschrijving, zie het formele verzoek en de projectaanpak in de appendices. Deze informatie was vooraf beschikbaar voor de studenten aan het begin van het project.
.
.

Inhoud

Fase 1: Programma-specificaties opstellen
Opdracht verwerven
Huidige gang van zaken beschrijven
Scenario's produceren
Gebruikers- en taakprofiel bepalen
Kwaliteitsplan opstellen
Use Cases identificeren
Programma-specificaties opstellen
Rapport 'programma-specificaties' opstellen
.
Fase 2: Basisontwerp maken
Activity diagram maken
Metaforen kiezen (o.b.v. user model)
Interactiestijlen bepalen
Hoofddialoog ontwerpen (o.b.v. user model)
Panelen ontwerpen
Paneelcomposities ontwerpen
Storyboard tekenen
Evaluatie uitvoeren
Bijstellingen uitvoeren
Rapport 'Basisontwerp' opstellen
.
Fase 3: Prototype vervaardigen en evalueren
Platform kiezen
Widgets bepalen
Subdialogen ontwerpen
Prototype bouwen
Evaluaties uitvoeren
Bijstellingen bepalen
Eindrapport opstellen
.
Appendix I: Brief met formele casusomschrijving
Appendix II: Projectvoorstel PC garage1
Probleemstelling
Uitgangspunten
Globale omvang
Team en organisatie
Deliverables
.
.

Fase 1: Programma specificaties opstellen

Opdracht verwerven

Het eerste deel van de opdracht is gegund en wordt aan het eind van deze fase opgeleverd. Of de vervolgopdracht ook gegund wordt hangt af van onze overtuigingskracht. Wat is precies de Business case? In dit onderdeel kijken we nauwgezet naar alle informatie die we vooraf hebben gekregen in de brief en het projectvoorstel. We zetten alles op een rijtje om zelf goed overzicht te hebben. Een aantal van de belangrijkste wensen zijn:

  1. Via internet toegankelijk
  2. Klantgericht
  3. Persoonlijk
  4. Mogelijkheid zelf systeem samen te stellen
  5. Geschikt voor bedrijven en consumenten
  6. Geschiktvoor vaste klanten en incidentele bezoekers

Huidige gang van zaken beschrijven

De huidige gang van zaken wordt bestudeerd door het afnemen van (gestructureerde) interviews m.b.t. de taken en met welk doel die uitgevoerd worden. Op basis van de analyse van de interviews kom je er achter hoe de taken precies uitgevoerd worden: de verschillende scenario's komen zo in beeld. Plus dat je uit de interviews kunt opmaken of er huidige knelpunten zijn, of wensen voor verbetering. Hiernaast orienteer je je op vergelijkbare situaties, bijvoorbeeld als je een applicatie gaat ontwikkelen kijk je naar bestaande concurerende of vergelijkbare applicaties.
In deze voorbeeldcasus zijn m.b.t. PC Garage geen uitvoerige taakanalyses gemaakt, maar wel is de huidige situatie bestudeerd bij haar concurrenten in de stad, als ook op internet. Aan de hand van de informatie die hier gevonden / gehoord is hebben we onze kennis en inzicht aangaande het wel en wee van een computerwinkel uitgebreid. Dit betreft ook inzicht in de klanten: wat willen ze wel en wat willen ze niet?

Goed voorbeeld:

Een goed voorbeeld is het onderstaande verslag van een bezoek aan een computerwinkel:

Om een inzicht te krijgen in de vragen die mensen stellen als ze een PC gaan kopen zijn we naar de Dixons in Utrecht geweest om vragen te stellen aan een verkoper.

Doel

Ons doel was behalve inzicht in de vragen ook het opstellen van een aantal scenario's.

Voorbereiding

Ter voorbereiding hebben we een aantal vragen voor de verkoper opgesteld. We hielden er natuurlijk rekening mee dat de Dixons geen echte computerspeciaalzaak is. Toch leek het ons een goede stap om daar te informeren omdat de klanten daar vaak niet veel verstand hebben van computers en de kennis van de verkopers ook beperkter is, net zoals de kennis van onze webwinkel.

Vragen en antwoorden

Wat zijn de meest gestelde vragen?
'Heel verschillend en moeilijk om kort te zeggen. Veel vragen gaan over de vergelijking van producten en prijzen (waarom is deze duurder dan die? Wat is het verschil tussen Pentium en AMD?). Ook willen de mensen vaak weten wat ze bij de PC krijgen (software, boeken, handleiding?).'

Verwijzen jullie naar externe bronnen voor computerinformatie?
'In principe niet, wel naar onze reclamefolder of de folder van Sky computers.'

Is er voorkennis vereist om bij de Dixons te gaan werken? Krijgen jullie een cursus en wat doet u als u iets niet weet?
'Er is geen voorkennis vereist, wel is interesse in technologie een absolute pré. We krijgen geen cursus, maar we worden natuurlijk wel ingewerkt. Het inwerken gaat vooral over de klantvriendelijkheid, het werken met de kassa en de algemene regels. Het kan natuurlijk voorkomen dat iemand eens een keer iets niet weet, dan vragen we dat eerst aan andere collega's, als die er ook niet uitkomen kunnen we geen antwoord geven op de vraag. We hebben helaas geen groot boek met antwoorden op alle vragen.'

Kunt u een paar verschillende scenario's van het verkopen van een PC beschrijven?
'Je hebt klanten die precies weten welk systeem ze willen en die zijn echt binnen een minuut klaar. Je hebt ook klanten die een artikel uit onze reclamefolder willen hebben, klanten die een computer willen en voor de rest niks weten en je hebt klanten die een bepaald budget hebben vastgesteld voor de PC.'

Is er een groot verschil tussen de verkoop van software en de verkoop van hardware?
'Ja, over software krijgen we veel minder vragen. Klanten weten vaak al wat ze willen hebben.'

Tot slot: Als u een computer zou willen kopen via internet, waar let u op en wat vind u belangrijk?
'Als ik iets via internet koop vind ik de betrouwbaarheid van het bedrijf erg belangrijk. Ook de manier van betalen vind ik belangrijk, ik hou er helemaal niet van om mijn creditcard nummer via internet te versturen, ik krijg het pakket liever onder rembours. Verder vergelijk ik graag producten en lees ik graag achtergrondinformatie.'

.

Conclusie

We hebben uit het gesprek de volgende scenario's gehaald:

Ik wil

.

Scenario's produceren

Belangrijk is hierbij om scenario's afzonderlijk van elkaar te maken: laat je eigen fantasie los gaan. Beeld je in dat je een specifiek persoon of bedrijf bent, met leeftijd, beroep, etc. Beeld je vervolgens in dat je iets wilt weten of kopen bij PC Garage. Maak zo een flink aantal scenario's per persoon.

Slecht voorbeeld

Bezoeker met weinig ervaring/verstand van computers wil informatie over componenten

.

Wat is er fout?

De persoonsbeschrijving is veel te generiek: ik moet ook bedenken welke persoon ik ben (jong of oud? Waarom wil ik informatie? Waarover?). De stappen die de persoon doorloopt zijn daarentegen te specifiek: er wordt al uitgegaan van de keuze-elementen 'informatie' en 'componenten', terwijl je nog niet eens mag denken in termen van oplossingen zoals buttons, list boxes en dergelijke!

Goed voorbeeld:

Een jonge docente wil haar eerste computer aanschaffen

.

Je ziet het al: rijke fantasie is belangrijk. Let er op om te kijken naar de gebruiker, en niet naar de functionaliteit van de site zelf, zoals in het slechte voorbeeld het geval was.

Gebruikers- en taakprofiel bepalen

Aan de hand van alle scenario's kunnen we taken clusteren en personen clusteren. Bij het gebruikerprofiel clusteren we alle gebruikers in verschillende groepen. We zien bijvoorbeeld dat alle scenario's vallen in de volgende categorieën:

Hieronder volgt een uitwerking van de checklist van Mayhew bij het type 'gevorderde'. Dit team heeft de termen van Mayhew vertaald naar het Nederlands. In dit geval is daar geen bezwaar tegen (mits het goed gebeurt), maar in het algemeen moet men voorzichtig zijn met een te grote vertaaldrift van vaktermen. Met name veel engelse computertermen zijn goed ingeburgerd in het nederlands (je ziet, het staat er al: computer) en zo voorkom je vreemd aandoende woorden als 'ordinateur' (zo noemen de fransen de computer), 'Speicher' (memory volgens de duitsers) of 'aanwijzer' (cursor volgens sommige nederlanders).

Goed voorbeeld:

Gebruikersprofiel: Gevorderden

De gevorderde gebruiker is een gebruiker die vanzelfsprekend inzit tussen de beginnende en expert gebruiker. Dit maakt deze gebruikersgroep erg groot, waar zit de werkelijke grens? Bij deze gebruikersgroep hebben wij nogmaals een verdeling gemaakt; de beginnende gevorderde (hierin vallen de scenario's 1, 4, 7, 14, 19, 31 en 33) en de gevorderde gevorderde (scenario's 2, 6, 10, 12, 17, 24, 27, 37, 38). Deze gebruiker is over het algemeen redelijk goed opgeleid en heeft ook een redelijke ervaring met het gebruik van internet.

Psychologische karakteristieken

Houding:

Motivatie:

Kennis en Ervaring

Lees- en onderwijsniveau:

Taak- en systeemervaring:

Computer-bekendheid:

Gebruik van andere systemen:

.

Taak karakteristieken

Mate van gebruik:

Systeem gebruik:

Taak belang:

Taak structuur

Commentaar:

Is 'houding' echt een optimale vertaling van 'attitude'? En waarom zijn lees- en onderwijsniveau opgenomen? Heeft in Nederland niet vrijwel iedereen (zeker degenen die een pc aanschaffen en de website zullen gaan gebruiken) een voldoende niveau? Verder is dit zeker een goed voorbeeld. Waarom? Er is een bewuste keuze gemaakt uit Mayhew's checklist, elke keuze is onderbouwd en de consequenties voor het ontwerp worden aangegeven. Hieronder worden deze door het team nog eens samengevat:

Consequenties voor het ontwerp

Uit bovenstaande lijst kunnen we een aantal consequenties voor het ontwerp trekken. We gebruiken alle gebruikersprofielen van onze drie types gebruikers, en kijken welke consequenties dit heeft voor de site van PC Garage. Voor de gevorderde gebruiker zou dit bijvoorbeeld de volgende lijst kunnen opleveren:

Commentaar:

Is alles nu helemaal tiptop? Nee, nog niet helemaal, want in de regel zijn 'ease of use' en 'ease of learning and remembering' moeilijk met elkaar verenigbaar, althans hoe Mayhew 'ease of use' definieert: er snel en met een minumum aan keyboard- en muisacties mee kunnen werken. Denk aan de 'key accelerators' Alt+.. waarmee je direct een keuze kunt maken die anders in een reeks achtereenvolgende menu's moet worden bewerkstelligt. Alhoewel het bereiken van zowel 'ease of use' als 'ease of learning and remembering' niet van tevoren uitgesloten hoeft te worden, is het wel verstandig om tevoren te bepalen wat het belangrijkste is. Daarvoor kun je terecht bij Mayhew's checklist, en m.n. bij de gebruiksfrequentie: als je iets in een taak vaak gebruikt (hier denken we bijv. aan beroepsmatig gebruik, elke dag weer) dan scoort 'ease of use' het hoogst. Immers, iets wat je heel vaak gebruikt is belangrijk genoeg om van tevoren te leren, of leer je wel door het veelvuldige gebruik. Dat je er makkelijk en dus ook snel mee kunt werken is veel belangrijker.

.

Kwaliteitsplan opstellen

Als alle consequenties voor het ontwerp bekend zijn, kunnen we de 'usability-specificaties' gaan vastleggen in het z.g. kwaliteitsplan. Belangrijk bij dit onderdeel is dat we niet alleen het juiste kwaliteitseisenpakket samenstellen, maar ook dat we voldoende onderbouwing geven vanuit de voorgaande onderdelen.
We hebben bij de gebruikersprofielen vastgesteld dat er drie soorten gebruikers zijn: beginner, gevorderde en expert. In het project maken we dan een keuze voor een van deze drie, om de hoeveelheid werk binnen de beschikbare tijd af te kunnen ronden. Slechts in uitzonderlijke gevallen wordt voor meerdere gebruikers ontworpen. De gekozen gebruiker heeft consequenties voor het vaststellen van de streefwaarden.

Slecht voorbeeld van een kwaliteitseis:

Bedienbaarheid in de praktijk:

- Omschrijving:

De mate waarin een gebruikersinterface zonder belemmeringen functionaliteit beschikbaar stelt aan de gebruikers. Mogelijke belemmeringen zijn onnodig ingewikkelde of technische handelingen.

- Streefwaarde:

Hoog

- Meetmethode:

Enquete onder gebruikers

.

Wat is er fout?

In het voorgaande voorbeeld zit een aantal fouten. Ten eerste mist de onderbouwing van de streefwaarde: waarom juist deze waarde? Ten tweede wordt niet verwezen naar de gebruikerscategorie, terwijl verschillende gebruikers het meest waarschijnlijk wel verschillende eisen tot gevolg zullen hebben. Ten derde ontbreekt een meetvoorschrift: hoe denk je het te kunnen gaan meten? Extra aandachtspunt hierbij is dat QUINT voor alle indicatoren dr(w)ingende meetvoorschriften geeft, maar in onze praktijk zijn die niet allemaal realiseerbaar. Hoe ga je dat probleem oplossen? Een optie is dit meetprobleem alleen te vermelden. Maar mogelijk is er een compensatie of 'workaround' denkbaar.
Merk ten slotte op dat in deze uitwerking gekozen is voor meerdere gebruikersgroepen. Het is, zoals hiervoor aangegeven is, legitiem om in het HCI-project een keuze te maken voor een bepaalde gebruikersgroep om de hoeveelheid te verrichten werk haalbaar te houden.

Goed voorbeeld van een kwaliteitseis:

Behulpzaamheid in de praktijk:

- Omschrijving

De behulpzaamheid zoals die is beoordeeld door de gebruikers na een periode van praktisch gebruik. De behulpzaamheid is de mate waarin de gebruikersinterface de gebruiker aanwijzingen geeft hoe ermee om te gaan (denk aan het tonen van de mogelijkheden op het scherm, het geven van invulinstructies).

- Schaal

Hoog, middelmatig, laag.

- Meetmethode

Enquête

- Meetvoorschrift

We selecteren een representatieve groep gebruikers en laten elke gebruiker een uitspraak doen over de behulpzaamheid, met als keuzemogelijkheden:

We bepalen ten slotte het gemiddelde.

- Streefwaarde

Hoog voor de beginner, middelmatig voor de gevorderde en expert.

- Verantwoording streefwaarden

Een gebruiker van de interface die nog niet veel verstand heeft van de computer en het gebruik ervan, stelt het op prijs wanneer er informatie gegeven wordt die hem of haar helpt bij het gebruiken van het product. Een gevorderde gebruiker of expert heeft daarentegen meer verstand van het gebruik maken van de computer en ervaart stap voor stap aanwijzingen vaak als hinderlijk. Toch zijn zij wel gebaat met enige uitleg bij stappen die niet voor zichzelf spreken.

.

Use Cases identificeren

Vrijwel alle scenario's kunnen we groeperen in Use Cases: de meeste cenario's volgen namelijk ongeveer hetzelfde patroon. Bij het bepalen van Use Cases geven we aan welke scenario's er bij horen. Daarna worden een of twee UC's uitgekozen om verder uit te werken. In elke Use Case stellen we het z.g. 'Use Case Scenario' op, wat de deelstappen zijn die de gebruiker onderneemt om het doel te bereiken.

.

Bij PC Garage kiezen we bijvoorbeeld voor de volgende Use Cases:

.

In een Use Case Diagram geven we deze Use Cases bijvoorbeeld als volgt weer:

Slecht voorbeeld Use Case

Titel

Gemiddelde gebruiker die kijkt naar zijn budget

Samenvatting

Een gemiddelde gebruiker gaat naar de site van PC Garage, komt door middel van een goed advies terecht bij het systeem dat betaalbaar is en hij wil hebben en bestelt het

Actor

De gebruiker

Scope

De PC Garage-website

Level

Bestellen systeem

Stakeholder en zijn belang

Gebruiker- Deze wil een compleet systeem hebben

PC Garage- Deze wil een systeem verkopen, dat voldoet aan de eisen van de klant

Minimale uitkomst

Een advies voor een PC, die aan alle eisen voldoet

Maximale uitkomst

Een advies voor de ideale PC in de gegeven situatie

Hoofdscenario

  1. gebruiker gaat naar site
  2. gebruiker krijgt de keuze tussen bestellen en advies
  3. gebruiker kiest advies
  4. gebruiker wil selecteren op budget
  5. gebruiker selecteert een van de van te voren vastgestelde budgetten
  6. gebruiker beantwoordt korte interactieve vragenlijst om de wensen van de gebruiker vast te stellen
  7. site kijkt in de database welk systeem het beste past bij de wensen van de gebruiker
  8. gebruiker krijgt systeem op het scherm
  9. gebruiker gaat bestellen
  10. gebruiker voert gegevens in
  11. site vraagt of gebruiker zich wil laten registreren als vaste klant (ivm korting in de toekomst)
  12. gebruiker wil dat en wordt geregistreerd
  13. het systeem wordt besteld
  14. er wordt zowel aan de gebruiker als naar PC Garage bericht dat er een bestelling geplaatst is

Subscenario 7

er is geen systeem wat voldoet aan de wensen van de gebruiker

de gebruiker kan een ander budget selecteren

Subscenario 12

a. gebruiker wil het niet en wordt niet geregistreerd

Wat is er fout?

In bovenstaand voorbeeld zijn veel dingen niet goed. Ten eerste lijkt er niet goed gemodelleerd te zijn bij het identificeren van de Use Cases: Naast het samenstellen van een systeem o.b.v. budget (deze Use Case) zal er zeker ook een Use Case zijn die o.b.v. andere factoren dan budget alleen een systeem doet samenstellen. Het laat zich raden dat bij deze Use Cases de overeenkomsten groter zijn dan de verschillen. Hierbij is ook de titel onduidelijk: Titelbestanddelen horen een werkwoord en het doel van de primaire actor te zijn. Bijvoorbeeld 'Budgetsysteem samenstellen' zou hier al veel beter zijn.
Ten tweede is er maar een stakeholder, wat tegelijk ook de primary actor is. Beter is om ook PCGarage als stakeholder op te nemen, die hebben immers ook een belang bij een goed uitgebracht advies.
Ten derde zijn er erg veel stappen in het hoofdscenario. Stap 1 is overbodig. Stap 7 betreft het systeem en kan hier verwijderd worden. Het verschil tussen stap 9 en 10 is niet geheel helder. Stap 11 bevat details die nu nog niet relevant zijn. Subscenario 7 betreft een 'faalactie', die nu nog niet relevant is. Subscenario 12 ook, en zowel subscenario 7 als 12 zouden aangeduid moeten worden als 7a resp. 12a.
Ten vierde: Het gaat net iets teveel de kant op van 'klikken'-denken, met knoppen etcetera (het is op het randje). Denk niet in termen van 'schermen', maar in acties van de gebruiker. Eventuele zijstappen kun je plaatsen in de subscenario's. In het hoofdscenario gaat het in ieder geval om de grote lijnen, en alleen om een succesvolle afloop.
Ten slotte is deze Use Case het hele proces dat één type gebruiker doorloopt. De verschillende Use Cases moeten draaien om een bepaalde groep acties, zoals 'informatie verzamelen' of 'bestellen van producten'. Ze moeten niet draaien om de verschillende types gebruikers en hoe zij met het systeem omgaan.

Goed voorbeeld Use Case

Titel

Systeem op maat adviseren

Samenvatting

  1. De Use Case begint met de klant die toetreedt tot het adviessysteem.
  2. De Use Case volgt een klant die een gebruikersgroep kiest, input geeft en producten kiest op basis van advies.
  3. De Use Case eindigt met de klant die het geadviseerde systeem bestelt en deze afrekent

Primaire actor

De klant/webwinkel-bezoeker

Scope

Adviessysteem voor PC Garage webwinkel

Level

User goal

Stakeholders

PCGarage – wil zijn persoonlijke advies mogelijk maken in de webwinkel

Klant van webwinkel (primary actor) – wil op basis van goed advies overgaan tot voor hem/haar geschikte koop, of wil alleen een goed advies inwinnen

Minimum uitkomst

De klant ontvangt een volledig advies, waarin alle artikelen als geschikt geclassificeerd kunnen worden voor de betreffende gebruikergroep (c.q. binnen de aangegeven prijs- en prestatiemarges liggen)

Succes voorwaarde

De klant schaft het geadviseerde systeem aan. Het gehele adviessysteem achten we succesvol bij een toename van ca. 40% van online aankopen van computersystemen.

Hoofdscenario

  1. Bestaande klant of nieuwe bezoeker gaat naar adviessysteem.
  2. Bestaande klant logt in of nieuwe bezoeker voert klantgegevens in en kiest gebruikersgroep; a)beginner, b)gemiddeld, c)gevorderd.
  3. De input wordt vergaard aan de hand van de wensen van gebruiker.
  4. Gebruiker kiest producten al dan niet op basis van advies.
  5. Een overzicht van de gekozen producten wordt getoond.
  6. Gebruiker gaat bestellen en afrekenen.

Subscenario's

3.a Beginnende gebruiker geeft aan wat hij/zij wil kunnen.
3.b Gemiddelde gebruiker geeft globaal aan wat hij/zij wil hebben.
3.c Gebruiker bedenkt zich en stapt over naar een andere interface.

4.a Een product is niet leverbaar (bijv. niet op voorraad), systeem adviseert een alternatief.

5.a Gebruiker gaat terug om wijzigingen aan te brengen.
5.b Gebruiker bedenkt zich en verlaat systeem zonder te bestellen.
5.c Gebruiker print overzicht uit.
5.d Gebruiker slaat 'verlanglijstje' op om later nog eens terug te keren.
.

Programma-specificaties opstellen

Uit alle voorgaande onderdelen kunnen we nu de eisen opstellen. We categoriseren ze in functionele en niet-functionele eisen. Functionele eisen (applicatiegebonden) kunnen we nog opsplitsen in eisen die betrekking hebben op de user interface, en overige functionele eisen. Belangrijk bij het formuleren van de eisen is dat ze in de imperatieve stijl zijn: het zijn eisen, dus ze moeten ook zo geformuleerd worden!

Slecht voorbeeld:

Functionele eisen:

Niet functionele eisen:

.

Wat is er fout?

In bovenstaand voorbeeld staan aan de ene kant eisen die te specifiek zijn, zoals de vakjes die aangevinkt moeten kunnen worden. Dit is al gericht op hoe het er uit moet komen te zien, en daar mag je nog niet aan gedacht hebben! Dat komt namelijk pas in de volgende fase.

Aan de andere kant zijn er ook heel algemene eisen, zoals 'het advies wordt op maat gegeven'. Dat is logisch, want het stond al in de opdracht! De niet-functionele eisen zijn daarentegen wel in orde, alhoewel de imperatieve stijl beter is. Het gaat om eisen, dus het werkwoord 'moeten' zou in elke zin moeten voorkomen (deze zin is ook een 'eis', omdat moeten er in voorkomt).

Goed voorbeeld:

Algemene functionele eisen:

  1. Informatie over het bedrijf:
    1. De gebruiker moet informatie over het bedrijf kunnen vinden.
    2. De garantievoorwaarden moeten te lezen zijn.
    3. De levertermijn moet te lezen zijn.
    4. De betaalmogelijkheden moeten te vinden zijn.
  2. Hulp bij het geleverde product:
    1. Het systeem moet de mogelijkheid geven om antwoord te geven op veel voorkomende vragen.
    2. Het systeem moet door verwijzen naar een de op e-mail gebaseerde helpdesk
  3. Aanschaf van een compleet systeem:
    1. De gebruiker moet een compleet systeem kunnen aanschaffen.
    2. Het complete systeem moet aangepast kunnen worden.
    3. Er moet een vergelijking tussen verschillende systemen gemaakt kunnen worden op prijs en mogelijkheden.
  4. Aanschaf van een los artikel:
    1. De artikelen moeten besteld kunnen worden.
    2. Er moet gezocht kunnen worden op specifiek product eigenschappen.
    3. Er moet informatie over de producten aangeboden worden.
  5. Het moet mogelijk zijn om de status van een lopende order te achterhalen.
  6. De site moet goed updatebaar zijn voor medewerkers PC-Garage.

Functionele eisen m.b.t. de user interface:

  1. De gemiddelde leertijd moet maximaal twee minuten bedragen.
  2. De webshop moet snel zijn om frustraties te voorkomen.
  3. De site moet een rustig uiterlijk hebben, met weinig verschillende kleuren.

Niet-functionele eisen:

  1. De site moet te gebruiken zijn m.b.v. de meest voorkomende browsers.
.

Rapport 'programma-specificaties' opstellen

In het rapport 'programma specificaties' bundelen we alle onderdelen uit fase 1 samen. Naast alle onderdelen, voegen we ook een brief en een management samenvatting toe.

Brief

Een brief bevat niet een samenvatting van wat je allemaal gedaan hebt. Het is slechts een korte begeleidende tekst die het management van PC Garage wijst op het rapport. Deze brief is formeel (dus kort en bondig). Zie voor een voorbeeld de brief van PC garage in de appendix.

Management samenvatting

Slecht voorbeeld:

… In dit rapport analyseren we uw wens een adviessysteem toe te voegen aan uw bestaande webwinkel. Op deze wijze willen we uw klantgerichtheid uitbreiden naar het internet. We formuleren doelen en het domein van het adviessysteem zoals wij denken dat het best aansluit op uw wensen. Hierna omschrijven we hoe we het onderzoek aangepakt hebben en wat daar uit is gekomen (zie appendices). …

Wat is er fout?

Deze management samenvatting zegt niets over de uitkomsten van de fase: dit wist PC garage allang! Ze zijn benieuwd naar wat je nu hebt m.b.t. de online webwinkel. Een beter voorbeeld is het volgende:

Goed voorbeeld:

… Aan de hand van onderzoek op internet en een interview in een winkel is de huidige stand van zaken onderzocht. Dit wordt behandeld in hoofdstuk 4 Scenario's. Hieruit is gebleken dat de klant globaal twee dingen wenst:

1. Service (informatie t.b.v. vertrouwensrelatie)

2. Product (incl. specificaties)

Tijdens een brainstormsessie hebben we deze twee punten en de door ons gevonden scenario's besproken en geprojecteerd op de PC Garage. Hier zijn de onderstaande categorieën uit voortgekomen:

  1. Informatie over het bedrijf
  2. Hulp bij het geleverde product
  3. Aanschaf van een compleet systeem
  4. Aanschaf van een los artikel

De door ons gevonden categorieën zijn gebruikt als basis voor het maken van de use-cases. Deze worden besproken in hoofdstuk 5 Use-cases. Elke categorie is een use-case geworden. Er is één use-case, afrekenen boodschappenmandje, toegevoegd op het hoogste niveau. …

.

Fase 2: Basisontwerp maken

Activity diagram maken

Bij het maken van het activity diagram is het belangrijk dat je alleen het main path overneemt, anders heb je niet de hoofdlijn te pakken, zoals te zien is in onderstaand voorbeeld:

Slecht voorbeeld:


.

Wat is hier fout?

Er is een 'loop', en er zijn veel te veel activities. Het gaat alleen om de hoofdactiviteiten, zoals weergegeven in je Use Cases in fase 1. Als je een join hebt om paralelle activiteiten aan te geven, moet je ook een join gebruiken om ze bij elkaar te brengen. Ook dat is fout in dit diagram.

Onderaan is een rare 'loop' in het diagram: er gaan verschillende pijlen in en uit de 'klant kiest systeem uit' activity. Een loop is eigenlijk nooit toegestaan, en deze constructie zeker niet.

Beter voorbeeld

Dit activity diagram geeft vrijwel dezelfde stappen als in de Use Case weer. Waarom is ook dit voorbeeld niet optimaal? Dat betreft de weergave: De ruitvormen (branches en merges) gebruiken we in onze cursus liever niet in dit diagramtype; ze zijn in dit geval ook geheel niet nodig. Beter is om de variŰteit (extensions) in je Use Case scenario weer te geven door middel van alternatieve activities (threads) die een activiy verlaten. De conditie waaronder dat plaatsvindt geef je aan met een 'guard'. In dit diagram is zowel sprake van variŰteit als van 'parallelliteit', dus horen er ook een fork en join te zijn die 'bekijk alternatieve onderdelen' en 'vraag advies over onderdeel' insluiten. Hieronder staat een goede versie. Merk op dat nu ook het aantal gebruikte symbolen lager is, wat de leesbaarheid ten goede komt.

Verbeterd voorbeeld

.

Metaforen kiezen (o.b.v. user model)

Bij het kiezen van metaforen is het belangrijk dat je uitlegt waarom bepaalde metaforen gebruikt zullen worden. We laten hier ook een paar schetsen zien, om een indruk te geven van wat we bedoelen. Het is echter niet de bedoeling om een gedetailleerd ontwerp van het icoon te maken en af te beelden: dit is iets voor fase 3! In fase 2 moet je nog met schetsen werken…

Je moet bij het bedenken van de metaforen rekening houden met bepaalde user models die de gebruikers hebben. Bij PC Garage formuleren we bijvoorbeeld die van het WWW:

User model: het World Wide Web

Een aantal voorbeelden waarbij de gebruiker bepaalde verwachtingspatronen heeft als hij het WWW op gaat, zijn links, bijbehorende buttons van de browser en het feit dat men de inhoud en opmaak van andermans website niet zo kan veranderen als bij veel op de eigen computer geinstalleerde applicaties wel het geval is.

Links – Links zijn er voornamelijk in twee soorten, (meestal) onderlijnde tekst in verschillende kleurtjes of afbeeldingen. De gebruiker verwacht dat als men op een link klikt, men op een andere pagina belandt of op een ander deel van de pagina terecht komt.

Buttons – In het algemeen verwacht een gebruiker dat met een button een bepaalde actie gestart kan worden. Vandaar de volledige naam 'command button' (de gebruiker geeft een commando). De gebruiker van een browser verwacht dat door middel van de Back en Forward buttons in de toolbar in de zoekgeschiedenis kan worden genavigeerd.

Inhoud – Een gebruiker verwacht dat het onmogelijk is om de presentatie op een webpagina te veranderen. De gebruiker verwacht dan ook niet dat men bijv. met drag en drop de presentatie van de website kan aanpassen.

.

Daarbij wordt er waarschijnlijk een aankoop gedaan, iets waarvan we wel een mentaal model hebben opgebouwd! Het is van belang tegemoet te komen aan de verwachtingen van de gebruiker. Metaforen springen in op de user models die gebruikers hebben. Bij PC Garage is goed metafoor zoals al in veel webshops gebruikt wordt, het winkelwagentje. Een winkelwagentje raakt aan het user model van winkelen. Voor het afrekenen zal een gebruiker dus zoeken naar een soort van kassa-functie. Ook verwacht een gebruiker dat hij kan zien wat er in het karretje zit en dat hij er iets wat er in zit ook weer uit kan halen. Dit zijn allerlei verwachtingen die komen omdat we het winkelwagentje als metafoor gebruiken.

Een winkelwagentje lijkt dus interessant, maar het moet wel goed omschreven worden wil het goedgekeurd worden…

Slecht voorbeeld:

Winkelwagen:

Verder zullen we een 'winkelwagen / boodschappenmand' introduceren als metafoor om het stapsgewijs samenstellen van een systeem duidelijker en begrijpelijker te maken.

.

Wat is hier fout?

Allereerst is het icoon te gedetailleerd weergegeven: het moet een schets zijn! Verder wordt er helemaal niet uitgelegd waarom dit icoon geschikt is in de situatie van PC Garage. Keuzes moeten altijd (zoveel mogelijk) onderbouwd worden.

Goed voorbeeld:

Winkelwagentje:

Een winkelwagentje willen we gaan gebruiken voor het stapsgewijs samenstellen van een systeem. Met dit icoon doelen wij op een associatie met de winkelwagen in de supermarkt.
We hebben een winkelwagentje verkozen boven een winkelmandje omdat een winkelwagentje al impliciet voor winkelen staat. Een winkelmandje heeft tevens als nadeel dat het ook op een picknick mandje kan lijken.

Slecht voorbeeld:

Systeem met uitroepteken:

Een systeem met een groot rood uitroepteken op het beeldscherm. Hiermee kun je de mogelijkheden bekijken.

.

Wat is er fout?

Behalve dat er niet onderbouwd wordt is het probleem dat er een verkeerd user model wordt opgeroepen bij de gebruiker: De kleur rood wordt meestal geassocieerd met iets wat niet goed is en het uitroepteken versterkt dat nog eens. Gevolg daarvan is dat de gebruiker er liever niet mee te maken krijgt. Waar wij juist de gebruiker willen uitnodigen om de mogelijkheden van onderdelen te bekijken, wordt de gebruiker nu juist geweerd om er naar te kijken: hij of zij zal er niet snel op klikken. Wat beter zou zijn, is een grote i, die gebruikers snel zullen associëren met Informatie, omdat dit teken (internationaal) regelmatig op openbare plaatsen (straat, station, winkels etc.) gebruikt wordt.

.

Interactiestijlen bepalen

In het gebruikersprofiel dat we aan het uitwerken zijn, kwamen we op de volgende consequenties voor het ontwerp:

Deze eisen gebruiken we bij het bepalen van de interactiestijl en het dialoogmodel.

Merk op dat al eerder het probleem aangestipt is van de mogelijke tegenstrijdigheid tussen 'ease of use' en 'ease of learning and remembering'. Het is verstandig om te bepalen welke van de twee het hoogste moet scoren. Daarvoor kun je terecht bij Mayhew's checklist, en m.n. bij de gebruiksfrequentie: als je iets in een taak vaak gebruikt (hier denken we bijv. aan beroepsmatig gebruik, elke dag weer) dan scoort 'ease of use' het hoogst.

Interactiestijl: slecht voorbeeld

We kiezen als interactiestijl voor de 'commandotaal', omdat gebruikers kunnen inloggen. Ze moeten dus hun wachtwoord typen in een veld. Dus hebben we de 'commandotaal' nodig.

.

Wat is er fout?

In dit voorbeeld zit een drietal fouten.

  1. Het gebruik van een 'text box' impliceert niet automatisch een commandotaal. Een commandotaal heet zo omdat je voor de besturing van een applicatie (c.q. besturingssysteem) bepaalde commando's moet geven. In een text box kun je van alles invoeren, niet alleen commando's maar ook bijvoorbeeld een login naam; het is slechts een invoerveld voor tekst, wat dan ook.
  2. Een commandotaal is vrij gebruikersonvriendelijk. Ease of learning, wat als belangrijk is bepaald voor het ontwerp, wordt door middel van een commandotaal zeker niet makkelijker gemaakt: commando's moet je immers uit het hoofd leren. Je kunt er wel een 'ease of use' mee realiseren (het intikken van commando's gaat erg snel), waarmee we maar weer eens demonstreren dat 'ease of use' en 'ease of learning' vaak op gespannen voet verkeren.
  3. De onderbouwing ruikt naar een cirkelredenatie en staat geheel los: Er wordt niet gerefereerd aan de ontwerpconsequenties uit het gebruikersprofiel.

Interactiestijl: goed voorbeeld

We kiezen voor het krijgen van alle gegevens tijdens de adviesprocedure voor een invulformulier. Dit komt tegemoet aan het huidige mentale model omdat gebruikers al bekend zijn met invulformulieren en deze (mede daarom) algemeen aanwezig zijn op het internet. Het is belangrijk dat we de vragen duidelijk stellen, zodat de gebruiker weet wat hij of zij moet invullen. Dan komen we ook tegemoet aan de eis 'veel syntactische hulpmogelijkheden en -messages'.

.

Deze voorbeelden geven ook aan hoe het goed of mis kan gaan bij het bepalen van het dialoogmodel in deze ontwerpstap. Ook daarin verwijzen we naar de ontwerpconsequenties uit het gebruikersprofiel. We kiezen een dialoogmodel waarin 'ease of learning' voorop staat, zonder daarbij een maximaal haalbare 'ease of use' uiteraard uit het oog te verliezen. Bijvoorbeeld zal een lineaire dialoog vaak geen goede keuze zijn bij een nagestreefde 'ease of use', omdat dan mogelijk door een heleboel schermen heen gegaan moet worden om het doel te bereiken, wat inherent veel tijd en muisklikken kost (vaak tot grote ergernis van ervaren gebruikers). Het is wel een extreme vorm van 'ease of learning': er hoeft immers niets geleerd te worden, de gebruiker wordt stap voor stap aan het handje genomen. Anderzijds ligt in ons adviessysteem een lineaire dialoogvorm wel een beetje voor de hand, omdat er eerst allerlei informatie vastgelegd moet worden, waarna het systeem een advies geeft, en het onwaarschijnlijk is dat al deze gegevens op een enkel beeldcherm zullen passen (wat bijv. in een enkelvoudige dialoogvorm het geval zal zijn). Wil je dus persÚ ook een 'ease of use' bereiken, dan zal dit probleem opgelost moeten worden. Het gevolg is mogelijk dat er veel informatie op het scherm zal komen, wat voor onervaren gebruikers niet geschikt is. Dus waar ligt het compromis? Dat verschilt van geval tot geval en is ook hier niet eenduidig weer te geven als 'de enige goede oplossing is ..'. Er is in de casus gekozen voor een lineaire dialoog, gecombineerd met een netwerkdialoog. Deze keuze is alleszins verdedigbaar gelet op de gebruikers en de belangrijkste ontwerpuitgangspunten. Maar het hoeft niet de enige goede keuze te zijn.

Hoofddialoog ontwerpen (o.b.v. user model)

We kijken naar de acties in het activity diagram en naar de activiteiten in de Use Case die we geselecteerd hebben. Al deze gegevens combinerende, maken we het volgende STD:

De acties zijn vanuit het oogpunt van de gebruiker genoteerd. De titels en nummers van de panelen worden in 'panelen ontwerpen' en 'paneel composities ontwerpen' gebruikt om te laten zien hoe een scherm eruit komt te zien. We bepaalden dat we hoofdzakelijk een lineaire dialoog wilden hebben met 'netwerkdialoog-eigenschappen'. De lijn is te volgen in het hoofddialoog, maar ook de netwerkdialoog-eigenschappen hebben we weergegeven door de pijlen aan de linker zijde.

N.B.: Merk op dat labels van de transities in het STD niet helemaal de juiste syntax hebben. Ook zou een kortere omschrijving de leesbaarheid ten goede komen. Maar het is nu ook weer niet zo slecht dat hier het rode potlood gehanteerd is: het wordt dus zo weergegeven als ooit door het studententeam vervaardigd is.

.

Panelen ontwerpen

In dit onderdeel kijken we wat we nodig hebben bij ieder scherm. De bij elkaar horende widgets en views worden eerst op aparte panelen geplaatst. Daarna pas bepalen we de gehele compositie.

Goed voorbeeld

Scherm 1: Introductie

Paneel: Gebruikers kiezen

Het paneel waarin de gebruiker zijn niveau kiest (beginner/gevorderd/expert) is een commandopaneel.

Het bestaat uit 3 iconen die de verschillende categorieën aanduiden. Ze zijn aanwezig om in 'ease of learning' tegemoet te komen. Naast elk icoon staat een verklarende tekst. Dit om de gebruiker extra syntactische hulpmiddelen te geven zoals we wilden in het gebruikersprofiel. Door op het icoon te klikken selecteert de gebruiker zijn niveau waarop het advies gebaseerd wordt.

.

Op deze manier wordt een schets gegeven, samen met een omschrijving en argumentatie die verwijzen naar de vorige onderdelen. Het team heeft dit uitgevoerd bij alle panelen, geidentificeerd bij alle schermen. Uiteindelijk zijn de volgende panelen uitgewerkt:

.

De grootste fout die je kunt maken, is deze fase over te slaan en direct te beginnen aan de paneelcompositie. Dit is niet de bedoeling!

Paneelcomposities ontwerpen

Goed voorbeeld (ingekort)

Nu gaan we alle panelen bij elkaar stoppen. We hebben ze genummerd toen we ze los ontwierpen, en nu combineren we ze tot een uiteindelijk ontwerp.

We kiezen er voor om één standaard layout te houden wat betreft de paneel-combinaties. Eén layout helpt de gebruiker om het overzicht te bewaren, wat tegemoet komt aan 'ease of learning and remembering': constant hetzelfde betekent makkelijk leren. De panelen worden op de volgende manier gecombineerd:

1: Webshop navigatiepaneel

We hebben dit paneel links geplaatst, omdat …

2: Prijspaneel

3: Adviessysteem navigatiepaneel

Dit paneel is rechts bovenaan te vinden op de site. De reden hiervoor, is dat …

4: Het paneel dat hoort bij de huidige 'state'.

Zie voor een overzicht de lijst in 'Panelen ontwerpen'. Daar hebben we ook al alle uitleg staan met betrekking tot de onderdelen op de betreffende panelen.

.

Storyboard tekenen

In dit onderdeel combineren we alle paneelschetsen tot de schermen uit de hoofddialoog (zie het STD). Belangrijk is dat alles netjes (maar niet tÚ) wordt geschetst op papier: op de computer schetsen is uit den boze! Een paar voorbeelden:

Scherm 1: Introductie

Commentaar: Op zich is deze schets in orde, maar onder het webshop paneel staat geen prijspaneel, zoals aangegeven was bij de paneelcompositie. Waarom niet moet nog extra worden beargumenteerd.

Scherm 3: Basissysteem scherm

Commentaar: Paneel 4 (rechtsonder, zie ook Paneelcomposities) is goed uitgewerkt, maar paneel 3 (het navigatie paneel) is niet uitgebreid geschetst. Dit had wel gedaan moeten worden, anders kun je het storyboard niet goed gebruiken om te testen: O.a. staan er dan te weinig opties op, waardoor je het de tester te makkelijk maakt en zo mogelijk te weinig ontwerpfouten vindt.

Evaluatie uitvoeren

We voeren de think-aloud methode exact uit zoals is aangegeven in de literatuur. We noteren alle uitspraken die de gebruikers doen tijdens de test, en indien mogelijk maken we een geluidsopname, zodat er echt niets verloren kan gaan en zelfs de intonatie bewaard blijft. Ondertussen maken we aantekeningen van alle activiteiten die de gebruiker doet. Later kunnen we uit deze beide aantekeningen alle problemen destilleren. Een goed voorbeeld van verslaglegging zou er als volgt uit kunnen zien:

Goed voorbeeld

Proefpersoon: A. Nonymus (lid team 3)

Opdracht: bestel een systeem dat je wilt gebruiken om met name spellen te spelen.

.
Proefpersoon Handeling Geïdentificeerd probleem
(Pagina is geopend) Hmm, even kijken…  

-

Ik zal wel gevorderde zijn… Klikt op 'gevorderde'. -
… Kan ik hierop klikken? Zal wel niet… Muis beweegt over het menu in paneel 3. De knoppen in het menu zijn niet duidelijk genoeg.
…  …  … 
.

Hierin wordt exact weergegeven wat er gezegd is, wat de gebruiker deed en welk probleem we eruit constateerden.

Slecht voorbeeld

Winkelwagen:

Met het plaatsen van het systeem in de winkelwagen was het enige probleem dat hij het aantal wilde verhogen maar dit niet kon bevestigen. Verder was hij tevreden met betrekking tot het overzicht met daarin de extra optie (processor).

.

Wat is hier fout?

Er is geen transcriptie van de sessie en dus is het niet duidelijk wat de precieze oorzaak van het gevonden probleem is. Misschien zijn we het wel helemaal niet eens met deze conclusie. Maar in dit geval is het niet mogelijk dat na te gaan: alleen de 'uitkomst' is genoteerd. De lezer moet het dus maar geloven. Niet voor niets leggen we in de wetenschap de nadruk op verifieerbaar en herhaalbaar.

.

Bijstellingen uitvoeren

In dit onderdeel geven we aan wat we gedaan hebben aan de knelpunten die geïdentificeerd werden tijdens de evaluatie. Daar was te zien dat bepaalde zaken een probleem zijn. Hier geven we ook argumenten in het geval dat we geen wijzigingen uitvoeren op een knelpunt.

Voorbeeld

Tijdens de evaluatie vonden we de volgende knelpunten:

  1. Buttons navigatiepaneel: Ze worden door middel van kleur, diepte en vorm duidelijker en opvallender gemaakt. De tekst op de knoppen wordt gewijzigd in: 'basisvragen', systeemconfiguratie', 'specifieke vragen'.
  2. De woordkeuze voor 'basissysteem' en 'compleet systeem': Deze woordkeuze wordt niet veranderd, omdat na overleg de woordkeuze duidelijk refereert naar het doel. Er wordt in de inleiding een korte beschrijving gegeven van de precieze inhoud van deze woorden.
  3. De checkboxes: Er wordt in een zin boven de checkboxes in het kort uitgelegd dat er meerdere keuzes mogelijk zijn.
  4. De advies –en informatiebuttons: Er komt een inleidende tekst in het scherm voor de systeemconfiguratie, waarin de functie van de advies –en informatiebuttons wordt vermeld.
  5. Ontbreken van prijs per product: Er wordt een prijs per product vermeld in het scherm 'systeem configuratie'.
  6. De link om de eerste vragen binnen het systeem over te slaan: De tekst 'overslaan' komt naast het kopje 'algemene vragenlijst' te staan.
  7. De dropdown menu's: Aan het aantal wordt niks veranderd, omdat er geen andere mogelijkheid is om veel producten weer te geven. De producten zijn ingedeeld in productclusters om het voor de klant duidelijk te houden.
  8. Dropdown menu's: De mogelijkheid om een bepaald product niet te selecteren voor aankoop wordt toegevoegd.

Commentaar: Dit voorbeeld is goed wanneer je kijkt naar alles wat er gedaan is. Het geeft echter niet aan waarom het beter is met de voorgestelde veranderingen en handhavingen. Eigenlijk zou dit er ook nog bij aangegeven moeten worden. Argumentatie is dus ook nodig bij alle wijzigingen.

.

Rapport 'Basisontwerp' opstellen

Dit gaat op dezelfde wijze als 'Rapport 'programma specificaties' opstellen. Zie voor goede en slechte voorbeelden dat onderdeel.

.

Fase 3: Prototype vervaardigen en evalueren

Platform kiezen

Ook de keuze voor het platform moet onderbouwd worden.

Slecht voorbeeld:

Wij gaan ons ontwerp implementeren in een browser omgeving. De site werkt alleen optimaal met Internet Explorer. Wij denken dat deze browser het meest wordt gebruikt door beginners en gemiddelde gebruikers. Na het ontwerpen van de site bleek het te zijn dat sommige onderdelen van de site niet door Netscape worden ondersteund. Door het te kort aan tijd konden wij dit echter niet meer verbeteren. Daarom hebben we gekozen voor Internet Explorer als platform.

Wat is er fout?

Er is een aantal grote fouten aanwezig in de argumentatie. Ten eerste worden er geen aantallen genoemd: hoeveel procent van de gebruikers gebruikt Internet Explorer? Ook gebruiken we hier geen externe bron, maar onze eigen mening. Dat is volstrekt onwetenschappelijk, dus niet toelaatbaar. Ten slotte wordt als een argument gebruikt dat bij het prototype geen tijd meer was om het compatible te maken aan Netscape. Hier zit een denkfout: het prototype hoeft niet te voldoen aan alle platform-eisen die je gaat stellen! De keuze die je hier maakt geldt voor het eindproduct, niet voor het prototype.

Goed voorbeeld:

Wij hebben gekozen voor een browser omgeving. We ontwerpen de site voor Microsoft Internet Explorer (MIE) v4.0 of hoger, maar de site moet ook Netscape Navigator 4.0+ compatible zijn. We gaan uit van een minimale resolutie van 800x600 pixels.

De motivatie hiervoor is als volgt:

In de niet-functionele eisen in het rapport 'Programma-specificaties' hebben we de volgende eis opgenomen: 'De site moet te gebruiken zijn m.b.v. de meest voorkomende browsers.'

We wilden op zoek naar 'de meest voorkomende browsers'. In andere woorden kunnen we dit als volgt formuleren: we zijn op zoek naar de meest gangbare specificaties.

Op dit moment maakt 79% (EchoEcho.com, 2001) van de gebruikers gebruik van IE 4.0 of hoger. Als we zouden kiezen voor een website die ook compatible is met de 3.0 versies van de browsers zouden we slechts 1% (EchoEcho.com, 2001) meer gebruikers ondersteunen, maar zou de website een stuk minder geavanceerd kunnen worden.

Om ongeveer dezelfde reden hebben wij gekozen voor een resolutie van 800x600 pixels. Op dit moment surft 96,8% (Nedstat, 2001) van de gebruikers met een resolutie van 800x600 of hoger. Om de website overzichtelijk en duidelijk te laten hebben we ook minimaal deze schermgrootte nodig.

.

Widgets bepalen

Bij vrijwel elke widget kan uitleg gegeven worden waarom deze nodig is. Omdat widgets op meerdere plaatsen voorkomen, noemen we de belangrijkste plaatsen en argumentatie daar waar deze belangrijk is.

Slecht voorbeeld:

Voor een goede navigatie en interactie zullen we gebruik maken van de volgende widgets:

Ook maken we gebruik van cues. De volgende cues zullen gebruikt worden:

.

Wat is er fout?

In dit voorbeeld ontbreken twee zaken: ten eerste is er geen argumentatie waarom deze widgets gebruikt worden. Ten tweede wordt niet aangegeven waar deze widgets in de site gebruikt gaan worden.

Goed voorbeeld

Image (Multimedia cues):

De belangrijkste menuopties (login, bestellen, etc.) geven we aan met plaatjes. Hierdoor is in één oogopslag te zien hoe de klant de belangrijkste handelingen kan uitvoeren. Op deze manier wordt 'ease of learning and remembering' bewerkstelligd, zoals we van plan waren in ons gebruikersprofiel.

Textbox (Tekstinvoer controls):

We gebruiken de text box voor de registratie pagina. De klant kan zijn of haar gegevens in de text boxes invoeren. Verder gebruiken we de text box ook op de login-pagina. Daar kan de klant zijn of haar username en password in de text boxes invoeren.

Subdialogen ontwerpen

Een aantal voorbeelden van mogelijke subdialogen die we in het geval van PC garage zouden kunnen identificeren, zijn de volgende. De subdialogen uit de Use Case kunnen hier uitgewerkt worden. Het zou kunnen dat we iets over het hoofd gezien hebben, zoals in het geval van het volgende voorbeeld de 'cluster specifieke feedback'.

Voorbeeld

Subdialoog 1.a: Algemeen foutmeldingscherm:

We ontwerpen een algemeen foutmeldingsscherm voor gevallen waarin de server down is.

Subdialoog 4.a: Alternatieve keuze:

Producten die op dat moment niet beschikbaar zijn zullen 'faded' weergegeven worden in de lijsten met daarnaast een button 'Alternatief', die naar een vergelijkbaar product zal wijzen.

Nieuw: Cluster specifieke feedback:

Indien er door de klant keuzes voor bepaalde onderdelen gemaakt worden die niet erg logisch zijn, zal het systeem direct onder die keuzes een regel feedback kiezen.

In bovenstaand STD geven we aan wat er gebeurt in geval van een specifieke situatie.

Commentaar: Eigenlijk zou in bovenstaand voorbeeld ook nog een nadere uitleg moeten van de pijlen uit het STD: wat gebeurt er wanneer er een fout plaatsvindt? Dat komt in het voorbeeld niet goed naar voren. Wat wel goed is, is dat er verwezen wordt naar de Use Cases. Bij een werkelijke uitwerking moeten ook nog schetsen komen van hoe de subdialogen er in de panelen uit komen te zien.

Prototype bouwen

We onderbouwen ieder detail van de site. Belangrijk is dat we terugkoppelen naar de eisen in het rapport 'programma-specificaties'. Ook is belangrijk om hier te verwijzen naar de literatuur: termen als 'wij vinden dit mooi' zijn uit den boze! Mooi is 'mooi' meegenomen als het lukt, maar in eerste instantie moet het ontwerp een optimale 'usability' hebben. Mooi is ook een erg onprecieze definitie: In de praktijk wordt het design afgestemd op de doelgroep en/of de huisstijl van de organisatie, een aparte kunde die door grafische ontwerpers wordt uitgevoerd.

Redelijk voorbeeld:

Kleurenaantal

In de interface moeten niet te veel verschillende of te felle kleuren voorkomen: hierdoor zou de gebruiker, net als bij overmatig gebruik van contrast, snel vermoeid kunnen raken, waardoor zijn of haar geduld minder wordt en de persoonlijke 'gezelligheidssfeer' verdwijnt (Verpoorten, 2001). U wilt graag dat de applicatie persoonlijk en klantgericht overkomt: wij hebben gedacht dit het beste te bereiken door, met behulp van kleurkeuze, een warme, huiselijke sfeer op te roepen. Om bovenstaande redenen hebben we gekozen voor een beperkt aantal warme, zachte kleuren op de achtergrond en de voorgrond. De voorgrondkleur zal echter iets minder zacht zijn en van een kleur die in contrast met de achtergrondkleur is, om het hierboven beschreven contrast te bereiken. Toch moeten de voorgrondkleuren nog steeds voldoen aan de eis een persoonlijke sfeer te scheppen.

Commentaar: De subjectieve argumenten overheersen ietwat in de onderbouwing. Verder wordt er niet aangegeven volgens welk kleurschema gewerkt wordt (analoog, complementair etc.) en waarom, in relatie tot het doel van de website (de 'Business Case') en de gebruikers. Het is bijvoorbeeld nog maar de vraag of 'gamers' behoefte hebben aan het theekrans-sfeertje wat hier opgeroepen wordt, en of zakelijke en ict-ervaren klanten dit een professionele uitstraling zullen vinden.

Evaluaties uitvoeren

Erg belangrijk bij de verslaglegging van de evaluaties, is dat alles wordt vastgelegd: het aantal personen, commentaar, eigenschappen van de testpersonen etcetera. We hebben in het volgende voorbeeld gebruik gemaakt van twee experts die we de heuristische evaluatie lieten doen. Op ongeveer dezelfde manier kan ook van de SUMI-lijst verslag worden gedaan: een overzicht van de test, de uitkomsten van de test, extra gebruikerscommentaar, samenvatting van problemen.

Redelijk voorbeeld: Heuristische Evaluatie

Voor het testen van de interface is gebruik gemaakt van een heuristische evaluatie. In een dergelijke evaluatie wordt de interface getest door een groep hci-experts, die kijken of de interface wel voldoet aan sommige ontwerpprincipes (de heuristieken). Deze evaluators gebruiken de '10 usability heuristics' van Nielsen (Nielsen, 1991).

Voorbereiding: Voor de heuristische evaluatie zijn twee evaluators gebruikt. Er werden 13 vragen aan hun gesteld (zie hieronder), die gebaseerd zijn op de '10 usability heuristics', om de interface te evalueren.

Vragen Evaluator 1 Evaluator 2
Houdt het systeem je goed op de hoogte van wat er gaande is? Ja Ja
Houdt het systeem je goed op de hoogte van wat er nog gebeuren moet? Ja nee
Is het taalgebruik in het systeem duidelijk? Dat wil zeggen worden er onduidelijke 'computer termen' gebruikt? Nee Ja
Is het duidelijk hoe je het systeem kunt eindigen? Ja Ja
Is het duidelijk hoe je vooruit en/of achteruit in de stappen van het systeem kunt gaan? Ja Ja
Is het systeem consistent? Met de nadruk op de volgende zaken:
  1. Consistentie in de verhaallijn
  2. Consistentie in de iconen (hebben iconen dezelfde betekenis door het systeem heen)
  3. Consistentie in de te ondernemen acties (zijn acties in de verschillende delen van het systeem vergelijkbaar)
Ja Ja
Nee Ja
Ja Ja
Vind je dat je gemakkelijk fouten maakte bij het gebruiken van het systeem? Ja Ja
Zijn de 'error messages' duidelijk? Nee Ja
Is het duidelijk waar de actie- en optieknoppen gesitueerd zijn? Nee Nee
Is het duidelijk hoe je sommige stappen in het systeem kan overslaan? Nee Ja
Is de gegeven informatie te veel? Nee Nee
Is het systeem visueel te complex? Nee Nee
Is het duidelijk waar je op het systeem hulp kunt zoeken? Ja Ja

Resultaten evaluatie:

Na de evaluatie door middel van de vragenlijst zijn de evaluatoren verder ondervraagd aangaande specifieke aandachtspunten in het prototype. Hieruit kwamen de volgende aandachtspunten:

Zichtbaarheid van de systeemstatus

De aanwezigheid van de 'pop-knoppen' is niet duidelijk genoeg. Ze vallen weg tegen de achtergrond. Hierdoor is het niet duidelijk genoeg waar je je bevindt in het systeem als afgegaan wordt op de indicatie die de 'pop-knoppen' zouden moeten geven.

Match between system and the real world

Het verschil tussen een 'basissysteem' en een 'compleet systeem' was niet duidelijk, en de foutmelding werd als fataal gezien, terwijl het niet fataal is. Het was niet duidelijk dat de melding een 'advies' is vanuit het systeem, en dat daarna doorgegaan kon worden met productkeuze.

User control and freedom

Het was niet duidelijk hoe vooruit en achteruit te gaan in het systeem. Reden hiervoor is dat de 'pop-knoppen' niet als buttons te zien zijn. Ze vallen te veel weg tegen de achtergrond.

Consistency and standards

Bij de checkboxes bij de eerste vragen in het systeem is het niet duidelijk dat er geen maximum zit aan het aantal keuzes die ingevuld kunnen worden.

Error prevention

De advies –en informatiebuttons zijn niet duidelijk. Hierdoor ontstaat het probleem dat het verkeerde scherm weergegeven wordt als op een van die buttons geklikt wordt. Ook is het verschil tussen de tekst op de knoppen (advies en informatie) niet duidelijk. De tekst refereert dus niet genoeg naar het doel.

Recognition rather than recall

De actie -en optieknoppen zijn niet allen duidelijk. Het probleem ligt bij de 'pop-knoppen'. Ze worden niet als buttons herkend en daarom niet gebruikt als zodanig.

Prijs per produkt mist en ook zijn de teksten vragen 1 en vragen 2 op de 'pop-knoppen' onduidelijk.

Flexibility and efficiency of use

De link om de eerste vragen in het systeem over te slaan zou duidelijker aangegeven kunnen worden. Het is niet duidelijk wat er gebeurt als de link wordt gebruikt.

Er is geen mogelijkheid om een bepaald product niet te selecteren voor aankoop.

Aesthetic and minimalist design

Er zijn veel drop-down list boxes op het scherm van 'systeem configuratie' wat enigszins vervelend overkomt.

Help users recognize, diagnose, and recover from errors

In de tekst van de foutmelding staat het woord advies en er zit geen link achter dit woord. Het is ook niet duidelijk wat nu een kritieke fout en wat een niet kritieke fout is. De tekstuele weergave van het foutmeldingsscherm is dus niet duidelijk.

Help en documentatie

Geen problemen geconstateerd.

Opsomming knelpunten:

Uit de heuristische evaluatie zijn de volgende punten naar voren gekomen die eventuele veranderingen behoeven:

Commentaar: Dit team heeft de heuristic door 2 experts laten uitvoeren, maar 3 is het minimum. De tekst geeft verder aan dat men de experts eerst 13 vragen heeft gesteld, gebaseerd op Nielsen's 10 heuristieken, en dat er later verder doorgevraagd is. Maar dat is beslist niet de bedoeling! Het is bedoeling dat elke expert aan de hand van de 10 heuristieken problemen probeert te vinden in de interface. Alle experts zullen overeenkomstige problemen vinden maar ook verschillende en geen expert vindt alle problemen, en dat is precies de reden waarom je minstens 3 experts nodig hebt om er genoeg problemen uit te halen. Zie verder de theorie hoe de evaluatie uitgevoerd dient te worden. Waarom weet dit team het beter dan Nielsen? Nielsen heeft dit niet zomaar bedacht: Het is het resultaat van gedegen wetenschappelijk onderzoek. Als je het anders wilt doen zul je daarvoor wel erg goede argumenten moeten hebben!
In de tekst is sprake van 'pop-knoppen'. Dit is een zelf bedachte naam w.s. voor enkele buttons, die beslist niet nagevolgd moet worden!
De vorm en de indeling van het verslag zijn best wel goed, reden waarom we het hier opgenomen hebben.

.

Bijstellingen bepalen

Dit gaat hetzelfde als bij 'bijstellingen doorvoeren' uit het rapport 'Basisontwerp'. Argumentatie voor de veranderingen is weer enorm belangrijk. Ook wanneer bepaalde testuitkomsten als irrelevant worden bestempeld, moet dat hier beargumenteerd worden. De werkelijke veranderingen hoeven we niet meer uit te voeren: Er wordt alleen aangegeven wat er gedaan zou moeten worden.

Voorbeeld

.

Commentaar: Dit voorbeeld is goed als je kijkt naar alles wat er gedaan is. Het geeft echter niet aan waarom het beter is met de voorgestelde veranderingen. Eigenlijk zou dit er ook nog bij aangegeven moeten worden. Argumentatie is dus ook nodig bij alle wijzigingen.
Tja, en alweer die 'pop-knoppen'... snel vergeten maar.

Eindrapport opstellen

In eerste instantie wordt het 'Rapport Prototype' vervaardigd op dezelfde wijze als Rapport 'programma specificaties' opstellen. Zie voor goede en slechte voorbeelden dat onderdeel. Dit rapport wordt echter niet apart ingeleverd, maar is onderdeel van het totale eindrapport, dat tevens de eventueel gecorrigeerde versies van fase1 en fase2 bevat.

.
.

Appendix I: Brief met formele casusomschrijving

.

PC Garage

Industrieweg 999
1234 AB Utrecht
Tel.: 030 9876543
Fax: 030 9999888

.

Utrecht, 15 oktober 200X

.

Betreft: haalbaarheidsonderzoek
Ons kenmerk: JHV/011015-1

Aan:
Human-Computer Solutions
Utrecht University
3584 CH Utrecht

.

Geachte firma,

Bij deze verzoeken wij U te onderzoeken of een computerondersteunde oplossing voor een knelpunt in onze bedrijfsvoering mogelijk c.q. haalbaar is. Wij verwachten van u een projectvoorstel met een indicatieve begroting en een plan van invoering.

Hieronder zullen we ons probleem nader uiteen zetten. Dit willen we gaarne in mondeling overleg toelichten, op welke bijeenkomst welllicht ook reeds van gedachten kan worden gewisseld over de mogelijke oplossingsrichtingen.

Wij zijn enige tijd op internet actief. Enige tijd geleden heeft u voor ons de basis van een front office (de z.g. 'demand chain') opgezet. Deze functioneert naar tevredenheid. Echter, de functionaliteit hiervan loopt achter bij de winkel zelf, zodat we het tijd vinden onze internet site met een feature te gaan uitbreiden.

Het probleem is onze grote klantgerichtheid, een belangrijk aspect van onze bedrijfsvoering (en succes). Als toekomstige klanten bij ons de winkel binnenlopen, gaan ze niet weg met het duurste systeem dat we ze kunnen aanpraten, maar met een systeem dat past bij hun persoon en/of hun bedrijfsvoering. Geen massa-verkoop van kant-en-klare 'bakkies' bij ons! Of dat nu een tweedehandsje is voor de kleinkinderen die regelmatig bij Opa en Oma logeren, of een uitgebreid systeem voor een klein of middelgroot bedrijf. Onze filosofie is om echt de tijd te nemen om erachter te komen wat de klant nodig heeft. We verstrekken de klant graag een kopje koffie onder het overleg, en we gaan regelmatig naar de klant toe om de situatie aldaar op te nemen. Dit is dus een zeer persoonlijke benadering, en wij vragen ons af of en hoe we deze klantgerichte filosofie via zo'n toch veel onpersoonlijkere webpage over kunnen brengen. Hoe kan je de klant het idee van zo'n vriendelijk kopje koffie geven bijvoorbeeld?
Wij willen dit aspect op de een of andere manier ook gestalte geven op onze internet site. Er leven bij ons enkele ideeen hoe dit zou kunnen, maar zijn uiteraard op uw deskundigheid aangewezen m.b.t. de (on)mogelijkheid en financiele consequenties. Graag willen wij dit met u doorspreken, als voorbereiding op een opdracht aan uw bedrijf.

Met onze directiesecretaresse kunt u een afspraak voor een gezamenlijke bijeenkomst maken. Wij vertrouwen op een goede afloop.

.

Hoogachtend,

P.C. Omputer

(Directie PC Garage)

.
.

Appendix II: Projectvoorstel PC garage

[ briefkop, datum, aanhef etc. weggelaten ]

Op basis van de probleemstelling in uw schrijven d.d. 15 oktober en enkele verkennende vervolggesprekken presenteren wij bij deze een voorstel voor een te ontwikkelen applicatie. Na akkoord bevinden uwerzijds zullen wij de ontwikkeling starten.

Probleemstelling

U heeft een winkel op internet. Deze wilt u uitbreiden met een feature, analoog aan de productadviezen die u nu in de winkel geeft. Daarbij streeft u een heel persoonlijke benadering na. U betwijfelt of een dergelijke persoonlijke benadering (inclusief het kopje koffie) op internet wel mogelijk is, maar hecht hier ook grote waarde aan.

Uitgangspunten

In het plezierige overleg dat we met u mochten hebben, zijn veel mogelijkheden de revue gepasseerd. Wij begrijpen heel goed wat u wilt. Alhoewel 'het kopje koffie' niet direct een internet-equivalent heeft, denken wij een heel persoonlijke benadering te kunnen realiseren met de inrichting van een adviescentrum. In zo'n adviescentrum kunt u allerlei gegevens over vaste klanten (reeds ruim aanwezig in uw bedrijfssystemen) meenemen. Door gerichte vragen te stellen, kunt u bij klanten het vertrouwen wekken dat ze een goed en persoonlijk advies ontvangen. Om uw klanten 'zonder koffie' tevreden te stellen is er de mogelijk om kortingen of gratis onderhoudsservices op bepaalde bestellingen te geven.
Na een advies moet een klant de online aankoop kunnen doen. Zowel u als de klant moeten een bevestiging ontvangen van de bestelde artikelen (plus dat u een melding ontvangt of de betaling goed verlopen is). Daarna levert u op de gebruikelijk wijze de bestelling af. Hierbij moet verschil gemaakt kunnen worden tussen vaste klanten (waarvan een aantal bij u een rekeningkrediet heeft) en degenen die voor het eerst of incidenteel uw winkel bezoeken. Dit zijn de belangrijkste uitgangspunten.

Globale omvang

De globale omvang van het project is 6 weken. Hierna beschikt u over een gevalideerd ontwerp en een programma-prototype. Op basis hiervan kan de feitelijke programmering plaastvinden. Deze activiteit wordt apart begroot c.q. door derden aangenomen.

Team en organisatie

Het ontwikkelteam bestaat uit ca. 7 personen, per ontwikkelfase (zie invoering) elk met een eigen taak en verantwoordelijkheid. Het team kiest voor elke ontwikkelfase opnieuw een coordinator. Een ontwikkelfase begint met het opstellen van een projectplanning. Er is een wekelijkse bijeenkomst, waar de opdrachtgever (of diens vertegenwoordiger) bij aanwezig is.

De opdrachtgever is op de hoogte van de vorderingen d.m.v. zogenoemde groupware. Via het logboek kan de opdrachtgever de activiteiten in de tijd volgen. Ook kan hij het werk inspecteren door inzage in de projectplanning en de bestanden via de groupware.

Invoering

De invoering geschiedt in drie fasen, te noemen programmaspecificaties (en kwaliteitsplan), basisontwerp en prototype. Het project wordt pas vervolgd als de opdrachtgever akkoord gaat met het in een fase bereikte resultaat. Uw bedrijf is betrokken bij elk van de fases. Behalve de onder 'team en organisatie' genoemde aspecten betreft dit ook het inschakelen van toekomstige gebruikers, met name bij de productevaluaties.

Deliverables

Het programma zal ontwikkeld worden uitgaande een n-tier opzet. De hier beschreven te ontwikkelen producten hebben uitsluitend betrekking op de client. De volgende producten komen tot stand.

Rapport programmaspecificaties en kwaliteitsplan

Er zal een analyse uitgevoerd worden. Doel hiervan is exact vast te stellen welke functionaleiten benodigd zijn in de te ontwikkelen applicatie en met welke gebruikerskarakteristieken rekening gehouden moet worden. Op basis hiervan en van de uitgangspunten zullen concrete programmaspecificaties en een kwaliteitsplan totstand gebracht worden. Deze worden aan de opdrachtgever gepresenteerd in een rapport. Na goedkeuring door de opdrachtgever zullen de werkzaamheden vervolgd worden.

Rapport basisontwerp

Het basisontwerp behelst het globale ontwerp van de applicatie. Dit omvat het gekozen scenario en user interface ontwerpen, waarin keuzes voor de metaforen en de interactiestijl verwerkt zijn. Deze ontwerpen zullen worden geëvalueerd. De resultaten van het ontwerp en de evaluaties zullen ter goedkeuring aan de opdrachtgever worden gepresenteerd in het 'Rapport basisontwerp'.

Eindrapport en Prototype

Het prototype betreft de nadere uitwerking van het basisontwerp zoals de visuele vormgeving, interactie-elementen, dialoogstructuur en de concrete uitwerking in een z.g. 'prototype'. Het prototype suggereert de werking van het uiteindelijke resultaat. Het is volledig m.b.t. de user interface maar is niet feitelijk functioneel. Het prototype zal op verschillende manieren worden geëvalueerd, o.a. met toekomstige gebruikers. De resultaten van het ontwerp en de evaluaties zullen ter goedkeuring aan de opdrachtgever worden gepresenteerd in het begeleidende eindrapport. In dit rapport wordt een overzicht gegeven van het gehele afgelopen ontwikkeltraject. Op een bijeenkomst zullen wij u het prototype demonstreren.

.