We merken dat veel projecten worden gestart vanuit een algemeen gevoel van noodzaak of een weloverwogen beslissing over de algemene richting. Bijvoorbeeld:
“We hebben een portal nodig om onze producten te combineren in één omgeving.”
De geïnformeerde beslissing over de algemene richting zou kunnen zijn dat deze klant wil dat zijn klanten (de kopers) meer van hun producten gebruiken en dus de verkoop stimuleren. Het algemene gevoel van noodzaak kan zijn dat de kopers of gebruikers de functies nodig hebben die die andere producten bieden.
Met dit soort uitgangspunt is het moeilijk om te bepalen wat de focus van het ontwerp moet zijn. Ofwel de verkeerde veronderstellingen worden gemaakt over waarom kopers en gebruikers het product waarderen. Of er is geen focus en het projectteam probeert alles aan te pakken. Zonder de duidelijkheid van producentenwaarden leidt dit niet alleen tot eindeloze discussies. Het zal er waarschijnlijk ook toe leiden dat het project zijn deadlines overschrijdt. En het grootste risico van allemaal: er is een reële kans dat het product niet de (algemene) resultaten zal opleveren die ervan verwacht werden.
Bovenstaande risico's kunnen eenvoudig worden afgewend door duidelijk te maken waarom het product waardevol is voor de producent. In feite is het niet moeilijk om meerdere goede en concrete zakelijke redenen voor te stellen om de portal die ik noemde te ontwerpen en ontwikkelen. In waardegedreven ontwerpen worden dit “producentwaarden”* genoemd.
Producerwaarden zijn niet beperkt tot portals. Deze real-life case waar we aan hebben gewerkt, een portal die moet fungeren als een "catch all" voor alle producten van onze klant, is echter een geweldig voorbeeld. Tijdens de gesprekken die we hadden met hun CEO, CTO en CFO, kwam een fundamenteel andere kijk op de doelstellingen van de portal aan het licht.
Mogelijke producentenwaarden voor de hierboven genoemde portal waar we het over hadden waren:
In de praktijk zijn opdrachtgevers geïnteresseerd in de waarde van al deze potentiële resultaten. Maar zolang het algemene noodzakelijkheden zijn, zal het moeilijk zijn om beslissingen te nemen tijdens het project. Wat op zijn beurt zal leiden tot een oplossing die niet zo waardevol is als hij zou kunnen zijn.
Een heel simpele manier om hiernaar te kijken zou kunnen zijn: welke van deze 6 oplossingen is het meest waardevol? Welke van deze zal u het meeste geld opleveren? Een beetje verstandiger zou zijn: welke van deze waarden geeft u de "grootste waar voor uw geld", dwz het meeste geld voor de minste kosten? (Trouwens, niet elke bedrijfswaarde is direct geldelijk.)
Waarom is dit belangrijk? Omdat het uw project en projectkosten structureert. Laten we elk scenario eens bekijken:
U moet een portal ontwerpen met toegang tot uw individuele producten met 1 oplossing voor uw terugkerende ondersteunende oplossingen. Je hebt er al meerdere, dus je kunt degene kiezen die het beste bij je past. Die oplossing vereist een beetje tweaken.
U zult een portal moeten ontwerpen met toegang tot uw individuele producten. En u zult een doel-IT-architectuur moeten "ontwerpen", die u moet implementeren. Voor een MVP kan dit betekenen dat gebruikers er niets van merken.
U moet uitzoeken welke gebruikerstaken kunnen worden overgezet naar selfservice en welke impact elk van deze taken heeft op de bedrijfskosten. Vervolgens doe je het onderzoek met je gebruikers om te zien of ze het met je eens zijn. De combinatie van dit werk laat je zien welke gebruikerstaken kunnen worden geschakeld, en je kunt de besparing die je daarvan verwacht uitrekenen. Het ontwerp kan erop gericht zijn dat de gebruiker zichzelf kan bedienen.
In dit scenario moet u uitzoeken welke opties voor cross-selling het meest waarschijnlijk en voordelig voor u zijn. U moet dan een portal of omgeving ontwerpen waarin uw producten elkaar ondersteunen. En waarin je cross sales ondersteunt. In de voorgaande scenario's hoeft u niet per se rekening te houden met andere prijzen. In dit scenario is een andere prijsstelling om cross-selling aan te moedigen zeker iets dat u kan helpen dat doel te bereiken.
Als je portal aantrekkelijker moet worden omdat je producten combineert die gebruikers toch gebruiken, dan is het belangrijk om te kijken welke producten op welke manier worden gebruikt. En hoe je de producten in die ene portal kunt combineren om werkprocessen te ondersteunen.
Het toevoegen van functionaliteit die uw bedrijfsresultaten aanzienlijk zou moeten verhogen, is een investering in ontwerp, ontwikkeling en marketing. Met andere specialisten die ook meespelen. Een heel ander en riskanter vooruitzicht.
Elk van de bovenstaande scenario's betekent verschillende dingen doen om verschillende opbrengsten te krijgen. De meeste van hen betekenen dat elke ontwerpopdracht anders is dan de volgende. En daar gaat het ons ontwerpers om. We gaan verschillende ontwerpen maken voor verschillende producentenwaarden.
Goede ontwerpers zullen waarschijnlijk ook zonder duidelijkheid goede dingen maken. Goede dingen die zelfs relevant zijn, misschien. Inderdaad: misschien, en: misschien. Veel richtingen kunnen goed zijn als je doelen niet al te duidelijk zijn. Wil je echt een solide business case met een goede ROI? Begin dan uw project met zoveel duidelijkheid over de producentenwaarden als u in uw projectrapporten wilt zien.
Voor alle duidelijkheid, ik pleit er niet voor om uw klant door een bedrijfsstrategieproject te leiden. Wij zijn ontwerpers en geen bedrijfsstrategen. Maar we moeten ze wel de juiste vragen kunnen stellen. Hoe ze aan de antwoorden komen, is hun zaak.
Als uw klant u kwantitatief kan vertellen waarom ze geld betaalt om een digitaal product te laten ontwikkelen, dan zal dat leiden tot beslissingen in uw ontwerp. Die je nodig hebt om de resultaten te krijgen waar je klant naar op zoek is. En soms heb je helemaal geen ontwerp nodig.
* "Producer-waarden" zijn bedrijfsdoelen, maar verschillend van "koperswaarden", "partnerwaarden" en "leverancierswaarden" (die ook allemaal bedrijfsdoelen zijn) en natuurlijk "gebruikerswaarden".
Misschien vind je het ook leuk:
Een inleiding tot waardegedreven ontwerpen
Koperswaarden in het ontwerpproces: wanneer 'waarom' belangrijker is dan 'wat'
Veel gebruikersverhalen zijn geen gebruikersverhalen
Upgraden van functiegedreven naar waardegedreven ontwikkeling