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
2
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
3
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
4
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
5
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
6
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.
7
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
8
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.
9
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.
10
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.
11
