We hebben hier bij Netlash wel al een aantal webprojecten afgewerkt. Door de jaren heen is er een bepaalde systematiek uitgekristaliseerd - een manier van werken, een stappenplan, waarvan we ondertussen weten dat dit de goede manier is om een website tot stand te laten komen.
In dit artikel wil ik deze methodiek met jullie delen, en jullie feedback daarop vragen (want alles kan altijd beter, niet?).
De stappen die we nemen zijn er met een goede reden. Zie het bouwen van een website als het beklimmen van een berg. Ja, je kan zonder zekeringen helemaal naar boven klimmen. Maar toch zal je beter op regelmatige intervallen een haak in de bergwand slaan om je musketon vast te maken. Als je niet gevallen bent, bij het naar boven klimmen, heb je inderdaad een hele hoop extra en overbodig werk gehad met die musketons. Maar als je wel mistrapt en valt, zorgen de borgen ervoor dat je maar een kleine afstand opnieuw moet omhoogklimmen - en niet de dodelijke val over de volledige diepte meemaakt.
Vandaar dit proces. Een aantal van de stappen lijken overbodig, maar ze zorgen wel voor een constante kwaliteitsgarantie over projecten heen.
0. Voorbereiding
Na de eerste prospectiegesprekken wordt de prospect meestal onze klant. We starten met een beetje administratie: zorgen dat de afspraken rond facturatie goed gemaakt zijn, en een duidelijke planning. Op de stappen die hieronder volgen wordt een datum gekleefd, zodat zowel onze klant als wijzelf duidelijk weten wanneer wat van ons verwacht wordt.
Tegelijkertijd sturen we al een eerste vragenlijst door (voer voor een andere blogpost) rond inhoud en vorm.
1. Analyse
De eerste echte stap is heel eenvoudig samen te vatten: 'goed nadenken'.
Mijn vader zei me altijd: "Beter twee keer meten en maar één keer zagen - da's efficiënter". Wel, da's ook zo bij het bouwen van websites.
Dit is vooral praten. Praten met onze klant: hoe zit zijn bedrijf of organisatie in elkaar, wat zijn de doelgroepen, wat is de doelstelling van de site?
Het gaat over het verzamelen van informatie: de transfer van kennis die in het hoofd van onze klant zit, naar onze hoofden - om die dan te bevruchten met onze kennis van wat werkt online en wat niet.
We doen dit in eerste instantie met een echte kick-off meeting. Daarin overlopen we met onze klant nog eens de zaken uit de voorbereidingsfase - en vragen we hem de pieren uit zijn neus over zijn bedrijf of organisatie.
Typisch verzamelen we al die informatie in een mindmap; zo kunnen we onze gedachten op een gestructureerde manier ordenen.
Hier worden ook de functionele vereisten van de website verzameld: wat moet de site doen, op welke manier? Je kan dit gerust een functionele analyse noemen.
2. Informatie-architectuur
Die verzamelde informatie - hoe geordend of chaotisch ook - gaan we structureren, hiërarcheren, labelen. Dit heet informatie-architectuur.
We bouwen al een eerste ruwe versie van de site in html - wat wij een structuurdocument noemen. Dit is een lege versie van de site: zonder layout, zonder functionaliteit, vaak ook zonder afgewerkte teksten.
We zouden dit op papier (of in Powerpoint of in Visio of ...) kunnen doen (en vaak doen we dat ook eerst); maar een klikbare versie legt de flow doorheen de site bloot. Als je effectief van pagina naar pagina kan klikken via werkende links, voel je hoe de site in elkaar zit, en waar de 'kleine haperingskes' zitten.
Je voelt hoe het klikt.
Dit is een iteratief proces: op basis van de informatie die we verzamelden, maken we een eerste voorstel, en zetten dat online voor onze klant. We vragen feedback, sturen bij, leveren een nieuw voorstel op, vragen feedback... tot het goed zit.
Dit is de belangrijkste fase in het hele proces.
Vergelijk het met het bouwen van een huis: vooraleer je begint te metselen, teken je toch eerst een plan? Dit structuurdocument is het architectuurplan van de website.
Het voorbeeld hierboven is dat van de vernieuwde bSeen website - je vind de twee iteraties van het structuurdocument hier.
3. Design
Na goedkeuring van het structuurdocument starten we met de layout-fase.
We vertrekken hiervoor vanuit de wensen van de klant. In de voorbereidende fase vroegen we hem een like/dislike lijst: een lijst van andere websites die hij visueel goed vind (en waarom) of niet goed vind (en waarom).
Daarnaast gebruiken we ook het aangeleverde huisstijlmateriaal. We hebben al het volledige spectrum meegemaakt: van 'er is helemaal niets, doe maar' tot 'hier is onze 260 pagina's tellende huisstijlgids'.
Onze designers beginnen altijd met schetsen, op papier. Ze baseren zich daarbij op het bovenstaande structuurdocument:
Die eerste ruwe schetsen worden verder verfijnd en uitgewerkt:
Daarna beginnen we aan het eerste ontwerp in Photoshop. We starten daarvoor met een binnenpagina - wat wij het 'werkpaard' noemen. (Het 'werkpaard' is die pagina die zonder extra ondersteuning al het harde werk moet doen: overbrengen van betekenis.)
Deze fase (eerste echte ontwerp in Photoshop) dient om de stijl van de site vast te leggen. Het is niet de bedoeling om hier alle details al vast te leggen. Wel om onze klant een gevoel te geven van hoe de site er zal uitzien. Vertrekkend van dit eerste ontwerp zullen de webdesigners dan extrapoleren naar andere pagina's.
Het gaat dus over de grote layout-lijnen. Vandaar dat we niet met de homepagina starten - de binnenpagina, de inhoudspagina zal veel meer van deze layout-lijnen blootleggen.
(Bovendien is de homepagina al lang niet meer de belangrijkste pagina van een website.)
Ook dit is een iteratief proces: we leveren een eerste voorstel, vragen feedback, sturen bij...
Als die algemene stijl goedgekeurd is, werken we ook de andere pagina's uit: de homepagina, een blogpagina, een contactformulier...
4. Slice
Deze goedgekeurde Photoshop documenten worden uitgewerkt in html/css templates.
Ze worden opgemaakt volgens onze interne normen, en klaargezet om geïntegreerd te worden in ons CMS.
5. Development
Ondertussen zijn de webdevelopers al druk bezig om de functionaliteit die op maat moet geprogrammeerd worden uit te werken. Ze baseren zich daarbij op de functionele analyse uit stap 1 en het structuurdocument uit stap 2.
We hebben al heel veel veelgevraagde functionaliteiten uitgewerkt als standaard modules voor Fork CMS; maar tegelijkertijd geloven we dat elke site maatwerk vraagt.
Die maat-functionaliteit wordt dus uitgewerkt in nieuwe Fork-modules.
6. Integratie
De structuur, het design, en het programmeerwerk worden geïntegreerd in het Content Management Systeem, Fork dus.
Als we ons werk in de vorige stappen goed gedaan hebben, staat hier een werkende website die voor 90% goed zit.
7. Testen
Het spreekt vanzelf dat we dit uitgebreid testen; we leveren ook een testversie op aan onze klant zodat ook hij kan testen.
Onze klant moet uiteraard niet testen of het werkt (dat is onze job) - wel of alles er in zit, of alles op de juiste plaats zit, of we alles goed begrepen hebben...
Maar zoals gezegd, door de stapsgewijze aanpak waarbij de klant op elk moment mee stuurt, zal dit een quasi afgewerkte site zijn.
8. Content
Als alles aan beide kanten uitvoerig getest is, leveren we de site op.
Dat is het moment waarop onze klant inhoud in het CMS kan plaatsen. Ik 'eis' meestal van mijn klanten dat ze effectief zelf in het CMS werken - zo leren ze het kennen, en als er nog vragen of kleine wijzigingen opduiken dan kan dit nu, en niet als de site live is en de ganse wereld zit mee te kijken.
Op dat moment kan de klant niet alleen de teksten aanpassen, maar ook de beelden.
De website wordt op de definitieve server geplaatst (en nog eens getest, om verrassingen te voorkomen), maar voorlopig onder een niet-definitieve URL.
9. Live
Als alle inhoud geplaatst is, kan de website live gaan. We koppelen dan de definitieve URL aan de server.
Vanaf dat moment kan de klant die site volledig zelf beheren. Om het met een overdrijving te zeggen: na afloop van het proces wil ik die klant niet meer zien. Dit is uiteraard niet waar; maar voor dagelijkse aanpassingen moeten onze klanten volledig zelfstandig met het Content Management Systeem kunnen werken. (Als voor elke dt-fout een klant naar zijn webbureau terug moet, creëert dit alleen maar frustratie. Het webbureau moet dit inplannen, de klant wil dit onmiddellijk; het webbureau moet dit factureren, de klant wil dat gratis... Vandaar is een flexibel en uitgebreid CMS levensnoodzakelijk.)
Uiteraard ondersteunen we op elk moment onze klant; en staan we klaar voor functionele wijzigingen of uitbreidingen van de site - dan start dit proces opnieuw.
Het eindresultaat van de bovenstaande staooeb voor de bSeen website kan je online bekijken.
10. Support
We volgen elk project op met een support-periode: een aantal weken na oplevering dat we die site met de loep mee volgen - zodat we snel kunnen ingrijpen mochten er bugs opduiken of als er kleine wijzigingen nodig zouden zijn.
Als onze klant dat wil (meestal enkel bij grotere projecten), bouwen we dit structureel in met een onderhoudscontract.
Dit zijn dus de stappen die we volgen bij het uitbouwen van onze websites. Nogmaals in een grafiek gegoten:
De verschillende stappen na elkaar in een slideshow tonen het onstaansproces van zo'n site:
We hebben ondertussen geleerd dat de stappen in dit proces nodig zijn. Als we er één overslaan, betekent dit heel vaak problemen of frustratie verder op de lijn.
Dit betekent niet dat we een maand afgezonderd in een hokje gaan zitten met een koude pizza en een fles cola - onze klant stuurt op elk moment mee. We spelen als het ware ping-pong met hem.
Het gevolg is dat we net zo veeleisend zijn voor onze klanten als we zijn voor onszelf. Maar dat is de enige manier om tot een goed eindresultaat te komen.
Zo, da's de korte samenvatting van ons webdesign proces. Hebben jullie feedback? Hoe verloopt het bij jullie? Hoe zouden jullie dit proces verbeteren?
Door stijn 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Ga je in stap 1 ook de "concurrentie" gaan bekijken? Hoe zij het aanpakken op vlak van structuur en vorm? Waar de opportuniteiten liggen?
Door Stijn Henderickx 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Welk programma gebruiken jullie voor de Informatie-architectuur ?
Door Erlend 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Een logisch proces, zoals dat vandaag zou moeten lopen. Maar kan je wat meer uitleg geven over de IA stap?
Ik ga er van uit dat wireframing een logisch gevolg is van een uitgewerkte IA. In hoeverre zijn jullie wireframes bepalend voor het design; bepalend in de zin van compositie van grote blokken (niet in kleur, typo, ...).
Door dipfico 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Logisch process.
Wat me vooral interesseert is hoe jullie met heirkrachten omgaan.
Wat als één van de deliverables door omstandigheden niet volgens de planning loopt. Klant geeft te laat feedback, onverwachte change requests van de klant laat in het process, ziekte, ... verandering van startegie, ...
Hoe gaan jullie daar met om? Dat dit impact heeft op timing en budget is logisch maar wat als daar weinig of geen flexibiliteit in is. Wat doen jullie dan.
Door Koen 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Helder en duidelijk Bart. Leuk om te lezen hoe collega's met dit proces omgaan. In grote lijnen werken wij op een gelijkaardige manier.
Een paar vraagjes:
- stellen jullie soms ook meerdere design alternatieven voor? Wij enkel indien het expliciet gevraagd wordt. In praktijk wordt dat toch steeds 1 design waar we voor willen gaan, en 1 waarvan we hopen dat het niet gekozen wordt...
- ervaar je een meerwaarde uit de papier-schets tussenstap? Of is dit puur intern. Ik vind het nl. wat overlappen met de wireframes. Zelf toon ik ook liever geen onafgewerkte designs, want dan beginnen klanten mee te designen :-)
Door Michel Vuijlsteke 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Een mooi overzicht.
Ik heb twee vragen:
1) Hoe gaan jullie om met eindgebruikers? Gaan jullie spreken met hen, of is het voronamelijk wat de klant vertelt en eigen ervaring die informeren hoe de website gemaakt wordt? [Vooral dan in het kader van grotere sites, of meer intranet-achtige of sites voor een gespecialiseerd publiek.]
2) Uit oprechte nieuwsgierigheid: waarom een eigen CMS? Is dat niet voor een heel groot deel het wiel opnieuw uitvinden, en dreig je daar niet veel tijd mee te verliezen als pakweg de Drupals van deze wereld al 90% van elke website aankunnen out of the box en dat de overige 10% voor het overgrote deel ingevuld kunnen worden door bestaande dingen?
Door Karl Gilis 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Praten met de klant? Oké, maar dan maak je wel iets voor de klant.
Moet je geen websites maken voor de klanten van de klant en dus onderzoeken wat die doen en willen?
Volgens mij kan je geen goede informatiearchitectuur maken, zonder dat aspect grondig te onderzoeken. Zoals Michel zegt, geldt dat eerder voor de wat grotere websites.
Nuttig artikel over informatiearchitectuur is misschien: http://usability-blog.be/informatiearchitectuur-wat-waarom-hoe/
Door Thomas 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Erg leuk om lezen. Testen jullie de informatiearchitectuur en het ontwerp nooit bij 'echte' gebruikers vooraleer de site live gaat? Zien welke vorm het beste het doel bereikt, welke informatie duidelijk te vinden is en wat niet enz.
Bij grotere sites zou ik dit als essentieel vermoeden?
Door Jan Seurinck 25/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Om het even uit docentenoogpunt te bekijken: ik denk dat dit een onderdeel moet zijn van elke opleiding e-communicatie.
Denk dat dit een grosso modo algemeen aanvaard werkschema is. Waar je dan nog punten en komma's aan kunt hangen.
Door Jan Ottenbourg 26/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Logisch, doch mooi overzicht.
Door wannes 26/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
ik denk dat we bezig zijn met een goede evolutie bij ons. Zeker naar grotere projecten.
Wat je zegt dat elke site maatwerk nodig heeft, klopt als een bus: 90% kan je met wat bestaat, de rest kost 90% van de inspanning.
De keuze van jullie eigen cms snap ik ergens wel (je hebt me dat ooit uitgelegd) maar vind ik net als Michel een beetje wiel en warm water.
Wel mooi uitgewerkt:feit is dat iedereen dat zou moeten kunnen doen. Als je met heel je team weet hoe je ergens moet/wil geraken, loopt dat stuk alvast vlotter.
Door Android X10 27/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Zeer heldere uitleg! Niet alleen handig wanneer je voor een klant werkt, minstens net zo bruikbaar om eens naast je eigen project te leggen. Alleen moe je die interactie dan iets anders regelen.
Door Marnik D'Hoore - bSeen 28/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
Alhoewel ik geen webdeveloper ben, heb ik ondertussen 12 jaar ervaring met websites en hoe deze optimaliseren. Ik wist dus zeer goed wat ik wou /niet wou, voor we begonnen.
Netlash begreep zeer goed mijn verwachtingen en heeft door zijn aanpak ons in de juiste richting gestuurd. Het eindresultaat is gekomen door wederzijdse input & feedback tussen bSeen en Netlash.
Van de totaalstructuur en het geheel zijn we zeer tevreden. We plannen nu een upgrade van de inhoudelijke SEO + finetunings om onze boodschap beter over te brengen en onze bezoekers nog meer aan te zetten tot actie (conversie marketing).
Door Michel Vuijlsteke 29/01/10 (6 maanden geleden)
Praten met de klant van de klant?
Om voor een deel op mijn eigen vraag te antwoorden: je hoeft niet altijd te praten met de eindgebruiker om een degelijke website te maken.
Een groot deel van wat een goede ontwerper een goede ontwerper maakt (en hetzelfde geldt voor informatie-architecten, usability-mensen, etc.), is dat hij genoeg ervaring en expertise heeft om te weten wat de eindgebruiker wil.
En dan zijn gebruikersinterviews, veldstudies persona's, workshops niet meer nodig: de maker heeft die allemaal al lang geïnternaliseerd, vaak zelfs zonder er nog te moeten over nadenken.
...maar dat geldt natuurlijk niet voor alle mogelijke projecten. Als je een webinterface gaat bouwen voor, pakweg, radiologen om hun beeldmateriaal mee te beheren, of voor notarissen om hun dossiers te archiveren, of een complex intranet dat door zeer welbepaalde mensen in zeer welbepaalde processen zal ingeschakeld worden, dan moét je die basisdingen wel doen, denk ik.
En ik denk niet dat Bart anders denkt. Toch?
Door stijn 30/01/10 (6 maanden geleden)
re: Webdesign proces bij Netlash
@michel: is die geïnternaliseerde kennis niet vooral technisch van aard? gaat het dan niet vooral over best practices op vlak van usability, design etc.?
het lijkt mij veel moeilijker om als webprofessional (uit welke discipline dan ook) meteen inzicht te hebben in de context waarin de eindgebruiker in aanraking komt met jouw product of dienst. zelfs al gaat het om iets éénvoudig.
Door Lieke - Berendsohn Relatiegeschenken 02/02/10 (5 maanden geleden)
re: Webdesign proces bij Netlash
Leuk en duidelijk om het stappenplan zo te zien! Het is een logisch proces, maar de praktijk wijst uit dat er maar weinig bedrijven zijn die het gestructureerd aanpakken...
Door KBD-Design 05/02/10 (5 maanden geleden)
re: Webdesign proces bij Netlash
Wow die is echt goed gelukt, trouwens mooie analyze, heb dit ook reeds gebruikt voor mijn eigen site KBD-Design. Echt goed gelukt ;)
Door webdesign 06/02/10 (5 maanden geleden)
re: Webdesign proces bij Netlash
Logisch maar leuk overzicht. Bedankt voor het delen.
Door Kris Van den Bergh 08/02/10 (5 maanden geleden)
re: Webdesign proces bij Netlash
Uitermate interessant om het webdesign proces van dit agency onder de loep te nemen. Het is een zeer gestructureerde aanpak en het ontstelt me in zijn geheel niet al te veel. Ook meen ik dat deze aanpak aansluit bij de wetenschappelijke literatuur.
Toch zijn er nog enkele zaken die ik me in het bijzonder afvraag. Ten eerste, of er bij de meer complexe klantvereisten soms gesleuteld moet worden aan het proces van de klant, of worden alle klantprocessen klakkeloos overgenomen of noch, moet er wel eens aan re-engineering worden gedaan?
Bij de analyse fase wordt er gesproken over het verzamelen van informatie. Hoe wordt deze informatie concreet verzameld? Zoals je al aangeeft zijn consistentie en compleetheid twee belangrijke criteria die de kwaliteit meebepalen. Daarom, worden er bijvoorbeeld data dictionaries opgesteld? Welke vormen (UML, DFD, ontologische modellen, etc.) worden er gehanteerd om dingen te modelleren? Zijn mindmaps wel voldoende en consistent genoeg voor het ganse project team. Komt dit überhaupt overeen met de eindgebruiker zijn visie?
Tenslotte, feedback gebeurt enkel bij de informatie architectuur en de layout. Waarom niet meteen na de functionele analyse?
Rest mij nog te zeggen: word up voor de transparante en begrijpbare ontbloting :-) Respect.
Door Maak-mijn-website-Design 20/02/10 (5 maanden geleden)
re: Webdesign proces bij Netlash
Dit is de ideale voorbeeld van hoe een project uitgevoerd moet worden.
Door 5235 30/03/10 (4 maanden geleden)
re: Webdesign proces bij Netlash
Erg leuk voorbeeld om te zien hoe jullie dat doen.
Door Webdesign DragolinDesign 05/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Bedankt dat jullie dit willen delen collega's!
Ik toon meestal niet meer dan 1 design aan de klant. Vooraf heb ik al wel verschillende designs en tussenstappen gemaakt (voor mijzelf) en het eindresultaat is waar ik wil voor gaan. Anders gaan de klanten vaak mee-designen wat niet altijd een positieve invloed is. Uiteraard hou ik wel rekening met de eisen/verwachtingen van de klant.
Deze interactie hangt ook zeer sterk af van de kennis/ervaring van de klant die je een beetje moet weten in te schatten. In het eerste geval krijg je dan ook vaak een 'doe maar iets' verhaal, terwijl de andere kant je sterker zal opvolgen en meer input zal verwachten.
Door Edwin Waelbers 06/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Ik vind het toch maar raar dat je geen rekening houdt met de feitelijke gebruiker.
Je gaat maar af op wat de opdrachtgever je wil en kan vertellen. En die weten het meestal ook niet erg juist.
Ja, je kan software en websites ontwikkelen zonder met die gebruiker zijn eigenheid, zijn taken en zijn omgeving rekening te houden.
Het resultaat is dat die software wel op maat is van jou of je opdrachtgever, vanuit jullie omgeving en context, maar absoluut niet op maat van de gebruiker.
Als je niks weet over die gebruiker en moet werken met 2de hands informatie, hoe kan je dan kundige en juiste usability doelen vastleggen? Dat gaat niet.
Stel je voor dat Apple voor zijn iPod alleen maar afging op de ideeën van het management en de 'technici', denk je dan ook niet dat het toestel er compleet anders had uitgezien? En we weten allemaal hoe succesvol hun iPod was/is doordat ze wél veel aandacht aan de effectieve gebruikers schonken.
Maar goed, bovenstaande is wel min of meer de norm in de meeste organisaties: ze maken bijna allemaal applicaties (web- en desktop gebaseerd) zonder enig onderzoek naar de mensen die het feitelijk moeten gebruiken.
Mensen die eens wat 'anders' willen proberen: bekijk het Fusion Usability Recept eens.
Door mlitn 06/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Edwin,
We houden zeer zeker rekening met de uiteindelijke gebruiker. Don't just take my word for it maar neem gerust even een kijkje door ons portfolio.
Zoals je bij deze blogpost (http://www.netlash.com/blog/detail/het-geintegreerde-webbureau) ziet, is elke website die door ons geproduceerd wordt het resultaat van een samenwerking van zowel de klant zelf en de project manager, designers, developers EN een usability engineer. Deze laatste is de voorvechter van de uiteindelijke gebruiker, en staat garant voor een excellente gebruikservaring.
Het is bij ons een expertise op zich, in tegenstelling tot vele andere webbureaus. Niet enkel is hij de persoon betrokken bij het structuurdocument (om ervoor te zorgen dat alles voor de gebruiker intuitief aanvoelt), maar ook doorheen het gehele ontwikkelproces blijft hij betrokken om de gebruiksvriendelijkheid te bewaken.
Door Edwin Waelbers 06/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Mlitn,
Dan is het goed, ik kan weer rustig slapen vannacht ;)
En wat doen jullie dan zoal om die gebruiker in kaart te brengen?
Door Bart De Waele 06/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Vrij frappant dat de enigen die reageren met "jullie moeten gebruikerstesten doen!" net diegenen zijn die zo'n gebruikerstesten ook commerciëel aanbieden...
Maar goed: ja, we houden rekening met gebruikers. En nee, we doen niet altijd gebruikerstesten. De redenering daarachter? Voer voor een andere blogpost. Abonneer op de RSS-feed!
Door Edwin Waelbers 06/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Bart,
Ja, ik vind dat ook.
Die gebruikerstesten kunnen gewoon niet altijd.
Tuurlijk vind ik het ook beter dat die testen wel gebeuren, maar als het budget op is, of er is geen tijd, of het is praktisch lastig, tsja, dan kan het niet.
Ik vind dat geen must, er zijn genoeg alternatieven om het toch best goed te testen.
Bij kleine tot middelgrote projecten:
Gewoon gestructureerd (al dan niet automatisch) testen en een heuristische usability evaluatie doen wonderen. Als het die testen goed doorkomt, dan kan het meestal wel 'live' gaan, daarna krijg je meestal toch nog feedback van gebruikers.
Door Michel Vuijlsteke 06/04/10 (3 maanden geleden)
re: Webdesign proces bij Netlash
Oh, als ik ook geviseerd werd met "diegenen die zo'n gebruikerstesten ook commercieel aanbieden"; mijn vraag was absoluut niet naar gebruikerstesten achteraf, maar wel naar de plaats van de eindgebruiker in jullie ontwerpproces.
Stel dat je een (stuk van een) intranet maakt dat door loketbedienden van de NMBS of een bank of een stadsdienst moet gebruikt worden, gaan jullie dan af op wat de bazen van de bazen van de bazen van die loketbedienden zeggen dat de onderschikten van de onderschikten van hun ondergeschikten willen? Of gaan jullie spreken met loketbedienden, en loketbedienden observeren?
Gebruikerstesten achteraf, trouwens, zijn vaak veel te laat. Best genoeg weten om goede ontwerpen te maken, en die in een zo vroeg mogelijk stadium laten testen.
Testen kan ook op papieren versies of op prototypes, en hoeft uiteraard absoluut niet in een lab met camera's en zorgvuldig geselecteerde testpersonen.
Door Anita Holwerda 18/05/10 (2 maanden geleden)
re: Webdesign proces bij Netlash
Bart,
Helder artikel. Interessant om te lezen hoe jullie projectmatig met het ontwikkelen van een website omgaan.
Hier kunnen nog veel webdesigners / ontwikkelaars wat van leren. :)
Door Ray 18/05/10 (2 maanden geleden)
re: Webdesign proces bij Netlash
Leuk om te lezen hoe jullie het gehele proces uitvoeren. Mijn complimenten voor de schets. Zien er echt geweldig uit!
Door netlash 25/01/10 (6 maanden geleden)
Het webdesign proces bij Netlash: http://www.netlash.com/blog/detail/webdesign-proces-bij-netlash
Door gertbaudoncq 25/01/10 (6 maanden geleden)
RT @netlash: Het webdesign proces bij Netlash: http://www.netlash.com/blog/detail/webdesign-proces-bij-netlash
Door webdesignblogs 25/01/10 (6 maanden geleden)
Webdesign proces bij Netlash - Blog - Netlash Webdesign: Blog… http://goo.gl/fb/MbAU #webdesign
Door wadje12 25/01/10 (6 maanden geleden)
Het proces > RT @netlash: Het webdesign proces bij Netlash: http://bit.ly/6kHiqL
Door webdesignblogs 25/01/10 (6 maanden geleden)
Webdesign proces bij Netlash - Blog - Netlash Webdesign: Blog… http://goo.gl/fb/TjEw #webdesign
Door geertdelaet 25/01/10 (6 maanden geleden)
(Dutch) Goede post over webdesign proces door @netlash : http://bit.ly/7dy4rg
Door bytte 27/01/10 (6 maanden geleden)
Het webdesignproces bij Netlash, heel mooi overzicht — http://www.netlash.com/blog/detail/webdesign-proces-bij-netlash
Door gertbaudoncq 16/02/10 (5 maanden geleden)
inderdaad, http://bit.ly/beTiP6, daarom maken wij altijd een structuurdocument bij Netlash: http://bit.ly/aRO3fU
Door bramus 19/02/10 (5 maanden geleden)
Een blogbericht van de @netlash blog (http://tinyurl.com/yax7dmg) - met toestemming - omvormen tot lesmateriaal #ikdoeict
Door miente 19/02/10 (5 maanden geleden)
RT @bramus: Een blogbericht van de @netlash blog (http://tinyurl.com/yax7dmg) - met toestemming - omvormen tot lesmateriaal #ikdoeict
Door jkivit 24/02/10 (5 maanden geleden)
Leest "Webdesign proces bij Netlash" http://icio.us/jfs1s0
Door research11 24/02/10 (5 maanden geleden)
RT @jkivit: Leest "Webdesign proces bij Netlash" http://icio.us/jfs1s0
Door dirkbonhomme 06/04/10 (3 maanden geleden)
@netlash verzint een nieuw woord: "staooeb" http://tinyurl.com/yf46e4b ;-)