Tien criteria voor het selecteren van een webdesigner

Met confronterende regelmaat komen wij ze tegen: klanten die na een slechte ervaring met een “webdesigner / webontwikkelaar / ontwerper / programmeur / webbouwer” lichtelijk getraumatiseerd bij ons aankloppen om “de boel weer vlot te laten trekken”, oftewel een nieuwe website te laten ontwikkelen. Onze ervaringen met het overnemen van bestaande sites vormen de basis voor dit artikel. Het is in deze tijd, waarin iedereen alles kan en doet, blijkbaar dringend nodig om een helpende hand te bieden bij de leveranciersselectie. Oftewel: wat zijn de actuele regels der kunst bij het bouwen van een deugdelijke website en hoe weet ik dat mijn (huidige of toekomstige) ontwikkelaar die beheerst?

Hoe scheidt u als vragende partij het kaf van het koren? Zonder de juiste hulp lijkt ons dat voor de leek heel ingewikkeld, simpelweg omdat het bouwen van een website een specialistische expertise vraagt en er geen regelgeving, diploma’s of gangbare certificeringen zijn waaraan je een professional kunt herkennen (al is een succesvol afgeronde IT-opleiding, gecombineerd met een jaar of tien concrete ervaring waarschijnlijk wel alvast een hint in de goede richting).

Daarom deze checklist voor het selecteren van een professioneel webdesign-bureau of webontwikkelaar. Niet omdat we de waarheid in pacht hebben, of omdat we andere ontwikkelaars terecht willen wijzen (dat zou arrogant zijn), maar omdat de kwaliteit die geleverd wordt soms zo bedroevend slecht is dat daarmee ons mooie vak geschaad wordt. Welwillende ondernemers worden daar de dupe van. We hopen dan ook dat andere ontwikkelaars en/of webdesigners dit artikel lezen, de discussie willen aangaan en ons verder willen aanvullen (of verbeteren!).

Laten we dit voorop stellen: het ontwikkelen van een website, webshop, blog, etc. is het ontwikkelen van software. Software-ontwikkeling is een serieuze zaak, omdat er veel kennis, organisatie en specialistische hulpmiddelen bij komen kijken. Helaas onderkent lang niet elk bureau (of zelfstandig individu) dit, omdat het soms heel gemakkelijk lijkt om “even snel” een website in elkaar te draaien en dit als bureau even “erbij te doen”. De kunst zit echter niet in het uitrollen van een content management systeem (CMS) en het installeren van een standaard template (dit kunt u tegenwoordig ook aan een brugklasser vragen), maar in het ontwikkelen van een robuuste lange termijnoplossing, die u ook echt iets oplevert. Onderstaande checklist helpt u hopelijk om de hobbyisten van de professionals te onderscheiden.

1. Is de offerte gedetailleerd en/of modulair opgebouwd?

Een website (of andere weboplossing) bestaat altijd uit verschillende onderdelen. Denk daarbij aan het visuele ontwerp, het CMS, de template voor het CMS, de hosting, verschillende functionaliteiten of modules in het CMS, etc. Om zekerheid te hebben over de inhoud van het project, is het daarom belangrijk dat de kosten voor de verschillende onderdelen opgenomen zijn in de offerte. Zo niet, dan kunt u voor verrassingen komen te staan als blijkt dat bepaalde functies die u wenst, niet in het eindresultaat blijken te zitten. Met een duidelijke en gedetailleerde offerte voorkomt u dat er verwarring ontstaat over de inhoud van de opdracht (en de hoogte van de factuur).

Overigens is het uurtarief geen goede maatstaf voor het vergelijken van aanbieders. Een ervaren ontwikkelaar werkt veel sneller dan een beginner. Ook de kwaliteit van de uiteindelijke code is bepalend voor toekomstige onderhoudskosten, deze kwaliteit zal bij een ervaren ontwikkelaar hoger liggen. Vraag dus liever naar het totaalbedrag voor een bepaalde functionaliteit en weeg af of dit de investering waard is. Wat is de directe of indirecte opbrengst van een bepaalde functionaliteit en wat voegt hij toe aan de beleving van de website?

Risico’s bij het ontbreken van een gedetailleerde offerte:

• Uw verwachtingen worden niet waargemaakt.
• Afspraken worden niet nagekomen.
• U bent duurder uit dan voorzien omdat bepaalde functies niet gespecificeerd zijn.
• Gebrek aan transparantie werkt slecht voor het vertrouwen.

Alarmsignalen:

• Pas extra goed op bij offertes die slechts één totaalbedrag vermelden. Deze manier van werken biedt de ontwikkelaar de mogelijkheid om te doen en laten wat hij wil.
• Te lage of te hoge uurtarieven in relatie tot het aantal jaren ervaring zijn ‘verdacht’. Een beginnende programmeur heeft (in 2008/2009) een tarief tussen de 30 en 60 euro per uur, een zeer ervaren programmeur tussen de 75 en 190 per uur (bron: PUBLIMIX Prijzen en Tarievengids 2008/2009).

2. Zijn de voor u geregistreerde domeinnamen uw eigendom?

Het is mogelijk dat webontwikkelaars – uit gemak of onwil of zelfs met bewuste opzet – domeinnamen voor hun klanten op hun eigen naam registreren. Dit betekent dat zij de eigenaar zijn van de domeinnaam die gebruikt wordt voor uw website. Controleer daarom altijd of u zelf als eigenaar van een domeinnaam geregistreerd staat! Omdat een domeinnaam na verloop van tijd (merk)waarde heeft, is het belangrijk dat u altijd zelf kan beslissen over de naam. Dat kan alleen als u zelf de eigenaar bent.

Risico’s als de domeinnamen niet op uw naam staan:

• Leveranciers lock-in (u bent gebonden aan uw huidige leverancier en kunt niet gemakkelijk overstappen naar een andere).
• Verlies van de domeinnaam (en soms zelfs van de gehele website en inhoud daarvan) in geval van een conflict met uw leverancier.

Alarmsignalen:

• De leverancier registreert de domeinnaam op zijn eigen naam. Controleer dit eventueel via www.sidn.nl (voor Nederlandse .nl domeinnamen) of www.dns.be (voor Belgische .be domeinnamen).

3. Hoe zijn de backups van documenten, ontwerpen en software geregeld?

Het ontbreken van goede backups van uw website kan bij ongeregeldheden tot grote vertragingen in een project leiden. Backups moeten niet alleen lokaal, op de locatie waar de ontwikkeling plaatsvindt, maar ook extern opgeslagen worden (bijvoorbeeld met behulp van een cloud-oplossing). Een backup die zich maar op één locatie bevindt, is feitelijk geen backup, omdat brand of diefstal risico’s zijn die niet genegeerd mogen worden. Controleer of de webontwikkelaar er goede back-up gewoonten op nahoudt.

Risico’s bij het ontbreken van goede back-up faciliteiten:

• Vertragingen in het project.
• Verlies van gegevens.
• Problemen bij toekomstig onderhoud omdat bestanden ontbreken.

Alarmsignalen:

• Er zijn geen back-ups? Run away!
• Er is wel een lokale backup, maar geen externe backup-faciliteit of geen geautomatiseerde oplossing? Wees kritisch!
• Vroeger was het nog wel acceptabel dat een medewerker de backup-tapes mee naar huis nam, maar met de technische mogelijkheden van vandaag is het eenvoudig om dit te automatiseren en daarmee het risico op menselijke fouten (“oeps… tape vergeten”) te beperken. Lange termijn backups op CD-ROM of tape vergaan overigens in de loop van de tijd omdat het medium verslijt, pas hier dus ook mee op.

4. Worden er open source oplossingen gebruikt?

In tegenstelling tot zelfontwikkelde websoftware, zijn open source oplossingen gratis in gebruik en worden ze veelal onderhouden door grote groepen ontwikkelaars. Voorbeelden van open source software zijn CMS Made Simple, WordPress en OpenCart, Drupal en Joomla. Het voordeel van het inzetten van open source oplossingen is dat de kans op een leveranciers lock-in klein(er) is. Het is vaak niet zo lastig om een andere ontwikkelaar te vinden die de code kan overnemen, mocht dat nodig zijn, en daarnaast kan de leverancier geen rechten claimen. U behoudt dus uw flexibiliteit, mocht u willen overstappen naar een andere webpartner.

Het is echter wel erg belangrijk om open source code goed te onderhouden, zodat eventuele lekken in de software snel gedicht kunnen worden. Ook is het belangrijk om goede programmeurs te betrekken bij een open source project, zodat een project niet vastloopt zodra er even geen “standaard oplossing” (plug-in of extension) beschikbaar is voor een gewenste functionaliteit.

Risco’s als er geen open source gebruikt wordt:

• Leveranciers lock-in (u kunt niet gemakkelijk van leverancier wisselen).
• Hoge kosten omdat dure modules gekocht moeten worden of apart voor u ontwikkeld moeten worden.

Alarmsignalen:

• Er wordt open source aangeboden, maar dit blijft beperkt tot bestaande modules, plug-ins of extensions (allemaal woorden voor hetzelfde) die beschikbaar zijn uit externe bronnen omdat er geen echte programmeurs bij het project betrokken zijn. Iedereen kan tegenwoordig eenvoudig (bijvoorbeeld) een WordPress-installatie uitvoeren en een aantal standaardtemplates met modules installeren. Dit vormt echter een groot risico voor elk (serieus) project. Zodra een deel van de website niet doet wat het moet doen, kan uw webbouwer u niet meer helpen en heeft u dus een probleem. Professionele bureaus die met open source werken, hebben minimaal kennis van technieken als PHP, HTML, CSS en javascript in huis (controleer dit!), om een inschatting te kunnen maken van de kwaliteit van de open source code en problemen te kunnen oplossen.

5. Maakt de ontwikkelaar gebruik van geautomatiseerd versiebeheer?

Versiebeheer zorgt ervoor dat elke wijziging in de programmacode van uw website (automatisch) nauwkeurig wordt bijgehouden in de daarvoor bestemde software. Zonder versiebeheer is het onmogelijk om websites op professionele wijze technisch te beheren, te onderhouden en eventueel over te dragen aan een andere ontwikkelaar. Het is zoiets als het onderhoudsboekje van uw auto, maar dan op de (programma)letter nauwkeurig ingevuld. Versiebeheer vindt over het algemeen plaats met hulp van een degelijke cloud-service (bijvoorbeeld Beanstalk of Sourceforge) of een eigen, goed onderhouden, server waarop een versiebeheersysteem zoals SVN of Git geïnstalleerd is.

Risico’s bij het ontbreken van versiebeheer:

• Leveranciers lock-in.
• De ontwikkelaar maakt moeilijk overdraagbare code, waardoor andere leveranciers/ontwikkelaars de site niet in beheer willen of kunnen nemen.
• Duur onderhoud.
• Problemen bij upgrades.
• Risico op verlies van code.
• Het is vrijwel onmogelijk om met meerdere mensen aan de ontwikkeling te werken.

Alarmsignalen:

• Als u over versiebeheer begint en de ontwikkelaar kijkt u vragend aan: hoog amateur-alert (code rood, ruimte direct verlaten).
• Ontwikkelaars die wel weten wat versiebeheer is, maar het niet toepassen, hebben óf een fotografisch geheugen gecombineerd met veel zelfvertrouwen (“ik onthoud al mijn wijzigingen zo wel” en “niemand hoeft ooit aan mijn code te komen”) óf ontwikkelen alleen heel kleine sites, met standaardsoftware en dito templates, die verder geen onderhoud behoeven (zelfs in deze laatste gevallen is versiebeheer nuttig).

6. Welke competenties heeft de webontwikkelaar nog meer behalve het technisch bouwen van websites?

Het ontwikkelen van een goede website (of ander online communicatiemiddel) is een samenspel van ontwerp, teksten, marketing en techniek. Een ontwikkelaar die zich alleen op de techniek focust, heeft wellicht onvoldoende kennis in huis van de overige aspecten, om er een goed werkend totaalproduct van te maken. U krijgt waarschijnlijk een ondermaats eindresultaat als het gevoel voor visueel ontwerp en kennis van een goede organisatie van de inhoud ontbreken, of onvoldoende rekening wordt gehouden met de doelstellingen die u met uw website wilt bereiken. Techneuten zijn soms geneigd om zich puur te focussen op de techniek en zich niet met de rest bezig te houden. Vormgevers weten vaak weinig van techniek en sterke teksten en ontwerpen wellicht websites die niet goed technisch realiseerbaar zijn. Het is echter essentieel dat er een totaalbalans is tussen de verschillende componenten. Naast een goede techneut, dient er dus ook een goede vormgever en tekstschrijver bij een project betrokken te zijn. Soms vindt u deze eigenschappen in één persoon, maar meestal niet.

Een ander belangrijk punt is de hosting van de website (hosting is altijd nodig om de website te kunnen tonen op het internet). Hoe is deze geregeld? Zorgt uw leverancier voor de hosting of hangt u straks zelf met het hostingbedrijf aan de lijn als er problemen zijn? Wees op uw hoede als uw leverancier niet voor de hosting zorgt maar dit bij u neerlegt.

Risico’s wanneer slechts op één discipline gefocust wordt:

• Onrealistische voorstellen en ideeën.
• Eindproducten die niet voldoen aan de verwachting.
• Minder rendement op de investering.
• Inferieure kwaliteit van die activiteiten die niet de kerncompetentie van de webontwikkelaar zijn.
• U wordt van het kastje naar de muur gestuurd als er problemen zijn (bijvoorbeeld met de hosting).

Alarmsignalen:

• Een programmeur die “ook wel even het ontwerp zal doen”.
• De kostprijs voor het visueel ontwerp en/of de teksten van de site zijn niet opgenomen in de offerte.
• Sites uit het portfolio bevatten slechte teksten of onprofessionele lay-out. Onderzoek in dat geval wie hiervoor verantwoordelijk is.
• De leverancier voelt zich niet verantwoordelijk voor de hosting of zegt dat u dit zelf moet regelen.

7. Worden de laatste technieken en technologieën gebruikt?

Vraag de ontwikkelaar welke technieken gebruikt worden en waarom. Op dit moment zijn responsive design (= een site geschikt maken voor desktop, tablet en mobile), HTML5 en CSS3 (= de ’talen’ waarin de site ontwikkeld wordt) een aantal moderne technieken die toegepast kunnen worden. Het is belangrijk dat de ontwikkelaar kennis heeft van de laatste stand van zaken, omdat uw website waarschijnlijk enkele jaren zal moeten meegaan. Vraag hem dan ook hoe hij zijn kennis bijhoudt.

Risico’s bij het gebruik van oude technologie:

• De website is al verouderd bij het lanceren.
• De website kan niet goed bekeken worden op bijv. mobiele telefoons of tablets.
• De website is minder goed vindbaar in zoekmachines.
• U krijgt geen waar voor uw geld.

Alarmsignalen:

• De ontwikkelaar heeft geen kennis van de laatste technologieën (dit komt voor als er een standaard CMS gebruikt wordt met een standaard template). Indicatie voor een hoog hobby-gehalte.
• De ontwikkelaar stelt voor om Flash te gebruiken (werkt niet op iPhone of iPad en slecht op veel andere apparaten) of stelt voor om een andere verouderde technologie te gebruiken (helaas soms lastig in te schatten als klant).

8. In welke browsers zal uw website goed functioneren?

Er zijn momenteel veel verschillende browsers in omloop. Een aantal populaire browsers zijn Internet Explorer, Firefox, Safari, Google Chrome en Opera. Daarnaast zijn er die speciaal ontwikkeld zijn voor mobiele telefoons, waaronder Mobile Safari (voor iDevices als iPhone en iPad), Chrome voor Android en Opera Mini. Omdat alle browsers hun eigen techniek gebruiken om een webpagina te tonen, kan dit voor ontwikkelaars redelijk problematisch zijn. Uw website ziet er dan anders uit in verschillende browsers, bijvoorbeeld doordat bepaalde onderdelen niet of foutief worden getoond. Met name de verouderde browsers van Microsoft (Internet Explorer versie 6, 7 en 8) leveren nogal wat problemen op bij moderne websites.

Daarom is het erg belangrijk om in de offerte te (laten) specificeren in welke browsers de website zal werken. Houd er rekening mee dat voor het ondersteunen van een oude webbrowser hoogstwaarschijnlijk extra budget nodig is en dat er concessies gedaan zullen moeten worden aan de mogelijkheden en het uiterlijk van de website.

Risico’s bij het niet vooraf specificeren van de gewenste browsers:

• De website voldoet niet aan uw verwachtingen.
• Uw klanten kunnen de website niet optimaal bekijken (bijv. doordat onderdelen niet zichtbaar zijn in hun browser).
• De ontwikkelaar heeft (veel) meer tijd nodig dan vooraf verwacht (als blijkt dat bepaalde browsers toch ondersteund hadden moeten worden).
• U betaalt teveel (als achteraf blijkt dat bepaalde browsers uw site niet hoefden te ondersteunen).

Alarmsignalen:

• Browserondersteuning staat niet vermeld in de offerte.
• De ontwikkelaar zegt dat hij Internet Explorer 6, 7 en 8 “er wel even bij doet”.
• De ontwikkelaar heeft niet de expertise en/of techniek in huis om de verschillende browsers te testen.

9. Hoe en wanneer kunt u de leverancier bereiken (ook na oplevering)?

Goede communicatie is één van de belangrijkste succesfactoren voor het laten slagen van een project. Het is belangrijk dat uw leverancier goed bereikbaar is, zowel tijdens als na het project. Wanneer u een dringende vraag heeft, is het belangrijk dat u snel geholpen wordt. Een goed bereikbaar telefoonnummer en e-mailadres zijn dus minimaal noodzakelijk.

Daarnaast is het belangrijk dat u goed op de hoogte bent van de voortgang van het project. Tijdens het project is het gebruik van projectmanagementsoftware (bijvoorbeeld Basecamp) ten zeerste aan te raden. Doordat u het projectverloop hiermee goed kunt volgen, voorkomt u dat zaken tijdens de ontwikkeling vergeten worden. Ook hierin zal de leverancier moeten voorzien, als onderdeel van zijn professionele beroepshouding.

Risico’s als uw leverancier slecht bereikbaar is:

• Het project is moeilijk in de hand te houden, u heeft (te) weinig inzicht in de status.
• Problemen worden niet of pas na lange tijd opgelost.

Alarmsignalen:

• De betrokken ontwikkelaar ontwikkelt uw site in de avonduren en heeft eigenlijk een ander beroep of is (fulltime) student.
• U mag alleen contact opnemen per mail.
• Er worden vooraf geen goede afspraken gemaakt over contactmomenten, onderhoud en (after sales) service.

10. In hoeverre heeft de leverancier zijn eigen zaken goed geregeld?

Net als bij veel andere zakelijke dienstverleners geldt de regel: “practice what you preach”. Als de leverancier zelf een belabberde website heeft, dan is dat geen goed teken! Het vaak gehoorde excuus “een website voor jezelf maken is veel moeilijker dan een website voor iemand anders maken”, is niet wat u van een professioneel bedrijf mag verwachten. Juist door als bedrijf ook aan je eigen profilering te werken, leer je veel dat je vervolgens ook weer voor klanten kunt toepassen. Een professionele organisatie is daarom continu bezig om bij te leren en zichzelf te verbeteren.

Een ander punt onder het kopje “goed geregeld” is de vraag of er meerdere programmeurs (of schrijvers, of ontwerpers, maar met name programmeurs) beschikbaar zijn. U wilt uw webproject namelijk niet in handen leggen van één persoon met alle risico’s van dien. Zorg ervoor dat uw leverancier dus ook hiervoor altijd een back-up geregeld heeft. Mocht de ene programmeur op vakantie zijn, ziek zijn of het bedrijf verlaten, dan is er altijd een iemand anders beschikbaar om het werk over te nemen. Wel zo’n fijn gevoel.

Risico’s als uw leverancier intern de zaken niet op orde heeft:

• U krijgt niet de gewenste kwaliteit.
• Uw website wordt niet (tijdig) opgeleverd.
• U moet voortijdig of onverwacht van leverancier wisselen, met alle gevolgen van dien.

Alarmsignalen:

• De website van de leverancier ziet er niet professioneel uit.
• De leverancier geeft adviezen die hij klaarblijkelijk zelf niet toepast.
• De leverancier is een éénpitter zonder ondersteuning van buitenaf.
• Uw leverancier gebruikt stagiaires voor uw project, die u niet kunnen ondersteunen na afloop van hun stage.

Tenslotte nog dit

Het welslagen van uw webprojecten is niet enkel afhankelijk van de kwaliteit van uw leverancier. Ook uzelf levert een essentiële bijdrage aan het succes. Als goede opdrachtgever bent u actief betrokken bij het project, formuleert u uw wensen en doelstellingen duidelijk, communiceert u helder, bent u bereikbaar voor vragen en het aanleveren van input en feedback, weet u welk budget u wenst uit te geven en welke planning u nastreeft.

Hopelijk hebben bovenstaande punten u aan het denken gezet. Niemand is perfect en overal gaan dingen mis, maar deze checklist zal in ieder geval bijdragen aan een beter resultaat en meer controle over het proces. Wij hopen in ieder geval van harte dat het niveau van webontwikkeling door deze bijdrage over de hele linie een fractie omhoog gaat. Dan is ons doel bereikt.

Mocht u vragen hierover hebben, reageer dan gerust op dit artikel of neem contact met ons op.