10 conseils pour vous guider vers l’échec de votre application mobile

Lors de la création d’une application mobile, qu’elle soit cross-platform ou non, un ensemble de questions se posent concernant la réalisation, le design, le déploiement…

Si votre film leitmotiv est La stratégie de l’échec ou si vous souhaitez mener votre projet d’application mobile droit dans le mur, voici 10 conseils qui vous permettront de mener à mal votre projet.

strategie de l'echec

Conseil n°1 : Ne faites pas la différence entre web et mobile

Il est courant qu’une entreprise possède son site web, et, par effet de mode, veuille le porter sur mobile. Si c’est le cas pour votre projet, il est donc primordial de garder le même design, et la même expérience (navigation par exemple) entre le site web et l’application mobile. Quoi de mieux qu’un menu où l’on navigue en survolant avec la souris… sur mobile!

Efficiency Niveau d’efficacité : 6/10

C’est un beau démarrage vers la route de l’échec puisque l’expérience utilisateur diffère entre le web et le mobile. Si les habitudes des utilisateurs mobiles sont bafouées en proposant une expérience web, cela peut faire fuir certains utilisateurs qui désinstalleront bien vite l’application.

Conseil n°2 : Tester, c’est douter

tester c'est douterIl est fréquent aujourd’hui d’intégrer des tests unitaires dans le processus de développement. Cela assure une qualité du code, c’est donc une pratique à bannir le plus rapidement possible. Le double effet kiss cool est que cela permettra d’accélérer les livraisons, qui sont déjà généralement bien trop longues pour les décideurs du projet.

Efficiency Niveau d’efficacité : 5/10

Si cela prend quelque temps à se voir, les utilisateurs finiront bien par se rendre compte de régressions. Cela entraînera une baisse de la note sur le store et/ou une baisse des utilisateurs.

Conseil n°3 : Spécifier, c’est tricher

Pourquoi s’embêter à faire des bêtas tests auprès d’un panel d’utilisateurs ? La spécification, qui se doit de ne pas être claire, suffit amplement pour les développeurs. Sans ajouter que les développeurs auront sans doute testé eux-même leur travail, s’il sont consciencieux. Si cela peut sembler être une petite erreur de parcours, il est facile de se rassurer grâce au fait que les développeurs ne sont pas la cible finale. Il y a donc de grandes chances pour que leur avis soit peu objectif.

Efficiency Niveau d’efficacité : 6/10

L’effet sera immédiat, car l’application n’aurait pas été éprouvée et ne répondra peut être pas ou plus au besoin.

Conseil n°4 : Laisser de côté le design et l’ergonomie

Il est bien connu que faire travailler ensemble des designers ou ergonomes avec des développeurs est souvent long et compliqué. Il est donc peu recommandé de se donner cette peine, afin que le résultat final de l’application répugne les gens. Certains logiciels ont un design horrible pourtant cela n’empêche pas les gens de les utiliser, heureusement cela s’applique rarement au mobile. Laissez-donc le talent des développeurs s’exprimer, ils seront à même de réaliser le design.

Efficiency Niveau d’efficacité : 7/10

Jusque-là le plan se déroule sans accros ! Et en tant qu’utilisatrice quotidienne de smartphone, je peux vous assurer que cette stratégie est redoutable.

Conseil n°5 : Penser que les utilisateurs ont tous le même téléphone avec la même version

La problématique de gérer différentes versions des OS mobiles, avec la rétrocompatibilité, permettrait de gagner plus d’utilisateurs, mais cela prend du temps et complique les développements, alors le plus simple est de passer à côté. Sans compter la quantité affolante de tailles d’écran des téléphones… Même si l’équipe de développeurs possède différents téléphones, cela ne couvrira jamais l’ensemble des smartphones du marché, ce qui au final ne met pas en péril la stratégie.

Efficiency Niveau d’efficacité : 8/10

Super Effective

Il y a de grande chances qu’en terme d’ergonomie l’application soit une catastrophe, voire qu’elle ne soit pas compatible sur certaines versions des OS mobiles. Les textes seront tronqués, les boutons seront au mauvais endroit, les images à la mauvaise taille… Autant de petits détails qui raviront rapidement les yeux des futurs utilisateurs.

Conseil n°6 : Lors du lancement, ne pas se préoccuper du texte, des images, …

Si le projet n’a pas déjà été abandonné, et si le lancement sur le store approche, pas de panique, il reste encore quelques cartes à abattre. Lors de l’envoi du formulaire de l’application vers le store, arrangez-vous pour mettre peu de texte de description. Un texte sans intérêt fera aussi l’affaire, tout comme un logo et des images peu valorisantes pour l’application. L’arme secrète réside dans les mots-clés, pour que l’application soit introuvable depuis la recherche.

Efficiency Niveau d’efficacité : 7/10

Si l’application ne donne pas envie, personne ne la téléchargera, et bien qu’in extremis, l’échec sera bien atteint.

Conseil n°7 : Ne pas mettre à jour l’application

Pour ce conseil, l’application doit déjà être présente sur un store. Avec un peu de malchance, des personnes auront téléchargé l’application, ou pire l’utiliseront. Heureusement, il est possible de les faire fuir sur le long terme, surtout si l’application a été publiée au départ sans beaucoup de fonctionnalités. Les mises à jour sont un facteur essentiel pour garder les utilisateurs intéressés par l’application. Il est donc tout aussi essentiel de laisser l’application stagner telle quelle.

Efficiency Niveau d’efficacité : 2/10

Les utilisateurs vont plus ou moins rapidement se lasser du manque de nouveauté, d’autant plus si vous suivez le conseil suivant…

Conseil n°8 : Ne pas prendre en compte les feedbacks

no feedbackSi par malheur vous avez été forcé de montrer l’application, d’initier une période de bêta-test ou pire si l’application est déjà publiée, il est toujours possible de retrouver la route de l’échec : si feedbacks il y a, la tête d’autruche ou la sourde oreille tu feras. Parce qu’il ne faudrait pas rajouter des temps de développement pour améliorer l’application et satisfaire madame Michu.

Efficiency Niveau d’efficacité : 3/10

Un utilisateur non satisfait et non écouté finira forcément par désinstaller l’application. Et pourquoi pas faire profiter d’une note salée sur le store.

Conseil n°9 : N’adaptez pas l’application en fonction des utilisateurs cibles

Que l’application vise un public sérieux ou récréatif, il est important de ne pas adapter l’expérience, la charte graphique ou le design en fonction de la cible. Une application de finance se voit rarement parée de boutons et d’animations de jeux vidéos. En temps normal la question se pose également concernant la tranche d’âge des utilisateurs finaux. Le design se fait généralement moins grossier et plus sérieux quand la tranche d’âge augmente. L’idée ici est donc de ranger au placard ces principes, et de proposer par exemple à une entreprise l’équivalent d’une application pour le plus jeune âge.

Efficiency Niveau d’efficacité : 3/10

Partir dans cette direction est un bon moyen de choquer les utilisateurs. En effet, que ce soit selon le besoin ou l’âge de ceux-ci, les attentes changent. Mais nous ne sommes pas à l’abri d’utilisateurs business qui seraient séduits par l’ambiance rose et les gros boutons.

Conseil n°10 : Pourquoi faire simple quand on peut faire compliqué ?

Il est facile de se laisser emporter par l’enthousiasme lors de brainstormings ou de l’établissement des spécifications. C’est logique, car aujourd’hui les téléphones proposent quantité de fonctionnalités exploitables par les applications. A l’image des applications d’entreprises qui ont tendance à faire énormément de choses à la fois, il est pertinent de partir dans cette direction.

Efficiency Niveau d’efficacité : 4/10

Le logiciel montré ci-dessous, porté sur mobile, serait un bon exemple d’application compliquée à utiliser. Les utilisateurs seront ravis !worst ui ever mobile

Conclusion

On observe aujourd’hui une majorité de projets échoués avant la production, ou qui ont peu à peu coulé après celle-ci. Grâce aux différents retours d’expérience, articles, et aussi grâce à mes propres expériences, j’ai pu identifier et regrouper certaines erreurs. Ces erreurs sont multiples et peuvent venir des développeurs, décideurs, marketing…

Je vous ai proposé dans cet article différentes stratégies à mettre en place pour transformer un projet d’application mobile en échec cuisant. Certains points sont plus ou moins efficaces, il ne faut donc pas hésiter à les coupler entre eux pour plus d’efficacité.

N’hésitez pas à agrémenter ces astuces de vos propres idées, pour conquérir la médaille d’or de la pire application mobile !

Soirée Lightning Talks Mobilité

L’avènement du développement mobile a entrainé ces dernières années de nouvelles problématiques et solutions pour les développeurs ou designers. Afin d’honorer les différentes facettes du domaine du mobile, j’ai proposé et organisé une soirée de Lightning Talks le 18 février dans les locaux de SOAT, avec pour thème la mobilité.

Les sujets représentés étaient :

  • L’UX & le design pour le mobile
  • L’A/B Testing d’une application
  • L’utilisation du VisualLayer pour une application Windows 10
  • Le langage Swift
  • React Native
  • Le projet Hermes.Net

J’ai pour ma part pu présenter le langage prodige d’Apple, Swift, avec ses enjeux, ses caractéristiques, ou encore son avenir.

Lien

L’utilisation du storyboard avec iOS et Xamarin iOS

En matière de design d’application mobile, chaque système, que ce soit Windows Phone, Android ou iOS, aborde une manière différente de concevoir ses interfaces. Du côté d’iOS, Apple a opté pour le principe du storyboard. Cette gestion des vues, un peu particulière, demande de maîtriser un certain nombre de principes, qui sont valables pour une application développée en Swift, Objective-C ou encore pour Xamarin iOS.

Nous allons voir dans cet article les bases d’utilisation du storyboard, quelles sont les méthodes pour réaliser une interface adaptative, et en profiter pour réaliser un parallèle avec un projet Xamarin iOS, qui peut aussi utiliser ce concept.

Accéder à l’article sur le blog de Soat