Onlangs mocht ik presenteren op een bijeenkomst voor ondernemers via Westartup. De bedoeling was om de mensen uit het publiek die een website of web applicatie wouden (laten) ontwikkelen, enkele practische tips mee te geven. Onmogelijk om in een presentatie van een dikke 10 minuten alles uitgelegd te krijgen, maar toch vonden de meesten het interessant. Bij deze de slides.

Fact: Mensen zijn lui en ongeduldig.

Hoe sneller hoe beter. Als een website 1 seconde hapert worden we redelijk ongeduldig. Bij de tweede seconde volgt er een *zucht*. Bij seconde nummer 3 klikken we gefrustreerd op “back”. Hoe minder clicks hoe beter. Hoe eenvoudiger hoe beter. De “Like” button van Facebook is niet toevallig ontstaan: door de interactie met de gebruiker te beperken tot een eenvoudige klik, wordt er veel meer geïnterageerd. Zo hoeven de luie gebruikers niet telkens iets neer te pennen. Gewoon “Like” klikken volstaat al. Snel en efficiënt.

Hou rekening met luie klanten!

Vraag van je (toekomstige) klanten niet te veel. Maak de drempel om geld uit te geven zo laag mogelijk. Elke virtuele drempel, hoe klein ook, is een moment waarop gebruikers mogelijks afhaken.

• Zorg dat het niet meer dan een paar klikken kost om een gebruiker aan te maken.
• Zorg dat online betalingen eenvoudig en voor de hand liggend werken. Volg hierbij de juiste design patterns.
• Vraag zo weinig mogelijk gegevens om in te vullen bij online bestellingen, zodat dit geen klanten afschrikt. Email, naam, en adres zouden moeten volstaan. Andere optionele velden kunnen, maar maak ze niet verplicht om de drempel tot aankoop laag te houden. Duid ook duidelijk aan dat ze niet verplicht zijn.
• Werk niet met (ingewikkelde) invite-systemen waarbij gebruikers enkel via een registratie-code een user kunnen aanmaken zolang daar geen goede reden voor is. Ik weet het: Google werkt wél zo. Maar de kans is groot dat u niet Google bent, maar wel een startup die zich nog moet bewijzen.
• Leid klanten doorheen hun aankoop aan de hand van duidelijke en eenvoudige stappen. Elke scherm is een mogelijk scherm waarop ze afhaken, dus hou het aantal schermen indien mogelijk beperkt.
• Zet op elke pagina je contactgegevens (onderaan bijvoorbeeld), zodat luie klanten die vastlopen op elk moment je zonder veel moeite kunnen contacteren. En antwoord hen asap. Goede klanten support doet enorm veel. Ikzelf tracht altijd zowel meteen te antwoorden als mogelijk. Je kan je niet voorstellen hoeveel mensen verbaasd zijn dat ze meteen antwoord krijgen. Ze antwoorden vaak met een “leuk dat je zo snel antwoord!” of “bedankt voor je snelle antwoord”.

Nog best practices?

Noot: lui zijn is volgens mij geen negatieve eigenschap. In tegendeel: om efficient en effectief te zijn, moet je een op een of andere manier “lui” zijn. Excuses aan al mijn klanten die zich beledigd zouden voelen.

Vele ondernemers, vooral die met een technische achtergrond, zijn vaak bezig met HOE ze werken. In web-termen gaat het dan over de taal in dewelke de software is geschreven (PHP? Ruby?), de server waarop de e-commerce site draait tot en met het Operating System van de computer waarop die software ontwikkeld is (Mac OS? Windows?). En nu de waarheid: klanten zijn daar helemaal niet in geïnteresseerd!

Uiteindelijk zijn we als ondernemer allemaal met hetzelfde bezig: oplossingen voorzien voor problemen. (Als dat niet zo is, bel me gerust even op om je verhaal te horen!). Voor een oplossing willen klanten betalen. Zorg ervoor dat je bij het eerste contact niet begint over hoe je de problemen aanpakt, maar wel welke problemen je aanpakt. Klanten willen eigenlijk gewoon meteen duidelijk weten of jij een oplossing hebt voor een probleem dat ze hebben. Indien dat niet zo is, mag je nog de beste intenties hebben: als je een oplossing hebt voor een probleem dat er niet is, bye bye!

Als je de kans hebt je kort voor te stellen: zeg wat je oplost. Op de homepagina van je website: schets het probleem dat je oplost. Op je business kaartjes: zet een slagzin die wijst op een oplossing voor een probleem. Een ideaal verkoopspraatje gaat als volgt:

1. Schets het probleem (dit probleem is algemeen, hier is nog niets specifieks aan wat betreft jouw business)
2. Geef jouw oplossing voor dit probleem.
3. Indien de klant interesse heeft, vertel meer over het hoe, de methode, de manier van aanpak.

Het is geen goed idee om deze stappen in omgekeerde volgorde te doorlopen, om “het beste voor het einde te houden”. Eerst de klant warm maken met het hoe, en dan …tataaa…de oplossing! FOUT! Zou een kok jou kunnen overtuigen door:

1. een uur te zeveren over de ingrediënten en manier van klaarmaken (=hoe)
2. je dan te laten proeven van zijn heerlijke gerecht (=de oplossing voor het probleem “ik wil lekker eten”)

Ik dacht het niet…

Gebruikers of klanten van je e-commerce website, software of web applicatie maken geen verschil tussen “de software” en “de helpdesk”. Voor hen is dat één en dezelfde gebruikers-ervaring. Indien ze vragen hebben over het gebruik van je software of website, dan willen ze die eenvoudig en snel kunnen stellen, en vooral snel antwoord krijgen. Zorg ervoor dat klanten die met een vraag of probleem zitten, snel geholpen worden. Dit is eens zo belangrijk als een mooie en goede webapplicatie of software op zich. Velen focussen zich vooral op ontwikkeling van de software. Echter, een vriendelijke stem aan de helpdesk die u een welgemeende prettige dag wenst nadat uw vraag is opgelost, kan wonderen doen!

Het is makkelijk om je te verschuilen achter een website, en een FAQ online te zetten waarmee klanten zich maar moeten behelpen. Het is veel minder leuk en makkelijk om telefoons op te nemen of de meest onnozele vragen te beantwoorden via email. Vragen die soms niets met uw software te maken hebben (“ik kan niet online bestellen want ik krijg een foutmelding van VISA”). Toch loont het, en is het een eenvoudige manier om op termijn klanten om te toveren in evangelisten die nieuwe klanten overtuigen.

Hoe bent u zelf als u – tegen alle verwachtingen – snel, professioneel en met een glimlach geholpen wordt door een helpdesk of een support team. Hoe zou u reageren moest u een mailtje sturen naar info@blablabla.com, en binnen het half uur een to the point antwoord krijgen?

Online software en webapplicaties moeten afgestemd worden op de business processen van uw bedrijf. Niet andersom. Dit klinkt logisch, maar al te vaak zien we het omgekeerde: een software pakket dat de business NIET ondersteunt, en soms zelfs hindert. Hoe komt dit? Waarom is er zo veel software binnen bedrijven dat zijn doel mist?

Laat ons even uitgaan van een business proces dat we willen automatiseren. We willen hiervoor een online software laten ontwikkelen. We werven een legertje Deloitte/Accenture/… consultants aan die de processen komen beschrijven in flow charts. Na een paar weken of maanden hebben we een bundeltje Powerpoints. Vervolgens betalen we Softwarehouse XYZ om de processen in functionele designs te gieten. 3 maanden na de kick off van het project hebben we een FD (=Functionele Design, of beschrijving van de software die we willen laten ontwikkelen), een Word document van zo’n 250 pagina’s, waarin elk mogelijk scenario en scherm is beschreven. We gaan naar Web Dev Agency ABC, overhandigen de FD, en laten de webapplicatie ontwikkelen. 4 maanden en enkele tienduizenden euro’s later staat onze software online. Hoera!

En wat blijkt nu?

• Je bedrijf is sterk aangegroeid op die 7 maanden. De business is veranderd. Je processen eigenlijk ook.
• Functionaliteit ABC die op papier super nuttig en sexy leek, is eigenlijk toch niet zo interessant als eerst gedacht.
• De mensen “op de vloer”, oftewel de dagdagelijkse eindgebruikers, vragen zich af waarom feature XYZ ontbreekt…in hun ogen cruciaal, maar blijkbaar compleet vergeten door Deloitte/Accenture/het management.
• …

In het algemeen geldt dat software over de tijd heen devalueert. De wereld verandert, de business verandert, processen veranderen, concurrenten veranderen, leveranciers haken af, klanten krijgen andere eisen . Alleen groeit software niet altijd mee. Agile development is een methode van software ontwikkeling, die deze problemen wil aanpakken. De belangrijkste filosofie erachter is de volgende:

Focus op 1 core probleem

Tracht dat ene, aller belangrijkste basisprobleem duidelijk te omschrijven en op te lossen. Laat eindgebruikers het probleem omschrijven. Externe (dure) consultants mag, maar eindgebruikers werken dagdagelijks met de software en bedrijfsprocessen. Zij weten waar de nood het hoogst is! Los dit ene core probleem op met het minimum aantal features die nodig zijn. Less is more. Wie houdt er niet van een eenvoudige, simpele software, die exact doet wat ie moet doen en niet meer? Het bekendste voorbeeld is het volgende scherm. Je vergissen in wat deze online soft doet is onmogelijk.

Laat je business meteen genieten van de software

Laat je software en gebruikersinterface zo snel mogelijk los op eindgebruikers. Zet meteen online wat je online kan zetten, zelfs al ben je beschaamd over hoe weinig je software kan en hoe lelijk de interface is. Eindgebruikers zullen je dankbaar zijn, want vanaf de eerste release hebben ze (1) een basis oplossing voor hun core probleem, en (2) je geeft hen een manier om concrete feedback te geven. Feedback die gebaseerd is op gebruik van de software en niet op een 250 pagina’s dik document dat men “Functionele Design” noemt. Beter een software die na 1 week al online staat en (een deel van) het basis probleem oplost, dan een software die 7 maanden op zich laat wachten om te verschijnen op het moment dat uw processen en de wereld al deels veranderd zijn!

Korte release cycles op basis van feedback van je gebruikers

Na de eerste prille versie krijg je ongetwijfeld feedback. Positieve en negatieve. En aan de hand van die feedback kan je je gebruikers omtoveren van onverschillige gebruikers tot echte fans. Zorg ervoor dat je een eenvoudige release cycle hebt, waardoor je wekelijks kleine verbeteringen en nieuwe fine tunes online kan brengen zonder al te veel moeite. Gebruikers die vandaag klagen over een button op een ongelukkige plaats, zullen veranderen in enthousiaste fans indien die knop de week erna al op de juiste plaats staat! Gebruikers zijn je veel meer dankbaar indien je erin slaagt om een probleem meteen op te lossen of binnen de week hun feedback in nieuwe functionaliteit om te zetten, dan indien je hen belooft dat er ooit, one day, in de toekomst, een enorm fantastische soft aankomt die elk aspect van hun werk ondersteunt.

Wat is jullie ervaring met software ontwikkeling? Waar loopt het vaak fout, en hoe kunnen we dit verbeteren? Comments welkom!