We zijn het helemaal eens dat een hoop klanten moeite hebben met het lezen van een functioneel ontwerp. Vaak is dat omdat een functioneel ontwerp ook best technische elementen beschrijft, en ook dient als input voor een ontwikkelaar. Een klikdemo kan ook zeker waardevolle input leveren (mits je representatieve gebruikers hebt,ik heb ook wel DURE gebruikerstesten mogen surveilleren waar dan 4 goedwillende personen worden uitgenodigd die nog net niet met de muis op het beeldscherm zitten waardoor de feedback van zeer twijfelachtige kwaliteit is…)

We zijn het gelukkig wel eens dat een FO een goede zaak is! Bedankt voor de tip , ik zal eens kijken naar Axure. Maar ik vind eigenlijk dat we dan stiekem al bezig zijn met Usability testen, en niet zozeer meer het beschrijven van de sec requirements?

Vind jij dat uitgewerkte wireframes bij het FO traject horen, of is het meer input voor het uiteindelijke grafisch ontwerp? Of een tussenstap? en moet de business analist dit maken?

Ik stel erg prijs op jouw mening in deze

Met ‘opvoeden’ bedoelde ik inderdaad vanuit je expertrol een klant adviseren wat logisch, handig en functioneel is.

Ik herken het feit dat bedrijven vaak niet (extra) willen betalen voor een werkend prototype of klikmodel. Terwijl dit in FO of vroege bouwfase in principe prima meegenomen kan worden door de ontwerper of bouwer. Waar het mij om ging: we besteden vaak wel een weekje aan het schrijven van een functioneel ontwerp, maar onze klant is nauwelijks in staat om dit functionele plan echt te beoordelen. Een klikmodel of demo laat zich sneller door een eindgebruiker beoordelen.

Ik ben het met je eens dat je zoveel mogelijk zou moeten aansluiten bij webstandaarden. Gelukkig zijn er op internet een heleboel design patterns en page grids die dit helpen vergemakkelijken. Toch zie ik nog vaak genoeg sites langskomen die het wiel zelfstandig opnieuw uitgevonden (denken) te hebben en daarin hopeloos de plank misslaan.

Daarom vind ik een weekje schrijven op een goed FO prima, maar wanneer je dit bijvoorbeeld doet met Axure software dan is het ook heel eenvoudig dit project te exporteren tot mini-klikdemo. Dan zou ik er eens doorheen bladeren. Samen met collega’s, en wat mensen die wat verder van het project af staan (vrienden, ouders, kinderen, de doelgroep). Gewoon over hun schouder meekijken wat ze aan het doen zijn en je ziet binnen 5 minuten of alles werkt zoals het moet werken. Vaak vinden mensen het zelf juist ook wel leuk om ergens doorheen te klikken.

je hebt gelijk dat voor eenvoudige zaken geen FO nodig is en bij een uitgebreidde community wel. Zoals je aangeeft is het inderdaad om op te voeden (of liever: de klant te adviseren vanuit je expert-rol) en te kunnen sturen naar goede standaard-oplossingen.

Voor wat betreft een klik-model of een beta-evrsie:

Ik merk vaak dat klanten geen budget hebben om een prototype te laten maken. Met zoiets als websites lijkt me dat ook nagenoeg overbodig.Het is immers een redelijk uitgekristalliseerd concept. De header staat bovenin, het menu staat links of over het midden etc. Het is geen rocketscience meer. Een klik- of stappenplan door een site zie ik zleden langskomen

Een best practice in websiteland is immers zorgen dat je gebruiker binnen 2 klikken op de plek van bestemming is! (niet altijd haalbaar helaas, denk aan een winkelmandje of afrekenproces)

Daarnaast moet je denk ik zoveel mogelijk aansluiten bij standaarden die je op internet ziet langskomen in plaats van zelf het wiel opnieuw gaan uitvinden.

Als ik spreek over een FO heb ik het over maximaal een week in kaart brengen wat er op de site komt, en hoe dit werkt voor de gebruikers, puur om de scope van het project in kaart te brengen.

Het laten testen van een FO door meerdere gebruikers is reeds stukken duurder en omslachtiger, tenzij je het door expertconsultants laat reviewen.

Hoe denk jij hier verder over?
Ik nodig je graag uit om hier op te reageren!

Ik sluit me graag aan bij Timmermans, flexibiliteit is zeer belangrijk! De kunst is echter wel om ook de eerste release te beperken toe een voor ieder acceptabele scope. Anders lever je nooit een eerste versie op, en blijft de planning uitlopen.

De eerste release van de site moet datgene doen waarvoor de site in het leven is geroepen. Dus eerst de core, en vervolgens meten en analyseren of je business case nog gerechtvaardigd is. Vervolgens kun je dan de site doorontwikkelen.

Een site is inderdaad nooit echt af, het internet ontwikkelt door, technieken worden slimmer, klantvragen veranderen, je website zal uiteindelijk mee moeten veranderen wil je mee kunnen blijven draaien.