Webdeveloppers gebruiken vaak de term ‘wireframes’ (ook wel eens ‘interactie-ontwerp’ genoemd). Dit artikel geeft een uitleg wat wireframes zijn, hoe ze kunnen worden ingezet, hoe je zelf wireframes ontwikkelt en waarom wireframes belangrijk zijn in het proces van het ontwikkelen van een website of (web)applicatie.
Wat zijn wireframes?
Wireframes zijn een visueel hulpmiddel bij het ontwikkelen van een website of -applicatie. Ze kunnen gezien worden als de bouwtekening van een website, waarin een overzicht wordt gegeven van de verschillende onderdelen die op een website aanwezig zullen zijn.
In de wireframes worden zaken vastgelegd als navigatie, indeling en inhoud, zonder gebruik te maken van een grafisch ontwerp. Het grote voordeel is dat alleen op de inhoud gefocust wordt en niet op het grafische aspect (en of het dus ‘mooi‘ is of niet).
Een voorbeeld van Wireframes van een bekende zoekmachine.
Wanneer worden wireframes ingezet?
Vanaf het eerste moment dat de doelstellingen van de website bekend zijn kunnen de ideeën in wireframes uitgewerkt worden. Het is goed dat zo vroeg mogelijk in het proces wordt begonnen met een visuele functionele weergave van een website of applicatie, zonder daarbij nog over vormgeving na te denken.
Communicatiehulpmiddel
Met wireframes kun je helder communiceren met de betrokkenen bij een webproject (klant, projectmanager, front-end developer, programmeur, zoekmachinespecialist). Regelmatig merken wij dat onze klanten onbewust wireframes beginnen te tekenen om hun concept te verduidelijken zodra zij hun idee beginnen te verwoorden.
Concept toetsen
Het mooie van wireframes is daarnaast dat je snel een concept kunt toetsten, niet alleen om te kijken of het idee goed is uitgewerkt, maar ook of het op het gebied van gebruiksvriendelijkheid voldoet. Begrijpt de gebruiker wel hoe de website of applicatie in elkaar zit? In het algemeen zijn wireframes eenvoudig om te zetten in een werkend (klikbaar) prototype om zo nog meer test-data te verzamelen alvorens het concept te laten uitwerken tot een grafisch ontwerp.
Hoe maak je een wireframe?
Er zijn verschillende manieren om een wireframe te maken. Uiteraard kan je ze zelf tekenen met behulp van pen en ruitjespapier. Daarnaast zijn er ook een aantal programma’s die je hierbij kunnen ondersteunen. Ik heb hieronder vier programma’s kort te beschreven waarmee wij zelf ervaring hebben. Uiteraard zijn er veel meer programma’s, maar dat gaat iets te ver voor deze introductie in wireframes.
Microsoft Visio
Visio is ontwikkeld als programma om complexe situaties te modelleren en relaties in kaart te brengen. De standaard aanwezige functionaliteit gaat veel verder dan het maken van wireframes, en deze rijkdom aan mogelijkheden kan voor een beginner overweldigend zijn.
Hierboven zie je een voorbeeld van een Wireframe in Microsoft Visio
Microsoft Powerpoint
Het mooie van Powerpoint is dat bijna iedereen het op zijn computer heeft staan en kennis heeft van dit programma. Uiteraard is Powerpoint niet bedoeld om wireframes op te maken en moet je alle elementen zelf ontwerpen. Gelukkig heeft Yahoo een bestand samengesteld, waarin de meeste basiselementen van een webpagina zijn te downloaden.
Dit scheelt een hoop tekenwerk! Een andere tijdsbesparing is het aanmaken van masterslides met de basis-layout, zodat je deze eenvoudig kan aanpassen. Een groot nadeel van Powerpoint is dat het veel werk kost om te maken, maar ook om aan te passen. Daarnaast bestaat er een kans dat de discussie over layout gaat, doordat de elementen allemaal (te) netjes vormgegeven zijn.
Hierboven zie je een voorbeeld van een Wireframe in Powerpoint
Adobe Indesign
Veel designers gebruiken Indesign (of Illustrator) om Wireframes mee te maken. Dit programma biedt veel tekenmogelijkheden en ook kun je eenvoudig schuiven met elementen. Je moet dan wel beschikking hebben over dit programma en enige ervaring om hier snel een opzet mee te kunnen maken. Een groot nadeel is dat mensen vaak te gedetailleerd willen gaan ontwerpen in Indesign, vaak worden hier al zaken als een grid in vastgelegd. Terwijl dit juist zaken zijn die pas in de designfase bepaald moeten worden. Laten we eerst zorgen dat alles logisch in elkaar zit.
Hierboven zie je een voorbeeld van een Wireframe in Adobe Indesign
Balsamiq
Eén van de grote nadelen van de bovenstaande programma’s is dat de wireframes teveel op een design lijken, waardoor een discussie al snel over uitlijning en kleur gaat en niet over waar het over zou moeten gaan: de benodigde elementen binnen een interface.
Balsamiq onderkent dit probleem en heeft een erg gebruiksvriendelijk programma ontwikkeld dat als output een “sketch style” heeft, hierdoor is het altijd duidelijk dat het om een grove schets gaat en zal de discussie minder snel over opmaak gaan. Een beperking van Balasamiq is dat je bij grote websites met veel verschillende documenten werkt en je erg georganiseerd moet werken om door het bomen het bos nog te zien.
Hierboven zie je een voorbeeld van een Wireframe in Balsamiq
Uiteindelijk moet je vooral een programma gebruiken waarmee je prettig werkt. Elk programma heeft zo zijn voordelen en nadelen, het belangrijkste is dat er geen drempel is om het te gebruiken (anders kun je beter pen en papier gebruiken). Houdt er wel rekening mee dat je een bestand vaak zal moeten aanpassen.
Enkele tips voor het maken van Wireframes
Bij het ontwikkelen van wireframes is het goed om een aantal punten in acht te nemen:
- Wees consistent met de elementen in een wireframe. Als je een bepaald type knop gebruikt voor een actie, gebruik dan altijd die knop voor acties. Dit zorgt er voor dat de applicatie al snel intuïtief in gebruik is voor de eindgebruiker.
- Don’t repeat yourself! Een bekende regel uit het programmeren geldt voor het ontwikkelen van wireframes. Zorg dat je eenmalig een menu opbouwt en de basisstructuur en dat de overige wireframes hierop gebaseerd zijn. Mocht dan onverhoopt halverwege de navigatie veranderen dan is dit snel over te nemen in alle wireframes.
- Zorg ervoor dat je goed georganiseerd te werk gaat. Doordat er veel versies van de wireframes gemaakt worden is het belangrijk goed de verschillende versies bij te houden (bijvoorbeeld met versie- of datumnummers).
- Maak je vooral niet druk over uitlijning, zorg er eerder voor dat dit er niet teveel in zit. Dit voorkomt dat de discussie zich verplaatst van inhoud naar opmaak.
- Betrek de klant: Laat de klant vooral op de wireframes tekenen, stimuleer ze om andere oplossing/ideeën uit te tekenen. Dit geeft niet alleen meer feeling met de mogelijke problemen, maar is ook de eenvoudigste manier van communiceren (in plaats van een uitgebreid document met abstracte beschrijvingen)
Wireframes besparen tijd en kosten
Hoe klein een website ook is, onze ervaring is dat het altijd verstandig is om eerst wireframes te maken. Mensen denken vaak dat dit extra kosten en tijd met zich meebrengt, maar uiteindelijk bespaart het juist tijd (en kosten). Op het moment dat de wireframes goedgekeurd zijn kan de designer aan de slag en voor kleine projecten heeft een eventuele programmeur hier voldoende aan om een functioneel ontwerp (FO) uit op te maken.
Het scheelt alle partijen veel frustratie dat werk niet constant opnieuw gedaan hoeft te worden, omdat er in het begin niet goed over nagedacht is. De designers en programmeurs hoeven hun werk niet constant aan te passen aan nieuwe eisen en wensen. Uiteraard is het niet uitgesloten dat er geen aanpassingen meer plaatsvinden, maar het aantal aanpassingen zal zeker afnemen.
Daarnaast krijgt de klant veel meer feeling met het project. In de praktijk merken wij dat klanten het proces erg leuk en nuttig vinden.
Petshop 
Wouter 
Samuel Driessen 
Wim Leegwater 
michel van der bij 
de firefox ‘pencil’ add-on is een geweldige en erg simpele wireframe tool, erg functioneel.
Nog een alternatief is iPlotz, dat veel weg heeft van Balsamiq. iPlotz heeft bovendien een online versie; Balsamiq werkt daar nog aan.
Ik werk eigenlijk altijd in Visio. Er zijn handige Stencils beschikbaar die het maken van een Wireframe nog makkelijker maken.
Wij werken al een tijdje met Omnigraffle en sinds kort ook met Balsamiq. Erg efficient en voor de klant ook goed inzichtelijk wat er gaat gebeuren!
Ik maak veel gebruik van axure. echt een must voor de creatie van wireframes. Mooie van axure is dat je met “Masters” kunt werken wat je ontwerpen erg consistent maakt.
http://www.axure.com
Dit is ook een leuke online wireframe tool.
http://gomockingbird.com/
Cheers,
Justin
Mijn ervaring met Axure is dat het toch net niet zo snel en lekker werkt als Visio. Met Visio kun je overigens ook prima met masters werken. En er is een handige macro voor Visio te krijgen waarmee je ook direct documentatie genereert.
Deze is ook interessant:
https://pidoco.com/en
En nog een mooi lijstje van tools:
http://articles.sitepoint.com/article/tools-prototyping-wireframing
Olaf@ilink.nl
Toevoeging op bovenstaande, uitstekende suggesties: HotGloo, http://hello.hotgloo.com
Overigens, 2 punten nav dit artikel:
- imho maakt een programmeur/developer een Technisch Ontwerp (TO), en wordt een FO niet perse door techniek gemaakt, zelfs beter van niet. Een team met een combinatie van architect/designer/interaction-designer/usability expert is vaak het beste om een goed FO te ontwikkelen. Een goed FO staat nl ook los van techniek, en is puur op functie gericht.
- hoe gaan jullie om met vorm vs wireframes? In mijn ervaring is de eerste stap nl echt een een-tweetje met een designer en een interaction designer. Je kunt als wireframer nl pas aan de slag als er ook al iets van een “zoning” is gedaan, want ook met wireframes ben je eigenlijk al met vorm bezig, al is het alleen nog maar vlak-indeling en verhoudingen. Imho is de ideale manier om een interaction designer te laten bepalen welke informatie in welke schermen getoond moet worden, een designer hier een rough design bij te laten ontwikkelen, en hier vervolgens door de interaction designer weer een wireframe overheen te leggen en bij te sturen, zodat design en wireframes elkaar wederzijds beinvloeden en uiteindelijk tegelijkertijd zowel een design als een bijbehorend wireframe/interaction document wordt opgeleverd.
Ben benieuwd naar jullie ideeen hierover, ik hoor nl altijd veel verschillende ideeen hierover, maar de praktijk is vaak weerbarstig :)
Olaf at ilink.nl
Wellicht ook interessant: met Axure kun je ook vanuit de wireframes een clickable demo maken.
Wat mij betreft ook de enige echte wireframe oplossing zoals hierboven genoemd.Visio komt dicht bij. Powerpoint is wat mij betreft eerder voor business mensen om hun ideeen in weer te geven. Indesign / illustrator is toch veel bewerkelijker, wat mij betreft niet efficient voor wireframe development.
Balsamiq gebruiken we nu meer en meer als concept schetser. Voor het uitwerken van alle templates van een website is Balsamiq toch te beperkt.
Wachten is nu tot Axure ook een sketch look heeft :-)
@Lennaert: voila ;) http://consulting.ascentium.com/blog/ux-seo/Post222.aspx
Overigens kan je met Balsamiq je wireframes exporteren naar Flex, waar je heel makkelijk een clickable prototype mee kunt bouwen.
wireframes zijn een hele fijne manier van site ontwikkeling. punt is dat vooral de klant moet begrijpen wat hij ziet. ook de FO ontwikkelaar en de grafisch designer moeten goed begrijpen waar functionaliteit begint en design ophoudt. ik heb vaak genoeg webdesigners van wireframes voorzien, maar denk maar niet dat ik iets terug kreeg wat daar enigzins inpaste.
het fijne aan wireframes is vooral dat de functionaliteit en het gedrag van pagina’s zichtbaar wordt en niet het plaatje. het belang hiervan moet in een vroeg stadiGum erkend worden, anders krijg je na oplevering een hoop misverstanden. veel mensen hebben worden helemaal wild van het kleurtje en het plaatje maar kunnen zich niets voorstellen bij het functioneel gedrag van een site.
nog een aspect is content management systemen. door in wireframes te werken kun je design en interactiviteit zodanig scheiden dat je deze vrijwel onafhankelijk en vooral tegelijkertijd kunt ontwikkelen. ik doe dat heel graag, eerst een wireframe bouwen, kan iedereen zijn dingetje aanleveren en vervolgens ziet iedereen zijn bijdrage vlot op de website verschijnen. Dan zijn correcties ook snel gemaakt tijdens het proces. Het meeste werk zit hem mijns inziens in het inpassen van het grafische werk in het wireframe. Dit zou een taak moeten zijn van de grafisch ontwerper, maar ik zie dat zelden door hem/haar gebeuren. Het afmaken van een site is bijna altijd een zaak van de techneut. de techneut is de pineut zeg maar….
wireframes dus een goede stap in de richting, maar het blijft allemaal mensenwerk…
@blogdog: daarom is het ook essentieel dat (front-end) designer en interactiondesigner(wirefames) met elkaar samenwerken, want design beinvloed interactiviteit, en andersom.
Het klopt dat het voor opdrachtgevers vaak heel lastig is om wireframes, interaction designs en FO’s te lezen en te begrijpen. Daarom ben ik ook een groot voorstander van de SCRUM methodiek: ontwikkel in je eerste sprint een minimaal benodigd FO met wireframes en interaction design, dus geen weken of maanden knutselen aan een uitgebreid FO dat niet begrepen wordt en al achterhaald is als er daadwerkelijk ontwikkeld gaat worden. Vervolgens in snelle iteratieve sprints dit basis-FO prototypen, en direct met de opdrachtgever reviewen en evt. bijsturen. Werkt echt veel beter.
@olaf Ik ben het geheel met je eens. Die mega-FO’s en uitgebreide designsessies gaan vaak genoeg ongelezen de kast in. Maar ze dienen wel vaak als arbitrage document als de opdrachtgever ontevreden is. Deze nieuwe werkwijze moet dus wel op een andere manier borgen dat de opdrachtgever weet wat hij mag verwachten.
Eern tool die volgens mij minstens zo goed als Axure of Balsamiq, is Flairbuilder. Beschikbaar in online en desktopversie. Komt ook met een gratis viewer waarin het project dan door iedereen bekeken kan worden.
Vooral geschikt voor websites en basisinteracties. Ik zou niet aanraden er een hele toepassing in te maken.
Bijkomend voordeel: de prijs.
@blogdog: dat is idd de grote uitdaging, daarom geloof ik eigenlijk ook niet meer in fixed-price projecten als het om complexere online projecten gaat. De requirements die steeds veranderen door voortschrijdend inzicht bij zowel klant als developers maken dat je eigenlijk van tevoren niet meer sluitend kunt definieren wat en hoe voor hoeveel. Gooi het open, bepaal met elkaar welk budget er is, en bepaal welke minimale “Stories” je nodig hebt om release 1.0 live te kunnen gooien. Door de sprints heb je gedurende het proces allemaal inzicht in de verbruikte uren, en dus je budget, en ook in de snelheid die je dev-team maakt. Dit is gewoon de realiteit, hoe vervelend dat soms ook is voor opdrachtgevers die denken dat ze voor een vast bedrag *alles* kunnen krijgen, inclusief zaken die niet in een document gedefinieerd zijn.
Daarom ben ik ervan overtuigd dat je een project als partners in moet gaan, en niet als opdrachtgever/opdrachtnemer.
@olaf ben ik ook met je eens. als je een goede vertrouwensrelatie hebt met je opdrachtgever dan kan het ook wel. alleen is nu juist de trend dat opdrachtgevers minder bereid zijn risico’s te lopen of te dragen.
fixed price is achterhaald, maar ik vind het niet makkelijk om dan toch goede raamovereenkomsten in elkaar te zetten. vergelijk je sitebouw met het bouwen van een huis dan zijn er nog teveel opdrachtgevers die na de bouw nog wel eens vragen of het huis niet ergens anders neergezet kan worden, maar dan met een kelder en een hele andere indeling… wireframes is wel een goed middel om in een vroeger stadium dit soort zaken af te kaarten. ik denk dat faseren en concensus na iedere fase van belang is…
@blogdog: helemaal mee eens, dit is de grote uitdaging van (online) projecten.
ik begin in vrijwel alle gevallen met pen en papier, ver uit de buurt van een computer. Soms is dit al voeldoende, afhankelijk van het project. De uitgeschetste ideeën verwerk ik hierna in een wireframe dat ik maak met Keynote (de ‘Powerpoint’ van Apple). Hiervoor heb ik ooit zelf een uitgebreide collectie interface-elementen aangemaakt die ik keer op keer opnieuw gebruik.
interessant artikel , @blogdog @olaf goede discussie. Ik ben er persoonlijk van overtuigd dat fixed price projecten niet zonder ontwerp kunnen, en het is dus in het belang van zowel opdrachtgever als uitvoerder om de wensen goed vast te leggen. Gelukkig worden klanten ook steeds meer internetwise en is er veel sneller begrip om de afspraken voldoende vast te leggen. In de serie websites op maat in het watervalmodel op Publishr, http://www.publishr.nl/2009/10/websites-op-maat-in-het-watervalmodel/ ga ik hier zelf nog dieper op in. wellicht hebben jullie hier nog tips of aanvullingen op.
@Bart: het probleem met interactieve deliverables is: wat je op papier vastlegt is per definitie een multi-interpretabel document, *als* je al kunt begrijpen wat er staat beschreven. Je kunt dus nog zo uitgebreid beschrijven, je houdt altijd discussie. Het is eigenlijk hetzelfde als een film op papier proberen te beschrijven, er zijn miljarden verschillende manieren om het script/plot te interpreteren en te verfilmen. Je probeert in 2 dimensies iets dat 3 of misschien wel 4 dimensies is vast te leggen. Daarom ben ik van mening dat je beter zsm kunt beginnen met het prototypen van een interactief model, nadat je natuurlijk wel de basics hebt vastgelegd in een minimaal interaction ontwerp/FO. Alleen is dat document meer voor de developers, dan voor de opdrachtgever.
@olaf
Deels eens, wellicht als je inderdaad spreekt over ‘interactieve deliverables’, ik ga er dan gemakshalve vanuit dat je webapps of flash sites bedoeld. Het vormgeven en ontwerpen en uitwerken van een functioneel/grafisch/technisch ontwerp is voor de meeste zakelijke informatieve sites geen enkel probleem, een website is natuurlijk al lang geen rocket science meer. Een wireframe kan hier goed aan bijdragen. Prototypen moet je mijns inziens alleen doen bij sites waarvan je van te voren niet goed kunt inschatten wat de site echt moet gaan doen (ingewikkelde workflow of ingewikkelde interactie). Voor het gros van de sites is een uitgewerkt functioneel ontwerp ook niet een hele grote klus maar het scheelt wel overhead en ontevredenheid, en levert je on the long run gewoon geld op. Maar dat is na het doen/overzien van ca 400 projecten mijn bescheiden ervaring, de projecten MET ontwerp zijn gewoon veel strakker te managen op het gebeid van kosten, deadline en kwaliteit, resulterend in een win/win voor klant en opdrachtgever.
Ik zeg niet dat je geen ontwerp moet hebben, ik zeg dat je niet moet proberen om een uitputtend ontwerp te maken, omdat het toch lang niet alles kan bevatten. Maak dus een minimaal ontwerp, en ga vanaf daar prototypen. (mijn bescheiden mening met 14 jaar internet-projecten ervaring ;)
@bart ik wil niets afdoen aan je ervaring waar ik niet aan kan tippen, maar ik vind dat websites tegenwoordig meer rocket science zijn dan ooit. SEO, Usability, Analytics, Animaties, Ajax (of niet), Browsercompatibility, accessability, er zijn veel meer dimensies aan websites dan pakweg 6 jaar geleden en ik denk dat de klant vaak veel minder overzicht over al deze zaken heeft dan je als leverancier zou willen.
Elk succesvol project begint met een goed plan, en een FO is een onmisbaar onderdeel. In mijn ervaring zijn de meeste FO’s echter te summier of te abstract waardoor er veel ruimte is voor interpretatie waar Olaf het over heeft.
Wireframes en wellicht andere intermediate deliverables zijn vaak noodzakelijk om de trein op de rails te houden, en ervoor te zorgen dat je als uitvoerder niet telkens terug naar start wordt gestuurd. Ik zou willen dat dit juist meer wordt omarmd en ook gezien wordt als best practice.
@olaf ik denk echt dat het toch goed mogelijk is. Als je een goede functioneel ontwerper in dienst hebt kom je echt een heel eind. Ik wilde je ook zeker niet afschilderen als iemand die kennis van zaken heeft, bedankt voor jouw reactie!
@blogdog
Wees je ervan bewust dat veel internetbouwers en experts en consultants deze ontwikkelingen jarenlang van dag tot dag op de voet hebben gevolgd. Usability was in de jaren negentig (Nielsen) al een issue, Analytics draait al vanaf 2005 voor het grote publiek, SEO is ongoing evenals de nieuwe frontend-technieken die je opnoemt. De klant heeft hier wellicht geen goed overzicht van, maar that’s where you come in als expert! Met jouw advies stuur je de klant de kant op door gebruik te maken van de best practices , bewezen technieken en succesvolle cases (lijkt wel een vacaturetekst zo). Fijn dat je ervaring is dat een FO een onmisbaar onderdeel is, ik sluit hier volledig bij aan. Jammer dat ze jouws inziens te summier zijn of soms te abstract. Maar denk je niet dat dit misschien aan de maker van het FO ligt? De oplossing zit hem er niet in om te accepteren dat FO’s onvoldoende worden uitgewerkt, en het geijkte proces dan maar helemaal los te laten, maar mijns inziens in het perfectioneren en vervolmaken van de ontwerpen. (hebben we zelf doorgevoerd, en werkt uitstekend). Nog even een kanttekening: ik spreek dan dus nog steeds over de zakelijke informatieve sites, niet over flash-sites of zeer complexe webapplicaties.
Ik heb FO’s van meer dan honderd paginas voorbij zien komen, geen enkele garantie op dat wat er in staat ook gesnapt wordt door zowel de opdrachtgever als de developers die er een TO van moeten maken. Ook bij zakelijke informatieve sites lijkt het me vrij onmogelijk om in een FO te beschrijven op welke manier bv een panel uitklapt of slide, met welke snelheid, met welke geluidjes er wel of niet bij, wat die button precies doet als je er met je muis overheen beweegt, hoe validatie-velden precies je form in komen, en weer weg gaan, etc. Kortom: alle interactieve elementen. Je kunt je een ons beschrijven, nog steeds is wat er staat alsof je muziek in woorden probeert te beschrijven. Iedereen leest er wat anders in.
Maargoed, we zijn het er dus allemaal wel over eens dat een goed FO met wireframes, design en interaction-design benodigd is, alleen niet tot in hoever je daar moet gaan. :)
Mooi om te zien dat wireframes steeds meer ingeburgerd raken. Persoonlijk denk ik dat je nog wel een aantal voordelen van wireframes onderbelicht laat, en hoe je deze het beste kunt opzetten (maar misschien was dat ook niet de bedoeling van je artikel).
@Olaf: je vraag over vorm vs wireframes is interessant. Je voorstel om een interactie ontwerper en designer samen te laten werken in een vroeg stadium is een goede, alleen passen wij dat iets anders toe.
Wireframes veranderen – zeker in het begin – veel. De klant ziet consequenties van wensen in, er komt extra informatie boven tafel, uitgangspunten wijzigen etc. Als je dan al (ook al zijn het ruwe) designs hebt moet je op twee vlakken veel bijwerken. Wij sparren wel in een vroeg stadium met designers om input te krijgen, maar pas als de wireframes gestabiliseerd zijn worden deze naar grafische designs omgezet. Zo werk je efficiënter en voorkom je dat de klant over kleuren begint in het stadium waar dit geen toegevoegde waarde heeft.
Voor lezers die geïnteresseerd zijn in wireframes, ik heb een tijdje terug een artikel geschreven over interactie-ontwerp, waarin wireframes ook uitgebreid aan bod komen. Wie weet staat ook hier nog wat interessants voor jullie in.
@bart je slaat de spijker op zijn kop: het komt allemaal neer op goede ervaren mensen die weten waar ze het over hebben. eigenlijk mijn punt op al mijn comments, niet alleen op dit artikel. maar dit is een beetje utopisch, misschien niet voor jou, en in de meeste gevallen ook niet voor mij, maar bij grote projecten met veel betrokkenen en een iets te ver doorgevoerd poldermodel gaat het toch niet altijd soepel om op basis van papieren plannen… is mijn 2cent ervaring… in intermediate deliverables kun je een hoop van die kwaliteit kwijt.
@Olaf
Dat vind ik een interessante discussie, tot hoever moet je gaan? Als je nou zelf voorstander bent van prototypes, dan ga je toch niet uiten treure beschrijven in een FO hoe een menu openslide? Dan pak je een goed voorbeeld uit de praktijk, laat dit in de FO sessie aan de klant zien, en vraagt: is dit soms wat u bedoeld? Dat documenteer je vervolgens netjes in je FO, desnoods met referentie (en / of screenshot, scheelt weer wireframes ;) ).
Je FO moet een verzameling zijn van best practices, en als je het slim doet heb je na verloop van tijd behoorlijk veel standaardfunctionaliteit gedocumenteerd die je in de volgende FO’s weer kunt hergebruiken. Je doet het nu een beetje voorkomen alsof je moet gaan beschrijven en vastleggen hoe het internet werkt voor een klant , dat lijkt me niet de bedoeling.
En als je FO’s niet begrijpelijk zijn voor je klanten of developers, dan doet je business analist toch echt wat fout. (ergo :vertaalt hij de klantwensen blijkbara niet goed naar oplossingen)
@Olaf: een FO kan imho wel degelijk toegevoegde waarde hebben. Je schrijft: “Ook bij zakelijke informatieve sites lijkt het me vrij onmogelijk om in een FO te beschrijven op welke manier bv een panel uitklapt of slide, met welke snelheid, met welke geluidjes er wel of niet bij, wat die button precies doet als je er met je muis overheen beweegt, hoe validatie-velden precies je form in komen, en weer weg gaan, etc. Kortom: alle interactieve elementen”
Als je in je wireframes alle unieke pagina’s en componenten beschrijft en uitwerkt (bv de generieke opzet van een formulier, inclusief weergave van foutmeldingen, hoe ze eruitzien etc), dan kun je een FO aardig waterdicht krijgen, zonder dat het je erg veel tijd kost: veel hangt van de opzet van de wireframes af. En 100% waterdicht krijg je het toch niet ;-) Voor de volledigheid: een FO volgt bij ons ná de wireframes, en niet vooraf zoals in de praktijk ook voorkomt
@Ivo: in hoeverre vind je de “zoning”, dus de vlak-indeling, design danwel interaction design? In mijn opinie is het nl al design, omdat je bezig bent met meer dan informatie in een scherm, maar ook al in welke verhoudingen en op welke plaats, en dat zie ik als design. Maar het blijft een lastige discussie. Als je zegt dat je moet beginnen met wireframes worden designers dan niet gedegradeerd tot alleen maar een soort “skinners”? :)
@blogdog fijn dat we daar hetzelfde over denken!
ik snap helemaal wat je zegt over die grotere projecten, zeer herkenbaar. Maar, daar zit het probleem mijns inziens toch vaker in het projectmanagement en het managen van de klant en zijn verwachtingen dan in de feitelijke ontwerpen is mijn ervaring (want draagvlaak creeren, iedereen moet zijn plasje erover doen etc, de een wil het zus de ander zo etc). Een slagvaardige (internetwijze!) projectleider doet in dat soort projecten wonderen. (en soms moet je gewoon iemand bij de klant hebben zitten die de knopen doorhakt). Met intermediate deliverables bedoel je denk ik deelopleveringen, maar daar ben ik ook absoluut voor. Alleen dien je de workpackages wel uitgewerkt te hebben in een FO voor elke deeloplevering, anders zul je blijven verzanden in discussies over RFC’s en wat zat er nou wel of niet buiten scope (lees: een rampproject)
Helaas komt het nog soms voor dat mensen zonder verstand van zaken een ontwerp maken, of bedenken dat het een goed idee is als de navigatie op elke pagina op een andere plek staat. Maar goed, uiteindelijk komen de klanten van dat soort mensen toch wel bij jou en mij me dunkt ;)
@Olaf: de vlak-indeling blijft altijd een lastige scheidslijn. De informatie op een pagina moet logisch gestructureerd zijn, en afgestemd op de behoeften van de bezoeker. Als interactie-ontwerper denk je daarom na over de elementen op een pagina, en waar ze staan en waarom. Het is een bewuste, onderbouwde keuze. Onze designers hebben de vrees ‘skinners’ te worden ook uitgesproken, maar in de praktijk zijn ze juist erg tevreden. Omdat er goed is nagedacht over de indeling van de pagina (en de flow door de site) kunnen zij zich volledig concentreren op de vormgeving, waar ze vroeger – voor we ID-ers inzetten – allerlei ontwerp-beslissingen moesten nemen die als lastig werden ervaren. Bovendien geeft een ID-er aan wáár iets moet komen, niet tot in de puntjes hoe het er uit moet zien. Doordat ze in een vroeg stadium betrokken worden kunnen ze ook waardevolle input leveren, waar je als ID-er rekening mee houdt. Op deze manier bereik je in mijn ogen de beste resultaten: je krijgt een doordachte website die usable is, én er grafisch goed uitziet. Als één van de twee niet goed is uitgevoerd heb je een probleem… ;-)
@bart precies, ik zie dat we in dezelfde loopgraven hebben gezeten. Met intermediate deliverables bedoel ik oa wireframes, maar ook design mockups, CMS componenten en UI componenten. Een goed plan (FO), Expectancy management, project management en vooral mensen met verstand van zaken zijn de ingredienten voor een succes. De FO’s waar internet opnieuw wordt uitgevonden ken ik ook… diepe zucht. Het liefst wil je naar een werkwijze waar FO’s heel compact zijn, en detailinvulling aan een klein team professionals wordt overgelaten.
Handige tool om wireframes te maken is wellicht ook Lovelycharts.com
Leuk om te merken dat er zoveel goede tips en reacties komen op dit artikel!
Paar goede alternatieven voor in het artikel genoemde programma’s (uit de reacties):
Olaf stipt terecht aan dat een FO niet door een programmeur/developer wordt gemaakt. Ik ben zelf ook van mening dat een goed FO door meerdere disciplines wordt gemaakt. Als ik kijk naar onze workflow zit daar altijd iemand van strategie, een designer, een interaction/usability expert en iemand vanuit techniek. Uiteraard vormen de wireframes maar een gedeelte van het FO.
Blogdog maakt terecht de opmerking dat de wireframes ook een goed arbitrage document vormen als de opdrachtgever ontevreden is of er onenigheid bestaat over de verwachtingen. In de praktijk laten wij de klant dan ook altijd alle wireframes ondertekenen, zodat we later geen discussie bestaat over bijvoorbeeld de functionaliteiten (of in iedergeval minder). We kunnen dan altijd duidelijk aantonen dat bepaalde zaken niet zijn meegenomen in de begroting.
@Hans: helpt dat ondertekenen van de wireframes als arbitrage document? Aangezien in een FO pas de échte verdiepingsslag gemaakt wordt (en waar – iig in mijn ervaring – ook de meeste discussiepunten ontdekt worden).
Voor diegenenen die geïnteresseerd zijn geraakt in genoemde wireframepakketten in dit artikel en de comments, is een achtergrond van een aantal pakketten na te lezen in Review wireframepakketten (deel 1)
[Disclaimer: ik ben co-auteur van dat artikel, en het is niet mijn bedoeling te spammen. Als het zo ervaren wordt hoor ik het graag]
Hi guys,
thanks for mentioning pidoco in your blog! Although I do not really understand Dutch, let me point out that pidoco has a lot more to offer than just wireframing. Since we want to support the complete user centered design process, we integrated some cool usability testing features like expert reviews an a remote usability tester with which you can perform one2one usability test session via a shared screen and a flex phone.Check out our <a href=”https://pidoco.com/en/wireframe-tool-en”>wireframing tool</a> or give me a buzz when you have more questions: +49-30-4881 63 82Michael from pidoco°
@Ivo: Uiteraard is dit niet waterdicht, maar het geeft je iets meer houvast. Dit is ook de reden dat wij de Wireframes aanpassen en doorsturen naar de klant bij eventuele toevoegen gedurende het project. Goede aanvullende link, ben benieuwd naar deel2.
Ik begrijp niet zo goed dat je bij Powerpoint en Visio aangeeft dat het risico is dat het juist al te veel op een ‘design’ lijkt. Dat vind ik in die gevallen juist totaal niet het geval. Powerpoint vind ik verder een erg vreemd platform om te gebruiken voor interactie ontwerpen, maar goed met wat templates kan alles.
Wij gebruiken zelf Adobe Fireworks voor IxD en voegen eventuele beschrijvingen toe in Omnigraffle (nadeel is dat de laatste Mac only is). Voordeel van Fireworks is dat je de wireframes heel makkelijk clickable kan maken en naar html kan exporteren wat handig is voor early prototypes of gebruikersonderzoeken. Daarnaast kunnen onze vormgevers en developers er meteen mee aan de slag en hoeven zij pagina’s niet vanaf het begin opnieuw op te gaan bouwen met een visio of powerpoint printje er naast.
Zelf heb ik ook in Fireworks wat ‘sketchbook’ elementen aangemaakt om het schetserige gevoel in de wireframes te krijgen. Een risico hiervan is echter weer dat ook dat een visuele ‘stijl’ opzich zelf is en dus misschien juist bepaalde gevoelens oproept bij de klant die je niet zou hebben wanneer je echt een zwart/wit/rechte lijnen IxD neerlegt.
[...] in Frankwatching (het gehele [...]
Fijn en helder artikel! Wireframes, de backbone van een ontwerp…
@Olaf en @Ivo Een ontwerp is idealiter multidisciplinaire samengesteld is mijn stelling. Ik heb geleerd en ervaren dat elke UI altijd uit de driedeling concept/interactie, vorm en inhoud bestaat, die staan niet los van elkaar. Veel interaction designers vervullen naast hun eigen rol ook min of meer de rol van vormgever, information designer of redacteur. Ik vind het wat kort door de bocht om te zeggen dat je met een zo ver mogelijk uitgewerkt wireframe, het alleen maar makkelijker maakt voor de vormgeving. Ik denk dat er dan kansen tot een optimaler ontwerp gemist worden.
Wanneer de gelegenheid er is om veel meer in aanvang van de ontwerpfase samen met een vormgever en information designer of redacteur aan een ontwerp te werken, heb je een optimale combinatie. Vast staat dat je als interaction designer de eerste contouren bepaalt van het concept en de hoofdinteractie van een ontwerp via o.a. flows en wireframe. Door het echter zo snel mogelijk multidisciplinair op te pakken zie je verrassende verbeteringen op een wireframe (concept/interactie); sterker, een wireframe kan zelfs fundamenteel wijzigingen. De inzichten vanuit grafisch ontwerp en information design en redacteur geven nl. net die puntjes op de i waar je als interaction designer niet altijd op bedacht bent (laat staan de vertaling naar kunt maken).
Ik denk wel dat de interaction designer in de lead is: ontwerpbeslissingen staan in eerste intstantie in dienst van de bruikbaarheid (het specialisme van de interaction designer). Ik denk alleen wel dat de inzichten van andere disciplines in een vroeg stadium van het ontwerpproces tot een nog beter resultaat leiden, een bruikbaarder ontwerp. Vooral voor minder ervaren interaction designers gaat dit op denk ik, hoe meer ervaren hoe beter onderlegd in de expertises van de andere dissciplines (maar nooit volledig).
@Anouschka: ik ben het absoluut met je eens: juist door samen te werken wordt je eindresultaat beter. Ik bedoel ook niet een zo ver mogelijk uitgewerkt wireframe, maar het moet ook geen draft meer zijn.
Het verbaasd mij dat Adobe Fireworks niet is meegenomen in dit artikel?
Ik maak tot nu toe nog steeds wireframes op papier. Vooral omdat ik vind dat dit makkelijker overlegd met de klant.
Ik ga de programma’s bekijken, maar ontwerpen op papier blijft mijn voorkeur houden.
[...] Gelezen op Frankwatching (gehele artikel) [...]
[...] Bird een is handige tool om zogenaamde Wireframes te maken. De website ziet er uit als een online programma en is heel eenvoudig in gebruik. Aan de [...]
[...] wireframe de site met de klant; [...]
[...] inhoud en indeling van de website te denken. Deze factoren kun je testen door gebruik te maken van wireframes. Als de wireframes af zijn kan de gebruiksvriendelijkheid getest worden. Kun je eenvoudig navigeren [...]
[...] Laag 3: Interaction Design / Information Architecture Nu je de doelen en functionele elementen van de website hebt, ga je kijken naar de inrichting. Je kunt deze stap ook wel de ‘blauwdruk’ van je website noemen. Je gaat kijken naar hoe je het ontwerp grofweg gaat indelen. Probeer er voor te zorgen dat de structuur van de website overzichtelijk is en dat de belangrijkste content gemakkelijk te vinden is. In deze stap word de methode ‘wireframing’ toegepast, waarin je doormiddel van simpele lijnen aangeeft hoe de website ingedeeld is. Voor wie niet weet wat wireframing is en wat het doet, hier een interessante guide. [...]
[...] Wireframes en ontwerp Middels de analyse en de wensen van het Muiderslot is Curt aan de slag gegaan met het ontwikkelen van wireframes om een indruk te geven hoe de app eruit zou komen te zien. Hiermee is het doel van de applicatie meegenomen en de gebruiksvriendelijkheid uitgewerkt. Middels de wireframes wordt een blauwdruk van de applicatie gemaakt die dient als basis voor de verdere ontwerpen, hierbij worden zaken als usability, navigatie en informatievoorziening weergegeven. Wanneer er akkoord is op de wireframes wordt een ontwerp gemaakt waarbij kleurgebruik meegenomen wordt en de look and feel van de applicatie tot leven komt. Als inspiratie van de applicatie heeft Curt gebruik gemaakt van de website. [...]
[...] Bronnen:Slides college: Usability & Designhttp://www.frankwatching.com/archive/2009/11/23/wireframes-de-bouwtekening-van-een-website/http://www.matchminds.nl/index.php/nieuwsberichten-en-prikbord-items-2/14-user-experience/93-prototyping-in-2011http://www.tribal-im.com/nl/internet-marketing-diensten/website-usability Delen:TwitterFacebookVind ik leuk:LikeWees de eerste om post te waarderen. [...]