juni 2009

maandag 15 juni 2009

Kosten/Baten Analyse

Door Edwin

Home > Methodologie > Fusion Usability Recept > Business Context > Kosten/Baten Analyse

Fusion Usability Recept Fase

Business Context

Gebruikers Context

Gebruikers Ervaring

Installatie

Doel

Er zijn minstens 2 redenen om een Kosten/Baten Analyse uit te voeren voor een Usability Project Plan:

Om Usability Engineering te verkopen in het algemeen.
Om te assisteren bij het plannen van een bepaald project.

Een Kosten/Baten Analyse van de usability engineering inspanningen kunnen beschouwd worden als een strategie om algemene ondersteuning te verkrijgen om Usability Engineering technieken uit te proberen in een organisatie. Wanneer een bedrijf geen ervaring heeft met Usability Engineering dan kunnen Kosten/Baten Analyses helpen bij het verkrijgen van middelen om er mee te experimenteren. Bij bedrijven die wel ervaring hebben met Usability Engineering worden Kosten/Baten Analyses gebruikt ter ondersteuning van de usability inspanningen van een bepaald project.

Je start met uit te rekenen wat de kosten zijn van alle Fusion Usability Recept taken (inclusief de meest rigoureuze procedures ) die je wil implementeren. Daarna berekenen je een conservatieve schatting van de voordelen. Wanneer de baten de kosten dramatisch overklassen, wat ze meestal wel doen wanneer alle cruciale parameters zijn mee opgenomen, dan kan je vrij eenvoudig goede argumenten aanhalen voor zelfs het meest agressieve Usability Project Plan. Omdat enkel de meest conservatieve voordelen betreffende de baten zijn gebruikt, kan je deze dan ook gemakkelijk verdedigen. In feite kan je uw werk betreffende de baten herhalen, maar deze keer gebruik je een meer optimistische (maar nog altijd realistische) veronderstelling. Hiermee geef je aan dat wanneer alles mee zit, de voordelen nog meer zullen doorwegen.

Wanneer de kosten en baten eerder in evenwicht zijn, dan zal je het initiële idee, het gebruiken van een agressief Usability Project Plan, moeten laten varen. Herbekijk dan welke taken echt nodig zijn en misschien moet je minder intensieve Fusion Usability Procedures gebruiken of minder iteraties uitvoeren.

Je kan bijvoorbeeld interviews gebruiken in plaats van een enquête bij het opmaken van een Gebruikers Profiel. Of je kan minder tijd spenderen aan het onderzoeken van de gebruikers tijdens het opmaken van het Taak Profiel. Misschien moet je minder intensief (of anders) testen tijdens het aanmaken van de prototypes. Door de kosten naar beneden te brengen, kan je eventueel de nog steeds conservatieve inschattingen qua baten overklassen. Op die manier kan je met vertrouwen een gezonde Return On Investment (ROI) voorspellen. Echter, wanneer je minder usability taken gebruikt, ze minder intensief uitvoert of minder iteraties verricht dan is het aannemelijk te stellen dat ook de voordelen zullen dalen. Wees kritisch en herbekijk de vooropgestelde baten.

Deze aanpak is op lange termijn waarschijnlijk meer doordacht dan het maken van buitensporige optimistische prognoses wat betreft de baten, er tevens veel inspanningen voor willen doen om deze te bereiken en deze dan misschien niet behalen en zo alle krediet verliezen.

Omschrijving

De kosten en baten kan je dus verantwoorden met een generische en algemeen aanvaarde Kosten/Baten Analyse techniek. Om de kosten te berekenen dien je dus een gedetailleerd Usability Project Plan te ontwerpen . Daarna ga je dus de baten berekenen, wat een heel stuk moeilijker is. Kijk na wat de voordelen kunnen zijn voor je project en hoe deze zich kunnen vertalen in effectieve baten.

Concreet kan je bijvoorbeeld de volgende zaken in overweging nemen:

Het aantal unieke bezoekers naar een site.
Het aantal terugkerende bezoekers naar een site
De conversie van een E-commerce site en de diepte van het winkelkarretje
De gemiddelde conversieratio in de branche
Omzet en winst via de website
De productiviteit van de gebruikers
Het aantal fouten van gebruikers en de gecorreleerde kosten.
De kosten voor het ontwikkelen van de applicatie
Onderhoudskosten nadat de applicatie is afgeleverd
De kosten voor ondersteuning en helpdesk
Kosten voor training en handleidingen
...

Niet al deze zaken zijn relevant voor elk type project. Ook kan het best zijn dat andere dingen kunnen bekeken worden. Het hangt af van de business doelen en de belangrijkste verwachtingen van de gebruikers.

Managers zullen dus moeten beslissen of ze al of niet zullen investeren. Ze gebruiken daarbij verschillende ratio’s om een investering te beoordelen:

Ratio	Formule
Winst Groei	Winst Groei = Toekomstige winst – Huidige winst
Return On Investment of ROI	ROI = (Winst Groei x 100) / Usability Kosten Het resultaat is een percentage dat vergeleken kan worden met markrentevoeten van andere alternatieve beleggingen.
Pay-back of PB	PB = Usability Kosten / Winst Groei x 365 dagen Geeft het aantal dagen weer waarna de investering terug is verdiend.

Er zijn nog andere ratio’s zoals Net Present Value, Internal Rate of Return, Discounted Pay-back, maar de formules in voorgaande tabel zullen doorgaans voldoende zijn om een goede kosten/baten analyse te stofferen voor een Usability Project Plan.

Voor een E-commerce site kunnen we toekomstige omzetten en winsten berekenen. We kunnen hiervoor de volgende parameters gebruiken:

Bezoekers

B	Aantal huidige bezoekers van de website per jaar
Bfut	Toekomstige aantal bezoekers van de website per jaar of B + percentage toename verkeer (doorgaans 20% of meer)

Conversie Ratio

Dit is het percentage bezoekers van een website die effectief tot een aankoop overgaat

CR	Huidig Conversie Ratio
BCR	Conversie Ratio van een bepaalde branche (bv. gegevens van Fireclick Index)
CRfut	De toekomstige Conversie Ratio kan men beramen door een vergelijking te maken tussen deze 2 cijfers (CR en BCR). Een website met een hoog usability gehalte zal doorgaans een hogere ratio hebben als het gemiddelde van een bepaalde branche. Wanneer de huidige Conversie Ratio veel lager ligt dan het landelijk gemiddelde, dan kan men een conservatieve inschatting toepassen die ergens tussen beide ligt. Toekomstige Conversie Ratio of BCR + 10% of een cijfer tussen CR en BCR

Omzet en Winst

GO	Gemiddelde huidige omzet per klant
GW	Gemiddelde huidige winst per klant
TO	Totale huidige omzet via website
TW	Totale huidige winst via website Gebruiksvriendelijke sites stralen meer vertrouwen uit, zijn plezieriger te gebruiken en gebruikers vinden gemakkelijker wat ze zoeken. Hierdoor komen ze eerder terug en besteden ze ook meer. Conservatief bekeken is een stijging van de winst en omzet met 15% doorgaans gemakkelijk haalbaar.
GOfut	Toekomstige Omzet per klant of GO + 15%
GWfut	Toekomstige Winst per klant of GW + 15%
TOfut	Toekomstige Totale Omzet of Bfut x CRfut x GOfut
TWfut	Toekomstige Totale Winst of Bfut x CRfut x GWfut

Voorbeeld:

Een site heeft 10.000 bezoekers per jaar met een huidige conversie ratio van 1%, het gemiddelde voor deze branche is 2%. Klanten besteden gemiddeld 50 €, wat in een winst resulteert van 32 €.

Bezoekers
B = 10.000 (Huidige bezoekers aantallen per jaar) Bfut = 10.000 + 2.000 = 12.000 (Toekomstige bezoekers aantallen per jaar)

Conversie Ratio
CR = 1% (Huidige Conversie Ratio) BCR = 2% (Gemiddelde landelijke Conversie Ratio voor de branche) We gaan uit van een conservatieve inschatting van 1,5% voor de nieuwe site: CRfut = 1,5% (Toekomstige Conversie Ratio)

Omzet & Winst

GO = 50 € (Huidige Omzet per klant)
GW = 32 € (Huidige Winst per klant)

GOfut = 50 € + 7,5 € = 57,5 € (Toekomstige Omzet per klant)
GWfut = 32 € + 4,8 € = 36,8 € (Toekomstige Winst per klant)

TO = 5.000 € (Huidige Totale Omzet)

TW = 3.200 € (Huidige Totale Winst)

TOfut = Bfut x CRfut x GOfut of 12.000 x 1,5% x 57,5 € = 10.350 € (Totale Toekomstige Omzet)

TWfut = Bfut x CRfut x GWfut of 12.000 x 1,5% x 36,8 € = 6.624 € (Totale Toekomstige Winst)

Stel dat de kosten voor de nodige usability werken beraamd zijn op 5.000 € dan kunnen we de volgende ratio’s berekenen:

Ratio’s
Winst Groei = TWfut – TW Winst Groei = 6.624 € - 3.200 € = 3.424 € ROI = (Winst Groei x 100) / Usability Kosten ROI = (3.424 € x 100) / 5.000 € = 68,48% Pay-back = Usability Kosten / Winst Groei x 365 dagen Pay-back = 5.000 € / 3.424 € x 365 dagen = 533 dagen of 1 jaar, 5 maanden en 18 dagen

Conclusie

De ROI in dit voorbeeld is relatief hoog (68,48%), maar voor een usability project niet zo uitzonderlijk. Verschillende bronnen rapporteren dat het gemiddelde hedendaagse usability project een ROI heeft van om en bij de 80% a 90%. Merk op dat dit een stuk lager is dan pakweg 10 jaar geleden.

De Pay-back (533 dagen) lijkt niet zo gunstig, doch een website heeft een minimum levensduur van 3 jaar en langer (een Google of Amazon hebben al meer dan 10 jaar dezelfde look and feel).

Bovendien gaan we in dit voorbeeld uit van een conservatieve prognose. In werkelijkheid zal het resultaat wellicht nog beter mee vallen. Het is niet ondenkbaar dat de Conversie Ratio opschuift naar het landelijk gemiddelde voor deze branche en misschien deze zelfs overstijgt. Ook zal het aantal bezoekers na het eerste jaar nog wat stijgen. De bonus aan tevreden gebruikers in het eerste jaar zullen mede zorgen voor meer mond aan mond reclame en hierdoor de bezoekersaantallen wellicht nog doen opkrikken.

De nieuwe gebruiksvriendelijke site zal ook opgemerkt worden door de media (pers, branche literatuur, internet, …) en door een positieve setting allicht ook extra bezoekers aantrekken.

Deze kleine E-commerce site kan zijn marktaandeel meer dan verdubbelen na 1 jaar en dit met een conservatieve prognose. De usability investering zou een gezonde investering zijn en zal wellicht groen licht krijgen van de klant.

Er zijn nog andere manieren om de kosten voor een usability project te verantwoorden. Deborah J. Mayhew beschrijft bijvoorbeeld welke enorme impact het sneller verwerken van gegevens kan hebben.

Ze gebruikt hiervoor een voorbeeld van een applicatie waarbij 250 gebruikers in een bedrijf een 60tal schermen verwerken per dag en dit 230 werkdagen per jaar aan een brutoloon van 25 € per uur. Als we veronderstellen dat de verwerking van elk scherm 1 seconde sneller kan gebeuren dan kunnen we eenvoudig de baten hiervan berekenen:

250 gebruikers x 230 dagen x 60 schermen x 1/3600 uren x 25 € = 23.958 € in het eerste jaar.

Dit type applicaties wordt doorgaans meerdere jaren gebruikt waardoor de baten nog hoger oplopen. De snellere verwerking heeft nog andere indirecte voordelen: gebruikers hebben minder het gevoel dat ze onzinnige taken uitvoeren, waardoor absenteïsme en personeelsverloop daalt en tegelijkertijd hun motivatie stijgt. Ook dat heeft een financiële impact.

De 'seconde van Mayhew' kan uiteraard niet overal gebruikt worden. Er moeten relatief veel gebruikers zijn die de applicatie veel gebruiken. Trouwens deze ene seconde is een extreem lage conservatieve schatting, doorgaans kan men na een usability kuur de productiviteit met 20% verhogen (en meer). Wellicht kunnen er dus ook voor kleinere gebruikerspopulaties significante voordelen op dit vlak gerealiseerd worden.

Kosten/baten analyses voer je niet noodzakelijk uit enkel aan het begin van een project. Het kan gebeuren dat bijvoorbeeld na (of tijdens) het opstellen van de diverse gebruikers, taak en omgeving profielen je bepaalde inzichten hebt die niet bekend waren aan het begin van het project. Je kan dan nieuwe kosten/baten analyses uitvoeren, deze voorleggen aan de stakeholders en op die manier eventueel meer budget en tijd voor usability disciplines verkrijgen.

Procedures

Fusion Usability Recept Fase

Business Context

Gebruikers Context

Gebruikers Ervaring

Installatie

Bekijk Ook:

Overzicht

Usability Project Planning
Kosten/Baten Analyse
Visie
Glossarium

Video

De ROI van Usability

Vond je dit artikel interessant? Doe dan het volgende:

Plaats een reactie
Volg Usability Vlaanderen op Facebook of Twitter
Schrijf je in op de E-mail nieuwsbrief of RSS feed
Deel dit artikel met vrienden en collega's

maandag 8 juni 2009

Conceptueel Model

Door Edwin

Home > Methodologie > Fusion Usability Recept > Gebruikers Ervaring > Conceptueel Model

Fusion Usability Recept Fase

Business Context

Gebruikers Context

Gebruikers Ervaring

Installatie

Doel

Het ontwikkelen van de eigenlijke gebruikersinterface (de Gebruikers Ervaring dus) kan uitgesplitst worden in drie niveaus:

Conceptueel Model	Het ontwikkelen van high-level presentatie regels, gebaseerd op de use case modellen van de Reëngineering taak.
Basis Prototype	Het ontwikkelen van de low-level regels voor de gebruikersinterface.
Gedetailleerd Prototype	In deze taak wordt de volledige interface ontworpen, gebaseerd op de regels gegenereerd, verfijnd en gevalideerd in de vorige 2 niveaus.

De gereëngineerde use case modellen, aangemaakt in de vorige Reëngineering taak, dienen als basis voor het ontwikkelen van de gebruikersinterface. Het bevat de onderliggende structuur en organisatie van de volledige gebruikersinterface architectuur. Het Conceptueel Model en het basis prototype bevatten een aantal conventies gerelateerd met deze structuur, welke dan weer de “look and feel” van het gedetailleerde prototype bepalen.

Het is enorm belangrijk om de gereëngineerde use case modellen goed te modelleren en dit af te zonderen van de ontwikkeling van het Conceptueel Model. Dit maakt het globale ontwikkelproces eenvoudiger en zorgt voor een scheiding tussen organisatie en presentatie.

De use case modellen zijn onafhankelijk t.o.v. enige gebruikersinterface aanpak, terwijl je van een Conceptueel Model een bepaalde visuele en interactie stijl mag verwachten die specificeert hoe de componenten de onderliggende use case modellen presenteert.

Het doel van het Conceptueel Model is het definiëren van een coherent, op regels gebaseerd raamwerk welke voorziet in een algemene fundering voor alle toekomstige ontwikkel beslissingen.

Mensen die een interactief systeem gebruiken hebben de neiging om te zoeken naar zo’n gegeneraliseerd model – een serie regels dat hun toelaat om de volledige complexiteit van een product te reduceren naar een kleinere hoeveelheid te verwerken informatie, dit om het eenvoudiger te leren begrijpen.

Dit Mentaal Model helpt mensen om:

Het product sneller aan te leren
Het meer efficiënt en effectief te gebruiken
Om het gedrag van de software te voorspellen in vergelijkbare omstandigheden

Een goed uitgewerkt Conceptueel Model vereenvoudigd het aanmaken van een goed mentaal model door gebruik te maken van de manier waarop mensen doorgaans denken, redeneren en leren.

Omschrijving

Om te begrijpen hoe je een goed Conceptueel Model ontwerpt, dien je eerst te weten wat de algemene inzichten zijn over het Mentaal Model.

Hoe kunnen we een Conceptueel Model ontwerpen?

Alhoewel er weinig research is uitgevoerd over de impact van Conceptuele Modellen, kunnen we toch enkele vuistregels meegeven:

Ontwerp het Conceptueel Model op zo’n manier dat het de ontwikkeling van een effectief en efficiënt mentaal model ondersteunt.

Hou rekening met de mentale modellen die gebruikers willen meenemen naar een nieuw systeem.

Een Conceptueel Model zou expliciet ontworpen en effectief gepresenteerd moeten worden via de gebruikersinterface.

Het geplande Conceptueel Model zou moeten anticiperen op de verwachting van de gebruikers en geen reflectie horen te zijn van de ontwerpers hun kennis en hun specifieke mentale modellen.

Maak onzichtbare delen en processen van het systeem zichtbaar.`

Ontwerp het Conceptueel Model consistent.

Ontwerp het Conceptueel Model op zo’n manier dat het maximaal put uit reële kennis en ervaring en dat het minimaal een beroep doet op abstract en logische denken.

Voorzie in consistente, ondubbelzinnige, concrete en informatieve feedback, dit om het Conceptueel Model te versterken.

Vermijd irrelevante en misleidende feedback, die een afleiding vormt voor het Conceptueel Model en een hindernis is voor de ontwikkeling van een optimaal mentaal model.

Gebruik namen, labels en een terminologie die consistent is met het Conceptueel Model.

Een Conceptueel Model dat is gebaseerd op een vertrouwd metafoor, zou consistent dit metafoor zo veel mogelijk moeten ondersteunen, zonder kracht en efficiëntie op te offeren en het mag tevens niet misleidend zijn.

Ondersteun, via het Conceptueel Model, de ontwikkeling van mentale modellen van zowel beginnende als gevorderde gebruikers.

Het ontwerp van het Conceptueel Model, welke de eerste stap is in de ontwikkeling van de feitelijke gebruikersinterface, beschouwen we als het hoogste niveau in de ontwikkeling van een gebruikersinterface.

We zullen dus beslissingen moeten maken zo als:

Zal het Conceptueel Model een product- of een proces oriëntatie krijgen?
Hoe gaan we deze producten en processen definiëren?
Hoe gaan we deze presenteren?
Welke regels gaan we volgen voor het gebruik van de verschillende vensters?
Hoe gaan we de belangrijkste schermen definiëren en de navigatie methodes tussen deze?
Welke functionaliteit gaan we modelleren?

Het Conceptueel Model zal gebaseerd zijn op de organisatie van de functionaliteit zoals gepresenteerd in de gereëngineerde use case modellen, maar ook van alle informatie gegenereerd tijdens de Gebruikers Context fase. Initieel zal je nu starten met een iteratief proces van ontwerp en evaluatie om teneinde het definitieve Conceptueel Model vast te leggen.

Je zal diverse concepten modelleren, welke later het onderwerp zullen zijn van een objectieve evaluatie. Je eerste Conceptuele Modellen zullen gebaseerd zijn op kleine, representatieve delen van de totale functionaliteit. Ook zal je de grote lijnen moeten vastleggen van de presentatie en navigatie methodes. Er zal maar weinig, zelfs geen, echte inhoud zichtbaar zijn op de schermen. Op dit punt is de invulling en lay-out nog niet belangrijk.

Het eigenlijke Conceptueel Model kan je maken op 2 manieren:

Via een serie tekeningen op papier (low-fidelity)
Via een prototype tool of bijvoorbeeld de .NET IDE (high-fidelity)

Beide soorten prototypes hebben hun voor- en nadelen.

Voorbeeld Conceptueel Model

Dit is het conceptueel model van een scherm zoals gebruikt in een software programma dat medische printers test. Zoals je ziet is er nauwelijks detail zichtbaar. De grijze zones zijn manipuleerbaar (klikken met muis, iets intikken, etc...) door de gebruiker. Op die manier kon o.a. de ruwe werking en de navigatie naar andere schermen getest worden.

Wanneer de gebruiker op Bestanden klikt in het menu, dan krijgt hij dit te zien:

Procedures

Fusion Usability Recept Fase

Business Context

Gebruikers Context

Gebruikers Ervaring

Installatie

Bekijk ook:

Overzicht

Conceptueel Model
Basis Prototype
Gedetailleerd Prototype
Usability Evaluatie (in voorbereiding)

Vond je dit artikel interessant? Doe dan het volgende:

Plaats een reactie
Volg Usability Vlaanderen op Facebook of Twitter
Schrijf je in op de E-mail nieuwsbrief of RSS feed
Deel dit artikel met vrienden en collega's

Information R/evolution

Door Edwin

Home > Video's > Information R/evolution

Vinden, bewaren, creëren, kritiek uiten en informatie delen hebben we altijd al gedaan, maar de laatste jaren is dit drastisch veranderd. Deze video neemt je mee op een verkenningstocht naar die veranderingen.

Oorspronkelijk is deze leuke video gemaakt om het ijs te breken tijdens een brainstorm sessie over de nabije toekomst waarbij bijzondere vaardigheden nodig zijn om efficiënt informatie te vinden, evalueren en aan te maken.

Bekijk Ook:

Andere video's

Vond je dit artikel interessant? Doe dan het volgende:

Plaats een reactie
Volg Usability Vlaanderen op Facebook of Twitter
Schrijf je in op de E-mail nieuwsbrief of RSS feed
Deel dit artikel met vrienden en collega's

donderdag 4 juni 2009

Reëngineering

Door Edwin

Home > Methodologie > Fusion Usability Recept > Gebruikers Context > Reëngineering

Fusion Usability Recept Fase

Business Context

Gebruikers Context

Gebruikers Ervaring

Installatie

Doel

In het Taak Profiel heb je diverse modellen geconstrueerd die uitbeelden hoe gebruikers momenteel denken en praten over hun taken. In deze fase zul je dan ook deze modellen gaan reëngineren en dit om de volgende doelen te bereiken:

Het realiseren van kracht en efficiëntie die automatisering mogelijk maken.

Het herbewerken van werkprocessen om de usability doelen beter en effectiever te ondersteunen.

Het minimaliseren van training, door gebruik te maken van de latente kennis over hun taak en het maximaliseren van de efficiëntie en effectiviteit door rekening te houden met de menselijke cognitieve beperkingen en mogelijkheden, binnen de context van hun taak.

Wanneer je bent aangekomen in deze fase van het Fusion Usability Recept, dan heb je niet alleen een duidelijk beeld over hoe gebruikers denken en hoe ze hun taak invullen, je hebt ook inzicht verwerft over hoe de gebruiker en zijn werkomgeving de usability vereisten sturen.

Je kan dus het derde doel (uit bovenstaand lijstje) beter gaan verenigen met de eerste twee doelen.

Je start met het Use Case Model, de Specificaties en het Organisatie Model te bestuderen en verbeteringen aan te brengen die enkel en alleen de eerste 2 doelen ondersteunen. Hierdoor zul je dus de Use Case Specificaties en zijn bovenliggende Modellen hebben gereëngineerd. Deze vormen op hun beurt dan de basis voor het ontwerp van de feitelijke gebruikersinterfaces.

Omschrijving

De Reënginering taak bestaat uit de volgende drie basis stappen:

Reëngineering van het Use Case Model, Use Case Specificaties en Use Case Organisatie Model
Valideren en verfijnen Use Case Model, Use Case Specificaties en Use Case Organisatie Model
Documenteer reëngineerde Use Case Model, Use Case Specificaties en Use Case Organisatie Model

Je reëngineert de huidige Use Case documenten met als expliciete doelen kracht en efficiëntie te realiseren om automatisering mogelijk te maken en het herbewerken van werkprocessen om de usability taken beter te ondersteunen. Je voert enkel veranderingen en verbeteringen uit die deze 2 doelen ondersteunen, op die manier zal je automatisch alle drie de doelen, zoals hoger vermeld, bereiken.

Daarna laat je de reegineerde Use Case documenten valideren door de gebruikers en verfijn je deze indien nodig.

Tenslotte documenteer je alle verbeteringen, zodat ze als basis kunnen dienen voor het creëren van de Gebruikers Ervaring.

Procedures

Fusion Usability Recept Fase

Business Context

Gebruikers Context

Gebruikers Ervaring

Installatie

Bekijk ook:

Overzicht

Vond je dit artikel interessant? Doe dan het volgende:

Plaats een reactie
Volg Usability Vlaanderen op Facebook of Twitter
Schrijf je in op de E-mail nieuwsbrief of RSS feed
Deel dit artikel met vrienden en collega's

woensdag 3 juni 2009

Test: Microsoft Bing, de decision engine

Door Edwin

Home > Nieuws > Test: Microsoft Bing, de decision engine

Where do you want to Bing today?

Het nieuwe search engine kindje van Microsoft heet Bing en is vanaf vandaag online. Het betreft een beta versie, waarbij de inwoners van de Verenigde Staten iets meer functionaliteit mogen gebruiken dan de rest van de wereld. De aanpassingen voor de locale markt zijn een hels karwei en voor Vlaanderen zullen we nog moeten wachten tot het einde van het jaar.

Bij Microsoft zouden ze graag hebben dat we Bing als een decision engine aanzien en niet als een search engine, wat uiteraard het onvermijdbare marketing gewauwel is.

Kan Microsoft de hegemonie van Google verstoren ?

Dat valt nog af te wachten, het is te vroeg. Het product is nog niet officieel gelanceerd en dat is er een beetje aan te merken.

Bijvoorbeeld de zelfverklaarde decision engine Bing heeft het niet zo voor zoekopdrachten opgesteld in een natuurlijke taal. Een simpele vraag zoals ‘What’s the time in Antwerp?’ zal je doorverwijzen naar sites die je het vertellen in plaats van zelf het antwoord te geven.

De synchronisatie met andere Microsoft sites en producten is nog niet klaar: de map button brengt je naar een lege pagina, terwijl Multimap wel in de lucht hangt. De MSN site doet alsof Live Search nog wel bestaat, maar de zoekresultaten verschijnen wel in Bing. Het is natuurlijk een beta versie en men mag verwachten dat dit soort kinderziekten er straks wel uit zijn.

De lay-out is wel goed aangepakt, het heeft ten dele de sobere minimalistische design visie van Google overgenomen. Op de hoofdpagina staat enkel het noodzakelijke en de achtergrond tekening zou elke dag moeten wijzigen. De zoekresultaten verschijnen zeer snel op je scherm, doch op een andere manier dan je doorgaans gewend bent van Google. Bijvoorbeeld links naar Wikipedia staan niet in de hoogste regionen zoals bij Google, wat toch even aanpassen is.

Bing wil dat we minder muisklikken gaan maken en voor dit doeleind kan je met de muiscursor zweven boven items en video’s om een preview te bekijken. Dit werkt heel mooi en goed. Hierdoor zorgt Microsoft dat we langer op de Bing site blijven en dit doen ze nog op een andere manier door links aan te bieden die in verband staan met het gezochte onderwerp. Een zoekopdracht naar een bepaald (voorlopig alleen Amerikaans) bedrijf kan je uitfilteren op winkellocaties, werkaanbiedingen, promoties en dergelijke en dit zonder de Bing site te verlaten.

Conclusie

Bing is goed en zal nog veel beter worden, maar bij Google zitten ze natuurlijk ook niet stil en hebben ze ook tal van nieuwe functionaliteit klaar om de strijd met Microsoft aan te gaan.

Bing lijkt heel goed te werken voor de doorsnee mens die meer algemene informatie wil opzoeken. Een vliegtuig of hotelkamer boeken, een restaurant zoeken dat zijn zaken dat Bing wel goed kan. Google doet het echter iets beter bij het zoeken naar gespecialiseerde informatie.

Je kan Bing zelf uitproberen op:

http://www.bing.com/

Bekijk Ook: