iMove

Comment concevoir une application mobile qui rend la ville vraiment accessible aux PMR ?

Comment j’ai pensé, designé et prototypé une application de navigation inclusive — du persona PMR jusqu’à la passation avec les développeurs, en mode Agile ?

Focus projet · iMove — Application mobile PMR

Client

iMove — Application mobile de navigation pour les personnes à mobilité réduite (PMR)

Logiciels

Prototypage UI/UX avec Figma – Noémie Bouton, designer à Bordeaux
Création de logos et affiches vectorielles avec Illustrator – Designer à Bordeaux

Ce projet de stage m'a appris que designer pour l'accessibilité, c'est d'abord designer pour l'humain — avec ses contraintes réelles, pas celles qu'on imagine pour lui.

Processus de conception : analyse du besoin, prototypage et passation dev.

Concept

Contexte/ Objectif

Dans le cadre de mon stage de fin d’études, j’ai intégré une équipe produit pour concevoir iMove — une application mobile pensée pour les personnes à mobilité réduite (PMR).

 

Le constat de départ est simple : les applications de navigation existantes ignorent largement les contraintes du handicap. Un trottoir mal signalé, un ascenseur en panne, un bus inaccessible — autant de frictions invisibles pour les valides, rédhibitoires pour les PMR.

 

L’objectif : proposer un outil de mobilité véritablement inclusif, qui intègre les contraintes d’accessibilité au cœur de sa logique de trajet, et non en option secondaire.

Recherche & Stratégie UX

Les 4 fonctionnalités fondatrices d’iMove :

 

  • Connaître tous les transports en commun accessibles à proximité
  • Être alerté en temps réel des anomalies sur le parcours (ascenseur en panne, travaux, etc.)
  • Filtrer les parcours selon l’accessibilité réelle
  • Obtenir un itinéraire adapté au profil de handicap de l’utilisateur
  • Définition des personas : conception de profils utilisateurs spécifiques aux besoins d’accessibilité — fauteuil roulant électrique, déficience visuelle, mobilité réduite temporaire. Chaque persona a orienté les décisions de priorisation fonctionnelle.
  • Parcours utilisateurs : modélisation des scénarios d’usage critiques — planifier un trajet multi-modal, recevoir une alerte en temps réel, adapter son itinéraire en cours de route.
  • Architecture de l’information : simplification maximale des arborescences pour limiter la charge cognitive.

Design

Identité Visuelle

Le branding d’iMove devait refléter deux valeurs en tension : la clarté fonctionnelle (outil de navigation utilitaire) et la bienveillance inclusive (conçu pour tous). Le résultat : une identité sobre, lisible, ancrée dans la confiance.

 

  • Logo : onception d’un symbole alliant mouvement et accessibilité — dynamique sans être agressif, mémorable sans être complexe.
  • Palette de couleurs : sélection rigoureuse d’une palette contrastée répondant aux ratios d’accessibilité WCAG AA minimum. Bleu primaire (#1B4FD8), blanc, noir — zéro compromis sur la lisibilité.
  • Typographe : choix d’une police à haute lisibilité, corps large, espacement généreux. Déclinaison d’une hiérarchie claire en 4 niveaux.
Maquettage & design system

Toute l’interface a été conçue en s’appuyant sur Material 3, le design system de Google — un choix délibéré pour garantir la cohérence avec les conventions d’usage mobile et faciliter la passation aux développeurs.

  • Composants Material 3 : utilisation et adaptation des composants natifs — navigation bottom bar, cards, chips de filtre, bottom sheets pour les alertes.
  • Prototypage haute fidélité : création d’un prototype interactif complet sur Figma couvrant les 3 parcours utilisateurs principaux.
  • Accessibilité by design : zones tactiles ≥ 44px, libellés descriptifs sur chaque élément interactif, contrastes vérifiés sur l’ensemble des écrans.

Réalisation

Collaboration & passation dev.

Toute la phase de réalisation s’est déroulée en mode Agile, au sein d’une équipe pluridisciplinaire. 

 

  • Synergie design-développement : présentation des maquettes annotées pour une passation sans friction. Les développeurs disposaient de tous les espacements, couleurs et comportements documentés directement dans Figma.
  • Intégration des contraintes techniques : adaptation de certains choix de design en fonction des retours développeurs sur les APIs transport disponibles et les limites de performance en temps réel.

Ce que ce projet m'a appris

  • Figma maîtrisé en conditions réelles : composants, auto-layout, variables, prototypage avancé — ce stage a transformé ma maîtrise de l’outil.
  • S’approprier un design syste : comprendre Material 3 en profondeur — pas juste utiliser les composants, mais en saisir la logique pour l’adapter sans le trahir.
  • Penser l’accessibilité, pas la subir : les contraintes WCAG ne sont pas des cases à cocher. Elles révèlent des problèmes de design que tout le monde rencontre.
  • Dialoguer avec les développeurs : mes 7 ans en production web ont ici tout changé — anticiper les contraintes tech, parler le même langage, livrer un fichier exploitable.