Verbeteringen voor een data-entry interface

Transcriptie

1 Universiteit Utrecht, Departement Information and Computing Sciences & Bol.com BV Utrecht Verbeteringen voor een data-entry interface Een gebruikersgerichte aanpak maart 2010 maart 2011 Student: Niels van den Berg Begeleiding: dr. H.H.A.M. Prüst Dhr. J. Heeg Het content-team van bol.com maakt gebruik van verschillende applicaties om productinformatie te bewerken en in de productdatabase te plaatsten. Voornamelijk de data-entry tool (lpdb-tool) lijdt onder problemen in gebruiksgemak. In dit onderzoek worden deze problemen middels interviews met de eindgebruikers in kaart gebracht. Op basis van de gevonden problemen worden verbeteringen voorgesteld en toegepast in het ontwerp van een paper-prototype van een verbeterde data entry-applicatie. Dit prototype is geëvalueerd middels iteratieve tests met eindgebruikers.

2 Voorwoord Als werknemer bij bol.com heb ik veel moeten werken met een data-entry applicatie (LPDB 1 -Tool) die gebruikt wordt om informatie toe te voegen over artikelen op de website. Mede door mijn studie informatiekunde en algemene interesse in usability engineering viel mij al snel op dat de interface van deze applicatie op een aantal gebieden te kort schoot. Het ondersteunde mij en mijn collega s niet optimaal in onze dagelijkse taken. In de loop der tijd zijn er verbeteringen doorgevoerd aan de applicatie, maar de nadruk lag daarbij vooral op functionaliteit. Het verhogen van efficiëntie en het creëren van een prettige gebruikerservaring door middel van een op de gebruiker afgestemde interface zijn pas recentelijk een ontwikkeldoel geworden. In het kader van mijn bachelorscriptie informatiekunde ga ik op zoek naar een ideale interface voor deze applicatie, opdat deze de gebruikers maximaal kan ondersteunen in hun werkzaamheden. Hopelijk kan het verantwoordelijke ontwikkelteam vervolgens inspiratie op doen uit mijn bevindingen. Bij dezen wil ik mijn dank uiten aan dr. H.H.A.M. Prüst voor zijn begeleiding en advies als interne begeleider namens de Universiteit Utrecht. Ook bedank ik Dhr. J. Heeg voor zijn ondersteuning als externe begeleider vanuit bol.com. Ten slotte wil ik graag de medewerkers van het content-team bedanken voor hun tijd, enthousiasme en goede ideeën. 1 Local Product Database 2

3 Inhoudsopgave Voorwoord Inleiding Probleemstelling Toepassingscontext Het Longtail model Onderzoeksmethode Wetenschappelijke motivatie bij de gekozen aanpak Het huidige proces van content-verrijken Gebruikersprofielen Doelen en Taken van de eindgebruikers Doelen Taken Acties Applicaties die het productinformatiebeheerproces momenteel ondersteunen LPDB-Tool Microsoft Excel Photoshop, Irfanview en Paint HTML-Tool Microsoft Outlook Welke problemen komen er aan het licht? Gebreken van de LPDB-Tool Gebreken van Microsoft Excel Gebreken van Photoshop, Irfanview en Paint Gebreken van de HTML-Tool Gebreken van Microsoft Outlook Overkoepelende gebreken Wenselijke verbeteringen Requirements Analyse Requirements elicitatie Requirements analyse Prototype Globaal overzicht van de applicatie Indeling van het scherm Status tab Packshot tab Title tab Attributes tab Description tab

4 6.8. Party tab Stills tab Category tab Tracklist tab Bulk data hanteren Dashboard Evaluatie van het prototype Discussie en Conclusie Discussie Conclusie Literatuuroverzicht Appendix Functionele Eisen Scenario s Vereiste Schermelementen Algemeen Gebruikersprofiel Interviews met eindgebruikers interview sessie interview sessie interview sessie interview sessie interview sessie HTA Diagram Think aloud sessies Think aloud sessie Bart S Think aloud sessie Laurens H Use Case Diagram

5 1. Inleiding 1.1. Probleemstelling Het doel van dit onderzoeksproject is om, door middel van onder andere een prototype interface, een helder inzicht te geven in de sleutelelementen van een sterk verbeterde content managementapplicatie; die het content-team 2 van bol.com optimaal ondersteunt in zijn werkzaamheden. Met deze doelstelling komen we tot de volgende hoofdvraag: Hoofdvraag: Hoe ziet de ideale content-verrijkapplicatie 3 voor bol.com er uit? Meten in hoeverre een toekomstige applicatie ideaal zal zijn met enkel een low-fi prototype is lastig, zeker omdat de uiteindelijke applicatie niet getest kan worden binnen de scope van dit onderzoek. Het is echter wel mogelijk om de tevredenheid onder gebruikers over de kenmerken van het nieuwe systeem op kwalitatieve wijze te bekijken. Door middel van gebruikertests met het low-fi prototype kan ook de efficiëntie en het gebruikersgemak van de toekomstige applicatie gepeild worden ten opzichte van de huidige applicatie. Om een beter inzicht te krijgen in welke factoren een applicatie ideaal maken voor deze gebruikers, hoe het nieuwe ontwerp tot stand zal komen en om na te gaan welke tekortkomingen de huidige interface heeft, hanteer ik de volgende subvragen: Subvraag 1: Hoe ziet het huidige proces van content-verrijken er uit? Met het beantwoorden van deze subvraag worden de individuele doelen en taken van gebruikers in kaart gebracht. In hoeverre worden de taken en doelen bepaald door de huidige applicaties, in plaats van andersom? Ook kan deze vraag inzicht geven in welke personen, op wat voor manier, betrokken zijn bij dit proces. Omdat de gebruiker centraal staat bij het ontwerpproces van een GUI en niet het (huidige) systeem, is het belangrijk te weten door wie en met welk doel de interface uiteindelijk gebruikt zal gaan worden (Lanter, 1991). Deze subvraag wordt behandeld in sectie 2. Subvraag 2: Hoe zien de applicaties die het verrijkingsproces momenteel ondersteunen er uit? De gebruikers maken op dit moment gebruik van verschillende applicaties om hun taken te volbrengen. Zo hebben ze Excel nodig om overzichten te maken en te beheren. Vervolgens gebruikt men de Oracle forms database applicatie (LPDB-tool) om informatie in de database te plaatsen. Al deze applicaties hebben hun sterke kanten: de reden dat ze gebruikt worden. Daarentegen hebben ze ook hun zwakke kanten: de reden dat er meerdere applicaties nodig zijn. Voornamelijk deze zwakke kanten vormen aanleiding tot dit onderzoek. Belangrijke aspecten bij deze tweede subvraag zijn: De mate waarin de huidige applicaties aansluiten op de taken en doelen die de gebruikers hebben De sterke punten van deze applicaties [mee te nemen in nieuwe interface] Zwakke punten [verbeteren of wegnemen] Algemene ervaringen van gebruikers [wat beïnvloedt dit?] 2 Ik zal in de rest van mijn onderzoek met de term gebruiker refereren aan de medewerkers van het contentteam. 3 Verrijken is de verzamelnaam die binnen bol.com wordt gehanteerd voor het toevoegen van productinformatie op de website. 5

6 Deze subvraag over de ondersteunende applicaties wordt nader uitgewerkt in sectie 3. Subvraag 3: Welke problemen komen er aan het licht? Door middel van subvragen 1 en 2 en door de werkzaamheden van de gebruikers op taak-, en actieniveau te monitoren zullen er verschillende (usability) problemen aan het licht komen. Een helder overzicht van de problemen vormt de basis van een goede set requirements. Met het beantwoorden van deze vraag scheppen we duidelijkheid omtrent de volgende punten: De taken die niet ondersteund worden door de huidige set van applicaties De plaatsen waar de interface tekortschiet bij het uitvoeren van taken Deze punten worden uiteengezet in sectie 4. Subvraag 4: Welke verbeteringen zijn wenselijk? Om de hoofdvraag uiteindelijk te kunnen beantwoorden moeten er verbeterpunten en nieuwe functionaliteiten aangedragen worden die voor de gebruikers zoveel mogelijk problemen wegnemen. De wenselijke verbeteringen en nieuwe functionaliteiten geef ik weer in een requirements-overzicht. Sommige requirements zal ik in sectie 6 uitvoeriger behandelen met voorbeelden in het prototype Toepassingscontext Bol.com is Nederlands grootste webwinkel met momenteel ongeveer 300 werknemers en 2,5 miljoen vaste klanten. Het internetbedrijf haalde in 2009 en een omzet van 268 miljoen Euro. Maandelijks worden er zo n nieuwe producten opgenomen in de catalogus en dit aantal groeit jaarlijks door. Dit komt mede doordat bol.com regelmatig nieuwe markten betreedt, waardoor bijvoorbeeld in begin 2010 e-books en speelgoed een plek kregen in het assortiment Het Longtail model De reden dat bol.com haar aanbod graag ziet groeien is omdat het bedrijf, net als bijvoorbeeld internetretailer Amazon, het Long Tail model hanteert (figuur 1). Dit is een economisch model dat focus legt op het handhaven van een zo groot mogelijke productaanbod, ook al betekent dit dat er daardoor van de meeste producten maar een lage afzet is. Voor een webwinkel is dit model effectief omdat zij een veel grotere markt weet te bereiken dan een lokale verkoper en centraal haar voorraad kan beheren, met een minimale voorraad per artikel. Met dit grote, groeiende productaanbod is het beheren van productinformatie een omvangrijke taak, dat een essentieel onderdeel van de bedrijfsvoering vormt, aldus managing director D. Ropers (Volkskrant ). Het streven van bol.com is om elk product dat aangeboden wordt te voorzien van een minimale hoeveelheid informatie. Niet alleen om de klant voldoende te informeren en te helpen bij het maken van zijn aankoopbeslissing, maar ook om hem te inspireren en nieuwe producten te laten ontdekken. Productinformatie vormt het belangrijkste communicatiemiddel van een webwinkel. Klanten kunnen het product niet fysiek zien of vasthouden zoals in een locale winkel. Ze doen hun aankoop dan ook veelal op basis van de informatie die hen tijdens het digitale winkelen verschaft wordt. Een goede en volledige indruk levert dus meer verkopen op (Chang, T. Z. & Wildt, A. R., 1994). Daarnaast is het tonen van genormaliseerde informatie belangrijk voor het aanwezig kunnen zijn in prijsvergelijkingsites of soortgelijke externe aggregrators. Laatstgenoemden zijn de laatste jaren steeds meer een autoriteit geworden bij het ondersteunen van aankoopbeslissingen van de consument. (Brown, J.R. & Goolsbee, A., 2002) 6

7 Productinformatie vergaart bol.com deels automatisch. Daarvoor werkt ze samen met leveranciers en andere partijen die gespecialiseerd zijn in het leveren van bijvoorbeeld filmtrailers of boekrecensies. Het overige deel van de productinformatie wordt aangevraagd, opgezocht en verwerkt door medewerkers van de afdeling Product & Content. Momenteel is een dozijn medewerkers dagelijks bezig met het verrijken van producten. Figuur 1: Een schematische weergave van het Long Tail model. Dit houdt in dat zij, afhankelijk van de productgroep 4 waar ze verantwoordelijk voor zijn, afbeeldingen, beschrijvingen, trailers, geluidsfragmenten, attributen en andere vormen van informatie aan de productpagina s op de website toevoegen. Hiervoor gebruiken zij een set van applicaties, waarvan de LPDBtool de belangrijkste is voor de directe invoer van de data in de database. Eén keer per dag wordt de recent ingevoerde productinformatie zichtbaar gemaakt op de website, door te wisselen van productiedatabase Onderzoeksmethode De aanpak van dit onderzoek is te classificeren als designresearch, waarin de onderzoeksvraag middels de constructie van een artefact (in dit geval een prototype) beantwoord wordt. Subsectie 1.1. gaf globaal de structuur van het onderzoek aan, enkel kijkend naar de vragen die beantwoord dienen te worden. Deze methodesectie daarentegen geeft kort een overzicht van de structuur en volgorde van de hoofdactiviteiten die deel uitmaken van dit onderzoek. In de loop van de tekst zal er regelmatig verwezen worden naar deze activiteiten. De belangrijkste activiteiten zijn als volgt samen te vatten: 1. Literatuurstudie 2. Interviews met gebruikers 3. Huidige situatie beschrijven (problemen in kaart brengen) 4. Gewenste situatie beschrijven (opstellen van requierements) 5. Low fidelity prototype ontwikkelen 6. Prototype evalueren 7. Gebruikertests De gebruikertests vormen niet letterlijk de laatste fase van het onderzoek, maar zijn een continu proces dat vanaf de ontwikkeling van het prototype in werking treedt. 4 Productgroepen vormen de hoogste categorieniveau: Boeken, Muziek, Dvd, Games, Speelgoed, Elektronica of Computerproducten 7

8 1.4. Wetenschappelijke motivatie bij de gekozen aanpak Het maken van verbeteringen aan een data-entry interface op gebied van snelheid en nauwkeurigheid leveren uiteindelijk besparingen op in arbeidstijd en de daarmee gemaakte kosten. Maar even belangrijk is het verhoogde gevoel van werktevredenheid van de gebruikers (Ernest, 1998). Interessant is om, kijkend naar de huidige situatie, te bepalen waar deze verbetering van het content-verrijkproces gemaakt kunnen worden. Door middel van interviews en focus Group-sessies met gebruikers komen knelpunten boven water en door hun taken in kaart te brengen komen omslachtige- of slecht ondersteunde handelingen aan het licht. Zoals ik in de probleemstelling aangaf, is het einddoel van mijn onderzoek het opleveren van een prototype interface. Hiervoor zal ik gebruik maken van een Throwaway Prototyping methode. Dit is een RAD 5 methode met een zeer gebruikersgerichte aanpak. Door middel van deze methode kunnen al in een vroeg stadium van het ontwikkelproces ingrijpende ontwerpkeuzes geanalyseerd worden. (Dennis, Wixom, & Tegarden, 2005) De Throwaway Prototyping aanpak kenmerkt zich door de korte intervals waarop iteraties getest worden. Bovendien is de gebruiker nauw betrokken bij vrijwel alle delen van het ontwerpproces. Dit zorgt er voor dat de kans klein is dat er vlak voor het opleveren van het eindresultaat nog drastische veranderingen plaats hoeven te vinden, of dat er zich tijdens de uitwerking van het eindconcept onvoorziene vraagstukken voordoen betreffende het interface ontwerp. Ik heb voor deze aanpak gekozen omdat het mij in staat stelt in relatief korte tijd zoveel mogelijk relevante ontwerpvraagstukken te behandelen en het resultaat te analyseren. Bovendien is het in mijn ogen van belang dat zoveel mogelijk relevante onderdelen van de interface onder de loep worden genomen om een consistent geheel te vormen voor de gebruiker. Om dit te realiseren binnen de opgegeven tijdspanne is een snelle ontwikkelmethode als Throwaway Prototyping noodzakelijk. Voorafgaand aan het maken van een prototype worden requirements opgesteld die middels elicitatie van de behoeften van de eindgebruikers zijn verkregen. Als slotonderdeel van de ontwikkeling van het prototype zal ik deze in sectie 6.14 evalueren. 5 Rapid Application Development 8

9 2. Het huidige proces van content-verrijken 2.1. Gebruikersprofielen Voordat we eisen vast kunnen leggen over hoe de ideale content management applicatie voor bol.com er uit ziet, dienen we te weten te komen wie de applicatie gaat gebruiken en waarvoor hij precies gebruikt gaat worden. In de huidige situatie wordt de lpdp-tool door een twaalftal content-medewerkers gebruikt om producten van informatie te voorzien. Door middel semi-gestructureerde interviews onder zes eindgebruikers is de nodige informatie over deze gebruikers verkregen. Minstens net zo belangrijk is de beschrijving die gebruikers geven van hun taken en doelen. Immers de nieuwe applicatie dient zoals de opdracht omschrijft, zoveel mogelijk ondersteuning te bieden in hun dagelijkse taken. Er is gekozen voor deze vorm van interviewen omdat het ruimte laat voor vrije input van de geïnterviewde (Sharp, Rogers, & Preece, 2007, p. 298) Wie zijn de gebruikers waar dit onderzoek zich op focust? Er zijn tal van stakeholders aan te wijzen die belang hebben bij taken en applicaties die in behandel in mijn onderzoek. Echter twaalf vaste werknemers, het content-team, zijn de eindgebruikers die waar ik mijn onderzoek op zal afstemmen, omdat zij als enige binnen het bedrijf geheel afhankelijk zijn van de applicaties waar in me op richt. Aan de hand van interviews met de eindgebruikers (zie appendix 9.5.) stel ik een algemeen gebruikersprofiel op volgens de checklist van Mayhew (1992), te zien in appendix 9.4. Zo n gebruikersprofiel is interessant omdat het inzicht geeft in wie de gebruikers precies zijn en wat ze kunnen. Dit is een essentiële basis van gebruikersgericht ontwerp. Het gebruikersprofiel heb ik enigszins aangepast naar de context van dit onderzoek, omdat er in mijn ogen een aantal zaken ontbraken en/of overbodig waren. In eerste instantie is het belangrijk de overeenkomsten te vinden tussen de gebruikers, omdat we hiermee bepaalde generalisaties kunnen maken die leidend zijn voor de niet functionele requirements 6 van het eindproduct. Op basis van dit gebruikersprofiel kan onder andere worden bepaald wat het niveau is van de gebruikers qua computergeletterdheid, expertise binnen hun productgroep en kennis van de contextterminologie zoals proces- en attribuutnamen die gehanteerd worden in de database en de overkoepelende systemen. Daarbij komt nog dat gebruikers ook een specifieke demografische achtergrond kunnen vertegenwoordigen, zoals overeenkomsten in leeftijd, opleiding, geslacht, etc. Dit kan ontwerpkeuzes beïnvloeden Doelen en Taken van de eindgebruikers Door middel van interviews (appendix 9.5) met de gebruikers ben ik opzoek gegaan naar de doelen die de gebruikers proberen te verwezenlijken. Daarnaast achterhaal ik welke recurrente werkzaamheden ze uitvoeren om deze doelen te verwezenlijken. Deze werkzaamheden noemen we in het vervolg taken. Ten slotte kijk ik naar de acties van gebruikers bij het uitvoeren van hun taken. Figuur 2 stelt een schematische weergave van het detailniveau voor, dat ik hierboven beschrijf. 6 Niet functionele requirements zijn vereisten die op kwalititatief niveau het functioneren van het systeem beschrijven. De beschrijving van specifieke taken (functionele requirements) valt hier dus buiten. 9

10 Figuur 2: Schematische decompositie van doelen, taken en acties. Het gebruikersprofiel in appendix 9.4 kan de indruk wekken dat de verschillen in de manier van werken, op globaal niveau, niet groot zijn. Echter, uit de interviews is op een getailleerd niveau te zien wat voor handelingen de gebruikers precies uitvoeren, en blijkt dat er wel degelijk grote verschillen bestaan tussen de onderlinge gebruikers in hun dagelijkse werkzaamheden (taken). Gebruikers die verantwoordelijk zijn voor de productinformatie bij muziekproducten besteden bijvoorbeeld het grootste deel van hun tijd aan het in orde maken van track-lists, in tegenstelling tot gebruikers verantwoordelijk voor productgroepen als dvd s of boeken. Bij deze productgroep ligt de nadruk weer op het correct aanvullen van party s 7. Juist dit verschil in taken moet aandacht krijgen om het eindproduct succesvol te maken. Een te generieke oplossing (zoals nu het geval is) ondersteund de individuele gebruiker niet genoeg in zijn dagelijkse taken. Hier zal ik verder op ingaan in sectie 4, waar de geconstateerde problemen behandeld worden. Eerst moeten alle relevante doelen, taken en acties in kaart gebracht worden Doelen Het hoofddoel van alle gebruikers is het maandelijks halen van de gestelde targets. De targets zijn een minimaal percentage van producten dat als volledig verrijkt 8 beschouwd kan worden. Dit percentage verschilt per productgroep, maar ligt vaak rond de 90%. Naast deze algemene targets hebben de meeste medewerkers ook specifieke targets, die de algemene kwaliteit van de informatie binnen hun productgroep weerspiegelen. Zo heeft de productgroep games bijvoorbeeld als target om alle producten die in de top-100 games voorkomen volledig verrijkt te krijgen. Kort samengevat zien de doelen van de gebruikers er als volgt uit: Jaarlijkse targets o Maandelijkse targets Minimaal percentage producten volledig verrijken Productgroepspecifieke targets, b.v: Top-100 bestverkochte producten Percentage verwerkte s Navolging van kwaliteitseisen Percentage volledig verrijkte pre-orders 9 7 Betrokken partijen, zoals: auteurs, acteurs, regisseurs, uitgevers, etc. 8 Een term die binnen het content-team gebruikt wordt om aan te geven dat een product van voldoende productinformatie is voorzien. De precieze invulling hiervan verschilt per productgroep, dit staat vastgelegd in een kwaliteitsdocument. 9 Pre-orders zijn producten die al besteld kunnen worden voordat ze daadwerkelijk uitgebracht zijn. Op de dag van uitgave worden ze direct verstuurd naar de klant. 10

11 De gebruikers zijn gemotiveerd om deze doelen te halen, omdat hun eindejaarsbonus en opslag hier direct van afhankelijk zijn. Naast deze meetbare doelen, stelde de meeste gebruikers in het interview ook dat zij zich in algemene zin verantwoordelijk voelen voor de kwaliteit van productinformatie op de website Taken De taken die gebruikers uitvoeren verschillen per productgroep. Toch is er een aantal taken dat elke gebruiker uitvoert. Deze taken zullen de meeste aandacht krijgen en vormen de leidraad bij het ontwerpen van een ideale verrijkingsapplicatie. 1. Packshots 10 van producten klaarzetten 2. Beschrijvingen van producten in orde maken en klaarzetten 3. Categorieën van producten controleren en/of toevoegen 4. Attributen van producten controleren en/of toevoegen 5. Aangeven of een product volledig is verrijkt 6. verwerken en beantwoorden 7. Voortgang rapporteren aan leidinggevende Het verrijken van een product (taak 1 t/m 5) bestaat in werkelijkheid uit meer taken dan ik hierboven beschrijf. Dit zijn echter de belangrijkste. In de hiërarchische taak analyse in appendix 9.6, is een volledig overzicht te zien van deze taken en de volgorde waarin deze elkaar meestal opvolgen. In appendix 9.8 is dit overzicht weergegeven in een use case diagriam. Hierme wordt de relatie tussen taken en de verschillende actoren duidelijker in beeld gebracht Acties Acties zijn handelingen op het laagste niveau van abstractie. Dit zijn de directe handelingen die de gebruiker uitvoert, om een bepaalde taak te volbrengen. Sommige acties zijn belangrijker dan andere omdat ze een vaak voorkomende handeling representeren. Welke acties veel voorkomen is doormiddel van twee think-aloudsessies uitgezocht en is te vinden in appendix 9.7. Het is belangrijk om veel uitgevoerde acties in kaart te brengen omdat deze, wanneer ze niet goed worden ondersteund, verantwoordelijk zijn voor een groot deel van de frustratie bij gebruikers. Achter iedere actie is aangegeven hoe de gebruiker deze uitvoert. De meest prominente acties zijn als volgt: 1. Selecteren [1 klik met lmb] [ctrl + a] 2. Zoeken/Query uitvoeren [F7 <query invoeren> F8] [ctrl + f] 3. Openen [2 klik met lmb] 4. Kopiëren [ctrl + c] [verslepen] 5. Plakken [ctrl + v] 6. Scrollen [muiswiel] [verslepen van scrollbar] 10 Een packshot is een hoofdproductafbeelding. Bijvoorbeeld de voorkant van een boek of cd-doosje, of een duidelijke afbeelding van een laptop. 11

12 3. Applicaties die het productinformatiebeheerproces momenteel ondersteunen Omdat we te maken hebben met een reeds bestaand systeem, en we niet vanaf nul hoeven te beginnen met ontwerpen dienen we zo goed mogelijk lering te trekken uit de gebruikerservaringen van het huidige systeem. Dit is namelijk een schat van relevante informatie. Het begrip systeem omvat in deze context de combinatie van applicaties en communicatiemiddelen die gebruikers tot hun beschikking hebben om hun taken uit te voeren. Door goed te kijken naar de huidige manier van werken kunnen toekomstige ontwerpkeuzes zodanig onderbouwd worden dat ze als verbetering gezien kunnen worden. Deze verbeteringen zal ik in sectie 5 bespreken. Ik zal de rollen en functies van de meest gebruikte applicaties nu toelichten. Deze applicaties beschikken over veel meer mogelijkheden dan ik in de beschrijving zal laten blijken. Echter, ik beschrijf de applicaties enkel met oog op de functionaliteit die gebruikt wordt bij de taken van de gebruikers om het zo bondig en relevant te mogelijk te houden LPDB-Tool Deze CMS 11 - applicatie is door en voor bol.com gemaakt in Oracle Forms, een op java gebaseerd platform voor interactieve databaseapplicaties. Deze applicatie speelt een sleutelrol bij vrijwel alle taken de gebruikers, omdat het de enige directe manier is om waarden in de database toe te voegen of aan te passen. Binnen de lpdb-tool wordt voornamelijk gebruik gemaakt van het products-scherm, zoals te zien in figuur 3. Dit scherm biedt CRUD 12 -functionaliteit op productniveau. Wanneer een gebruiker bijvoorbeeld een beschrijving, categorie of auteur wil toevoegen aan een product, opent hij dit scherm en navigeert naar het daarvoor bestemde tabblad. Figuur 4 laat zien hoe een beschrijving toevoegd kan worden via het extra contents tabblad. Hier kan de gebruiker een description record aanmaken, en er een beschrijving, in correcte HTML, invoeren. Vervolgens klikt de gebruiker op de knop synchronise linksboven. Op dat moment worden de aanpassingen opgeslagen. De veranderingen zijn echter pas na minimaal een dag zichtbaar op de website. Omdat er niet direct wordt gewerkt in de productiedatabase, zoals eerder beschreven in sectie CMS: Content Management System 12 CRUD: Create, Read, Update, Delete: De basisfunctionaliteiten van een CMS 12

13 Figuur 3: Het products -scherm in de lpdb-tool Figuur 4: Toevoegen van een beschrijving: via het description -tabblad 13

14 3.2. Microsoft Excel Hoewel Excel een generieke applicatie is, die niet speciaal voor bol.com is gemaakt, wordt er veel gebruik van gemaakt. De veel gebruikte tabelvormige lijsten met productgegevens laten zich eenvoudig bewerken in Excel. Bovendien bevat het programma een aantal handige functies die het werken met grote tabellen vergemakkelijkt. Denk hierbij aan sorteren op waarden van een bepaalde kolom (zoals in figuur 5), het uitsluiten van rijen die niet relevant zijn voor de taak voorhanden of het uitvoeren van kruisverwijzingen tussen verschillende tabellen, met overeenkomstige waarden. Tot slot biedt Excel, dankzij de sobere en ruime canvas een goed overzicht van de status van producten, wanneer er gekeken wordt naar rapportages uit de database. Deze, en nog veel meer functies worden niet ondersteund door de LPDB-Tool. Daarom wordt Excel veel gebruikt door de gebruikers waar dit onderzoek zich op richt. Figuur 5: Gameproducten sorteren op verschijningsdatum 3.3. Photoshop, Irfanview en Paint Afbeeldingen vormen een belangrijk onderdeel van de productinformatie die bol.com verschaft richting de klant. De auteurs en leverancier bieden op ongestandaardiseerde wijze afbeeldingen aan van hun producten. Zo bevatten sommige afbeeldingen bijvoorbeeld zeer veel witruimte, of een zwarte achtergrond, in plaats van een witte. Dit soort discrepanties worden met behulp van fotobewerkingssoftware weggenomen door de afbeeldingen, naar de standaarden die bol.com zelf stelt, aan te passen. De gebruikers zijn vrij in de keuze welke software zij hiervoor willen gebruiken. Voor het eenvoudige knip en plakwerk volstaan Paint en Irfanview. Wanneer er echter kleuren veranderd moeten worden, of collages gemaakt moeten worden voor bijvoorbeeld bundelartikelen, is Photoshop de aangewezen applicatie HTML-Tool De HTML-Tool is een applicatie waarmee normale tekst direct omgezet kan worden in overeenkomstige HTML. Deze applicatie werk in de browser, en is geheel gemaakt voor gebruik binnen bol.com. De applicatie onderstreept ook verboden woorden 13 zoals u en uw. Omdat deze niet overeenkomen met de schrijfstijl 13 Verboden woorden: Woorden die in de meeste gevallen beter vermeden kunnen worden op de website, omdat ze onduidelijkheid scheppen, of voor stijlbreuk zorgen met oog op de rest van de website. Bijvoorbeeld de woorden nieuwe en nieuwste dienen vermeden te worden, omdat ze verwarring zaaien wanneer er een 14

15 van bol.com. Zo kan de gebruiker fouten snel zien, en aanpassen. Daarnaast geeft deze applicatie ook de mogelijkheid om veel voorkomende uitdrukkingen en opmaakconstructies snel te generen met behulp van leestekens. Zo kan de gebruiker door, / te typen, de volgende output generen: <h3>kenmerken:</h3>. Figuur 6 geeft de HTML-Tool weer in gebruik. In het invoerveld, linksboven kan de gebruiker tekst invoeren. Links onder wordt een voorbeeld gegenereerd dat direct overeenkomt met uiteindelijke weergave op de website. Het paneel rechtsboven leent zich voor instellingen. Het tekstveld rechtsonder geeft de bijbehorende HTML als output. Deze HTML wordt vervolgens in het description-veld van het product geplakt, in de LPDBtool. Figuur 6: HTML-Tool in gebruik 3.5. Microsoft Outlook Microsoft Outlook wordt gebruikt voor communicatie en het plannen van afspraken. Dit laatste laat ik buiten beschouwing in dit onderzoek. Het verkeer met interne en externe partijen vormt een belangrijk onderdeel van het takenpakket van de gebruikers. Zo worden vrijwel alle verzoeken en rapporteringen gedaan via . Elke productgroep van het content-team heeft een eigen mailbox, die beheert wordt door de gebruikers die verantwoordelijk zijn voor die productgroep. De meeste s zijn verzoeken voor het toevoegen of aanpassen van productinformatie. Deze verzoeken komen vrijwel uitsluiten van product management, uitgevers of customer service nieuwere versie van het product verschijnt. In dit geval zouden alle oudere versies telkens gecontroleerd moeten worden op het gebruikt van deze woorden, omdat het niet meer de nieuwste versie betreft. Daarom worden deze woorden maar in het geheel vermeden. 15

16 4. Welke problemen komen er aan het licht? In deze sectie behandelen structureer ik alle gevonden problemen, opdat er een bruikbaar overzicht ontstaat dat het opstellen van verbeteringen in de volgende sectie vergemakkelijkt. In sectie 3 heb ik het gebruik van de huidige applicaties toegelicht. Hier zal ik grotendeels per applicatie de geconstateerde problemen benoemen. Echter, er zijn ook problemen aan te wijzen die niet op één applicatie te pinnen zijn; deze behandel ik apart in 4.6. Ik kies ervoor om de gevonden problemen te groeperen per applicatie omdat deze applicaties elk voor specifieke problemen zorgen, waarbij generalisatie vaak niet van toepassing is. De gevonden functionele problemen vallen onder het taak- en/of actieniveau. Het doelniveau staat bij dit onderdeel buiten beschouwing omdat het correct opstellen van doelen aan de gebruikers en hun leidinggevenden zelf is, en ik met dit onderzoek daar niet over kan oordelen. Net als in sectie 3 geldt dat ik de applicaties enkel behandel op hoe ze in de context van de werkzaamheden van de gebruikers worden toegepast. Dit kan betekenen dat bepaalde gebreken zich alleen voordoen wanneer applicaties gecombineerd gebruikt worden voor het uitvoeren van een bepaalde taak. In zo n geval neem ik het probleem op bij de applicatie die het grootste obstakel vormt, en zal ik refereren naar de andere applicatie Gebreken van de LPDB-Tool De LPDB-Tool laat zich alleen opstarten in firefox 6 (oude versie). Functionele gebreken o Beperkte functionaliteiten rondom tekstinvoer: Invoer wordt in de meeste gevallen niet gecontroleerd HTML, spelling- en schrijfstijlcontrole moet gedaan worden door HTML- Tool. Controle bestaat enkel bij bepaalde attributen met een vooraf ingestelde LoV 14 De waarden van de LoV is niet aan te passen door gebruikers zelf. De aanwezige hoofdlettergevoeligheid is hier zinloos, en storend. Veel waarden komen meer dan eens voor in de database. Er wordt redundantie gecreëerd, mede door de matige zoekfunctionaliteit die reeds bestaande records niet altijd toont. Een voorbeeld hiervan is het grote aantal auteurs dat meer dan één keer voorkomt in de database. Onduidelijkheid bij het invoeren van eenheden. Bijvoorbeeld. Gewicht: 0,5, of 0,5 kg? Dit is niet consistent. En daarom komt er soms op de website te staan: Gewicht: 0,5kg kg Sommige attributen moeten vrijwel altijd dezelfde waarde krijgen, maar toch moet dit telkens per product opnieuw ingevuld worden. Er zijn geen standaardwaarden in te stellen, door de gebruiker. o Sommige invoervelden (track-lists) hanteren een maximaal aantal karakters Grote boxsets (muziek) overschrijden deze limiet vaak. Vervolgens moet de informatie opgedeeld worden en per onderdeel ingeladen worden. o Geen goede zoekfunctie Er kan enkel direct gezocht worden op ean 15 of ptdid LoV: List of Values: De waarde van het attribuut moet overeenkomen met één of meerdere waarden uit de bijbehorende LoV. Het systeem controleert dit, en staat foutieve invoer niet toe. 16

17 o o o o o Zoeken op titel moet nu via de site, hier is het ean te vinden. Standaard sneltoetsen werken niet, op ctrl+c en ctrl+v na. Ctrl+A om alle tekst in een veld selecteren, werkt niet. Ctrl+F, om bijvoorbeeld een bepaald woord te zoeken, werkt niet. Limiet op aantal producten per attributensheet, voor bulk in- en uitvoor van productinformatie (256 tekens) Er moeten vier exportsheets gemaakt worden wanneer een gebruiker 900 producten wil nalopen in Excel. Geen manier om in één keer een bepaald kenmerk van meerdere producten tegelijk aan te passen. Afbeeldingen zijn niet zichtbaar in de lpdb-tool, enkel een url van de afbeelding. Snelle controle is dus niet mogelijk Samengestelde producten. (Producten die uit meerdere producten bestaan) worden niet als zodanig behandeld. Dit betekent dat een samengesteld product uitsluitend als een opzichzelfstaand product behandeld wordt, zonder enige relatie met de deelproducten. Hierdoor krijgen dit soort producten niet automatisch de productinformatie van de deelproducten. Dit moet apart ingevoerd worden. (Gekopieerd worden vanaf de deelproducten, en dit kan ook niet op eenvoudige wijze.) Dit heeft veel knip-enplakwerk tot gevolg met informatie die bol.com al beschikbaar heeft. Algemene usability gebreken: o Overvloedige, nietszeggende foutmeldingen. (Vaak wordt enkel een errorcode getoond, waar de gebruiker niets mee kan.) o Klikbare gebieden zijn klein en onduidelijk. Om de typen in een veld moet er vaak rechts naast het veld geklikt worden. o Kleuren pallet is niet optimaal. Er wordt veel gebruikt gemaakt van zwarte tekst op een donkerblauwe achtergrond. Dit maakt de leesbaarheid onnodig slechter. o De window-lay-out van oracle forms wekt de illusie dat er gelijktijdig gewerkt kan worden in verschillende schermen. Dit is bij de meeste windows echter niet mogelijk. o Vaak wordt de LPDB-Tool alleen gebruikt om de correctheid of aanwezigheid van informatie te controleren. Echter de overzichtelijkheid laat te wensen over. De invoervelden zijn veelal te klein, en niet te vergroten. Scrollen in een tekstveld met het muiswieltje kan niet Gebreken van Microsoft Excel Excel wordt gebruikt voor het behandelen grote selecties producten. Excel biedt overzicht en handige functionaliteiten die het werken met een lijst producten vereenvoudigt. Functionele gebreken: o De reportsheet moet aanzienlijk bewerkt worden (gefilterd), voordat er een bruikbaar overzicht ontstaat. Algemene usability gebreken: o Geen live overzicht 15 EAN: European Article Number. Wordt vaak ook barcode genoemd. Moderne boeken hebben als EAN een tiencijferige ISBN plus een driecijferige toevoeging. 16 Ptdid: Product id. Een door bol.com gegenereerd productnummer dat intern gebruikt wordt. 17

18 Excel-report wordt maximaal één keer per dag geüpdate Zelf bijhouden wat er is gedaan die dag. (Nog lastiger wanneer er meerdere gebruikers aan dezelfde set artikelen werken.) Voor een live status, moet er op productniveau in de lpdb-tool gekeken worden 4.3. Gebreken van Photoshop, Irfanview en Paint De noodzaak van het gebruik van Photoshop is duidelijk, sommige afbeeldingen moeten nog op allerlei manieren bewerkt worden voordat ze voldoen aan de richtlijnen van bol.com. Echter, de noodzaak van het gebruik van Paint en/of Irfanview valt te bezien. De laatstgenoemde applicaties vervullen vaak niet meer dan de crop-functie, om een afbeelding met zo min mogelijk witrand op te slaan. Functionele gebreken: o Afbeeldingen moeten na bewerking nogmaals opgeslagen worden o Er wordt niet direct een afbeeldinggeschiedenis bijgehouden Deze applicaties en opgeslagen afbeeldingen hebben geen betekenisvolle relatie met artikelen in de database. En kunnen daarom niet snel meer opgezocht worden. o De verwerking van afbeeldingen door het systeem is voor de gebruiker een black-box - proces, waarbij nog al eens iets mis gaat. Vervolgens worden afbeeldingen niet getoond op de website. Fouten in dit proces worden niet automatisch gerapporteerd aan gebruiker Gebreken van de HTML-Tool De HTML-Tool zelf vertoont vrijwel geen gebreken, omdat deze applicatie een gerichte oplossing is op een tekortkoming van de LPDB-Tool. De HTML-Tool is voor een specifieke taak (tekstsopmaak) ontwikkeld, en sluit geheel aan op de wensen van de gebruiker. Echter zijn er wel een aantal punten te noemen die in een later stadium relevant kunnen zijn. Zo is het niet eenvoudig voor gebruikers om zelf controle regels, verboden woorden of opmaakstructuren in te stellen. Daarnaast zijn sommige functionaliteiten, zoals undo (crtl+z), afhankelijk van de browser waarin de tool is geopend. Niet elke browser biedt hierin de zelfde ondersteuning Gebreken van Microsoft Outlook Algemene usability gebreken: o Veel verkeer verwijst direct naar zaken in de lpdb-tool. Er is altijd een ean vereist om het betreffende product op te kunnen zoeken in de lpdb-tool. Het ean wordt niet altijd genoemd in een . Er moet veel gewisseld worden tussen lpdb-tool en Outlook 4.6. Overkoepelende gebreken Opvallend is dat applicaties als Excel, HTML-Tool en Irfanview, vaak niet meer zijn dan een oplossing voor een onderdeel van een taak, waarin de LPDB-Tool zelf geen ondersteuning biedt. Dit probleem ligt ten grondslag aan andere problemen. Namelijk omdat veel problemen lijken te ontstaan wanneer gebruikers verschillende applicaties nodig hebben voor een uitvoeren van één taak. De imageload 17 is ondoorzichtig voor gebruikers en werkt niet altijd naar behoren o Hierdoor moeten afbeeldingen vaak opnieuw klaargezet worden (dubbel werk) Als informatie niet te vinden is moet de gebruiker dit ergens noteren en later opnieuw kijken of de informatie beschikbaar is. 17 Automatisch proces dat een maal per dag afbeeldingen verzamelt, bewerkt en naar de website exporteert. 18

19 De automatische loads van (content)leveranciers geven soms slechte of foutieve informatie door. o Dit soort foute informatie wordt pas te laat gevonden, vaak wanneer het al een tijd op de website staat 5. Wenselijke verbeteringen Uit interviews appendix 9.5 blijkt dat alle gebruikers experts zijn in het gebruik van de huidige database applicatie (lpdb-tool). Daarom ligt de focus in het ontwerpproces op ease of use, en niet op ease of learning. Uitgaande van het feit dat het beter leerbaar maken van een interface er op neer komt dat de gebruiker stapsgewijs keuzes voorgeschoteld krijgt, iets dat een expert belemmert in zijn efficiëntie, aangezien hij alle functionaliteiten al kent en een helder doel voor ogen heeft Requirements Analyse Zoals ik in de inleiding aangaf kan een degelijke interface alleen ontworpen worden wanneer duidelijk is aan welke voorwaarden het op te leveren product moet voldoen. Om helder beeld te schetsen van alle wensen en vereiste functionaliteiten stellen we requirements op. Dit proces kan opgedeeld worden in drie delen (IEEE, 2004): Requirements elicitatie: De wensen en behoeften van gebruikers inventariseren uit interviews en de gevonden problemen uit sectie 4. Vervolgens vertalen we deze naar formele requirements. Requirements analyse : De opgestelde requirements waar nodig uitbreiden, corrigeren of verduidelijken. Belangrijk is dat het een consistent geheel wordt dat aansluit op met de nietfunctionele requirements en algemene ontwerpprincipes als de heuristics van Nielsen (1994). Requirements validatie : Requirements kunnen in verschillende vormen gedocumenteerd en getest worden. Een manier van testen is door middel van prototyping, dit vormt het laatste onderdeel van mijn onderzoek. Hoewel de bovenstaande methode het niet expliciet noemt, bestaat een duidelijk onderscheid tussen functionele en niet-functionele eisen. De niet-functionele eisen vormen de fundering voor de functionele eisen, en hebben een controlerende rol bij het opstellen van de functionele eisen. Daarom zal ik de nietfunctionele eisen eerst behandelen, en vervolgens het IEEE-proces toepassen op de functionele eisen Niet-functionele requirements Uit de group session en de interviews (appendix 9.5) met gebruikers, zijn indirect de meest belangrijke nietfunctionele eisen duidelijk geworden. Deze zijn hieronder uiteengezet. Power: De gebruiker moet een gevoel van controle hebben over het systeem. De gebruiker bepaalt welke taken hij uitvoert en hoe het scherm er uit ziet (zie flexibiliteit.) Recognition over recall: Waar nodig laat de interface keuzes, mogelijke stappen en waarden laten zien aan de gebruiker, opdat hij zelf zo min mogelijk hoeft te onthouden. Daarnaast is het wenselijk dat gebruikers producten herkennen aan naam en afbeelding, i.p.v. zelf te moeten onthouden welk product ze aan het bewerken zijn in het overzicht. 19

20 Ease of use: Het gebruik van de applicatie moet snel en doeltreffend zijn. De gebruiker heeft snel toegang tot alle functionaliteiten die de applicatie biedt. Flexibiliteit: De interface moet aan te passen zijn door de eindgebruiker zelf. Het achterliggende systeem is continue in ontwikkeling. De gebruikersinterface moet daar adequaat in mee kunnen gaan. Error prevention & recovery: Er worden fouten gemaakt tijdens het verrijken van producten. Het moet eenvoudig zijn om fouten te herkennen en te verbeteren. De meest effectieve manier hierbij is foutpreventie Satisfaction: Gebruikers moeten tevreden zijn met het gebruik van de applicatie en het resultaat dat ze creëren Requirements elicitatie Functionele eisen zijn opgesteld gebaseerd op bevindingen uit interviews (appendix 9.5), een focus group sessie en think aloud sessies met eindgebruikers (appendix 9.7). Een volledig overzicht van de functionele eisen is te vinden in (appendix 9.1) Als overzicht heb ik de globale functionele eisen hier onder uitgelicht, en gerangschikt volgens de MoSCoW-methode 18. Must have: Overzichtstabel met uitgebreide filtermogelijkheden Mogelijkheid om instellingen per gebruiker op te slaan Geen hooflettergevoeligheid op invoervelden Input validatie (ook spelling en jargon) Zoekfuntie zoals op site (ean, titel) Default attribuutwaarden, afhankelijk van typecodes van producten (vast te leggen door gebruikers zelf) Heldere weergave van progressie bij te halen doelen. Should have: Drag & Drop images Ondersteuning voor het invoeren van grote hoeveelheden content, ineens. (bulk) Functionaliteit om productbundels te beheren Could have: Would like: Product management commentaar mogelijkheid bij producten Toegang en wizard-handleiding voor externe partijen Wizard-functionaliteit voor nieuwe gebruikers Sommige eisen kwamen direct van gebruikers zoals Ik wil overal en altijd kunnen copy-pasten in die nieuwe applicatie. Ik vind het storend dat dit nu niet kan. Dit soort opmerkingen van gebruikers zijn waardevol en kunnen vaak direct in de requirements worden opgenomen. Andere eisen zijn een generieke oplossing voor meerdere problemen. Bijvoorbeeld het probleem dat beschreven staat in requirement 1: De gebruikers 18 MoSCoW is een acronym voor een methode om functionele eisen te rangschikken op prioriteit. Eisen worden gegroepeerd als: Must have, Should have, Could have, Would like/won t have. 20

21 storen zich aan het feit dat ze telkens opnieuw hun filtersettings in moeten stellen in Excel. Daarnaast zouden ze ook graag alleen velden willen zien die ze gebruiken. Dit kan samengevoegd worden in 1 oplossing, het hanteren van gebruikersprofielen waarin dit soort voorkeuren centraal opgeslagen worden Requirements analyse Lanter (1991) stelde dat de problemen die de gebruikers ondervinden bij de uitvoer van dagelijkse werkzaamheden met een soortgelijke applicatie veelal te herleiden zijn op het interface ontwerp en niet zozeer op de technische inrichting van het systeem. Dit gaat ook op voor de huidige lpdb-tool. In theorie zou het achterliggende systeem zelfs zeer slecht en onlogisch ingericht kunnen zijn. Zolang er een degelijke GUI bestaat die een logisch user model doorspeelt richting de gebruiker zal deze geen directe belemmeringen hoeven te ondervinden in het gebruik. Met dit concept in het achterhoofd heb ik zoveel mogelijk gekeken naar hoe de interfaceonderdelen logisch en intuïtief over komen op de gebruiker, ongeacht de werking van het achterliggende systeem. Zo heb ik er voor gekozen om bepaalde data anders te groeperen en te tonen dan dat nu in het systeem het geval is. Toegepaste ontwerp principes: Om tot een degelijk ontwerp te komen van een interface is het goed om je als ontwerper aan een aantal richtlijnen te houden. Er zijn boeken vol geschreven over wat je als ontwerper vooral wel en niet moet doen. Toch zijn er twee korte sets van regels die, wanneer ze nageleefd worden, de meeste usability problemen voorkomen. De eerste is het de visuele deling op basis van Gestalt principes. Aan de hand van deze richtlijnen deel je de lay-out zodanig in, dat deze als vanzelfsprekend overkomt op de gebruiker. De tweede set, zijn de tien heuristics van Nielsen. (Nielsen, 1994) Visuele indeling: De volgende vier gestaltprincipes vormen de leidraad bij de totstandkoming van de visuele indeling van deze interface (McCracken & Wolfe, 2004, pp ) : Proximity: Mensen beschouwen dicht bij elkaar geplaatste elementen als gerelateerd. Het is dus zaak, gerelateerde elementen zoveel mogelijk te bundelen. Alignment: Door elementen langs onzichtbare op te stellen wordt er een gevoel van overzicht gecreëerd. Bovendien kunnen dan door middel van marges onderliggende elementen worden getoond. Consistency: Gerelateerde elementen moeten er hetzelfde uitzien. Bijvoorbeeld de knoppen in een menu of de velden in een formulier moeten op de zelfde manier opgemaakt zijn, zodat ze als geheel gezien worden. Contrast: Elementen met een verschillende functie moeten ook grafisch van elkaar verschillen. Zodat niet de illusie gewekt wordt dat ze bij elkaar horen, of een soortgelijke functie vervullen. De tien Heuristieken van Nielsen: 21

22 De volgende tien heuristieken van Nielsen vormen een goede basis voor elke interface. Zichtbaarheid van systeemstatus Overeenkomst tussen systeem en echte wereld Controle en vrijheid van de gebruiker Consistent en volgens standaarden Voorkomen van fouten Herkennen boven herinneren Flexibiliteit en efficiëntie in gebruik Esthetisch en minimalistisch ontwerp Help gebruikers bij het herkennen, diagnosticeren, en oplossen van fouten Hulp and documentatie Maar met oog op de taken en doelen die de gebruikers van deze specifieke interface hebben, krijgen de vier dikgedrukte heuristieken de meeste nadruk tijdens het ontwerp. Controle en vrijheid van de gebruiker: Expert users zijn er bij gebaat te beschikken over een uitgebreid aantal opties en functionaliteiten, ook als deze maar in bepaalde situaties bruikbaar zijn. Expert gebruikers hebben een goed beeld bij de werking van het systeem en weten zelf goed wat ze willen, en kunnen verwachten van het systeem. De werking ervan moeten ze daarom (in zekere mate) aan kunnen passen. Voorkomen van fouten Voorkomen is beter dan genezen. Dat geldt ook voor fouten die optreden bij het gebruik van een grafische interface. Het voorkomen van fouten moet in deze context op twee niveau s gebeuren. Ten eerste moet de gebruiker bij het gebruik van de interface niet onnodig tegen foutmeldingen aanlopen, of geconfronteerd worden met onlogisch werking van interface-elementen. Ten tweede moeten fouten in de productinformatie voorkomen worden. Herkennen boven herinneren De gebruikers van deze interface krijgen op een werkdag een heleboel keuzes voorgeschoteld. Het is daarom zaak het moeten herinneren van oplossingen op deze keuzes minimaal te houden. Door middel van herkenning kan de gebruiker makkelijker tot het volbrengen van zijn taak komen. Bovendien geeft Flexibiliteit en efficiëntie in gebruik 6. Prototype In deze sectie worden voorgestelde verbeteringen toegepast op het ontwerp van een nieuw systeem. Dit ontwerp is in de vorm van een low-fidelity papieren prototype. Het prototype is wel digitaal gemaakt, maar wekt de indruk getekend te zijn. Dit zorgt ervoor dat gebruikers tijdens tests, geen aandacht besteden aan het uiterlijk van de applicatie, maar enkel letten op functionaliteit. Het bouwen van het protoype is gedaan met het mock-up-ontwerpprogramma balsamiq. Het prototyping proces had een erg iteratief karakter, doordat na een aantal aanpassingen het ontwerp geprint, en direct getest werd met gebruikers. Dit process herhaalde zich totdat een bepaalde use case, en bijbehorende scenario s naar behoren ondersteund werden. 22

23 6.1. Globaal overzicht van de applicatie Figuur 7 laat de verbanden zien tussen de belangrijkste schermen. De schermen met dikgedrukte randen zijn pop-ups die vanuit meerdere situaties bereikbaar zijn. De schermen met stippellijnen zijn schermen die wel gewenst, maar buiten de scope van mijn onderzoek vallen. Ik zal deze later in dit hoofdstuk kort toelichten. De rode asterisk geeft het grote aantal connecties van de import & export pop-up aan. Admin scherm (teamleiders) Content-tool * Import & export content elements Personal settings Search Dashboard Import bulk data Grid view * Status tab * * * * * * * Packshot tab Description tab Stills tab Party tab Track list tab Custom tab(s) Figuur 7: Overzicht van de uitgewerkte schermen. De schermen met dikke rand zijn losstaande pop-ups Indeling van het scherm In het volgende hoofdstuk zal ik de ontworpen schermen toelichten en daarbij de toegepaste ontwerpprincipes behandelen. Het totale scherm bestaat uit grofweg drie delen. Het bovenste deel noem ik de main control bar. Deze is vrijwel onveranderlijk en blijft altijd zichtbaar voor de gebruiker. Hier vindt de gebruiker de meest belangrijke controls die van invloed zijn op de applicatie als geheel. 23

24 Figuur 8: De globale, verticale indeling van de interface. Main control bar: Onder de main control bar bevinden zich de grid views die de gebruiker op dat moment open heeft staan. Deze zijn toegankelijk als tabbladen. Het eerste tabblad is altijd het dashboard (geen grid view). Grid views: De grid views zijn gevuld met data, afhankelijk van de manier waarop de gebruiker deze heeft ingedeeld. De meeste velden in de grid fungeren op hun beurt ook weer als tabs die nadere informatie toegankelijk maken. Content element tabs: Op het moment dat een veld wordt aangeklikt vormt er zich onder de desbetreffende rij een paneel van meerdere rijen hoog waar de gebruiker informatie kan invoeren. Dit laatste is een designpattern dat accordeonstructuur genoemd wordt. Door op een ander veld, of nogmaals op het actieve veld te klikken klapt het paneel weer in. Ik heb voor de combinatie van tabs en een accordeonstructuur gekozen omdat het me toestaat de voordelen van beide patronen te benutten. Ten eerste zijn tabs overzichtelijk en flexibel. Ze groeperen op een duidelijke manier informatie en creëren diepte door het lagen-systeem dat ze uitdragen. Dit leidt tot een heldere affordantie voor de gebruiker, hij ziet namelijk welk veld focus heeft, en dat het actieve accordeonpaneel hier onderdeel van is. Doordat elk veld in principe als tab kan dienen kun je met één muisklik een schat aan informatie toegankelijk maken, zonder de gebruiker op voorhand te overspoelen met informatie die hij op dat moment niet nodig heeft. Het voordeel dat de accordeonstructuur is dat het de granulariteit van bepaalde informatie-chunks tijdelijk verhoogd, zonder dat het ten koste gaat van het totaaloverzicht. Er wordt immers extra ruimte gemaakt tussen de rijen, er vindt geen overlap plaats. Dit overlapprobleem zou wel het geval zijn als er gebruik gemaakt zou worden van verschillende schermen of pop-ups, waardoor de onderliggende informatie op dat moment ontoegankelijk wordt. Figuur 9 geeft de balans weer tussen overzicht en granulariteit bij een grid view en losstaande schermen. Met deze tabblad/acoordeonoplossing omzeil ik de afweging tussen overzicht en hoog detailniveau door het beste van beide werelden toe te passen. Het ontwerp van deze content element tabs zal ik nu per stuk toelichten. Per tab zal ik ook de ondersteunde taken opsommen. Figuur 9: De balans tussen overzicht en detailniveau bij een grid lay-out en losstaande schermen. 24

25 6.3. Status tab Ondersteunde taken: Product status controleren, -aanpassen. o Show flags beheren o Volledig verrijkt? Zo niet, het probleem vinden. o Commentaar plaatsen en lezen door PM en Content medewerkers. o Verschijnings-/reserveringsdatum aanpassen In de status tab vindt de gebruiker een overzicht van informatie over het product als geheel. Content status In de contentstatus groupbox vindt de gebruiker de status van het product wat betreft productinformatie. Het product is volledig verrijkt wanneer het voldoet aan de minimale eisen die hier aan verbonden zijn. Wat deze eisen precies zijn verschilt per productgroep, maar het komt er op neer dat een product moet beschikken over een afbeelding, een beschrijving, de nodige attributen en een verschijningsdatum. Deze eisen veranderen af en toe en zijn daarom in te stellen door de beheerder. In principe wordt automatisch herkend of een product volledig verrijkt is of niet. Maar het kan voorkomen dat een product handmatig op niet-volledig verrijkt moet worden gezet, omdat er bijvoorbeeld foutieve of onvolledige informatie bij een product staat. Figuur 10: Het statustabblad, met de onderdelen: Status van het product, verschijningsdatum, vindbaarheid, commentaar van werknemers bij het product, samenvatting. Release dates: In deze groupbox beheert men de verschijningsdatum, en de reserveringsdatum. De gebruiker kan een datum intypen in het datumveld of met de kalender-widget een datum selecteren. Show Flags: 25

26 Show flags bepalen de zichtbaarheid/vindbaarheid van een product. Wanneer een show flag op never wordt gezet, wordt het product op dat aspect onzichtbaar. Wanneer alle show flags op never worden gezet is het product niet meer te vinden op de site. Sommige producten moeten (tijdelijk) op never worden gezet omdat ze bijvoorbeeld niet in het assortiment thuis horen, of omdat ze dubbel in het systeem staan. Met de bovenste dropdown kunnen alle flags in één keer op never worden gezet, dit is in de meeste gevallen ook de bedoeling. Comments: In het huidige systeem bestaat er ook een mogelijkheid om producten van commentaar te voorzien voor interngebruik. Echter, dit attribuut wordt momenteel gebruikt om de content-status van het product weer te geven door de waarde volledig verrijkt aan te nemen. Elk commentaar wordt dus overschreven op het moment dat een product de status: volledig verrijkt krijgt. De nieuwe interface scheidt het attribuut volledig verrijkt en data entry comment, daarnaast is er nog een extra commentaarvoorziening voor product management bijgekomen. Met laatstgenoemde kunnen productmanagers op productniveau communiceren met het content-team. Dit heeft de volgende voordelen: Content medewerkers hebben een beter overzicht van openstaande verzoeken van PM. PM heeft direct kan zien wanneer een verzoek is afgehandeld. Er is voor beide partijen minder verkeer nodig. Communicatie op productniveau: het is dus niet meer nodig om eans op te zoeken en door te mailen. Een product manager voert een verzoekt in, in het PM comment-veld. De content medewerker ziet in zijn overzicht welke producten openstaande PM-comments hebben. De content-medewerker voert het verzoek uit en klikt de done checkbox aan. De productmanager krijgt bericht dat het verzoek afgehandeld is, en de openstaande PM-comment verdwijnt uit het productoverzicht van de content-medewerker. Wanneer de product manager opnieuw een verzoek wil plaatsen bij het product, kan hij de done checkbox uitvinken, en het commentaar overschrijven/aanvullen. Tenslotte is er nog bevat het status scherm nog een groupbox met algemene informatie over het product zoals voorraad, levertijd en een link naar het product op de website. Dit overzicht kan de beheerder aanpassen Packshot tab Ondersteunde taken: Packshot controleren, -toevoegen, -aanpassen, -kopiëren. Een packshot is misschien wel het meest belangrijkste content-element waar een product over kan beschikken. Een packshot is namelijk de eerste indruk die een klant krijgt van een product. Bovendien werk een afbeelding als een referentiepunt omdat een klant vooral scannend door de zoekresultaten heen leest. Afbeeldingen geven snel een complete indruk van het product. Het is daarom belangrijk dat een packshot upto-date is en duidelijk getoond wordt. Het duidelijk tonen doen we door de afbeelding zo goed mogelijk gebruik te laten maken van de beschikbare ruimte. Het wegsnijden van witranden is hierbij cruciaal. Veel afbeeldingen hebben witte ruimte aan de randen, door dit weg te halen komt de afbeelding effectief groter op de site. In het linker veld kan de gebruiker een afbeelding toevoegen via drag & drop uit een ander scherm of door hem te openen uit een bestand. Vervolgens kan de gebruiker de randen wegsnijden met de crop-functie. 26

27 Vanaf de randen van de afbeelding kan de gebruiker rulers inslepen tot aan waar de witrand afgesneden moet worden. Wanneer de vier rulers goed staan klikt de gebruiker op crop en de afbeelding word bijgesneden. Aan de rechterzijde wordt via een verticaal tab-menu versiebeheer beschikbaar gemaakt. Hiermee kan de gebruiker tijdelijke packshots aanstellen, dit is soms nodig voor acties waarbij de gebruiker bijvoorbeeld iets extra s krijgt, en dit opgenomen moet worden in de afbeelding. Gepaard aan de tijdelijke afbeelding gaat de periode waarin deze zichtbaar is (m.a.w. van wanneer tot wanneer deze afbeelding de standaard afbeelding overschrijft.) Figuur 11: Het packshot tabblad: Mogelijkheden om de hoofdproductafbeelding aan te passen en in te stellen Title tab Ondersteunde taken: Titel controleren, -aanpassen. Het titel tabblad behoeft geen verdere visuele ondersteuning. Het is niet meer dan een eenvoudige textbox waarin de gebruiker de huidige titel kan aanpassen naar een nieuwe titel. Toch is besloten er een apart tabblad van de maken, omdat het als losstaand content-element wordt gezien met een prominente rol Attributes tab Ondersteunde taken: Attributen controleren, -toevoegen, -aanpassen, -kopiëren. Dit tabblad geeft de gebruiker de mogelijkheid om productattributen te beheren. Linksboven kunnen nieuwe attributen worden toegevoegd, handmatig kun je een label selecteren, via de combobox en vervolgens een waarde invullen in het naastgelegen tekstveld. Beide controls zijn slim en geven indien mogelijk suggesties die aansluiten op wat de gebruiker typt. Type de gebruiker bijv. age dan zal het de het attribuut age rating als suggestie te zien zijn. Vervolgens wordt gecontroleerd of de ingevoerde waarde van het attribuut voldoet aan de richtlijnen voor dat attribuut. De manier van invoeren is afhankelijk van het attribuut, sommige attributen hebben een vast aantal mogelijke waarden (LoV). Deze worden beschikbaar gemaakt via een dropdown. Hierdoor hoeft de gebruiker de attribuutwaarde alleen te herkennen, en niet meer te herinneren. Hier moet echter wel een achterliggende laag voor zijn die slimme checks uitvoert op de invoerwaarden, die een groot aantal fouten in de attributen kunnen voorkomen. 27

28 Rechts van het invoergedeelte vind je het overzicht van de reeds gecreëerde attributen van het product. Verplichte attributen worden standaard getoond. Zo kan de gebruiker ze snel invoeren, zonder deze eerst toe te moeten voegen. Ook ziet hij op deze manier in het overzicht hoeveel van deze verplichte attributen niet ingevuld zijn. Wat deze verplichte attributen precies zijn is afhankelijk van de productgroep en dit is in handen van de beheerder (teamleider) back-end. Er zijn ook attributen die meerdere malen voor kunnen komen bij een product, zogenaamde multi-attributes. Door op het plusje achter een reeds toegevoegd attribuut te klikken wordt onder dit attribuut nogmaals hetzelfde attribuut aangemaakt, waarbij de gebruiker een andere waarde op kan geven. Dit zelfde is mogelijk via het invoerveld. Wanneer men een waarde ingevoerd heeft en op enter drukt, zal het label-dropdown weer focus krijgen, zodat door enkel de eerste letter in te typen, het volgende attribuut toegevoegd kan worden. Na het invoeren van een multi-attribuut kan de gebruiker ook shift+enter drukken. Na het toevoegen van de zojuist ingevoerde waarde zal de focus in attribuutwaarde veld blijven, opdat hetzelfde attribuut nogmaals toegevoegd kan worden. Redundante of conflicterende waarden zullen een duidelijke foutmelding generen, in het laatste geval met de vraag welk attribuut mag blijven (en impliciet welke dus verwijderd zal worden). Tenslotte laten sommige attributen achter het invoerveld de gevraagde eenheid zien. Dit voorkomt twee problemen. Ten eerste zal de gebruiker niet meer geneigd zijn naast de waarde, ook de eenheid in te voeren in het invoerveld. Hoewel dit ook met checks verholpen kan worden is het vooraf voorkomen eleganter. Het tweede potentiële probleem dat hiermee verholpen wordt is dat de gebruiker een verkeerde eenheid invoert. Bijvoorbeeld een waarde in cm in plaats van meter. Figuur 12: Attributentabblad: Gebruikers kunnen een variëteit aan attributen beheren, afhankelijk van het type product Description tab Ondersteund taken: Productbeschrijving controleren, -toevoegen, -aanpassen, -kopiëren. 28

29 Het tabblad voor het toevoegen en beheren van beschrijvingen komt grotendeels overeen met het tabblad voor packshots. Beiden hebben een verticaal tabblad systeem waarmee verschillende versies bijgehouden kunnen worden, mocht dit nodig zijn. (zie versiebeheer bij het packshot tab voor uitleg.) Slim tekstveld De gebruiker voert een beschrijving in, in de text area aan de rechterkant. Dit tekstveld toont veel overeenkomsten met de html-tool die nu gebruikt wordt voor het maken van teksten. Wat anders is, is dat de tekst er precies zo uit komt te zien als op de website. We spreken dus van een what-you-see-is-what-you-geteditor. Dit heeft als voordeel dat de gebruiker zelf niet meer met html-tags hoeft te puzzelen, of voor verassingen komt te staan met onvoorziene witregels of list-items die de huidige editor niet direct als zodanig laat zien. Naast de wysiwyg-functionaliteit beschikt de teksteditor ook over een spellcheck die controleert op spelfouten en rekening houdt met de bol-standaarden in taalgebruik. Denk hierbij aan een lijst van verboden woorden en controle op het vermijden van de u-vorm. Het doel van dit slimme tekstveld is om de gebruiker zoveel mogelijk werk uit handen te nemen, en om fouten te voorkomen. Controls De editor beschikt momenteel over drie controls om de ingevoerde teksten mee te bewerken. Regels kunnen bold gemaakt worden. Hiermee worden eigenlijk header-tags toegekent aan een regel tekst, maar dit uit zich voor de lezer als dikgedrukte tekst. Rechts van de bold-knop bevindt zich een list knop. Hiermee maakt de gebruiker op de plaats van de cursor een bullit (<ul><li> tekst </li></ul>.) Als de gebruiker een selectie heeft gemaakt terwijl hij op de list-knop drukt zal er van elke geselecteerde regel een list item gemaakt worden, net als in Micorosoft Word. De laatste control is een klein tekstveld waarin de gebruiker een productnaam kan plaatsen die veel terug komt in de tekst. Overal waar de gebruiker %% in de tekst typt, zal de opgegeven titel worden weergegeven. Hierdoor hoeft de gebruiker geen lange serienummers meer te onthouden, en het maakt het makkelijker om teksten te recyclen voor producten uit een (kleuren)serie. 29

30 Figuur 13: Description tabblad: De gebruiker kan de tekstuele beschrijving van het product beheren Party tab Ondersteund taken: Party s controleren, -toevoegen, -aanpassen, -kopiëren. Figuur 14 laat rechtsboven een tekstveld zien waarin de gebruiker de naam van een party (bijvoorbeeld een acteur) toe kan voegen aan een product. Tijdens het typen zoekt het systeem in de database naar records waarbij de ingetypte letters een substring vormen. Deze resultaten worden direct weegegeven als suggesties in een dropdown-menu onder het tekstveld. De gebruiker kan vervolgens stoppen met typen wanneer het systeem de juiste naam gevonden heeft. Vervolgens selecteert de gebruiker met de pijltjes toetsen, of de muis de juiste naam, meestal de bovenste suggestie. Het zoeken vindt zowel plaats op voornaam als achternaam, omdat de gebruikers soms de voornaam niet weet. 30

31 Figuur 14: Het slim zoeken en creëren van een nieuwe party Daarnaast wordt er geen onderscheid gemaakt in hoofdletters en accenten. Het komt voor dat de gebruiker een naam intypt die het systeem niet herkent, dit verschilt echter erg per productgroep. Op dat moment kan de gebruiker er voor kiezen een nieuw record aan te maken op deze naam. Belangrijk is hierbij dat er gelet wordt op typfouten, daarom wordt de gebruiker middels een pop-up uitdrukkelijk gevraagd of er een nieuw record gecreëerd moet worden. In dit geval weegt het voorkomen van updateanomalieën in de database meer dan het behalen van de meest efficiënte werkwijze van de gebruiker. Momenteel lijdt de database namelijk aanzienlijk onder redundantie doordat allerlei partijen meerdere keren voorkomen in de database, vaak onder een net wat andere naam. Bijvoorbeeld: Annie M.G. Schmidt, A. M. G. Schmidt of Annie Schmidt komen alle drie voor in de database. Het aanmaken van dubbele partijen moet dus worden voorkomen. Om te voorkomen dat er onbedoeld een reeds bestaande rogue-party geselecteerd wordt staat er achteraan de suggestieregel het aantal producten waaraan de betreffende partij gekoppeld staat. Hieraan herkent de gebruiker snel de echte partij. Een ander voorbeeld waarbij deze indexering nuttig kan zijn, is wanneer er werkelijk sprake is van een dubbele naam. Er zijn bijvoorbeeld meerdere M. Jacksons. De bekende popartiest kan dan vrij snel herkend worden aan het aantal producten dat hij op zijn naam heeft staan, in vergelijking met de andere, relatief onbekende M. Jackson. Suggesties voor het anders inrichten van de database vallen eigenlijk buiten de scope van dit onderzoek. Maar omdat de interface en gebruikerservaring uiteindelijk onlosmakelijk verbonden zijn met de manier waarop de data vormgegeven is, zie ik hier toch reden op in te gaan. Het selecteren van de juiste party wordt momenteel moeilijk gemaakt doordat er te weinig onderscheidende criteria naar voren komen. Zo kunnen vrijwel alle updateanomalieën voorkomen worden door naast de naam, een extra kenmerk te tonen, zoals geboortedatum. 31

32 Figuur 15: Party tabblad: geeft de mogelijkheid om alle betrokken partijen van ene product toe te voegen. Zoals: auteurs, acteurs, uitgevers of ontwikkelaars Stills tab Ondersteund taken: Stills controleren, -toevoegen, -aanpassen, -kopiëren en -rangschikken. Stills zijn extra afbeeldingen die de klant meer inzicht geven in het uiterlijk, of inhoud van het product. Een still is dus niet het zelfde als een packshot. Stills komen op verschillende manier tot uiting, afhankelijk van de productgroep. Bij elektronica worden afbeelding gebruikt waarop het product van verschillende kanten te zien is. Bij games krijgt de klant screenshots te zien, en bij boeken zijn er een aantal inkijkpagina s beschikbaar. Toch kunnen deze verschillende type afbeeldingen op een generieke manier beheert worden. In de stills tab kan de gebruiker aan de rechterzijde nieuwe stills toevoegen aan een product. De stills kunnen middels drag & drop uit een browser worden geïmporteerd, of handmatig met de browse knop worden opgezocht. Ook is de crop functionaliteit beschikbaar zoals bij packshots, om witranden of onnodige delen van de afbeelding te verwijderen. Als de gebruiker op de add still knop drukt wordt de afbeelding aan de collectie toegevoegd, aan de linkerzijde van het scherm. Deze collectie kan eenvoudig worden bewerkt. De volgorde kan worden bepaald door drag & drop. Er kunnen meerdere afbeelding tegelijk verwijderd worden, of naar een ander product worden geëxporteerd. Ook kan de gebruiker een still uit de collectie terugslepen naar de rechter editor, en deze vervolgens alsnog bijsnijden. Figuur 16 geeft de uiteindelijkse stills tab van het prototype weer. 32

33 Figuur 16: Stills tab: Met deze tab worden extra afbeeldingen van een product bewerkt en beheerd Category tab Ondersteund taken: Categorieën controleren, -toevoegen, -aanpassen, -kopiëren. Met de categorie tab kunnen gebruikers de categorieën beheren waaronder een product geschaard staat. Een product moet minimaal één categorie hebben om zichtbaar te zijn op de website. Voor de meeste productgroepen is het wenselijk dat het ook bij één categorie blijft, echter het is mogelijk dat er meerdere toegevoegd worden. De categorie structuur is opgedeeld in hoofdcategorieën en subcategorieën. De gebruiker kan een categorie toevoegen door deze samen te stellen met behulp van twee comboboxen. Met de eerste kiest de gebruiker een hoofdcategorie en met de tweede een subcategorie. Als een categorie is toegevoegd is deze vervolgens aan de rechterzijde zichtbaar, hier kunnen eventueel nog aanpassingen worden gedaan. Alle categorieën kunnen worden geëxporteerd naar een ander product. Ook kunnen categorieën van een ander product overgenomen met de import knop worden. 33

34 Figuur 17: Categorieëntabblad: Met dit tabbad beheren gebruikers de categorieën waaronder een product valt Tracklist tab Ondersteund taken: Tracklist controleren, -toevoegen, -aanpassen, -kopiëren. 34

35 Figuur 18: Overzichtscherm van een cd Artist en Track Title Afbeelding 18 geeft de overzichtstabel weer die de gebruiker te zien krijgt wanneer hij een track list wil toevoegen aan een muziekproduct. Een tracklist geeft een overzicht van de nummers die te op de cd, muziekdvd, LP, etc. staan. De tabel is opgedeeld in vier kolommen, waarvan de eerste twee (artiest en titel) het meest belangrijk zijn. Bij een album van een specifieke artiest wordt de artiesten kolom leeg gelaten. De naam van de artiest komt voor de naam van het nummer. Echter, deze informatie wordt niet altijd zo aangeleverd. De gebruiker krijgt bijvoorbeeld ook track lists aangeleverd in het format: <tracknaam> - <artiest> [track length]. Het systeem zal zelf herkennen wel stukje data, de track length is, maar onderscheid maken tussen artiest en tracknaam is niet op een consistente manier mogelijk. Daarom moet het de gebruiker zo makkelijk 35

36 mogelijk gemaakt worden om zelf wijzigingen te maken in de lay-out van de tracklist. In figuur 19 zie je hoe de gebruiker meerdere cellen met informatie door te selecteren en slepen kan verwisselen. Figuur 19: De kolom artist en trackname zijn verwisseld op cd1. De gebuiker selecteert de verkeerd geplaatste titels en wisselt deze, middels drag & drop, om met de artiestnamen. 36

37 6.12. Bulk data hanteren Ondersteund taken: Voor meerdere producten tegelijk controleren, -toevoegen, -aanpassen, -kopiëren. Figuur 18: Bulk data importeren: Gebruikers kunnen data vanuit gestructureerde tabelvorm (zoals:.txt.xls.csv, etc.) importeren naar de database Dashboard Het dashboardscherm geen niet directe taken, maar biedt op een handige manier overzichten van informatie die gebruikers normaliter handmatig tot stand moesten brengen. Zoals overzichten van het aantal verrijkte producten. Ook kan de gebruiker op het dashboardscherm direct overzichten opvragen met vaakgebruikte, persoonlijke filters. 37

38 Figuur 19: Het dashboard geeft gebruikers een gepersonaliseerd overzicht m.b.t. de status van hun taken, doelen en vaakgebruikte filters Evaluatie van het prototype Aan het eind van de methode-sectie (1.3) werd kort de rol van gebruikerstest aangeduid. Gebruikerstests vormen de basis van de iteratieve aard van het ontwerpprocess van het protoype. Telkens wanneer ik als systeemontwerper een aantal aanpassing verwerkt had in het prototype, zijn deze aanpassingen direct getest op gebruikers. Voornamelijk door hen relevante scenario s (appendix 9.2) te laten doorlopen. Daarnaast heb ik hun indrukken van deze aanpassingen met hen besproken. Nadat na meerdere iteraties van een prototype-onderdeel alle relevante scenario s naar behoren ondersteund worden, is een afsluitende test gedaan waarin de gebruiker aangaf het prototype onderdeel als compleet te beschouwen. Er is geen kwantitatieve testsessie geweest ter afronding van het onderzoek. Omdat, door de grote variatie in onbekende factoren, eventuele kwantitatieve resultaten van gebruikerstests van het prototype niet te vergelijken zijn met die van een operationeel systeem en dus weinig waardevolle informatie opleveren over bijvoorbeeld de daadwerkelijke snelheidswinst die behaald wordt. 7. Discussie en Conclusie In dit onderzoek ben ik opzoek gegaan naar een antwoord op de vraag: hoe ziet de ideale contentverrijkapplicatie voor bol.com er uit? Het antwoord op deze vraag heb ik in de vorige sectie uitgedrukt in de vorm van een prototype. Het ontwerp van dit prototype is gebaseerd op bevindingen die naar voren zijn 38