Strategische App Ontwikkeling

Het gaat niet over Technologie

Versie 3.2 2011-11

2

Inhoudsopgave  

Het  gaat  niet  over  Technologie   3  

Definieer  de  Strategie   3  

Ontwerp  de  Interface   4  Herkenbare  Mix   5  Passende  oplossing   5  Hybride  Apps   6  Raak  aan,  Draai  om   6  

Ontwikkel  de  App   7  Test,  Test  en  Her-­‐Test   8  

Lever  de  Oplossing   8  Meten  is  Weten   8  Vindbaarheid  telt   9  

Nu  niet  Stoppen!   10  

Ontdek   11  

3

Het gaat niet over Technologie Met onze blik op het Mobile fenomeen, de Apps wereld en het App Effect zijn we misschien geneigd te denken dat het een technische revolutie is. Dit is echter een onjuiste benadering. Natuurlijk is er een technologie aspect, maar de belangrijkste factor in Mobile is het menselijke verlangen om mobiel te zijn en verbonden blijven. Naar onze mening gaan Mobile Apps over mensen en hun gedrag.

Het is daarom noodzakelijk om de mogelijke gebruikers en hun gedrag goed te begrijpen als u Apps als een succesvol nieuw kanaal wilt inzetten om uw publiek te bereiken. De oplossing die u biedt is niet alleen een technische oplossing. Het is een oplossing voor een specifieke informatie-, interactie- of transactiebehoefte gedefinieerd door de volledige, rijke context van de potentiële gebruiker. Dat is nadrukkelijk inclusief aspecten als tijd en plaats van de interactie. Een manier van kijken naar al deze aspecten wordt vaak gebruikt in de journalistiek en is bekend als de vijf/zeven W's (wie, wat, wanneer, waar, waarom, hoe, met waarmee). De oorsprong van deze beschrijving is echter veel ouder. Victorinus tekende in de vierde eeuw al een diagram van aspecten van een bepaald scenario. Het mooie is dat de term “Persona” al staat bij de “Wie”. Om goede oplossingen te formuleren hanteren we de aanpak die bekend is bij vele marketeers: Persona’s en Scenario’s, Wie en de overige W’s.

Hoe meer we weten van al deze aspecten rond een specifieke gebruiker (Persona), hoe meer we begrijpen wat hij/zij probeert te bereiken en hoe beter we hem/haar kunnen assisteren bij het vervullen van de behoefte aan informatie rond de interactie of transactie (Scenario). Idealiter moeten wij ons bewust zijn van hun intentie op een bepaald moment en plaats. Van daaruit voorzien we via de App vervolgens in de specifieke, contextuele intentie en bijbehorende informatiebehoefte.

Definieer de Strategie Strategisch beslissen over meedoen in welk kanaal betekent beslissen wat u gaat doen, en ook wat u niet zal doen per kanaal. In een multichannel wereld (en dus zeker in een multiscreen wereld) betekent dit heldere keuzes maken. Deze keuzes moeten niet afhankelijk zijn van technologie en de bijbehorende beperkingen, zoals we hiervoor al beschreven, maar moeten gebaseerd zijn op hoe we waarde kunnen toevoegen aan de gebruikerservaring bij een specifieke interesse in informatie, interactie of transactie. Optimale inzet per kanaal, met behoud van een eenduidige uitstraling over de kanalen heen. Hiermee behoudt uw organisatie de belangrijke eigen identiteit.

Om te weten wat relevant is voor een specifieke gebruiker of gebruikersgroep, moeten we deze doelgroep definiëren in een Persona, als een referentiepersoon of archetype. Vanaf daar kunnen we denken in de situationele context rondom deze gebruiker die op

4

zoek is naar informatie of interactie met u, als een organisatie die in staat zou kunnen zijn om dit nu te leveren. Deze aanpak resulteert in scenario's, (use-cases) die kunnen leiden tot concepten voor mobiele toepassingen. Scenario’s voorzien van context zoals plaats en tijd, waar en wanneer. Die leiden tot AppConcepts die toegevoegde waarde leveren. Deze hebben een duidelijk en logisch doel voor de doelgroep doordat ze werkelijk in staat zijn deze waarde toe te voegen.

Deze stap helpt om te beslissen wat te doen, om strategisch te handelen en helpt daarmee onderdelen van de AppStrategy te definiëren. De strategie moet worden aangevuld met keuzes rondom businessmodellen als gratis, freemium, met reclame of betaald en hoe de diensten en producten verstrengelen of overlappen op het Mobiele Platform, Het Web en de Sociale Media. Een AppStrategy kan niet alleen de App Wereld beschrijven of de algemene aspecten van deze wereld raken. Een AppStrategy moet in lijn zijn met de Online strategie, de strategie voor het Web, de overige kanalen en natuurlijk de bredere bedrijfsstrategie.

Om beter te voldoen aan de behoeften van een specifieke gebruiker moeten we bouwen aan een relatie met deze gebruiker en deelnemen aan de dialoog. Vanaf daar kan de interactie rond informatie leiden tot een logische transactie. De transactie als gevolg van een relatie en een gesprek, niet andersom.

Voor veel organisaties is dit een nieuwe manier van denken over hun klanten, niet als een nummer of als een bron van inkomsten in een Excel-sheet, maar als relatie, als oprecht betrokken mensen. Daarom is het zo belangrijk dat een volledige communicatiestrategie wordt opgesteld, vooral voor online, voor Sociale Media, en in lijn met de AppStrategy. Elk kanaal heeft zijn eigen karakter, en dit karakter helpt de boodschap op zo’n manier dat het kanaal dat geselecteerd wordt zelfs onderdeel gaat worden van de over te brengen boodschap. The medium is the massage - Marshall McLuhan.

Ontwerp de Interface De informatiebehoefte van de gebruiker kunnen we analyseren in termen van het leveren van de informatie en in de bundeling van de informatie en interactie in clusters die we gaan gebruiken om de schermen te ontwerpen. Deze schermen worden in een specifieke volgorde gelegd, zodanig dat ze de doorloop van de applicatie laten zien. Deze logische schermen en hun volgorde worden aangemaakt zonder dat het nodig is om nog maar een letter van een App te programmeren. Het gaat alleen nog maar over het

5

ontwerp van de gebruikersinteractie en het -gedrag rondom de benodigde informatie. Meestal is dit een reeks slides die we kunnen laten zien aan een aantal vertegenwoordigers van de doelgroep. Door dergelijke “prototypes” op een mobiel device te tonen wordt een nog beter beeld en gevoel gegeven. Hiermee is de eerste test door de gebruikers eigenlijk al een feit. Ze zijn vanaf het eerste moment betrokken zodat het ook echt hun App wordt. De feedback van deze groep is heel erg waardevol en kan enorm goed gebruikt worden om het AppConcept nog verder te verfijnen.

Focussen rond een specifieke gebruiker en toegevoegde waarde bieden is daarmee de eerste sleutel tot succes in de App World. Specifiek zijn betekent dat er geen “Alles in één App” is, er zijn meerdere functionaliteiten die gebundeld kunnen worden, maar ze moeten allemaal relevant zijn voor de specifieke gebruiker en voor de context van het AppConcept, het Scenario. Dit betekent dat het voor elke organisatie belangrijk is om niet te denken in 'een App' maar in 'Apps' als logisch gebundelde functionaliteit per contextuele situatie met verschillende use-cases verdeeld over alle Apps.

Herkenbare Mix De App moet een mooie, schone, directe en logische interface hebben. De focus van de gebruiker moeten worden gerespecteerd, niet worden afgeleid. Dat betekent dat het elegante “één knop, één functie concept” de gebruikers beter helpt bij het bereiken van hun doel dan een fancy interface die teveel interpretatie verlangt. Dit is echt een uiterst delicaat evenwicht en daarom specialistenwerk. Designers die gewend zijn om met dit dilemma om te gaan bieden hier uitkomst. Design is niet een dun laagje grafisch vernuft. Design is hoe de App werkt.

Voor elke applicatie is het enorm belangrijk om een specifieke look-and-feel te ontwerpen. Dit ontwerp moet voldoen aan het AppConcept, maar dat is natuurlijk niet altijd de enige en meest belangrijke factor, hoewel het voor applicaties zoals games meestal wel de meest dominante is. Gebruikers van een specifiek platform zijn gewend aan de interactie die dit platform biedt. IPhone Apps ogen en gedragen verschillend in vergelijking met bijvoorbeeld Android Apps of Windows Phone 7 Apps. Deze platformen hebben elk hun eigen specifieke richtlijnen die naadloos moeten worden vermengd met het ontwerp van uw App. Immers, als de gebruiker de App niet begrijpt dan wordt hij niet meer gebruikt.

En als laatste punt, maar zeker niet onbelangrijk, moeten uw eigen richtlijnen voor het presenteren van uw merk of de uitstraling van uw website, in ogenschouw worden genomen en worden samengebracht met het AppConcept en de platformrichtlijnen. Dit resulteert in een App die onmiskenbaar uw App is, en de gebruiker toch herkent als de App speciaal ontworpen voor zijn of haar Smart Mobile. Overduidelijk resulteert dat dus in meerdere uitvoeringen per AppConcept als u ervoor kiest om verder te gaan met de ontwikkeling voor diverse platformen.

Passende oplossing Op een aantal plaatsen is al aangegeven dat Apps aan bepaalde standaarden en richtlijnen moeten voldoen om ervoor te zorgen dat ze passen in het totaalplaatje van een organisatie. Als Apps bijvoorbeeld worden ingezet om klanten transacties te laten uitvoeren is het belangrijk dat de klanten op een eenduidige manier, over alle kanalen heen, worden herkend en geautoriseerd. De meeste organisaties hebben voorzieningen en standaarden voor identity management, security management, multichanneling, CRM

6

etc. Vaak zijn deze beschreven in een zogenaamde enterprise-architectuur. Bij het ontwikkelen van Apps moet aangesloten worden bij deze enterprise-architectuur. Waar deze niet beschikbaar zijn, is het verstandig om deze te ontwikkelen.

Indien de organisatie veel verschillende Apps maakt voor verschillende platformen is het verstandig om een App-architectuur op te stellen met principes en standaarden voor het ontwikkelen, beheren en onderhouden van Apps. Het doel hiervan is te voorkomen dat voor iedere App het wiel opnieuw wordt uitgevonden.

Hybride Apps Hybride Apps bieden mogelijkheden om met minimale inspanning toch maximaal resultaat te halen op meerdere platformen. Het hergebruiken van delen van de content, opmaak en eventueel basis interactie is mogelijk doordat gewerkt wordt met een dunne ‘Native App’ die platform specifiek is en daarbinnen gebruik maakt van algemeen geldende internetstandaarden als HTML, CSS en JavaScript.

De inhoud kan op deze wijze eenvoudig gescheiden gehouden worden van de opmaak en de interactie. Voor de inhoud en opmaak gebruiken we standaarden als XML, HTML en CSS. Voor de basis interactie kan gebruikt gemaakt worden van JavaScript. Voor de echte, cruciale gebruikersbeleving op het device zelf kan gebruikt gemaakt worden van alle unieke eigenschappen van het platform door een relatief dun laagje in de native App op te nemen. Denk in termen van 80-20 waarbij er slechts 20% native wordt ontwikkeld en 80% op basis van de hiervoor genoemde webstandaarden, die door bijvoorbeeld redacteuren zelf kunnen worden gebruikt om de inhoud vorm te geven.

Een ander groot voordeel van deze optimale native ontwikkeling is dat de App met een beperkte inspanning ook naar andere platformen kan worden overgezet. Denk aan de opkomende markt voor Android tablets met Honeycomb en eventueel andere leveranciers. Naast deze optimale native aanpak kan voor de minder bekende tablets een mobiele website gemaakt worden, die tevens gebruik maakt van dezelfde informatiestromen. Hiermee wordt het mogelijk om op diverse platformen de unieke gebruikersbeleving te creëren, die hoort bij de specifieke eigenschappen van het platform (Android tablets zijn immers anders in gebruik dan iPads) en houden we toch de mogelijkheid voor hergebruik en eenvoudige redactie. Daarnaast is het pad “overig mobile” prima uit te breiden naar opkomende online platformen als QNX van BlackBerry, Windows 8 van Microsoft, WebOS van HP, ChromeOS van Google en Mobile Web voor anderen.

Een gezonde mix tussen Native en Webtechnologie kan op deze wijze helpen diverse gebruikers toch hun herkenbare platformmix op maat te leveren tegen relatief beperkte kosten.

Raak aan, Draai om Bij het ontwerpen van de App moeten we continu beseffen dat de gebruiker kan interacteren met de App door middel van aanraking. Dit betekent dat de gebruiker een deel van de interface bij de interactie afdekt met zijn eigen hand en dat de interface afgestemd moet zijn op de dimensies van de vingertoppen. De afmetingen van de knoppen, sliders en invoervelden moeten dit dus weerspiegelen. Maar ook de dimensie van het interfacescherm heeft invloed op de look-and-feel van een succesvolle interface. Op een groter scherm is er voldoende ruimte om de navigatie te combineren met de

7

inhoud, op kleinere schermen wordt dit bij voorkeur verdeeld over verschillende schermen.

Daarnaast beïnvloedt de schermgrootte ook de potentiële inzet van het device. Het karakter van een iPad, of andere touch-tablet zoals Galaxy Tab, Asus Transformer, of andere Android Tablet, is echt anders dan dat van een smartphone. Het verschil zit in de context, dus de te verwachten intentie van de gebruiker. Een smartphone is een apparaat voor onderweg, een tablet is een device voor onderuit. Deze houding zegt alles over het gebruik, de interactie, en dus ook de informatiebehoefte. De mobiele context van de gebruiker genereert een informatiebehoefte die anders is dan de consumerende gebruiker op de bank.

Wat relevant is op een smartphone hoeft dus helemaal niet zo relevant te zijn op een tablet. Zeker iets om rekening mee te houden bij het ontwerp en de mogelijk bredere inzet en uitrol van uw concept!

Daarnaast moeten we rekening houden met het feit dat de gebruiker het apparaat ook nog eens vasthoudt, waarbij meer en meer apparaten kunnen detecteren hoe een gebruiker dat doet. Er zijn bijvoorbeeld apparaten die het schudden of draaien kunnen detecteren waar door de App acties aan kunnen worden gekopppeld. Deze manier van omgaan met de App leidt tot een geheel nieuwe manier van interactie met de content, denk bijvoorbeeld aan het schudden van het apparaat om de inhoud van de App te verversen. Dit fysiek bewegen is een relatief nieuwe, maar steeds vaker voorkomende manier, om te interacteren met de App. Echte standaarden zijn hiervoor nog niet beschikbaar, maar een geheel nieuwe interactietaal wordt geboren en dat is een spannende ontwikkeling waar we zeker op moeten letten. Denk naast draaien en schudden ook aan spraaksturing, een grote belofte die eindelijk tot leven lijkt te komen.

Het is erg belangrijk om feedback te ontvangen van een geselecteerde groep van vertegenwoordigers op uw interface, de doorloop van de applicatie en het ontwerp van de schermen en algemene graphics. Het is altijd belangrijk om vroeg en vaak te testen, bij voorkeur met werkelijke gebruikers. Op deze manier krijgt u niet alleen waardevolle input maar wordt het echt hun App.

Ontwikkel de App Het is tijd om de App te gaan bouwen voor de gewenste platformen. Over het algemeen zal de App informatie gaan gebruiken uit diverse Internet- en Web Services. Het is het meest eenvoudig en voor de hand liggend om algemeen geldende webstandaarden te gebruiken om de App te voeden, zoals bijvoorbeeld XML of JSON. Door deze stromen te hergebruiken en te mixen op het nieuwe platform wordt het beheer ervan eenvoudiger.

Deze realisatieslag is de plek waar de eigenlijke serverintegratie plaatsvindt maar is iets om al in ogenschouw te nemen bij de Designfase omdat dit een showstopper is die enorme vertraging kan betekenen. Bedenk wel dat de services via beperkte bandbreedte kunnen worden aangeroepen. Services voor het Web zijn meestal rijk aan datavoorziening. Het kan handig zijn om deze te filteren voordat ze worden aangehaakt op de App.

Met een dun tussenlaagje zorgen we aan de ene kant voor hergebruik en aan de andere kant voor optimalisatie van dataverbruik en responsetijden voor de eindgebruiker.

8

Als gebruik wordt gemaakt van Web Services is het mogelijk tevens gebruik te maken van reguliere functionaliteiten om een gebruiker te identificeren en het beheer van rechten te regelen. Duidelijk en logisch identity management, gekoppeld aan het beheer van rechten is iets dat helpt bij het personaliseren van de ervaring en helpt bij het ten uitvoer brengen van het gekozen businessmodel.

Identity management helpt ook bij het creëren van een veilige oplossing. Veiligheid is niet iets dat we kunnen toevoegen aan de buitenkant zoals ketchup bij de maaltijd, het is iets dat geïntegreerd moet worden in het ontwikkelingsproces. Het moet niet alleen toegevoegd worden aan de App zelf; het moet ook worden vervlochten in de diensten, zoals dit al eerder is gedaan op het internet met de opkomst van het Web.

Het veiligstellen van de identiteit en het veiligstellen van de communicatie tussen de App, de online diensten en de data op het device is noodzakelijk voor een complete veilige oplossing. De ketting is zo sterk als de zwakste schakel. Security specialisten kunnen helpen deze ketting op de juiste sterkte te krijgen.

Test, Test en Her-Test We hebben het al eerder genoemd en doen het hier weer opnieuw: Test vroeg en Test vaak. Dit betekent niet alleen het testen van de ideeën, functionaliteit en look-and-feel met de gebruikers maar ook het testen van het ontwikkelingsproces, zoals genoemd bij prototyping. Verder houdt testen natuurlijk in dat de code moet worden beoordeeld door collega ontwikkelaars en dat niet alleen de programmeur zelf een module even moet testen. Nee, anderen moeten dat ook doen en veel grondiger en zorgvuldiger.

Naast het testen van modules is het van groot belang de integratie van de App met de werkelijke diensten te testen. Vaak worden Apps ontwikkeld met tijdelijke gegevens of diensten en worden ze getest tegen deze tijdelijke interfaces, maar de werkelijke integratietest is iets dat alleen kan worden gedaan in de laatste fasen. Het testen van de integratie op de live-services vergroot de algehele kwaliteit en levert de garantie dat de eerder geschatte levertijd wordt gehaald.

Lever de Oplossing De App kan nu worden ingepakt en toegevoegd aan de markt. Verschillende markets of stores hebben verschillende regels over de toelating tot de markt. Dit betekent dat niet alle oplossingen door het reviewproces voor levering aan een specifieke markt kunnen komen. Sommige markten hebben geen strikt toetsingsproces en Apps kunnen eenvoudig worden toegevoegd en bijgewerkt. Bij andere markets of stores duurt het enige tijd voor een toevoeging van een nieuwe App of herziening van een nieuwe versie kan worden verwerkt. Dit is dus iets om rekening mee te houden bij het lanceren van een App op een specifieke datum.

Tijd en plaats zijn belangrijk voor het AppConcept maar timing is zeker ook iets om rekening mee te houden bij de lancering van een App. Het is immers niet iets wat je elke dag doet: voor de eerste keer een App uitbrengen. Timing is cruciaal.

Meten is Weten De diverse App markets en stores geven ruim inzicht in hoe vaak een applicatie is gedownload. Dit is geen volledige indicatie van het gebruik aangezien een flink percentage Apps wordt verwijderd binnen enkele seconden nadat ze voor het eerst zijn

9

geïnstalleerd. Het geeft slechts een indicatie van hoeveel gebruikers in staat zijn om uw App te vinden en ook voldoende belangstelling hebben om de App te downloaden en te installeren.

Veel interessanter is de zeer lage drempel voor gebruikers om uw App te beoordelen en te becommentariëren in de diverse Markets. Er valt veel te leren van de feedback van deze werkelijke gebruikers, maar het kan moeilijk zijn om correcte feedback te krijgen. Er zijn eigenlijk twee logische momenten voor de gebruikers om feedback te geven: de ene is direct na het installeren van de App en de andere is direct na het verwijderen van de App. Beide opties helpen ons niet echt.

Wanneer een gebruiker de App net heeft geïnstalleerd is hij nog niet echt in staat om in te schatten of er een goede fit is of niet. Dus hij zal even wachten met de beoordeling en het meestal gewoonweg weer vergeten. Totdat ... de tijd komt dat de gebruiker het toch niet zo’n waardevolle toevoeging aan de collectie vindt en hij kiest voor het verwijderen van de App.

Dit kan de gebruiker ook trigger geven om de App te beoordelen, maar de beoordeling zal hierbij zeker niet een top 5-sterren rating worden. Wat kunnen we anders verwachten van iemand die zich juist nu probeert te ontdoen van uw App?

Meer en meer Apps proberen de actieve gebruiker de App na een aantal maal gebruiken te laten aanbevelen, te beoordelen of een opmerking over de App te plaatsen. Dit helpt om realistischer cijfers en beoordelingen te verkrijgen maar hoe meer Apps deze functie gebruiken hoe vervelender het wordt ervaren door gebruikers. Het is voor dit moment wel iets om te overwegen en te proberen. Wat natuurlijk ook helpt is een trouwe schare potentiële gebruikers die het in Beta hebben getest en de eerste waardevolle beoordelingen hebben gedaan. Daarnaast is het goed idee om in het scherm over de App (About) een knop in te bouwen voor de terugkoppeling van de gebruiker naar de producent. Dat kan via Twitter, email, telefoon maar natuurlijk ook via de stores en markets.

Hoe meer er gemeten wordt rond een App en het gebruik ervan, des te meer inzicht dat geeft over hoe een gebruiker de App ervaart. Dit kan helpen om een nog betere dienstverlening aan uw gebruikers te bieden.

Vindbaarheid telt Het beschikbaar stellen in de market of store is nog niet alles als het gaat om het leveren van de App, de gebruikers moeten immers ook weten dat er een App voor hen is. Met meer dan 15.000 nieuwe App releases per week is het relatief makkelijk om gewoonweg niet gezien te worden. Dit is waar het in lijn brengen met de overige kanalen de App verder kan helpen; bijvoorbeeld melden dat "er ook een App voor is" wanneer er aan een klant telefonische service verleend wordt. Dit helpt de klant de App beter te vinden. Er kan ook gebruik gemaakt worden van de andere meer traditionele kanalen zoals print en billboards om gebruikers te leiden richting het nieuwe App kanaal. Bijvoorbeeld door gebruik te maken van QR-Codes of op een reguliere factuur de App te vermelden. En het is heel gemakkelijk een nieuw ontwikkelde App te noemen en te linken op de website.

10

Mobile en Social zijn een win-win combinatie. Ze hebben allebei hetzelfde “Hier & Nu karakter”. Natuurlijk kunt u gebruik maken van Social Media om uw App te promoten, maar de verstrengeling van “Mobile Waar & Wanneer” met de sociale context is echt een heel goed huwelijk te noemen. Beiden leveren namelijk een deel van het antwoord op de levensstijl van gebruikers: altijd en overal verbonden.

Nu niet Stoppen! Het leveren van een App aan de market of store en hem vervolgens achterlaten om te sterven is natuurlijk geen recept voor succes. De gebruikers die hun feedback geven verwachten dat u luistert en de opmerkingen serieus in overweging neemt bij het verbeteren of aanvullen van diensten. Actualisering van Apps is vrij eenvoudig en gebruikers verwachten updates met nieuwe, logische functionaliteit op een regelmatige basis.

Probeer niet alle gevraagde functionaliteit toe te voegen in één grote nieuwe, verbeterde versie. Een slow release concept helpt bij het verspreiden van het woord en het creëren van extra aandacht. Dus blijven verbeteren, maar ook ruimte laten voor toekomstige verbeteringen. Het is handig om de handen tussen IT en Marketing in een te slaan om te zien welke mogelijkheden er zijn voor updates en wanneer die klaar zijn. Ook het hergebruik van componenten kan hier in worden meegenomen. Dat iets technisch gereed is wil niet zeggen dat het een goed moment is om de eventuele aanpassingen ook te leveren aan de eindgebruikers. Zoals we eerder aangaven: timing is cruciaal. U kunt dus uw roadmap inzetten als marketinginstrument door gebruikers periodiek te voorzien van updates en daarmee de aandacht van hen weer even te prikkelen.

Ook al is het perspectief van de klant meegenomen en werden gebruikers betrokken bij het concept van de App tot aan de ontwikkeling en oplevering, goede resultaten zijn nog steeds niet gegarandeerd. Het kan gebeuren dat er een mismatch ontstaat en de App niet bevalt. Laat deze niet in de markets staan om nog meer negatieve beoordelingen te verzamelen, verlos hem uit zijn lijden en verwijder de App uit uw portefeuille.

Updaten van Apps kan ook betekenen dat andere platformen worden betreden met een specifieke oplossing. Een App kan niet precies hetzelfde zijn op een ander platform en successen van het ene platform vertalen zich niet altijd direct in successen op een ander platform. Met name het ontwerp moet opnieuw worden gemaakt om het aan te passen aan de specifieke gebruikerservaringen en verwachtingen op het andere doelplatform, zoals ook al vermeld bij de fase Ontwerp. Het opnieuw ontwerpen betekent niet exact hetzelfde doen, maar ook niet alles weer opnieuw doen. Loop de designfases na en controleer welke stappen opnieuw moeten worden genomen voor de update van functionaliteit of de verbreding in doelplatformen.

Op deze manier beschouwd is het creëren van een App of Apps niet een (serie van) project(en), het is een proces dat op regelmatige basis Apps en updates voor deze Apps oplevert. Op eenzelfde manier als u zorg moet dragen voor uw andere strategische kanalen zoals bijvoorbeeld het Web.

11

Ontdek Sommige organisaties willen een applicatie maken direct na het ontdekken van de mogelijkheden van een nieuwe kanaal en zijn op zoek naar partners om hen te helpen bij het bouwen of ontwikkelen daarvan. Het is één ding om de mogelijkheden van een nieuw kanaal te zien, maar het is iets heel anders om succesvol te zijn en het kanaal strategisch te gebruiken. Met de 6D aanpak laten we organisaties zien waarom het geen goed idee is om overhaast in een nieuw kanaal als Apps te springen. Ons advies is om specifiek te zijn over wat u wel doet met dit nieuwe kanaal en wat niet. Wees selectief met het producten- en diensten-assortiment op specifieke kanalen. Maak keuzes, wees strategisch.

Met onze 6D aanpak geven wij u zowel positie –waar bent u nu– als richting –waar gaat u heen– om u te helpen de juiste strategische keuzes te maken en daardoor succesvoller op dit nieuwe en spannende App kanaal te opereren.