Er wordt momenteel veel geblogd (bij Cowgirls, 925, Human Experience, Mediakip), getwitterd en gehyved over het redesign van Hyves. Logisch, want de site wordt al jaren bekritiseerd als een zooitje, al betoogde ik ooit dat dat juist deel van het succes was. Dit redesign is de eerste grote interface verandering in 5 jaar tijd. Hier kun je wat voor-na screenshots zien, en Goldmembers kunnen sinds een paar weken al in het nieuwe design Hyven. Erg hip beta-user-centered dus.

Omdat ik ook een klein aandeeltje heb gehad in het redesign, en omdat er moeilijk een interessantere (en grotere) case te bedenken is, wil ik wat achtergronden met jullie delen. Ik wil het niet teveel hebben over welk kleurtje anders en welk randje ronder is, maar juist over hoe dit alles tot stand is gekomen en welke overwegingen er ten grondslag liggen aan het nieuwe design.

2007: kun je een usability reviewtje doen?

In juli 2007 werd ik gevraagd om een usability review van Hyves te maken. Ik zag de bui al hangen (en mijn opdrachtgever Floris ook) en stelde voor om in anderhalve dag de hoofdpunten op een rij te zetten. Als ik een “normale” review zou doen, zouden er vast 1001 todo’s en tips uitkomen, en daar zaten we beiden niet op te wachten. Hiernaast vind je de inhoudsopgave van wat ik uiteindelijk opleverde, en dit stond in de inleiding:

Het bleek tijdens de review moeilijk op een gedetailleerd niveau problemen aan te kaarten. Dit komt doordat de site relatief veel  globale problemen kent, die liggen in de manier waarop de site is opgebouwd. Om de review zo nuttig en toepasbaar mogelijk te houden, is daarom vooral gefocust op deze globale problemen, in plaats van details.
De uitdaging voor Hyves zit in stuk voor stuk de flows van afzonderlijke scenario’s te evalueren en te optimaliseren aan de hand van nieuwe design patterns. Daarnaast is in deze review relatief veel aandacht besteed aan functionaliteit die toegevoegd zou worden om nieuwe gebruikers te ondersteunen.

We need help!

Al vrij snel haalde ik vriend en über-interaction-designer Anton Bensdorp van interactie-ontwerp-bureau UltraFris (die slim zijn site heeft omgedoopt in Hyves Redesign stijl) erbij. Vooral om snel tot concrete verbeteringen te komen, en om snel alle ideeën die we hadden te gaan ontwerpen om ze te testen.  Daarbij lag de focus op het maken van design patters: terugkerende interface elementen die overal hetzelfde (en beter!) moesten worden.

Er zijn zonder overdrijven honderden kleine en grotere interactie ontwerpen gemaakt van elk menuutje, elk formulier en elke pagina template. De eerste paar maanden waren we vooral veel met zijn drieën aan’t overleggen en brainstormen over de fundamenten van een eventueel redesign, daarna haakte ik af en waren zij met het interne team bezig het daadwerkelijk waar te maken. Later kwam Bastiaan van SuperInteractive (die Usarchy’s WordPress implementatie heeft gedaan) er ook bij, om het HTML+CSS+Javascript vorm te geven samen met de technische afdeling van Hyves. Dat traject heeft dus nog zo’n anderhalf jaar geduurd, maar zoals je straks leest gebeurde er in die tijd genoeg.

Iets wat bij Hyves al heel normaal was, zijn ze nog meer gaan doen: interne usertests met de “Angels“. Dat zijn de dames (geen heren, voor zover ik me herinner…) die support verlenen aan de 8 miljoen gebruikers. Als er een knopje verschuift of een menuutje van naam verandert, krijgen de Angels hier in no-time een berg mailtjes over. Zij voelen dus op hun klompen aan wat wel en niet “kan”. En vaak zat kwam Floris met een door ons als geniaal bestempelde oplossing terug met het bericht: “Ze zeiden: Hoe kom je daaaar nou bij, wat een onzin!”. Dan waren we dus te ver doorgeschoten in onze eigen usability wereld, en vonden de Hyvers het niet goed genoeg.

Redesign is de slagroom, niet de taart

Het afgelopen jaar zijn er min of meer stiekem al allerlei dingen aangepast in het ontwerp van de site. Zo werd al eens de hele foto uploader aangepakt en de diverse editors om berichten e.d. te schrijven opgefrist. Anton van Ultrafris wat ondertussen aan een structuur bezig om het redesign mogelijk te maken. Het interactie ontwerp kent twee grote uitdagingen; die van constante verandering, en van de schaalgrootte van Hyves.Ik stelde Anton hierover een paar vragen:

Hoe ging de verandering van ad-hoc aanpassingen naar het “grote redesign”?

Anton: Aan de ene kant wil Hyves features zo snel mogelijk online zetten voor de gebruikers. Features werden dan rechtstreeks gebouwd aan de hand van de wireframes om later nog verder uitgewerkt te worden. Dit proces wilden we niet vertragen, omdat snelle verbeteringen n.a.v. gebruikersfeedback heel belangrijk zijn voor Hyves.

Aan de andere kant willen we dat features hun beste plek krijgen. Maar ja, In een systeem wat constant verandert is dit vrij lastig; je probeert te voorkomen dat je een feature op een plek neerzet waarvan je weet dat die plek er over 3 maanden niet meer is.

Hoe heb je dat aangepakt?

Anton: Het is vooral belangrijk om te weten waar je vandaan komt, dus inventariseren hoe de huidige functionaliteiten en pagina’s samenhangen. Pas daarna kun je dingen anders gaan indelen om ze een betere plek te geven. Bedenk dat Hyves uit letterlijk honderden templates bestaat, maar dat er binnen templates ook weer honderden functionaliteiten zijn die worden hergebruikt.

Om dit te kunnen overzien hebben we een grondige analyse gemaakt van de oorspronkelijke site. Dit hebben we opgedeeld in ‘content-systemen’: bijvoorbeeld het foto systeem of het blog systeem. Deze zijn uiteindelijk samen gekomen in een sitemap van de situatie op dat moment en een sitemap waar we op uit wouden komen. Hier zie je hem, helaas niet in detail want er zitten nog veel dingen in die nog niet voor publieke consumptie geschikt zijn:

OK, de bekende sitemaps en wireframes aangevuld met jullie “systemen”, kun je die iets meer uitleggen?

Anton: Een goed voorbeeld zijn foto’s. Op de meeste sites komt een foto maar op een of twee plaatsen voor. Bij Hyves is dat anders. Foto’s kunnen voorkomen op je profiel, in de buzz maar ook op de publieke homepage of de fotopijler. Om het nog iets complexer te maken kan een foto ook een onderdeel zijn van een blogpost, een tip of bijvoorbeeld een krabbel.

Om dit in kaart te brengen hebben we ‘content systemen’ bedacht. Een content-systeem kan je zien als een exclusieve flowchart voor een content-type. Aan de hand hiervan zijn we gaan kijken hoe een content type op al die verschillende plaatsen gebruikt werd. Zo kregen wij meer feeling met de site en werd het voor ons mogelijk om de verschillende content-systemen op elkaar af te stemmen.

En hoe ben je vanuit die sitemap en content-systemen dan weer naar wireframes gegaan?

Anton: Zoals je waarschijnlijk al voelt, kun je niet zomaar ergens beginnen, een pagina volledig uitwerken en naar de volgende gaan. We hadden overzicht nodig. Om dit probleem aan te pakken zijn we tegelijkertijd vanuit micro en macro niveau aan de slag gegaan. Hiervoor hebben we een simpele applicatie ontwikeld waarin we elementen en pagina’s konden invoeren. Dit was erg handig omdat we zo konden zien op welke pagina’s een element voorkwam en omgekeerd.

Van “onderaf”: we zijn bezig gegaan met onderdelen die niet altijd begrepen werden en die ons dwars zaten. Voor dit soort onderdelen (vaak een formulier of een specfieke interactie om iets te delen) zijn we in detail varianten gaan maken. Deze werden getest en besproken. Hiermee kregen wij een idee over de vorm en inhoud van de elementen.

Van “bovenaf”: dit zijn wireframes geworden die bestonden uit placeholders. Zonder teveel in detail te kunnen treden werd hierin verteld welke ellementen waar op de pagina’s kwamen te staan. Uiteindelijk werd het een invuloefening waarin deze deliverables (het overzicht van elementen, de sitemaps en de niet-gedetailleerde wireframes) bij elkaar kwamen. Nadat we al die maanden met losse stukjes bezig waren was het heel bijzonder om al die stukjes in een geheel te zien passen. bij elkaar kwamen.

Wireframe zonder details

Wireframe later ingevuld met details

Wat vind jij?

Ondanks mijn kennis over dit project, en de extra input van Hyves en Anton, merk ik dat het lastig is om het goed in kaart te brengen achteraf. Ik hoop dat je toch een beetje een beeld hebt gekregen van hoe het is aangepakt. Afhankelijk van de reacties op dit artikel, maken we er ook nog eentje over het visueel ontwerp en de frondend ontwikkeling in HTML, CSS en JavaScript.

Ik ben natuurlijk benieuwd naar jouw mening over het redesign. Maar zeker ook naar je vragen over het proces, want dat vind ik eerlijk gezegd nog interessanter. En mocht je nou denken dat je het beter kan, dan hebben ze nog wel wat vacatures opensaan voor een Information architect, een Front end developer en een User Interface Designer 🙂