Maatwerksoftware ontwikkelen doen wij volgens een Design Driven werkwijze. Een wat? Design Driven, Design Sprints en Design Thinking zijn opkomende termen in de software-wereld. Het komt erop neer dat je steeds begint bij wat de gebruiker nodig heeft en vandaaruit ontwerpen maakt. Zo kom je tot intuïtieve oplossingen voor een probleem. Design Driven werken is bijvoorbeeld geschikt om apps te ontwikkelen, maar ook voor productontwikkeling of in andere werkomgevingen. We leggen je uit hoe het werkt.
Design Driven werken in het kort
Eigenlijk zegt de naam het al: Design Driven werken betekent dat je begint vanuit het perspectief van design. Vanuit het ontwerp dus. En nee, dat gaat niet over zozeer over welke vormen en kleuren je gebruikt. Het gaat erom dat je in het algemeen direct iets gaat ontwerpen wat aansluit bij wat de gebruiker zoekt. Op basis van uitgebreid gebruikersonderzoek kom je tot intuïtieve oplossingen.
Design Driven werken is een heel geschikte werkwijze om te bepalen wat je gaat bouwen of om bestaande producten te verbeteren. Vaak wordt inventariseren wat je wilt gaan bouwen of wat verbeterd moet worden als voortraject gezien. Onterecht, vinden wij. Dat traject verdient meer aandacht dan het meestal krijgt. Je ontwikkelt een app, product of oplossing immers voor de gebruiker. Diegene moet ermee overweg kunnen en het moet aan zijn wensen en behoeften voldoen. Uitgebreid gebruikersonderzoek is daarvoor essentieel.
Hoe helderder je in kaart hebt wat de wensen, problemen en behoeften van de eindgebruiker zijn, hoe beter je het product op de gebruiker kunt afstemmen.
Vaak zien we in de praktijk dat softwareontwikkeling begint met een plan van eisen, gebaseerd op interviews met de opdrachtgever. Dat plan is alleen op zich nog geen compleet startpunt voor het ontwikkelen van apps. Je bouwt tenslotte niet software voor de opdrachtgever, maar voor de klant van de opdrachtgever. De eindgebruiker dus. Het is dus veel logischer om de eindgebruiker te betrekken bij de softwareontwikkeling.
Het idee om de behoeften van de eindgebruiker centraal te stellen vanaf de eerste fase noem je Design Thinking.
Design Driven werken bij softwareontwikkeling
Een mogelijke uitwerking van Design Driven werken is dat je software vormgeeft samen met alle stakeholders. Dat zijn natuurlijk de stakeholders bij de opdrachtgever, maar ook de eindgebruikers.
Door de kennis van User Experience Designers en User Interface Designers te combineren met de kennis die aanwezig is bij de opdrachtgever én met inzichten vanuit gebruikers krijg je een totaalbeeld van de situatie.
Samen kijk je naar vragen als:
- Wie zijn de stakeholders?
- Wie zijn de gebruikers?
- Wat zoeken de gebruikers in de software?
- Wat zijn hun behoeften of waar lopen zij tegenaan?
- Zijn er verschillende gebruikersrollen?
- Wie nemen intern de beslissingen over de app?
Design Driven werken in Design Sprints
Design Driven werken doe je in Design Sprints: korte fases van een aantal weken waarin je steeds een stukje van het project oppakt. Aan het eind van elke Design Sprint is er iets om aan de opdrachtgever te laten zien. Daar geeft de opdrachtgever vervolgens feedback op, zodat de software daarna doorontwikkeld en waar nodig verbeterd kan worden.
Voor opdrachtgevers kan dit proces in het begin even wennen zijn. Je weet nooit meteen wat een app gaat kosten. De eerste offerte die je krijgt, is altijd die voor één Design Sprint. Je weet dan wel wat die sprint gaat kosten, maar niet wat je aan het eind van de sprint krijgt. Althans, niet concreet. Je koopt met een Design Sprint een klikbaar prototype dat je op je telefoon, tablet of computer kunt laten zien. Maar wat dat prototype kan, is vooraf onbekend.
In principe moet je er dus op vertrouwen dat het eindresultaat beter wordt naarmate de softwareontwikkelaars verder onderzoek doen. Toch betaalt dat zich zeker terug. Juist door dit voorwerk professioneel op te pakken en daar voldoende tijd voor te vragen, kun je tot betere software komen. Wijzigingen aanbrengen is immers een stuk eenvoudiger (en dus goedkoper) in een vroeg stadium. Zo verdient een Design Sprint zich terug.
Vier stappen: OTAP
Voor het ontwikkelen van onze maatwerksoftware gaan wij uit van vier stappen (die samen OTAP heten), als een manier van Design Driven werken:
- Ontwikkelen: na het design en gebruiksonderzoek gaat de Developer de app bouwen.
- Testen: we doen eerst zelf een test van de app en doen waar nodig verbeteringen.
- Accepteren: daarna test de opdrachtgever deze versie van de app en geeft een akkoord zodra de app naar wens is.
- Publiceren: we publiceren de definitieve app (na eventuele laatste aanpassingen) in de app stores.
Dit is overigens geen lineair proces waarin je een aantal weken in fase 1 en dan een aantal weken in stap 2 zit. Deze vier stappen herhalen we tijdens het proces een aantal keer. Eerst komt versie 1 van de app. Later gaan we verder met versie 2, die meer gefinetuned is. Dan volgt versie 3, etc.
Zo ziet Design Driven werken er bij ons uit
In onze Design Driven werkwijze komen dus de vier OTAP-stappen terug. Meer in het algemeen bestaat ons proces uit een aantal fases. Die zie je terug in de infographic hieronder, maar we zullen ze ook één voor één bespreken.
1. Gebruikersonderzoek en eerste schets
Design Driven werken draait volledig om de behoeften van de gebruiker. Elk project start dan ook met gebruikersonderzoek. We gaan uitgebreid onderzoeken voor wie we de software bouwen. Samen met de opdrachtgever stellen we persona’s op om de diverse typen gebruikers in kaart te brengen. Daarnaast gaan we met gebruikers zelf in gesprek. Wat zijn hun wensen, behoeften, aandachtspunten, etc.?
Als de persona’s duidelijk zijn, doen we een stijlonderzoek. Vervolgens gaan we met de eerste schets van de app aan de slag. Dit is een grove schets die de opdrachtgever een beeld geeft hoe het kan gaan worden. Lo-Fi (low fidelity) noemen we dat.
2. Proof of concept
Als de eerste schets er ligt, gaan we onderzoeken of het maken van de app technisch haalbaar is. Daarvoor maken we een Proof of concept (POC). Dit betekent dat we demonstreren dat de grootste technische uitdagingen goed werken in de app. Daardoor weet je als opdrachtgever zeker dat het ontwikkelen van de app mogelijk is. Ook geeft dit opdrachtgevers houvast om te beslissen over de investering in het vervolgtraject.
3. Design, Development en testen
De volgende fase is een loop waarin Design, Development en testen elkaar afwisselen en door elkaar heen lopen.
Design
Van de schets gaan we een compact en toch volledig design maken. Dit dient als basis voor de eerste versie van de app. Dat noemen we ook wel het minimum viable product (MVP). In die eerste versie zie je alleen de essentiële functionaliteiten. Andere functies pakken we later in de doorontwikkeling op. Het resultaat van de design-fase noemen we het Hi-Fi-ontwerp (High Fidelity).
Development
Is de opdrachtgever akkoord met het minimaal vereiste product? Dan is het tijd om de software te bouwen. Dit doen we dus in Design Sprints, waarin we steeds een afgebakend deel van de software gaan bouwen en testen.
Testen
Zodra er iets is gebouwd, moeten we natuurlijk testen of alles werkt én of de app aansluit bij de wensen van de gebruikers. We doen hiervoor zelf gebruikerstesten: daarin gaat een groep gebruikers de app proberen en er feedback opgeven. Ook krijg je als opdrachtgever een testversie om uitgebreid te testen.
4. Versie 1
Zodra de app uitgebreid is getest en zodra jij akkoord bent, gaan we versie 1 publiceren. Nu kunnen mensen de app echt gebruiken.
5. De volgende versies
Nu versie 1 live staat, komen er vast weer verbeterpunten naar boven. Bovendien ontwikkelt het concept zich verder en kan het altijd zijn dat je voortschrijdend inzicht opdoet. Daarom werken we met onze opdrachtgevers toe naar een versie 2, 3, 4, etc. Ook dit doen we weer via de Design-Development-Test-loop.
Zo komen we tot een nóg betere versie van de app die aansluit op alle actuele ontwikkelingen bij je gebruiker, in de markt en in het concept.
Meer weten over onze software-ontwikkeling?
Software ontwikkelen volgens de Design Driven werkwijze hebben we bij Iconica al voor veel klanten mogen doen. Van gezondheidsorganisaties tot verduurzamingsinitiatieven en speelgoedfabrikanten.
Ben je benieuwd hoe we jou kunnen helpen bij de ontwikkeling van software? Neem contact op voor een kennismaking.
