Hoe specificeer je een website ?

[LittleBit]

Als je een auto of een huis wilt hebben, dan zijn er allerlei manieren om dat product te specificeren.

Daarmee ontstaat duidelijkheid. Je kunt 3 aannemers vragen te offreren op basis van een bouwtekening en besteklijst.

En met de huisspecificaties weet jij als opdrachtgever ook precies wat je straks gaat krijgen.

Met schetstekening, bouwtekeningen, besteklijsten etc etc ontstaat een redelijke poging om vooraf te kunnen bepalen of de aannemer daadwerkelijk een aanbod doet wat overeenkomt met jouw droomhuis.

Zoiets is ook in het voordeel van de huisbouwer, want als je vooraf specificeert: "een klein boerderijtje met rieten kap en 2 garages" dan weet ook hij wat de verwachting is.

En een specificatie zorgt ervoor dat je draagvlak kunt krijgen en dan kunnen je gezinsleden meedenken en kunnen zij ook warm gemaakt worden voor het project.

 

En zo werkt het bij de meeste producten.

 

Maar dan de website.

Als je een websitebouwer een site wilt laten bouwen dan wil je geen open opdracht geven.

Ook hier wil je dat er een website komt die overeenkomt met wat jij in gedachten hebt.

Maar hoe moet je nu een website gaan specificeren om te zorgen

dat een websitebouwer een beeld heeft van wat jij zoekt

dat je daarbij aanbieders kunt vergelijken

en zodat je een indruk krijgt of het resultaat straks is wat je verwacht ?

 

 

[DaMedia]

Uittekenen.

Schets elk scherm op een vel papier en geef de volgorde aan. Geef aan wat de functionaliteit is van het scherm en welke onderdelen op welke plaats moeten komen. Probeer ook zelf een menustructuur te bedenken zodat bezoekers snel bij de gewenste info zijn. De menustructuur bepaalt voor een deel de layoutindeling.

Daarnaast zal een lijst opgesteld moeten worden met alle gewenste functionaliteiten die niet direct op het scherm zichtbaar zijn zoals een CMS, mailinglijsten, cronjobs, etc.

 

Des te beter het functioneel ontwerp is, des te beter zal de prijs bepaalt kunnen worden en dus vergeleken kunnen worden van de diverse aanbieders.

Laat ze eventueel een contract ondertekenen dat de inhoud van het functioneel ontwerp niet door hun gebruikt mag worden voor andere zaken.

[wimj]

Kun je ongeveer aangeven wat voor soort website je wilt maken?

Bijvoorbeeld: een webshop, een site om de portfolio van je bedrijf onder de aandacht te brengen, of een vacature site die overal vacatures vandaan haalt.

Dan probeer ik daarna iets gerichter iets te schrijven.

 

[renep]

Maar dan de website.

 

Een website kan verschillende dingen zijn:

[*]Een ding op zichzelf: een paar webpagina's met een vormgeving, tekst en plaatjes

[*]Een uitgeefproduct, zoals een nieuwssite of informatieve site, met daarachter een cms en redactie

[*]Een communitysite (forums, bestanden delen, commentaren etc.)

[*]Een gebruikersinterface van een klassiek informatiesysteem

[*]De gebruikersinterface een cloudapplicatie

[*]...

 

Ik zou de manier waarop ik de site beschrijf laten afhangen van de categorie.

 

Over hoe je een klassiek informatiesysteem specificeert zijn bijvoorbeeld boeken vol geschreven, en dat het ding een webinterface in plaats van (of: naast) een desktop-GUI heeft verandert daar niet zo verschrikkelijk veel aan.

 

Maar in veel gevallen zou ik eerst het achterliggende data- of objectmodel maken, in plaats van beginnen met schermen te beschrijven.

[LittleBit]

@Wimj

 

> Wat voor soort site....... een site om de portfolio van je bedrijf onder de aandacht te brengen,

 

Momenteel denk ik aan enerzijds een centrale productsite waar details van de -vrij technische- producten is te vinden

en anderzijds denk ik aan een serie (bv 5a10 stuks) 'satelliet'-sites met eigen domainname, welke een toepassing/applicatie belichten met nadruk op emotie/beleving en geen technische details maar voor de technische info linken naar de centrale productsite.

 

[R.I.P. | Peter Bonjernoor]

Alleen kijkend naar de techniche aspecten moet je eigenlijk een zogenaamd functioneel ontwerp maken. Dat is een document waarin je van alle onderdelen van de website in gewoon Nederlands beschrijft wat het moet doen.

 

De truc is alleen om dat goed te doen, want te weinig detail maakt de hele exercitie zinloos, en teveel detail leidt de lezer af van de belangrijke zaken.

 

Een manier om het aan te pakken kan zijn om eerst in grote lijnen de gewenste onderdelen op te sommen, en dan per onderdeel in meer detail de subonderdelen uit te werken, en dan weer in nog meer detail de subonderdelen daarvan.

 

Niemand heeft bijvoorbeeld veel aan de losse kreet "Productoverzicht", maar een omschrijving die in extreem detail beschrijft hoe de kolomindeling van de detailpagina van een product er precies uit zou moeten zien is ook niet echt zinvol.

 

Het gaat om het functioneren van de pagina in kwestie, dus je wilt aangeven hoe de producten gesorteerd moeten (kunnen) worden, welke selectiemogelijkheden de gebruiker moet hebben, hoe je de details van een product beschikbaar wilt maken, wat er precies moet gebeuren als je op "Toevoegen aan winkelwagen" klikt, bijvoorbeeld, en daarnaast moet je dus ook bedenken welke informatie er achter de schermen beschikbaar moet zijn om dat mogelijk te maken (productcategorien, welke productdetails, etc.)

 

De informatie die je bij die onderdelen beschrijft moeten dan niet bestaan uit: "Als je op 'Toevoegen' klikt moet het product aan de winkelwagen worden toegevoegd" maar uit "Als je op 'Toevoegen' klikt moet het product aan de bestelling worden toegevoegd, moet de samenvatting van de winkelwagen rechtsboven aangepast worden met het nieuwe totaalbedrag, en moet in de linkerkolom de lijst met gerelateerde producten vervangen worden met een lijst met 'Mensen die dit kochten bestelden ook:'"

[wimj]

Momenteel denk ik aan enerzijds een centrale productsite waar details van de -vrij technische- producten is te vinden

en anderzijds denk ik aan een serie (bv 5a10 stuks) 'satelliet'-sites met eigen domainname, welke een toepassing/applicatie belichten met nadruk op emotie/beleving en geen technische details maar voor de technische info linken naar de centrale productsite.

 

 

Ik zal later wat zaken opschrijven. Zaken die me nu binnenvallen zijn;

1) De manier waarop enkele items worden gepresenteerd.

2) De manier waarop items zijn georganiseerd (als een hierarchische boom? Met bepaalde eigenschappen?)

3) De maner waarop gebruikers kunnen navigeren en zoeken op je site

4) De flexibiliteit van de site? Wil je heel simpel een andere "huisstijl" kunnen maken (toevoegen themes a la Wordpress), of

accepteer je dat dit iets lastiger is.

 

En last but not least: de backend: hoe kan je teksten, items etc toevoegen en beheren. Moet dat via de leverancier van de website (dat wil je niet denk ik), via een gebruikersvriendelijk interface zodat iedereen dat kan of via een iets lastigers interface die alleen voor getrainde mensen toegangkelijk is.?

Of moet die informatie worden "opgehaald" van andere sites?

 

En dan nog een paar vragen:

Wil je een site die voornamelijk functioneel is (veel informatie; presentatievorm minder belangrijk), of wil je een site waarvan mensen de vorm echt onthouden.

Met andere woorden: moeten mensen na een bezoek aan je site een gevoel hebben van "Daar staat veel informatie, en

makkelijk te vinden", of een gevoel van "Wouw, wat een fraaie site".

 

En heb je gedacht over een standaard site (Wordpress, Joomla, Drupal) met eventueel een eigen template?

 

[r.i.p. Ruben van den Oord]

Vraag aan een dakdekker waar je op moet letten bij de aankoop van een huis en die zal antwoorden: "Let er op dat het dak waterdicht is." De heier zal zeggen: "Laat een funderingsonderzoek doen." De metselaar zal zeggen: "Kijk goed of de muren niet scheef staan." De waarheid is natuurlijk dat alle onderdelen moeten kloppen.

 

Zo is ook het bouwen van een website afhankelijk van de samenwerking van meerdere disciplines. De ideale briefing zal dan ook een combinatie zijn van bovenstaande adviezen. Bedenk goed welke velden je in je formulieren wilt (en dus hoe je databases er uit komen te zien). Schets de diverse schermen zoals jij ze voor ogen hebt en beschrijf wat de gebruiker met je site kan doen. Beschrijf het een en ander vooral in termen van input en resultaat. Hoe dat resultaat er moet komen is de taak van de developer, hoe het er uit moet komen te zien de taak van de designer.

 

Maak dat hele document kort en bondig. Scheelt tijd met schrijven en scheelt tijd met lezen. Selecteer een developer en laat het dan los. Dat wil zeggen: Geef de developer en de designer voldoende vrijheid om alternatieven voor te stellen die voor een betere gebruikerservaring zorgen.

 

Succes met het opstellen van je briefing!

[evn64]

Hallo Wim,

 

alhoewel veel van de bovenstaande adviezen kloppen, kan ik mij voorstellen dat sommige wellicht niet concreet genoeg zijn om je snel verder te helpen. Ik ben zelf webdeveloper en merk dat heel veel klanten moeite hebben met het opstellen van een goede briefing.

 

Niet zelden heeft dit te maken met de terminologie die wordt gehanteerd. CMS, Desktop-GUI, backend, data- of object model en cronjobs zijn termen die bij het opzetten van een site weliswaar een grote rol spelen, maar voor opdrachtgevers vaak onbekend zijn. En eerlijk gezegd, denk ik ook niet dat ze voor de meeste opdrachtgevers relevant zijn. Om in de analogie van een auto te blijven: je hoeft de overbrengingsverhoudingen van een versnellingsbak niet te kennen om toch de juiste auto aan te schaffen waarmee je een caravan over de Alpen kan trekken.

 

De suggestie van René om eerst het achterliggende data- of objectmodel te maken ipv de schermen te beschrijven is zeker zinvol, maar is denk ik in jouw geval een stap die niet direct noodzakelijk is, gezien de eenvoudige gewenste functionaliteit die je zoekt. Mocht ik dit mishebben, en heb je een toch een complexere site voor ogen, dan moet dit wel gebeuren. De vraag is of jijzelf daarvoor de aangewezen persoon bent. Het is een vak. Zelf alles uitzoeken kan prima, maar dan moet je wel gemotiveerd zijn om er veel tijd in te steken. Ben je nieuwsgierig van aard en vind je het leuk, doen. Zo niet, iemand met ervaring doet dit vele malen sneller en maakt geen beginnersfouten.

 

In jouw geval zou ik volstaan met de suggestie van DaMedia. Maak maar een eenvoudige schets van

- wat wil je dat er op het scherm te zien is

- wat wil je dat de site kan, maar niet op het scherm te zien is (zelf onderhouden, nieuwsbrieven versturen, dat soort zaken)

- het is altijd prettig voor een developer dat je wat voorbeelden geeft van sites die je aanstaan en vergelijkbare functionalteit hebben.

- Geef je budget aan. Tailor-made sites zijn duur. Door gebruik te maken van generieke, gratis software zoals Joomla, Wordpress of Drupal kan je flink besparen op de kosten.

 

Deze drie namen hebben betrekking op open source, gratis content management systemen. Kort door de bocht zou ik je adviseren om een site zonder een dergelijk systeem niet eens te overwegen. Iemand die goed overweg kan met een dergelijk systeem bouwt een website even snel met als zonder zo'n systeem. Het voordeel is dat voor deze systemen al duizenden extra modules beschikbaar zijn, vaak ook gratis, die net die functionaliteit toevoegen die je zoekt. De eerlijkheid gebied te erkennen dat dit kan inhouden dat je soms consessies moet doen tav de wensen die je hebt. Maar zolang dit niet de essentie van de site beïnvloed, is het niet verstandig (en vaak kostbaar) om vast te houden aan een vooringenomen standpunt.

 

Wederom in de analogie van de auto: als je persé een Fiat Panda wilt, én een caravan over de Alpen wilt trekken, moet je voor een vermogen aan de auto vertimmeren. En helemaal goed wordt het nooit. Je zou met een Skoda Diesel veel goedkoper uitgeweest zijn, sneller klaar en toch precies bereikt hebben wat je wilt. Nl. twee weken zon op een camping aan het Garda meer.

 

Een goede webdeveloper zal aan de schetsen, omschrijving en voorbeelden genoeg hebben voor een eerste opzet en een offerte. Aan de eventuele vragen die hij je vervolgens stelt merk je vanzelf waar er hiaten in je briefing zaten ;)

 

De suggestie om een contract te ondertekenen om het functioneel ontwerp te beschermen lijkt mij in deze niet nodig. Waar jij naar op zoek bent is een website met een zeer generieke functionaliteit. Het heeft m.i. geen zin om deze contractueel te beschermen. Wat kan het overigens voor kwaad als de opsteller dit FO elders weer uit de kast trekt? Het is de content die de site uniek/aantrekkelijk maakt. En die is van jou.

 

Wat m.i. wel handig is: sluit met de bouwer van de site een onderhoudscontract af voor een jaar. Dat hoeft niet meer te zijn dan een één of twee uurtjes per maand. Zie het als je persoonlijke helpdesk. En een vangnet bij calamiteiten. Ik heb nog nooit meegemaakt dat een klant na oplevering toch niet tegen bepaalde zaken aanliep die niet voorzien waren.

 

En bij de opmerking van Ruben wil ik mij helemaal bij aansluiten: geef de developer de ruimte. Maak gebruik van zijn ervaring.

 

Tip: als je een bepaalde functionaliteit zoekt die nog niet bestaat, vraag je dan af waarom. Het kan zijn dat er een geniale ingeving aan ten grondslag ligt, maar ook dat er goede redenen zijn waarom het nog niet bestaat. In mijn ervaring is tot nu toe altijd het laatste gebeleken.

 

Succes met de ontwikkeling van je sites.

 

gr, Eric

 

PS: dit is mijn eerste kennismaking met dit forum. Kende het niet. Maar er is hier erg veel lezenswaardig te vinden :)