Difficile aujourd'hui de ne pas parler du design lorsque l'on se lance dans un projet d'app web ou mobile.
Du temps a passé, les looks option brûlure rétiniènne ne sont plus admissibles.

Les pauvres âmes qui nous on amenés à de tels chefs d'oeuvre ont finalement été embastillés.

L'UI (User Interface), c'est raffiné : les mises en page se sont complexifiées, les mariages de polices et de couleurs ont été maitrisés sans parler, de la multitude de nouvelles résolutions d'écran et la généralisation des animations. Pour avoir un visuel à minima crédible d'aujourd'hui, faire appel à un designer semble une évidence.

Et pourtant...

Maquetter entièrement une application avec un budget limité - une maquette par écran, avec tous ses états possibles, fonctionnant du mobile à l'écran extra large - c'est une charge de travail conséquente... ... et une somme d'argent conséquente. Pour un designer qualifié, comptez en moyenne 600 €/jour.

Solution optimale pour un budget serré ? Pas sûr.

La réponse académique

Construire un produit, c'est se heurter aux imprévus. Les contraintes techniques, les incohérences non détectées au maquettage, des ajouts et modifications de processus métiers, des changements légaux... Imaginer un produit de bout en bout est complexe.

La création demande de vraies expertises:

  • L'UX
  • L'UI
  • La technique
  • Le product ownership
  • Le métier

Dans la littérature, chacun de ces corps de métier a son représentant, voire une équipe complète. Il faut alors que toutes ces compétences s'allient et collaborent durant la phase de conception.

Rien ne garantit d'être complètement à l'abri de problèmes mais cette approche les limite au maximum.

Dans un monde parfait où les ressources sont illimitées, on peut se permettre d'appliquer l'état de l'art du développement de produit. Avoir les ressources humaines et / ou financières pour assumer ce processus n'est pas accessible à tous. Effectivement, dépenser 80 % du budget avant de commencer le développement n'est que rarement une option viable.

Et comme le dit le fameux proverbe:

" N'achète pas une Ferrari si tu n'as pas d'argent pour l'essence".
—Socrate

La stratégie de l'autruche

Pour pallier à ce problème, cette stratégie qui n'a pourtant jamais fait ses preuves est souvent mise en place. On met la tête dans le sable. Soit par ignorance des besoins de compétences initiaux, soit par manque d'alternatives.

On prendre une ressource, un designer, on lui expose l'idée et on espère pour le mieux.

Attribuer l'entièreté de la conception à une personne, c'est assumer qu'elle puisse endosser tous les rôles. Peu de personnes peuvent se targuer d'une telle polyvalence !

En partant sur cette stratégie, c'est au moment du développement que tous les manquements émergents.
Chaque point est remis en question : problème fonctionnel, logique d'enchaînement, manque d'une fonctionnalité... Les Users Stories sont modifiées, si tant est qu'elles existent. Finalement, brainstorming après brainstorming, des écrans différents de ceux imaginés en première instance sont implémentés.

Le temps de travail du designer à été énorme, basé sur la quantité, pour seulement un petit pourcentage utile qui est vraiment exploité. C'est la raison pour laquelle maquetter de A à Z ne nous semble pas toujours être une bonne idée.

Le point important à avoir en tête : le travail d'un designer, c'est d'abord faire du beau et non du fonctionnel.

Une approche hybride

Entre aucun travail de design et le tout "pré-maquetté", un entre-deux est possible.

Demander au designer ce qu'il sait faire : créer une charte graphique (choix des couleurs, typos...). Un style guide. Le design de la landing page, quelques pages et composants clés de l'application (d'ailleurs le concept de Design Principles s'est beaucoup démocratisé ces dernières années).

Faire intervenir les développeurs avec un droit de regard sur le travail de design. La réflexion sur la partie fonctionnelle est indispensable pour eux. Ils sont les plus à même de se projeter et d'orienter le travail sur les futurs besoins.

A partir des bases visuelles créées par le designer, des développeurs expérimentés peuvent extrapoler en réutilisant les composants et le feeling général.

Le designer est uniquement utilisé en début du projet sur des problématiques que les développeurs n'auraient pas su surmonter facilement. Le budget est allégé.

La charge mentale de chaqun à été divisée équitablement :

  • Le développeur prend en charge la technique avec un droit de regard sur l'ownership et de l'UX.
  • Le designer raffine une UI et imagine une UX en relation avec ca compréhension du métier.
  • Le porteur de projet explicite le métier et participe à l'ownership avec un regard critique sur l'UI.

D'expérience, nous trouvons ce processus être le meilleur rapport qualité / prix / temps. Naturellement, des itérations seront nécessaires. De nouvelles questions apparaîtrons. Rien ne garantit un déroulement sans accrocs.

Mais la réalisation de nombreuses maquettes inutiles a été évitée et le temps mieux utilisé.

Le pragmatisme par l'empirisme

L'important est d'avoir conscience des différents savoirs qu'induisent la création d'un produit, et qui est le plus capable d'en assumer la responsabilité dans une environnement à ressources limitées.

La définition du rôle de chacun est souvent sujet à l'interprétation personnelle.
Il n'y a pas d'évidence. Passer outre ses croyances personnelles, faire communiquer les différents corps de métier et réajuster les rôles au regards des différents profils demande plus de prise de recul que de "jeter" de la main d'oeuvre face à un sujet et d'attendre le résultat. Mais c'est à ce prix, tout compte fait raisonnable, que des processus sains se développent, se fluidifient est finissent par se normaliser, pour atteindre un optimum d'efficacité.