Strategische App Ontwikkeling
Upcoming SlideShare
Loading in...5
×
 

Strategische App Ontwikkeling

on

  • 884 views

 

Statistics

Views

Total Views
884
Views on SlideShare
884
Embed Views
0

Actions

Likes
0
Downloads
25
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Strategische App Ontwikkeling Strategische App Ontwikkeling Document Transcript

    • Strategische App Ontwikkeling Het gaat niet over Technologie Versie 3.2 2011-11
    • 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  2
    • Het gaat niet over TechnologieMet onze blik op het Mobile fenomeen, de Apps wereld en het App Effect zijn wemisschien geneigd te denken dat het een technische revolutie is. Dit is echter eenonjuiste benadering. Natuurlijk is er een technologie aspect, maar de belangrijkste factorin Mobile is het menselijke verlangen om mobiel te zijn en verbonden blijven. Naar onzemening gaan Mobile Apps over mensen en hun gedrag.Het is daarom noodzakelijk om de mogelijke gebruikers en hun gedrag goed te begrijpenals u Apps als een succesvol nieuw kanaal wilt inzetten om uw publiek te bereiken. Deoplossing die u biedt is niet alleen een technische oplossing. Het is een oplossing vooreen specifieke informatie-, interactie- of transactiebehoefte gedefinieerd door devolledige, rijke context van de potentiële gebruiker. Dat is nadrukkelijk inclusiefaspecten als tijd en plaats van de interactie. Een manier van kijken naar al dezeaspecten wordt vaak gebruikt in de journalistiek en is bekend als de vijf/zeven Ws (wie,wat, wanneer, waar, waarom, hoe, met waarmee). De oorsprong van deze beschrijvingis echter veel ouder. Victorinus tekende in de vierde eeuw al een diagram van aspectenvan een bepaald scenario. Het mooie is dat de term “Persona” al staat bij de “Wie”. Omgoede oplossingen te formuleren hanteren we de aanpak die bekend is bij velemarketeers: Persona’s en Scenario’s, Wie en de overige W’s.Hoe meer we weten van al deze aspecten rond een specifieke gebruiker (Persona), hoemeer we begrijpen wat hij/zij probeert te bereiken en hoe beter we hem/haar kunnenassisteren bij het vervullen van de behoefte aan informatie rond de interactie oftransactie (Scenario). Idealiter moeten wij ons bewust zijn van hun intentie op eenbepaald moment en plaats. Van daaruit voorzien we via de App vervolgens in despecifieke, contextuele intentie en bijbehorende informatiebehoefte.Definieer de StrategieStrategisch 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 eenmultiscreen wereld) betekent dit heldere keuzes maken. Deze keuzes moeten nietafhankelijk zijn van technologie en de bijbehorende beperkingen, zoals we hiervoor albeschreven, maar moeten gebaseerd zijn op hoe we waarde kunnen toevoegen aan degebruikerservaring bij een specifieke interesse in informatie, interactie of transactie.Optimale inzet per kanaal, met behoud van een eenduidige uitstraling over de kanalenheen. Hiermee behoudt uw organisatie de belangrijke eigen identiteit.Om te weten wat relevant is voor een specifieke gebruiker of gebruikersgroep, moetenwe 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 op3
    • zoek is naar informatie of interactie met u, als een organisatie die in staat zou kunnenzijn om dit nu te leveren. Deze aanpak resulteert in scenarios, (use-cases) die kunnenleiden tot concepten voor mobiele toepassingen. Scenario’s voorzien van context zoalsplaats en tijd, waar en wanneer. Die leiden tot AppConcepts die toegevoegde waardeleveren. Deze hebben een duidelijk en logisch doel voor de doelgroep doordat zewerkelijk in staat zijn deze waarde toe te voegen.Deze stap helpt om te beslissen wat te doen, om strategisch te handelen en helptdaarmee onderdelen van de AppStrategy te definiëren. De strategie moet wordenaangevuld met keuzes rondom businessmodellen als gratis, freemium, met reclame ofbetaald en hoe de diensten en producten verstrengelen of overlappen op het MobielePlatform, Het Web en de Sociale Media. Een AppStrategy kan niet alleen de App Wereldbeschrijven of de algemene aspecten van deze wereld raken. Een AppStrategy moet inlijn zijn met de Online strategie, de strategie voor het Web, de overige kanalen ennatuurlijk de bredere bedrijfsstrategie.Om beter te voldoen aan de behoeften van een specifieke gebruiker moeten we bouwenaan een relatie met deze gebruiker en deelnemen aan de dialoog. Vanaf daar kan deinteractie rond informatie leiden tot een logische transactie. De transactie als gevolg vaneen relatie en een gesprek, niet andersom.Voor veel organisaties is dit een nieuwe manier van denken over hun klanten, niet alseen nummer of als een bron van inkomsten in een Excel-sheet, maar als relatie, alsoprecht betrokken mensen. Daarom is het zo belangrijk dat een volledigecommunicatiestrategie wordt opgesteld, vooral voor online, voor Sociale Media, en in lijnmet de AppStrategy. Elk kanaal heeft zijn eigen karakter, en dit karakter helpt deboodschap op zo’n manier dat het kanaal dat geselecteerd wordt zelfs onderdeel gaatworden van de over te brengen boodschap. The medium is the massage - MarshallMcLuhan.Ontwerp de InterfaceDe informatiebehoefte van de gebruiker kunnen we analyseren in termen van hetleveren van de informatie en in de bundeling van de informatie en interactie in clustersdie we gaan gebruiken om de schermen te ontwerpen. Deze schermen worden in eenspecifieke volgorde gelegd, zodanig dat ze de doorloop van de applicatie laten zien. Dezelogische schermen en hun volgorde worden aangemaakt zonder dat het nodig is om nogmaar een letter van een App te programmeren. Het gaat alleen nog maar over het4
    • ontwerp van de gebruikersinteractie en het -gedrag rondom de benodigde informatie.Meestal is dit een reeks slides die we kunnen laten zien aan een aantalvertegenwoordigers van de doelgroep. Door dergelijke “prototypes” op een mobieldevice te tonen wordt een nog beter beeld en gevoel gegeven. Hiermee is de eerste testdoor de gebruikers eigenlijk al een feit. Ze zijn vanaf het eerste moment betrokkenzodat het ook echt hun App wordt. De feedback van deze groep is heel erg waardevol enkan enorm goed gebruikt worden om het AppConcept nog verder te verfijnen.Focussen rond een specifieke gebruiker en toegevoegde waarde bieden is daarmee deeerste 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 zemoeten allemaal relevant zijn voor de specifieke gebruiker en voor de context van hetAppConcept, het Scenario. Dit betekent dat het voor elke organisatie belangrijk is omniet te denken in een App maar in Apps als logisch gebundelde functionaliteit percontextuele situatie met verschillende use-cases verdeeld over alle Apps.Herkenbare MixDe App moet een mooie, schone, directe en logische interface hebben. De focus van degebruiker moeten worden gerespecteerd, niet worden afgeleid. Dat betekent dat hetelegante “één knop, één functie concept” de gebruikers beter helpt bij het bereiken vanhun doel dan een fancy interface die teveel interpretatie verlangt. Dit is echt een uiterstdelicaat evenwicht en daarom specialistenwerk. Designers die gewend zijn om met ditdilemma 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 teontwerpen. Dit ontwerp moet voldoen aan het AppConcept, maar dat is natuurlijk nietaltijd de enige en meest belangrijke factor, hoewel het voor applicaties zoals gamesmeestal wel de meest dominante is. Gebruikers van een specifiek platform zijn gewendaan de interactie die dit platform biedt. IPhone Apps ogen en gedragen verschillend invergelijking met bijvoorbeeld Android Apps of Windows Phone 7 Apps. Deze platformenhebben elk hun eigen specifieke richtlijnen die naadloos moeten worden vermengd methet ontwerp van uw App. Immers, als de gebruiker de App niet begrijpt dan wordt hijniet meer gebruikt.En als laatste punt, maar zeker niet onbelangrijk, moeten uw eigen richtlijnen voor hetpresenteren van uw merk of de uitstraling van uw website, in ogenschouw wordengenomen en worden samengebracht met het AppConcept en de platformrichtlijnen. Ditresulteert in een App die onmiskenbaar uw App is, en de gebruiker toch herkent als deApp speciaal ontworpen voor zijn of haar Smart Mobile. Overduidelijk resulteert dat dusin meerdere uitvoeringen per AppConcept als u ervoor kiest om verder te gaan met deontwikkeling voor diverse platformen.Passende oplossingOp een aantal plaatsen is al aangegeven dat Apps aan bepaalde standaarden enrichtlijnen moeten voldoen om ervoor te zorgen dat ze passen in het totaalplaatje vaneen organisatie. Als Apps bijvoorbeeld worden ingezet om klanten transacties te latenuitvoeren is het belangrijk dat de klanten op een eenduidige manier, over alle kanalenheen, worden herkend en geautoriseerd. De meeste organisaties hebben voorzieningenen standaarden voor identity management, security management, multichanneling, CRM5
    • etc. Vaak zijn deze beschreven in een zogenaamde enterprise-architectuur. Bij hetontwikkelen van Apps moet aangesloten worden bij deze enterprise-architectuur. Waardeze niet beschikbaar zijn, is het verstandig om deze te ontwikkelen.Indien de organisatie veel verschillende Apps maakt voor verschillende platformen is hetverstandig om een App-architectuur op te stellen met principes en standaarden voor hetontwikkelen, beheren en onderhouden van Apps. Het doel hiervan is te voorkomen datvoor iedere App het wiel opnieuw wordt uitgevonden.Hybride AppsHybride Apps bieden mogelijkheden om met minimale inspanning toch maximaalresultaat 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 algemeengeldende internetstandaarden als HTML, CSS en JavaScript.De inhoud kan op deze wijze eenvoudig gescheiden gehouden worden van de opmaak ende interactie. Voor de inhoud en opmaak gebruiken we standaarden als XML, HTML enCSS. Voor de basis interactie kan gebruikt gemaakt worden van JavaScript. Voor deechte, cruciale gebruikersbeleving op het device zelf kan gebruikt gemaakt worden vanalle unieke eigenschappen van het platform door een relatief dun laagje in de native Appop te nemen. Denk in termen van 80-20 waarbij er slechts 20% native wordt ontwikkelden 80% op basis van de hiervoor genoemde webstandaarden, die door bijvoorbeeldredacteuren zelf kunnen worden gebruikt om de inhoud vorm te geven.Een ander groot voordeel van deze optimale native ontwikkeling is dat de App met eenbeperkte inspanning ook naar andere platformen kan worden overgezet. Denk aan deopkomende markt voor Android tablets met Honeycomb en eventueel andereleveranciers. Naast deze optimale native aanpak kan voor de minder bekende tabletseen mobiele website gemaakt worden, die tevens gebruik maakt van dezelfdeinformatiestromen. Hiermee wordt het mogelijk om op diverse platformen de uniekegebruikersbeleving te creëren, die hoort bij de specifieke eigenschappen van hetplatform (Android tablets zijn immers anders in gebruik dan iPads) en houden we tochde mogelijkheid voor hergebruik en eenvoudige redactie. Daarnaast is het pad “overigmobile” 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 vooranderen.Een gezonde mix tussen Native en Webtechnologie kan op deze wijze helpen diversegebruikers toch hun herkenbare platformmix op maat te leveren tegen relatief beperktekosten.Raak aan, Draai omBij het ontwerpen van de App moeten we continu beseffen dat de gebruiker kaninteracteren met de App door middel van aanraking. Dit betekent dat de gebruiker eendeel van de interface bij de interactie afdekt met zijn eigen hand en dat de interfaceafgestemd moet zijn op de dimensies van de vingertoppen. De afmetingen van deknoppen, sliders en invoervelden moeten dit dus weerspiegelen. Maar ook de dimensievan 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 de6
    • inhoud, op kleinere schermen wordt dit bij voorkeur verdeeld over verschillendeschermen.Daarnaast beïnvloedt de schermgrootte ook de potentiële inzet van het device. Hetkarakter van een iPad, of andere touch-tablet zoals Galaxy Tab, Asus Transformer, ofandere Android Tablet, is echt anders dan dat van een smartphone. Het verschil zit in decontext, dus de te verwachten intentie van de gebruiker. Een smartphone is eenapparaat voor onderweg, een tablet is een device voor onderuit. Deze houding zegt allesover het gebruik, de interactie, en dus ook de informatiebehoefte. De mobiele contextvan de gebruiker genereert een informatiebehoefte die anders is dan de consumerendegebruiker op de bank.Wat relevant is op een smartphone hoeft dus helemaal niet zo relevant te zijn op eentablet. Zeker iets om rekening mee te houden bij het ontwerp en de mogelijk bredereinzet en uitrol van uw concept!Daarnaast moeten we rekening houden met het feit dat de gebruiker het apparaat ooknog eens vasthoudt, waarbij meer en meer apparaten kunnen detecteren hoe eengebruiker dat doet. Er zijn bijvoorbeeld apparaten die het schudden of draaien kunnendetecteren waar door de App acties aan kunnen worden gekopppeld. Deze manier vanomgaan 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 teverversen. Dit fysiek bewegen is een relatief nieuwe, maar steeds vaker voorkomendemanier, om te interacteren met de App. Echte standaarden zijn hiervoor nog nietbeschikbaar, maar een geheel nieuwe interactietaal wordt geboren en dat is eenspannende ontwikkeling waar we zeker op moeten letten. Denk naast draaien enschudden 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 vanvertegenwoordigers op uw interface, de doorloop van de applicatie en het ontwerp vande 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 waardevolleinput maar wordt het echt hun App.Ontwikkel de AppHet is tijd om de App te gaan bouwen voor de gewenste platformen. Over het algemeenzal de App informatie gaan gebruiken uit diverse Internet- en Web Services. Het is hetmeest eenvoudig en voor de hand liggend om algemeen geldende webstandaarden tegebruiken om de App te voeden, zoals bijvoorbeeld XML of JSON. Door deze stromen tehergebruiken en te mixen op het nieuwe platform wordt het beheer ervan eenvoudiger.Deze realisatieslag is de plek waar de eigenlijke serverintegratie plaatsvindt maar is ietsom al in ogenschouw te nemen bij de Designfase omdat dit een showstopper is dieenorme vertraging kan betekenen. Bedenk wel dat de services via beperkte bandbreedtekunnen worden aangeroepen. Services voor het Web zijn meestal rijk aandatavoorziening. Het kan handig zijn om deze te filteren voordat ze worden aangehaaktop de App.Met een dun tussenlaagje zorgen we aan de ene kant voor hergebruik en aan de anderekant voor optimalisatie van dataverbruik en responsetijden voor de eindgebruiker.7
    • Als gebruik wordt gemaakt van Web Services is het mogelijk tevens gebruik te makenvan reguliere functionaliteiten om een gebruiker te identificeren en het beheer vanrechten te regelen. Duidelijk en logisch identity management, gekoppeld aan het beheervan rechten is iets dat helpt bij het personaliseren van de ervaring en helpt bij het tenuitvoer brengen van het gekozen businessmodel.Identity management helpt ook bij het creëren van een veilige oplossing. Veiligheid isniet iets dat we kunnen toevoegen aan de buitenkant zoals ketchup bij de maaltijd, hetis iets dat geïntegreerd moet worden in het ontwikkelingsproces. Het moet niet alleentoegevoegd 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 deApp, de online diensten en de data op het device is noodzakelijk voor een completeveilige oplossing. De ketting is zo sterk als de zwakste schakel. Security specialistenkunnen helpen deze ketting op de juiste sterkte te krijgen.Test, Test en Her-TestWe hebben het al eerder genoemd en doen het hier weer opnieuw: Test vroeg en Testvaak. Dit betekent niet alleen het testen van de ideeën, functionaliteit en look-and-feelmet de gebruikers maar ook het testen van het ontwikkelingsproces, zoals genoemd bijprototyping. Verder houdt testen natuurlijk in dat de code moet worden beoordeeld doorcollega ontwikkelaars en dat niet alleen de programmeur zelf een module even moettesten. 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 dewerkelijke diensten te testen. Vaak worden Apps ontwikkeld met tijdelijke gegevens ofdiensten en worden ze getest tegen deze tijdelijke interfaces, maar de werkelijkeintegratietest is iets dat alleen kan worden gedaan in de laatste fasen. Het testen van deintegratie op de live-services vergroot de algehele kwaliteit en levert de garantie dat deeerder geschatte levertijd wordt gehaald.Lever de OplossingDe App kan nu worden ingepakt en toegevoegd aan de markt. Verschillende markets ofstores hebben verschillende regels over de toelating tot de markt. Dit betekent dat nietalle oplossingen door het reviewproces voor levering aan een specifieke markt kunnenkomen. Sommige markten hebben geen strikt toetsingsproces en Apps kunneneenvoudig worden toegevoegd en bijgewerkt. Bij andere markets of stores duurt hetenige tijd voor een toevoeging van een nieuwe App of herziening van een nieuwe versiekan worden verwerkt. Dit is dus iets om rekening mee te houden bij het lanceren vaneen App op een specifieke datum.Tijd en plaats zijn belangrijk voor het AppConcept maar timing is zeker ook iets omrekening mee te houden bij de lancering van een App. Het is immers niet iets wat je elkedag doet: voor de eerste keer een App uitbrengen. Timing is cruciaal.Meten is WetenDe diverse App markets en stores geven ruim inzicht in hoe vaak een applicatie isgedownload. Dit is geen volledige indicatie van het gebruik aangezien een flinkpercentage Apps wordt verwijderd binnen enkele seconden nadat ze voor het eerst zijn8
    • geïnstalleerd. Het geeft slechts een indicatie van hoeveel gebruikers in staat zijn om uwApp te vinden en ook voldoende belangstelling hebben om de App te downloaden en teinstalleren.Veel interessanter is de zeer lage drempel voor gebruikers om uw App te beoordelen ente becommentariëren in de diverse Markets. Er valt veel te leren van de feedback vandeze 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: deene is direct na het installeren van de App en de andere is direct na het verwijderen vande App. Beide opties helpen ons niet echt.Wanneer een gebruiker de App net heeft geïnstalleerd is hij nog niet echt in staat om inte schatten of er een goede fit is of niet. Dus hij zal even wachten met de beoordeling enhet meestal gewoonweg weer vergeten. Totdat ... de tijd komt dat de gebruiker het tochniet zo’n waardevolle toevoeging aan de collectie vindt en hij kiest voor het verwijderenvan de App.Dit kan de gebruiker ook trigger geven om de App te beoordelen, maar de beoordelingzal hierbij zeker niet een top 5-sterren rating worden. Wat kunnen we andersverwachten 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 gebruikente laten aanbevelen, te beoordelen of een opmerking over de App te plaatsen. Dit helptom realistischer cijfers en beoordelingen te verkrijgen maar hoe meer Apps deze functiegebruiken hoe vervelender het wordt ervaren door gebruikers. Het is voor dit momentwel iets om te overwegen en te proberen. Wat natuurlijk ook helpt is een trouwe scharepotentiële gebruikers die het in Beta hebben getest en de eerste waardevollebeoordelingen 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 deproducent. Dat kan via Twitter, email, telefoon maar natuurlijk ook via de stores enmarkets.Hoe meer er gemeten wordt rond een App en het gebruik ervan, des te meer inzicht datgeeft over hoe een gebruiker de App ervaart. Dit kan helpen om een nog beteredienstverlening aan uw gebruikers te bieden.Vindbaarheid teltHet beschikbaar stellen in de market of store is nog niet alles als het gaat om hetleveren van de App, de gebruikers moeten immers ook weten dat er een App voor henis. Met meer dan 15.000 nieuwe App releases per week is het relatief makkelijk omgewoonweg niet gezien te worden. Dit is waar het in lijn brengen met de overige kanalende App verder kan helpen; bijvoorbeeld melden dat "er ook een App voor is" wanneer eraan een klant telefonische service verleend wordt. Dit helpt de klant de App beter tevinden. Er kan ook gebruik gemaakt worden van de andere meer traditionele kanalenzoals 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 tevermelden. En het is heel gemakkelijk een nieuw ontwikkelde App te noemen en telinken op de website.9
    • Mobile en Social zijn een win-win combinatie. Ze hebben allebei hetzelfde “Hier & Nukarakter”. 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 eenheel goed huwelijk te noemen. Beiden leveren namelijk een deel van het antwoord op delevensstijl van gebruikers: altijd en overal verbonden.Nu niet Stoppen!Het leveren van een App aan de market of store en hem vervolgens achterlaten om testerven is natuurlijk geen recept voor succes. De gebruikers die hun feedback gevenverwachten dat u luistert en de opmerkingen serieus in overweging neemt bij hetverbeteren of aanvullen van diensten. Actualisering van Apps is vrij eenvoudig engebruikers verwachten updates met nieuwe, logische functionaliteit op een regelmatigebasis.Probeer niet alle gevraagde functionaliteit toe te voegen in één grote nieuwe, verbeterdeversie. Een slow release concept helpt bij het verspreiden van het woord en het creërenvan extra aandacht. Dus blijven verbeteren, maar ook ruimte laten voor toekomstigeverbeteringen. Het is handig om de handen tussen IT en Marketing in een te slaan om tezien welke mogelijkheden er zijn voor updates en wanneer die klaar zijn. Ook hethergebruik van componenten kan hier in worden meegenomen. Dat iets technischgereed is wil niet zeggen dat het een goed moment is om de eventuele aanpassingenook te leveren aan de eindgebruikers. Zoals we eerder aangaven: timing is cruciaal. Ukunt dus uw roadmap inzetten als marketinginstrument door gebruikers periodiek tevoorzien 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 bijhet concept van de App tot aan de ontwikkeling en oplevering, goede resultaten zijn nogsteeds niet gegarandeerd. Het kan gebeuren dat er een mismatch ontstaat en de Appniet bevalt. Laat deze niet in de markets staan om nog meer negatieve beoordelingen teverzamelen, verlos hem uit zijn lijden en verwijder de App uit uw portefeuille.Updaten van Apps kan ook betekenen dat andere platformen worden betreden met eenspecifieke oplossing. Een App kan niet precies hetzelfde zijn op een ander platform ensuccessen van het ene platform vertalen zich niet altijd direct in successen op een anderplatform. Met name het ontwerp moet opnieuw worden gemaakt om het aan te passenaan de specifieke gebruikerservaringen en verwachtingen op het andere doelplatform,zoals ook al vermeld bij de fase Ontwerp. Het opnieuw ontwerpen betekent niet exacthetzelfde doen, maar ook niet alles weer opnieuw doen. Loop de designfases na encontroleer welke stappen opnieuw moeten worden genomen voor de update vanfunctionaliteit 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 Appsoplevert. Op eenzelfde manier als u zorg moet dragen voor uw andere strategischekanalen zoals bijvoorbeeld het Web.10
    • OntdekSommige organisaties willen een applicatie maken direct na het ontdekken van demogelijkheden van een nieuwe kanaal en zijn op zoek naar partners om hen te helpenbij het bouwen of ontwikkelen daarvan. Het is één ding om de mogelijkheden van eennieuw kanaal te zien, maar het is iets heel anders om succesvol te zijn en het kanaalstrategisch te gebruiken. Met de 6D aanpak laten we organisaties zien waarom het geengoed idee is om overhaast in een nieuw kanaal als Apps te springen. Ons advies is omspecifiek te zijn over wat u wel doet met dit nieuwe kanaal en wat niet. Wees selectiefmet het producten- en diensten-assortiment op specifieke kanalen. Maak keuzes, weesstrategisch.Met onze 6D aanpak geven wij u zowel positie –waar bent u nu– als richting –waar gaatu heen– om u te helpen de juiste strategische keuzes te maken en daardoor succesvollerop dit nieuwe en spannende App kanaal te opereren.11