Indivirtual is al vele jaren overtuigd van Rapid Prototyping als ontwerpmethode. Hoe complexer het project, hoe groter de voordelen ervan. Het ontwerpproces van complexe webomgevingen wordt op verschillende manieren aangepakt. Veel mensen zal het rijtje: eisen en wensen verzamelen, interactie-, grafisch -, functioneel - en technisch ontwerp bekend voorkomen. Ook worden er vaak systematische benaderingen gekozen, meestal op basis van UML. Indivirtual gebruikt voor online selfservice portals een alternatieve methode: Rapid Prototyping. Hieronder leggen we uit wat Rapid Prototyping inhoudt en waarom het volgen van het bovenstaande rijtje van op elkaar volgende documenten een slecht idee is bij complexe online omgevingen. Net zoals het gebruiken van een sterk geformaliseerde methode, waarbij alleen stakeholders kunnen bijdragen die de gebruikte methodiek (zoals UML) kennen.

Selfservice portal

klanten beheren zelf online hun persoonlijke gegevens
meestal ook beheer van producten of diensten (verzekeringspolissen, financiële producten, bestellingen, abonnementen enz.)
in veel gevallen cross- en up-selling
soms koppeling met e-commerce omgeving (shopping cart, winkelwagen), sales funnels of gebruikerprofielen (social)
vaak heten deze omgevingen Mijn... (de puntjes staan voor de naam van het bedrijf / instelling)

Het speelveld

Het ontwerp van deze webomgevingen is ingewikkeld, want:

De techniek aan de bezoekerskant en die van de interne techniek (mid - en back office) is complex.
Deze omgevingen raken bijna alle aspecten van de betreffende organisatie.

Doorgaans zijn ten minste de volgende afdelingen betrokken:

Communicatie
Marketing
IT
Product/business/financiën
Legal/risk/compliance
Klantenservice

Het aanbieden van een selfservice portal is een strategische beslissing. Daarom raakt het ontwerpproces bovendien alle lagen van de organisatie:

directie, management
domain experts
uitvoerend

De inbreng van al deze betrokkenen zal sterk variëren:

Sommigen zullen focussen op de mogelijkheden en de kansen (Marketing, Business).
Anderen zullen zich ook moeten richten op de beperkingen en de risico's (IT, Legal).

Een selfservice portal stelt de buitenwereld in staat diep door te dringen in de interne organisatie en IT van het betreffende bedrijf (outside-in). Daarom moeten bij het ontwerp van elk afzonderlijk onderdeel de kansen, de randvoorwaardes, de mogelijkheden en de risico's worden afgewogen. Een succesvol georganiseerde ontwerpfase levert op basis van die mix een creatieve en (net) haalbare oplossing.

Waarom is het maken van een selfservice portal lastig?
Organisatie	Klantenservice, IT, business, gegevensverwerking, beheer financiële gegevens, verkoop, marketing, contracten, fulfillment, het portal raakt ze allemaal.
Verwerking	Niet alle gegevens kunnen geautomatiseerd worden verwerkt. Soms is voor sommige onderdelen handmatige controle of goedkeuring nodig en voor andere niet. Leg dan maar eens aan een bezoeker uit waarom hij/zij na mutatie soms toch nog de oude gegevens te zien krijgt.
Kwaliteit data	Eventuele problemen met de klantgegevens worden blootgelegd. Een interne code die door een klantenservicemedewerker tijdens een telefoongesprek moeiteloos vertaald wordt naar een bundel afgesloten contracten - apart op te zoeken in het oude systeem X - zegt een klant op de website niets.
Veiligheid	Het portal vraagt een waterdicht en toch gebruiksvriendelijk loginsysteem (vaak een single sign-on (SSO) met andere omgevingen). En dus ook een even waterdicht proces voor registreren en het herstellen van door gebruikers vergeten inloggegevens. Het aanmelden van bestaande klanten vereist al tijdens de registratie een koppeling met een CRM systeem om doublures te voorkomen. Tegelijkertijd dienen de gegevens van de bestaande klanten goed beschermd te blijven.
Koppelingen	Login en profieldatabases, mid office, back office, CMS en webapplicaties moeten samenwerken. Omdat de meeste van deze systemen bovendien een single point of failure vormen, zijn de stabiliteitseisen aan het geheel hoog. Secundaire koppelingen zijn gewenst voor analyse en rapportage, mailing enz.
Kanalen (mobile)	Omdat smartphones bij uitstek geschikt zijn om 'het even snel te regelen', worden in veel gevallen (delen van) selfservice omgevingen mobiel ontsloten.

Valkuilen ontwerpfase

De strategische beslissing is genomen om een self-service portal in te stellen, de business case geeft ruwweg de gewenste mogelijkheden voor de online klant aan; het ontwerp kan beginnen: Welke methodiek ook gevolgd wordt, het project vangt altijd aan met het verzamelen van de requirements. Hier ontstaat echter meteen al het belangrijkste probleem. Aan alle stakeholders wordt gevraagd om hun opsomming van eisen en wensen aan te leveren. Maar zij moeten dit doen op basis van hun eigen voorstelling van het eindresultaat. De een kan beter overzien hoe de online functionaliteit zal gaan werken dan de ander, maar voor iedereen is het abstract. Bovendien heeft ieder slechts verantwoordelijkheid voor een deel van het geheel. Dat komt door het verschil in expertise (de marketeer kijkt naar hele andere aspecten van het portal dan de IT-er) of door de verschillende rollen (de eisen van de productspecialist en die van de juridisch medewerker zullen verschillen). De resulterende requirements zijn dus niet geïntegreerd en evenmin geprioriteerd. De hierna gevolgde klassieke methode van op elkaar volgende documenten (zoals het genoemde interactie-, grafisch -, functioneel - en technisch ontwerp) vergroot het probleem: Er is geen weg meer terug. Als je je grafisch ontwerp baseert op je interactie ontwerp dat weer gebaseerd is op het requirements document, betekent een aanpassing in dat grafisch ontwerp al gauw dat je ook de twee eerdere documenten met terugwerkende kracht moet aanpassen. En hernieuwde instemming van de stakeholders moet verkrijgen. Hoe verder gevorderd, hoe groter de kans dat hierdoor een verlammende werking op het project ontstaat. Kortom: Het eindresultaat blijft abstract en zodra het niet meer abstract is, is het eigenlijk al te laat om nog te kunnen bijsturen: Er is geen ruimte voor voortschrijdend inzicht. Bij het opsommen van alle stakeholders in de vorige paragraaf is de belangrijkste betrokkene gemakshalve overgeslagen: de user (de klant, de eindgebruiker van het selfservice portal). De gebruiksvriendelijkheid van het ontwerp wordt doorgaans gevalideerd door een usabilitytest. En in die term schuilt eigenlijk al het probleem: "valideren" is iets dat je achteraf doet. Voordat je een usabilitytest kunt afnemen moet de userinterface beschikbaar zijn, dat betekent dat de ontwerpen al klaar zijn, en de bouw al begonnen is. Kortom: De enige uitkomst van de usabilitytest mag zijn dat de interface voldoet, het alternatief "back to the drawing board" is geen optie. Dit zijn de voornaamste redenen dat Indivirtual kiest voor een alternatieve aanpak: Rapid Prototyping.

Rapid prototyping stelt de stakeholders in staat gedurende het hele project te beoordelen hoe hun eigen requirements uitpakken en geeft hun het overzicht over het hele systeem.
Rapid prototyping stelt het projectteam in staat om de user al vanaf het begin bij het ontwerp te betrekken.

Rapid Prototyping: Voortschrijdend inzicht gebruiken

Simpel gezegd is de filosofie achter deze manier van werken dat een plaatje meer zegt dan duizend woorden. En dat je daarom vanaf de eerste dag met alle betrokkenen over dat plaatje wilt praten. In Rapid prototyping vervangt het prototype een groot deel van de gebruikelijke projectdocumentatie. De tooling (prototyping environment) stelt de ontwerpers in staat om requirements en specificaties te beheren. En stelt de stakeholders in staat om feedback te leveren en met het team te delen. [caption id="attachment_959" align="alignnone" width="1221" caption="Vergelijking ontwerpmethodes selfservice portals"]

Vergelijking ontwerpmethodes selfservice portals

[/caption] De belangrijkste verschillen met de klassieke aanpak worden duidelijk uit het bovenstaande schema:

Er wordt meer en al eerder getest met eindgebruikers.
Diverse secundaire projectdocumentatie wordt direct vanuit de prototyping environment gegenereerd.
De doorlooptijd van de ontwerpfase is korter.
Het aantal documenten is kleiner.
De projectrisico's worden kleiner doordat developers kunnen teruggrijpen op een werkend prototype en zich niet zelf een beeld hoeven te vormen op basis van diverse beschrijvingen (ook nu geldt het plaatje en de duizend woorden).
Het prototype wordt tijdens de bouw bijgewerkt, zodat ook in deze fase voortschrijdend inzicht gefaciliteerd wordt.

Klassieke aanpak, toch een prototype

In grotere projecten wordt vrijwel altijd een prototype gemaakt. Doorgaans tegen het einde van de projectfase. Dit prototype wordt gebruikt voor de final buy-in van de stakeholders en voor de usability test, die dan wat eerder dan in bovenstaand schema kan worden gehouden. Wat is het verschil met Rapid Prototyping? Vooral dat het een aanzienlijke extra inspanning is (minimaal van de grafisch designers en front-end developers), die doorwerkt op zowel het budget als de doorlooptijd. En dat dit type prototype bedoeld is voor eenmalig gebruik.

Rapid Prototyping in detail

De kenmerken van deze manier van prototyping zijn:

Er wordt gebruik gemaakt van een prototyping of modeling omgeving (bijvoorbeeld Serena Prototype Composer, MS Expression Blend SketchFlow of Axure RP) om de 'bouw' inspanning van het prototype te minimaliseren (Indivirtual gebruikt Axure RP v6).
Er wordt een user centered design approach (UCD) gekozen: De requirements worden zo snel mogelijk vertaald in mock-ups ("wireframes") van de schermen en functionaliteiten die de webbezoeker te zien krijgt (userinterface).
Het beheer van de requirements (classificatie, prioritering en verdeling over projectfases) vindt plaats binnen de prototyping environment.
Er wordt strikt vastgehouden aan een werkwijze waarbij begonnen wordt met het high level modelleren van de afzonderlijke userinterface schermen en waarbij van daaruit stapsgewijs meer detail wordt aangebracht (iteratieve aanpak).
De samenhang tussen de afzonderlijke onderdelen van de userinterface wordt op basis van het modelleren van processen en flows binnen de prototyping environment gevisualiseerd (klikbare flowcharts, use cases en diagrammen): Dit is de "30.000 feet view".
De prototyping environment stelt de stakeholders in staat om (per component) hun feedback toe te voegen, deze wordt automatisch gedeeld met het projectteam.

De kenmerken van de methodiek zijn:

In de projectgroep nemen alle stakeholders deel en daarnaast de ontwerper(s) die de verantwoordelijkheid hebben voor het prototype en de lead developer die verantwoordelijk is voor de bouw van het self service portal.
Zodra de stakeholders de eerste globale inventarisatie van hun requirements hebben gemaakt, wordt direct begonnen met het prototype. Het prototype wordt gemaakt in nauwe samenwerking tussen de ontwerper en de afzonderlijke inhoudsdeskundige(n) die de kennis hebben over het betreffende onderdeel.
De vraagstukken die het domein van een enkele inhoudsdeskundige overstijgen, worden aan de projectgroep voorgelegd.
Het prototype wordt voorgelegd (aan de individuele inhoudsdeskundigen en aan de groep). Dit stelt hen in staat om op basis van concrete schermen te beoordelen hoe hun requirements 'in het echt' uitpakken en om alternatieve scenario's naast elkaar te beoordelen. In deze fase wordt er actief gebruik gemaakt van voortschrijdend inzicht.
Het prototype wordt aangepast op basis van de feedback van de stakeholders. Het blijft de stakeholders toegestaan om de requirements aan te passen. (Zolang er geen scope creep ontstaat. Als dat wel het geval is, vormt het prototype de documentatie om de business case te verbreden of het mandaat van de projectgroep te verruimen).
Het aangepaste prototype wordt weer voorgelegd.
Deze cyclus van voorleggen, feedback verzamelen en aanpassen wordt meermaals doorlopen (met de individuele inhoudsdeskundigen en met de groep). Tegelijkertijd wordt het prototype voortdurend verrijkt met specificaties die gaandeweg duidelijk worden. Bijvoorbeeld doordat de scenario's in meer detail besproken worden. Of omdat op basis van de schermen de beperkingen of de ongedachte mogelijkheden van de bestaande infrastructuur of interne processen duidelijk worden.
De meest actuele versie van het prototype is te allen tijde beschikbaar voor alle leden van de projectgroep.

De kenmerken van het resulterende prototype zijn:

Het is nooit 'af' totdat het selfservice portal opgeleverd is en 'live' staat. (Zelfs daarna wordt het bijgewerkt met de toekomstige functionaliteiten en RFC's. Dus ook voortschrijdend inzicht tijdens de bouw is welkom en wordt verwerkt.)
Het bevat alle geprioriteerde requirements (MoSCoW) en vervangt daardoor het Requirements Document.
Het beschrijft de userinterface (de zgn. "wireframes") en vormt daardoor het Interaction Design.
Alle schermen van de userinterface zijn volledig gespecificeerd, inclusief content management, de databronnen van de gegevens, business rules voor de verwerking etc. Als functionele specificaties geen betrekking hebben op een specifiek onderdeel maar een overkoepelend karakter hebben, worden ze in een separate tak van het prototype opgenomen.
Het prototype fungeert hiermee ook als Functional Design.
Door de beschrijving van databronnen en gegevensverwerking dient het prototype ook als interface documentation (specificatie van de koppelingen), dit vervangt een deel van het Technical Design.
De opgenomen visualisaties (diagrammen, flowcharts) specificeren tevens de grote lijn van de software architectuur. Dit vervangt onderdelen van of is een opmaat tot het SAD (Software Architecture Document) en of TO.
Door een zorgvuldige classificatie van requirements en specificaties, kan een groot deel van de benodigde projectdocumentatie vanuit de prototyping omgeving gegenereerd worden. Voorbeelden zijn: requirements, use cases, release planning, content plan, risicoanalyse, testdocumentatie, gebruikersinstructie.
Indien gewenst wordt ook de userinterface voor de interne gebruikers gemodelleerd in wireframes, dit wordt gekoppeld aan de visualisatie van de business processen waar deze schermen onderdeel van uit gaan maken.

Tot slot

Rapid Prototyping wordt binnen alle projectmanagement methodes (bijvoorbeeld waterfall of Agile) toegepast. Maar bij een Agile aanpak (zoals SCRUM) of een aanpak met Agile kenmerken (waarbij de bouw niet pas start zodra het laatste document is goedgekeurd) komt Rapid Prototyping bijzonder goed tot z'n recht.

Ontwerpen van selfservice portals met Rapid Prototyping

Onderwerpen