Watervalmodel: Grafisch Ontwerp
Dit is het zesde artikel in een reeks over het tot stand komen van een maatwerk-website. Een introductie, de analysefase en ontwerpfase , en het functioneel ontwerp en het technisch ontwerp werden reeds eerder besproken. In dit artikel wordt ingegaan op wat er allemaal speelt in de grafisch ontwerp fase.
Het proces zoals we dit behandelen in deze reeks is als volgt gefaseerd:
- Analysefase
- Ontwerpfase
- Functioneel Ontwerp
- Technisch Ontwerp
- Grafisch Ontwerp
- Bouwfase
- Kwaliteitfase
- Acceptatiefase
- Lanceerfase
Het grafisch ontwerp is wellicht het meest bekend als het aankomt op websiteontwerp. Immers, dit ontwerp bepaalt hoe de site/applicatie eruit komt te zien. Toch is er nog vaak onduidelijkheid over wat er nu precies onder het grafisch ontwerp valt. Dus waar hebben we het nu precies over, en hyoe verloopt het ideale proces?
Input
Voordat een grafisch ontwerper aan de slag wordt gezet weet hij idealiter wat er op de site komt te staan. Ik adviseer daarom altijd om eerst het functioneel en technisch ontwerp te maken, dit kan namelijk erg goed zonder te weten hoe alles er precies uit komt te zien.
Bijkomend voordeel is dat er in een functioneel ontwerp al vaak wordt gewerkt met wireframes (zwart wit schetsen van pagina’s). Een grafisch ontwerper kan zich op basis van deze informatie volledig richten op zijn toegevoegde waarde, namelijk het maken en vormgeven van een mooi ontwerp. Een ander (groot) voordeel is dat er op die wijze geen elementen worden toegevoegd die niet in het functioneel ontwerp voorkomen (een veelgemaakte fout in de praktijk, je ziet vaak dat een grafisch ontwerper zich bediend van mooie voorbeelden die hij ergens anders heeft gebruikt maar voor de te bouwen site/applicatie in kwestie niet van toepassing zijn).
Grafisch Ontwerp
Een goed grafisch ontwerp biedt meer dan alleen een mooi plaatje. Denk hierbij aan de volgende zaken:
- User interface design: het ontwerp van belangrijke pagina’s of processen
- Usability: hoe gebruiksvriendelijk is de site? Staan de elementen op een logische plek?
- Interactie : hoe daag ik de gebruiker uit tot actie?
- Vormgeving van de site/applicatie (kleurstellingen/logo’s etc)
Usability en User interface design zijn nauwverwante termen en redelijk vaag gedefinieerd. Hieronder mijn interpretatie van deze twee veelvoorkomende definities en een korte uitleg over interactie en vormgeving.
User interface design
Een user interface designer denkt na over de plek van de componenten op een pagina, en over de ‘flow’ die de gebruiker volgt door de website, zodanig dat hij zorgt dat het ontwerp de gebruiker centraal stelt. Nauwverwant aan usability dus.
De meeste sites hebben niet een zeer uitgebreid user interface design nodig, maar voor specifieke maatwerksites met ingewikkelde bestelprocedures of andere zogenaamde workflows (uitgebreidde aanmeldprocedures) kan het zinnig zijn om deze van te voren uit te tekenen zodat je alle mogelijke ‘use cases’ van te voren kunt afvangen en bedenken wat de te nemen actie moet zijn als een gebruiker op dit punt in het proces aankomt.
Usability
Bij usability moet gedacht worden aan zaken als: Is het zinnig om een knop ‘leeg alle velden’ op te nemen onderaan een formulier. Hoe goed sluit het ontwerp aan op de best practices op het internet, en hoe gebruiksvriendelijk is mijn site. De diepte van het menu, de structuur van de informatie, de plek van het kruimelpad, alles dient in teken te staan van de gebruiksvriendelijkheid van de site, en het gemak van de gebruiker. Vele boeken zoals bv ‘Dont make me think’ van Steve Krug zijn over dit onderwerp geschreven.
Interactie
Tevens denkt een grafisch ontwerper na over ‘interactie’ met de gebruiker. Hoe kan hij ervoor zorgen dat de gebruiker wordt getriggerd om bepaalde acties te ondernemen (call to action) of de site flitsender en interessanter doen ogen? De uitdaging is om niet al te veel in ‘statische, tweedimensionale afbeeldingen’ te denken maar gebruik te maken van de mogelijkheden van het internet. Schiet hier niet te veel door, ik vind persoonlijke complete Flash sites altijd onoverzichtelijk en te dynamisch, maar enkele eyecatchers (in de vorm van een dynamisch blok oid) kunnen de website toch weer aantrekkelijk maken.
Vormgeving
Vaak zie je dat een grafisch ontwerper alleen een mooi plaatje maakt, afgestemd op de huisstijl en andere grafische componenten. In het plaatje stemt hij zorgvuldig alle kleuren op elkaar af, en past en meet hij alles op elkaar af. Het resultaat is vaak erg fraai, maar als er vervolgens ‘echte’ content wordt geplaatst zoals banners, of de site wordt gevuld dan blijft er vaak weinig meer over van het mooie ontwerp. Het is dus belangrijk dat een ontwerper meedenkt en op basis van echte content aan het ontwerpen gaat. Zo zorgt hij ervoor dat de site een half jaar later ook nog mooi blijft.
Je mag dus verwachten van een goed grafisch ontwerper dat meegedacht wordt over alle bovenstaande elementen. Nu we alle ontwerpen behandeld hebben kunnen we in het volgende artikel aan de slag met de bouw!
Stay tuned!
Gerelateerde berichten:
Trefwoorden: best practices, bouw website, business analist, functional design, Functioneel ontwerp, grafisch ontwerp, maatwerk, nieuw, ontwerp website, proces, technisch ontwerp, tips, watervalmodel
Bart Lelieveld is werkzaam als Manager Bouw bij Liones, internetbureau voor uitgevers. Als programmamanager overziet hij alle projecten binnen Liones, en is hij verantwoordelijk voor de dagelijkse operatie en het procesmanagement. Daarnaast is hij werkzaam als Senior projectleider en Business Analist. Bekijk meer berichten van Bart Lelieveld
Ik ben het er niet mee eens dat het Watervalmodel een goede aanpak is om een applicatie te ontwerpen.
In de praktijk liggen zaken zoals kosten, planning en resultaat helemaal niet vast met deze aanpak zoals je stelt op http://www.publishr.nl/2009/10/websites-op-maat-in-het-watervalmodel/
Lederer en Prasad hebben eens becijferd dat 63% van de grote projecten het budget ernstig overschrijden. In de 24 belangrijkste oorzaken van dit feit, staan op de eerste 4 plaatsen zaken die gedeeltelijk de schuld zijn van het Watervalmodel.
Om te beginnen is het inschatten van de tijd die nodig is om een applicatie te ontwikkelen met het waterval model quasi onmogelijk (tenzij het een klein project is). De brokken zijn immers te groot. Je kan (en moet) een aantal business doelen vooropstellen, maar in de praktijk kan blijken dat het niet werkt, aangepast moet worden of dat er dingen worden ontdekt die men in die fase nog niet wist.
Als je dan rigoureus het waterval model respecteert, wat in de praktijk best wel degelijk veel voorkomt, dan ga je op basis van die onvolledige business formulering een functionele analyse maken, vervolgens de architectuur bouwen en later een interface ontwerpen. Pas dan kan alles eens getest worden op mensen die het gedoe effectief moeten gaan gebruiken.
Als er dan zaken niet kloppen, dan kan men 2 dingen doen:
• Het zo laten, ermee leren leven, ze weten wel dat het beter zou moeten en kan, maar het kost te veel tijd en geld om het te veranderen. Dit is wat men meestal doet.
• Terug naar start. Business doelen herdefiniëren, een nieuwe functionele analyse maken, de architectuur herbekijken, opnieuw coderen en terug testen. Dit doet men soms voor kleinere zaken, waarvan de impact niet te groot is voor het project, in functie van respecteren van het budget en de tijd die nodig is om het project af te ronden.
Beide oplossingen kosten geld, veel geld en men kan dit vermijden door een iteratieve methodologie toe te passen. Of deze nu SCRUM, Agile, XP, RUP, Fusion Usability Recept of nog anders heet, dat doet er niet toe.
Usability is wel meer dan zorgen dat de juiste knoppen op de juiste plaats staan. Usability is eigenlijk het ontwerpen van een applicatie of website voor een bepaalde gebruiker, die een bepaalde taak uitvoert in een bepaalde omgeving.
Dit in kaart brengen, vroeg in het project, zal leiden tot enorme kostenbesparingen. Gebruikers profielen, contextuele taak analyses en omgeving analyses zorgen ervoor dat men veel meer weet over de eigenlijke gebruiker en zijn taken.
Het gevolg is duidelijk:
• De software is beter op maat van de gebruiker en zijn taak
• Men moet veel minder de architectuur en de source code aanpassen.
Hierdoor is het project niet alleen sneller klaar, de kwaliteit van de source code is doorgaans ook beter.
Ene Gilb heeft ooit eens het volgende gesteld:
Als een usability wijziging in de ontwerpfase 1 Euro kost, dan kost een identieke wijziging in de ontwikkelfase 10 Euro en zelfs 100 Euro na de oplevering van het systeem.
In mijn praktijk ervaring blijkt dat niet eens overdreven.
Meer over Usability hindernissen kan men hier vinden:
http://usability-vlaanderen.blogspot.com/2009/05/usability-hindernissen.html
Beste Edwin,
allereerst hartelijk dank voor je uitgebreide reactie, ik kan eruit opmaken dat je vaak met dit soort projecten te maken hebt gehad. Allereerst denk ik dat je gelijk hebt, het watervalmodel werkt prima bij de wat kleinere projecten (100K-500K)zoal ook genoemd in het introductieartikel in deze reeks. Bij projecten van grotere omvang denk ik dat deze methodiek minder geschikt wordt, maar ik zou dan adviseren om een dergelijk project op te hakken in deelprojecten (‘divide and conquer’ zeg ik altijd).
Ik ben erg benieuwd naar het onderzoek dat je aanhaalt. Ik heb even gegoogled op Lederer en Prasad maar daar vallen mij twee zaken op als ik kijk op http://www.usabilityworks.co.uk/docs/quotes.htm :
- het onderzoek stamt uit 1992
- er wordt de volgende quote gesteld:
“63% of all software projects overran their estimates, with the top 4 reasons all related to usability (Lederer and Prasad, 1992″
Wellicht heb ik een verkeerde samenvatting te pakken, maar deze bewering stelt dat de schattingen overschreden werden door usability- gerelateerde issues, en niet zozeer door het watervalmodel. Als ik ernaast zit, kun je me dit nog even laten weten?
Daarnaast denk ik dat je met me eens zult zijn dat 18 jaar ruimschoots voldoende tijd is om een proces te optimaliseren en te stroomlijnen. Vandaag de dag steekt de techniek anders in elkaar dan in die tijd. Dat betekent dat het bouwen van een website niet echt rocketscience meer is. De uitspraak dat het onmogelijk is om een schatting te maken van een project deel ik daarom niet met je. Ik heb de ervaring dat ca 90%-95% van de projecten die ikzelf doe binnen de oorspronkelijk ingeschatte tijd te realiseren is, en dat binnen het watervalmodel.
Ik ben het met je eens dat het onvermijdelijk is dat er voortschrijdend inzicht ontstaat nadat een applicatie in gebruik wordt genomen. Wellicht zijn zaken die je vooraf had bedacht , in de praktijk niet de meest ideale oplossing. Bij het bouwen van websites en kleinere applicaties valt dit echter wel mee. Het principe van een website/webshop is redelijk uitgekristalliseerd en de uitdaging van het ontwerpen en bouwen op maat is om zo goed mogelijk aan te sluiten bij de workflow van de klant waarvoor je de applicatie bouwt.
Mijn ervaringen met Scrumm, Agile, XP en RUP, DSDM zijn de volgende; de methodieken RUP en DSDM zijn denk ik goed toe te passen op veel grotere projecten, en bij de methodieken Scrumm, Agile en XP moet je een klant hebben die zo wenst te werken, of het moet een intern product zijn dat je zelf in huis ontwikkelt.
Hoe sta jij hier tegenover? Wat zijn jouw ervaringen hiermee?
Je aanvullende opmerkingen over usability beschouw ik als een waardevolle aanvulling op dit artikel waarvoor dank!
In de praktijk wordt dat Watervalmodel nog heel veel toegepast. Ook bij teams die zeggen dat ze iteratief werken. Die iteraties worden veelal enkel toegepast tijdens het programmeren van de source code an sich. Voor de rest zijn ze zo Waterval als Waterval kan zijn.
Iets wat weinig bekend is, maar de eerste die het fundamenteel beschreef, Winston W. Royce (1970), was zelf geen grote voorstander van het pure Watervalmodel.
Zijn fundamentele beschrijving was eigenlijk een kritiek op het systeem.
“I believe in this concept, but the implementation described above (het Watervalmodel) is risky and invites failure”
De methode die wel zijn voorkeur had, is eigenlijk nog steeds de basis voor quasi elk iteratief proces.
Je kan het originele document (PDF) hier vinden:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Wat betreft die samenvatting van Lederer en Prasad, heb je wel de juiste te pakken hoor.
Alleen staat er niet bij wat die 4 dingen zijn waarom projecten falen, maar hier zijn ze:
• Frequente wijzigingen op vraag van de gebruikers
• Niet genoteerde requirements van de gebruikers
• Gebruikers die hun eigen requirements niet kennen of begrijpen
• Gebrekkige communicatie en wederzijds onbegrip tussen gebruikers en analisten.
Die zijn inderdaad allemaal gelinieerd met usability, maar ook gedeeltelijk met de Waterval methode.
In een écht iteratief proces dat aandacht heeft voor de gebruiker, vroeg in het proces, voorkom je juist die problemen.
• Het is niet erg dat gebruikers hun specifieke noden frequent wijzigen. Zolang dat maar gebeurd voor de applicatie effectief geschreven wordt kost dat niet zoveel.
• Je pikt de meeste requirements van de gebruikers wél op, wanneer je in een vroeg stadium aandacht voor hun hebt
• Je kan véél gemakkelijker een idee of een concept aan hun verkopen waar ze zelf nog geen weet van hebben
• Ze voelen zich veel meer betrokken en hun motivatie om problemen te signaleren ligt hoger.
De leeftijd van Lederer en Prasad hun conclusie is voor mij geen bezwaar. Als iedereen die actief is in de creatie van software “The Mythical Man-Month”, een zeer dun boekje van 1975 (!) zou lezen, dan stonden we al veel verder. Terloops, daar staat eigenlijk bijna alles in wat je moet weten.
In de meeste projecten waar ik aan toegevoegd werd, had men geen of weinig oog voor de gebruiker en paste men doorgaans een variant op de Waterval methode toe.
Met alle gevolgen van dien. Soms verloor men veel geld, zonder dat ze het wisten.
In essentie durf ik stellen dat de oorzaak meestal lag aan het Waterval model en een gebrek aan aandacht voor de gebruikers (dikwijls gaan die samen).
Natuurlijk zijn websites anders dan ‘gewone’ applicaties, maar wat ze gemeen hebben is groter dan hun verschil. Het kost echt niet veel moeite om een lijstje samen te stellen van websites van grote bedrijven, die de middelen (in mankracht en budget) bezitten om er iets goeds van te maken maar die jammerlijk genoeg wel falen.
Scrum en DSDM vind ik wel goed. Je kan en moet niet alles van Scrum of DSDM toepassen overal, dat gaat soms niet en ja soms wil de klant ook niet mee. Ik vind ze geschikt voor kleine en middelgrote projecten. Doch, ook in grote projecten kunnen bepaalde aspecten goed uitpakken. Pakweg korte iteraties zijn een zegen voor bijna elk type project.
XP vind ik, en dat is een persoonlijke mening, waardeloos. Er zijn wel goede elementen aan dat proces, maar het is meer iets voor 10 PRINT ”Hallo Wereld”: GOTO 10 software.
Ik hoor ook wel eens zogenaamde succesverhalen over XP projecten, maar meestal slaagde dat XP project niet door XP, maar wel doordat quasi alle teamleden van een uitzonderlijke kwaliteit waren. Zo’n ‘supermensen’ maken er bijna altijd iets van, zelfs zonder methodologie. Maar een gemiddeld team bestaat niet uit supermensen alleen. De meeste zijn gewoon average.
RUP vind ik héél goed. Ik gebruik wel een aantal elementen van RUP in mijn visie over software ontwikkeling. RUP heeft de reputatie van groot en log te zijn en enkel geschikt te zijn voor grote projecten, maar dat is een verkeerde interpretatie. Het RUP raamwerk is effectief breed en groot en kan inderdaad heel grote projecten aan, maar je kan vanuit die mastodont ook een RUP light destilleren die geschikt is voor kleine projecten met kleinere teams.
Of je nu de Waterval, RUP, Scrum, DSDM of nog een andere propagandeert en gebruikt, dat is allemaal niet zo belangrijk. Ze hebben allen hun goede en zwakke kanten. En mits goed uitgevoerd kan je quasi elk project doen slagen met zowat elke methodologie.
Key is, volgens mijn nederig inzicht, de gebruiker, zijn taak en zijn omgeving. Als je daar rekening mee houdt vroeg in het proces, dan kom je er wel.
Gek genoeg doen ze dat meestal niet.
Beste Edwin, wederom dank voor je uitgebreide reactie.
We zitten volgens mij namelijk volledig op 1 lijn. Je raakt de kern met: “Je pikt de meeste requirements van de gebruikers wél op, wanneer je in een vroeg stadium aandacht voor hun hebt”.
Ik ben ervan overtuigd dat door middel van het maken van een goede requirementsanalyse /functioneel ontwerp je het gros van de problemen voorkomt. Dat is denk ik hoe je moet werken, je moet de klant kunnen adviseren vanuit jouw professionele ervaring hoe ze de oplossing eigenlijk ‘zouden moeten willen’ omdat jij de expert bent en weet hoe een website in elkaar steekt (met alles erop en eraan (shop/apps/ezine/koppelingen backoffice/beveiling/SEO etc).
Daarnaast is het managen van ‘scope creep’ een activiteit
die je tot kunst moet verheffen. Je kunt ook niet zeggen halverwege tijdens de bouw van een huis dat je toch de badkamer eigenlijk op het dak wil hebben, dan gaat dat je zeker geld kosten
Daarnaast zeg je terecht: “mits goed uitgevoerd kan je quasi elk project doen slagen met zowat elke methodologie.”
Daar zit de kern denk ik, de methodieken zullen allemaal in grote lijnen kloppen. maar de kneep zit hem in de uitvoering. Ik denk dat wij de uitvoering van het watervalmodel dusdanig hebben geperfectioneerd dat we nagenoeg elke project succesvol binnen budget, binnen planning, en met een zeer hoge kwaliteit kunnen doen.
Dat gezegd hebbende even een reactie op nog enkele zaken die je aanhaalt:
- Ik denk dat applicaties en website erg zijn veranderd sinds 1992. daarom wordt zoals jij bepleit, usability zeker belangrijker. De cijfers uit dat rapport van 1992 geloof ik echter niet meer zo.
- Het boekje “The Mythical Man-Month” is bij ons welbekend !
- je noemt wel steeds de factoren: aandacht voor de gebruiker en kwaliteit van de personen die binnen je project werken. Dat zijn natuurlijk vereisten voor het slagen van een project. Los van elke methodiek.
Je sluit af met : Key is, de gebruiker, zijn taak en zijn omgeving.
Ik sluit me daar volledig bij aan ! Deze kern, aangevuld met professioneel advies , best practices, goede code en strakke projectleiding kan toch niet anders dan een succesvol project opleveren? En dat zijn toch wel de ingrediënten die je moet kunnen
verwachten van een internetbureau anno 2010.
Bart,
Ik geloof best dat jullie implementatie van de Waterval methode kan werken hoor. Mits je de mantra ‘de gebruiker eerst’ toepast, dan is die methode niet slechter of beter dan een andere.
Maar geloof me vrij, in het segment waar ik actief ben, is dat niet de norm.
Zeker als de gebruiker Jan Modaal is of een laag geschoolde operator.
Als je dan oppert “Willen we eens met DIE mensen gaan praten?” dan zegt het middel management keihard o.a. de volgende zaken:
• Wat weten die er nu van? Die kunnen amper hun naam spellen, we gaan toch echt niet hun mening vragen?
• Ze moeten uitvoeren, wat wij zeggen. Punt.
• Als ik er mee kan werken, dan kunnen zij dat toch ook?
• Weet je wel wat dat kost? De ene wil groen, de andere rood, wel ze krijgen allemaal grijs.
Lees het barcode verhaal eens op mijn site. Da’s demonstratief voor onze business. Dezelfde soort problemen kom je zowel bij gewone applicaties als websites tegen.
Jammer dat er niets vermeld wordt over de eisen inzake de door W3.org opgestelde kleur- en helderheidscontrasten. Ik constateer regelmatig dat ontwerpers dingen maken die beeldschoon lijken op hun eigen (goed afgestelde) schermen. Ze zijn bovendien goed leesbaar door jonge getrainde ogen. Veel bezoekers zijn echter ouder, hebben wellicht last van kleurblindheid en hanteren schermen die niet goed zijn afgesteld en/of zijn geplaatst in minder optimale omgevingen. Wat te denken van de laptop in de trein of een scherm in de felle zon.
Onze eigen rijksoverheid startte het project logo 1 destijds met vastgelegde sRGB-kleuren voor alle 21 nieuwe huisstijlkleuren. Die bleken (pas veel later in het project) in het geheel niet te voldoen aan de W3C-eisen. Dus moesten al die kleuren allemaal aangepast te worden. Daardoor waren ze bovendien niet meer conform de drukkleuren waarop die bewuste huisstijl o.a. was gebaseerd. Maar dat terzijde.
Voor een overheid die zich verplicht om aan die bewuste eisen wel te voldoen is dat slordig. En bovendien kostbaar want hoe later in het project hoe groter de projectbudgetoverschrijdingen.
De eisen zoals vastgelegd door o.a. W3C, WCAG en HP zijn uitermate belangrijk.
Volgens mij horen ze in elk grafisch ontwerp van een site meegenomen te worden.
Laat een reactie achter!
Business »
‘Learnings’ van een dagje Business Modelling à la Osterwalder
Gisteren organiseerde het Stimuleringsfonds voor de Pers een ‘Business Modelling Day’. Een dagje stoeien met business modellen aan de hand van het business model canvas van Alexander Osterwalder.
Zoals gebruikelijk op dit soort dagen vliegen de …
Redactie »
De top 100 best gelezen Publishr.nl artikelen
De 100e nieuwsbrief van Publishr.nl wordt vandaag verzonden! Ter gelegenheid van onze jubileum nieuwsbrief publiceren wij de Publishr.nl top 100 best gelezen artikelen aller tijden.
Hot topics
Als we naar de belangrijkste topics kijken dan …
Social media »
Strategisch inzetten van social media in de mediabranche
Door de sterke positie die social media inneemt binnen het medialandschap, is het zeer belangrijk om social media niet meer als hype, maar als strategische tool te benaderen. Strategisch, omdat social media zeer veel mogelijkheden …
Techniek »
Eenvoudig inloggen met Facebook, Twitter of LinkedIn
De discussie over online datamining en de paywall blijft actueel. Uitgevers willen weten wie hun content consumeert, hier de content en campagnes op afstemmen en het liefst profielen van gebruikers samenstellen. Belangrijk hierin is het …
Trends »
Nieuw online verdienmodel: de concurrenten?
Webwinkel bol.com heeft het afgelopen jaar afgesloten met een recordomzet van 376 miljoen euro, 18 procent meer dan een jaar eerder. Steeds meer mensen kopen steeds meer producten bij Bol.com. De belangrijkste reden van deze …
Archief
Blogroll
Thema's
Willekeurige berichten
Laatste video
nieuwste berichten
Laatste reacties
Top 10 artikelen
Realisatie door Liones | Berichten (RSS) | LinkedIn Group: Online Publishing NL | Functioneel Ontwerpen, alles over FO's | Technisch Ontwerp, alles over TO's