10 manieren om een discoveryfase goed voor te bereiden
Veel digitale projecten beginnen met een oplossing. Er moet een nieuwe website komen. De organisatie wil een portaal. Het huidige CMS moet worden vervangen. Of iemand heeft al besloten dat de nieuwe applicatie met een bepaalde techniek gebouwd moet worden.
Dat lijkt voortvarend, maar daarmee sla je soms een belangrijke stap over. Want welk probleem moet die oplossing eigenlijk oplossen? Wie gaat ermee werken? Welke systemen moeten worden gekoppeld? Wat moet direct kunnen en wat kan later? En past dit allemaal binnen het beschikbare budget?
Wij komen als technisch partner regelmatig pas aan tafel wanneer een groot deel van deze keuzes al is gemaakt. Pas tijdens de ontwikkeling blijkt vervolgens dat bepaalde keuzes veel meer tijd kosten, niet goed schaalbaar zijn of botsen met eisen rondom toegankelijkheid, privacy en security.
Een discoveryfase helpt om strategie, gebruikers, content, ontwerp en techniek bij elkaar te brengen voordat je gaat ontwerpen en ontwikkelen. In dit artikel leg ik uit wat een discovery is, wat je ervan kunt verwachten en hoe je jezelf er goed op voorbereidt.
Wat is een discoveryfase?
Een discoveryfase is een onderzoeksfase aan het begin van een digitaal project. Tijdens deze fase onderzoek je wat er nodig is om van een idee, probleem of ambitie tot een realistische oplossing te komen.
Dat kan gaan om een nieuwe website, maar net zo goed om een klantenportaal, kennisplatform, intranet of maatwerk webapplicatie.
Het doel is niet om zo veel mogelijk documentatie te produceren. Het doel is om voldoende duidelijkheid te creëren om verantwoorde keuzes te kunnen maken.
- de doelen van de organisatie
- de behoeften van gebruikers
- bestaande processen en knelpunten
- content, data en koppelingen
- privacy, security en digitale toegankelijkheid
- technische mogelijkheden en beperkingen
- beheer, budget, planning en prioriteiten
Na een discovery moet duidelijk zijn wat je gaat maken, voor wie je dat maakt, waarom bepaalde keuzes worden gemaakt en hoe je het project kunt opdelen in haalbare stappen.
Waarom is een discovery nodig?
Bij de start van een project zijn er vaak veel aannames. Gebruikers zouden behoefte hebben aan een dashboard. De nieuwe website moet dezelfde content bevatten als de huidige website. Er is een app nodig. Het CMS moet headless worden. Alle functionaliteiten zijn nodig voordat het platform live kan.
Sommige aannames blijken te kloppen. Andere niet.
Wanneer je deze aannames pas tijdens de bouw onderzoekt, wordt het duur om nog van richting te veranderen. Een ontwerp moet worden aangepast, de architectuur blijkt niet geschikt of er is meer maatwerk nodig dan vooraf was ingeschat.
Een discovery haalt een deel van die onzekerheid naar voren. Dat voorkomt niet iedere verrassing, maar zorgt er wel voor dat je de belangrijkste risico's eerder ziet.
Begin niet met de gewenste oplossing, maar met het probleem dat je wilt oplossen. Dan ontstaat ruimte om te onderzoeken wat echt nodig is.
Thomas van Eldijk
Emble
10 manieren om je discovery goed voor te bereiden
Gebruik deze punten als praktische voorbereiding op de eerste discoverygesprekken.
Begin met het probleem, niet met de oplossing
Beschrijf eerst welk probleem je wilt oplossen. Niet alleen: we hebben een klantenportaal nodig, maar bijvoorbeeld: klanten nemen contact op omdat ze hun gegevens, documenten en aanvraagstatus niet zelf kunnen inzien.
Bepaal wat je wilt bereiken
Maak duidelijk welke verandering het project moet opleveren, zoals minder klantvragen, betere vindbaarheid, kortere doorlooptijden, eenvoudiger beheer of meer offerteaanvragen.
Verzamel de aanleiding en voorgeschiedenis
Leg uit hoe de huidige situatie is ontstaan. Welke oplossingen zijn eerder geprobeerd, welke beslissingen zijn al genomen en welke onderwerpen liggen intern gevoelig?
Betrek de juiste mensen
Een digitale oplossing raakt vaak management, communicatie, IT, beheer, juridische zaken, klantenservice, redacteuren en eindgebruikers. Zorg ook dat iemand kan besluiten.
Breng gebruikers en taken in beeld
Maak een eerste overzicht van bezoekers, klanten, medewerkers en redacteuren. Wat proberen zij te bereiken en waar lopen ze nu tegenaan?
Verzamel wat er al beschikbaar is
Denk aan analytics, zoekopdrachten, klantonderzoek, gebruikerstesten, persona's, sitemaps, contentinventarisaties, huisstijlrichtlijnen, documentatie, supportvragen en eerdere plannen.
Breng het digitale landschap in kaart
Maak zichtbaar welke systemen bestaan, wie eigenaar is, welke data erin staat, welke API's beschikbaar zijn en welke koppelingen nu of later nodig zijn.
Wees duidelijk over budget, planning en capaciteit
Budget, deadlines en interne capaciteit zijn geen ongemakkelijke details, maar randvoorwaarden waarmee je de best mogelijke eerste versie bepaalt.
Maak onderscheid tussen nodig en gewenst
Orden functionaliteiten in noodzakelijk, waardevol, handig en later. Zo ontstaat de basis voor een MVP: een bewuste eerste versie die echt waarde levert.
Sta open voor andere conclusies
Een discovery heeft weinig waarde wanneer de uitkomst vooraf al vaststaat. Soms is uitbreiden beter dan herbouwen, soms is maatwerk nodig en soms moet eerst een proces veranderen.
Wat kun je tijdens een discovery verwachten?
De invulling van een discovery verschilt per project. Een internationale website vraagt om andere onderzoeken dan een applicatie waarmee medewerkers complexe werkprocessen uitvoeren.
Meestal bestaat een discovery uit een combinatie van interviews, werksessies en onderzoek. We bespreken doelen, gebruikers, processen en wensen. We bekijken bestaande websites, applicaties, content en documentatie. Waar nodig werken we gebruikersflows, wireframes, scenario's of een technisch concept uit.
Tussen de sessies door wordt informatie geanalyseerd en samengebracht. Het discoveryteam toetst aannames, onderzoekt technische mogelijkheden en brengt afhankelijkheden en risico's in beeld.
Wat is het eindresultaat van een discovery?
Het eindresultaat is afhankelijk van de vraag en de omvang van het project. Voor sommige projecten is een technische architectuur belangrijk, terwijl bij een ander project eerst vooral duidelijkheid nodig is over gebruikers, content en processen.
- een duidelijke beschrijving van doelen en gebruikers
- gebruikersflows en belangrijkste processen
- een functionele scope en afgebakende MVP
- wireframes of een klikbaar prototype
- een voorgestelde technische architectuur
- een overzicht van systemen en koppelingen
- een backlog, risico-overzicht, roadmap, planning en budgetindicatie
De uitkomst moet concreet genoeg zijn om een besluit te nemen over de volgende stap. Geen dikke rapportage die in een la verdwijnt, maar materiaal waarmee ontwerp en development verder kunnen. Dat is ook hoe we onze discoverydienst hebben ingericht.
Wat moet je niet van een discovery verwachten?
Een discovery is geen volledige ontwerpfase. Er kunnen wireframes of prototypes worden gemaakt om ideeën te toetsen, maar meestal ligt er na de discovery nog geen compleet uitgewerkt visueel ontwerp.
Het is ook geen volledig dichtgetimmerd bestek waarin iedere knop en uitzondering vooraf is beschreven. Vooral bij maatwerkprojecten blijven er tijdens ontwerp en ontwikkeling details ontstaan die je pas goed kunt beoordelen wanneer je de oplossing daadwerkelijk ziet en gebruikt.
Daarnaast is een discovery niet bedoeld om alle bestaande ideeën te bevestigen. Soms is de belangrijkste conclusie juist dat een bepaalde wens niet binnen het budget past, weinig waarde toevoegt of technisch onnodig ingewikkeld is.
Discovery in de praktijk bij IKCplay
Voor IKCplay moest de nieuwe website meer doen dan producten en projecten mooi presenteren. De website moest internationale groei ondersteunen, in meerdere talen werken en eenvoudig uitgebreid kunnen worden voor nieuwe markten en campagnes.
In de aanloop naar de ontwikkeling hebben we daarom niet alleen gekeken naar het ontwerp. Ook de doelgroepen, contentstructuur, meertaligheid, vindbaarheid en het toekomstige beheer speelden een belangrijke rol.
Dat leidde uiteindelijk tot een meertalige Drupalwebsite met een flexibele component library. In de IKCplay-case lees je meer over de aanpak en het resultaat.
Wat gebeurt er na de discovery?
Na de discovery zijn er verschillende vervolgstappen mogelijk. Soms volgt eerst een UX- en ontwerpfase. Bij technisch complexe projecten kan het verstandig zijn om een prototype of proof of concept te ontwikkelen. In andere gevallen is er voldoende duidelijkheid om direct een backlog op te stellen en de ontwikkeling van de MVP te starten.
De roadmap uit de discovery helpt om het project in logische fases op te delen. Daardoor hoef je niet alles tegelijk te bouwen en houd je beter grip op budget en planning.
Ook na livegang blijft de informatie uit de discovery waardevol. De doelen en prioriteiten vormen het vertrekpunt voor het meten, testen en verder verbeteren van de oplossing.
Je hoeft nog niet precies te weten wat je nodig hebt
Organisaties denken soms dat ze eerst zelf een complete briefing moeten schrijven voordat ze een digitaal bureau kunnen benaderen. Wat ons betreft is dat niet nodig.
Een probleem, ambitie of onzekerheid is vaak voldoende om het gesprek te beginnen. Juist wanneer je nog niet precies weet hoe de oplossing eruit moet zien, kan het verstandig zijn om strategie, UX en techniek vroeg aan tafel te zetten.
Wil je een digitaal vraagstuk onderzoeken voordat je begint met ontwerpen of bouwen? Lees dan meer over onze discoverydienst voor websites en webapplicaties.
Discovery starten?
Wil je dit soort vragen eerst scherp krijgen voordat je een ontwerp- of ontwikkeltraject start? Dan is een discovery een logische eerste stap.
Plan een gesprek via de discoverydienst van Emble, dan kijken we samen welke voorbereiding voor jouw vraagstuk zinvol is.
