Pense tes écrans en 4D : la dimension temps que 99% des devs ignorent - Builder Créatif

Pense tes écrans en 4D

J’ai un aveu : pendant des années, je concevais mes écrans comme des photos. Un écran = un état figé. Layout, couleurs, typo. Je checkais le design sur Figma, ça rendait bien, je passais à la suite.

Sauf qu’une app, c’est pas une photo. C’est du cinéma.

Un utilisateur passe rarement plus de 3 secondes sur un écran “final”. Le reste du temps, le chargement, la transition, l’apparition progressive, c’est le temps mort que la plupart des devs traitent comme un bug à cacher. Un spinner au centre, on croise les doigts.

Mais ce temps mort ? C’est ta plus grosse opportunité UX.

L’écran a 4 dimensions, pas 2

Quand on pense “design d’écran”, on pense X et Y. Largeur et hauteur. Mais un écran dans une app mobile vit dans le temps. Il a des états :

Vide, l’utilisateur arrive, rien n’est chargé
Chargement, les données arrivent, mais l’écran est déjà visible
Transition, on passe d’un état à l’autre (ouverture, fermeture, navigation)
Interactif, l’écran est prêt, l’utilisateur agit
Feedback, l’utilisateur a agi, l’écran réagit

La plupart des apps gèrent l’état 4 et ignorent les autres. Les meilleures apps, Stripe, Airbnb, Duolingo, construisent chaque état comme un mini-écran à part entière.

Luke Wroblewski l’a bien dit : “Show, don’t tell. Every pixel of loading time is a pixel of your brand.” Les meilleurs designers d’interaction ne se demandent pas “comment cacher le chargement” mais “comment rendre le chargement agréable”.

Le spark de BeeDone v3

Quand j’ai commencé la v3 de BeeDone avec un designer UX via la méthode BMAD, le premier truc qu’il a posé c’était pas “montre-moi tes maquettes”. C’était :

“Montre-moi le chemin du splash screen à la home. Montre-moi chaque frame.”

Et là j’ai realised : j’avais jamais pensé à ce chemin. J’avais un splash, puis un loader, puis la home. Trois étapes indépendantes. Zéro continuité.

On a tout repensé comme une séquence continue. Le logo du splash anime et devient le logo de la home. Les éléments apparaissent pas d’un coup, ils “entrent” en cascade. La bottom sheet monte pas mécaniquement, elle répond au contexte.

Le résultat ? L’app feels alive. Pas parce qu’elle a des animations partout. Parce que chaque transition raconte une histoire.

Les 6 armes du chargement intelligent

Voici ce qu’on a implémenté dans BeeDone v3, chaque technique résout un problème de “temps” spécifique :

1. shimmer ciblé (Placeholder atom)

Le shimmer classique : tout l’écran pulse en gris. Utile en 2018.

Le shimmer ciblé : chaque zone de l’écran a son propre shimmer shape. La liste de tâches montre des rectangles horizontaux. L’avatar montre un cercle. Le header montre une barre plus épaisse.

Dans BeeDone, le ShimmerPlaceholder utilise un pulse alpha 0.3→0.6 sur 1200ms. Pas besoin de lib externe, 30 lignes de CustomPainter. L’utilisateur voit pas “un loader”. Il voit la forme de ce qui va arriver.

2. Logo animé en transition

Le logo_animated.gif est notre fil rouge visuel. Il apparaît à 4 endroits :

Splash screen
Écran de onboarding (saisie des goals)
Dialogue de mise à jour
Onglet hebdomadaire

À chaque fois, c’est le même logo, la même animation. Ça crée une identité temporelle, l’utilisateur sait “je suis dans BeeDone” même pendant un chargement.

3. Fake Progress Bar (pas si fake que ça)

Celle-ci, elle est diabolique. Le FakeLoadingProgressBar dans les routines affiche une barre de progression bleue→jaune qui avance… mais n’atteint jamais 100%.

Pourquoi ? Parce qu’une barre de progression réelle qui stresse, c’est pire que pas de barre du tout. L’utilisateur fixe la barre et angoisse. Notre fake bar donne une impression de mouvement sans promettre une fin précise. C’est du perceived velocity, tu sens que ça avance, tu stresses pas sur le temps exact.

C’est la même psychologie que les écrans “Nearly there!” des installateurs. Le mouvement apaise. L’immobilité angoisse.

4. hero animation, splash → home → bottom sheet

C’est la pièce maîtresse. Le MainLogoHero utilise le système Hero de Flutter pour créer une continuité visuelle du splash à la home :

Splash (logo centré) → Home (logo dans le header) → Bottom Sheet (logo miniature)

Le logo se déplace et rétrécit en suivant le chemin de l’utilisateur. Pas de coupure visuelle. Pas de “flash blanc” entre les écrans. C’est comme un plan-séquence au cinéma, la caméra suit le mouvement sans coupe.

Google le dit dans ses Material Design guidelines : “Motion provides meaning. Objects can transform and reorganize, not just appear and disappear.” Le Hero widget est la matérialisation de ce principe.

5. circular progress indicator, le signal subtil

Le LoadingCircle jaune (kColorYellow, 40px) apparaît dans les dialogues et les transitions secondaires. Pas de texte “Chargement…”. Juste un cercle qui tourne dans la couleur de la marque.

C’est un choix délibéré : le circular progress dit “ça travaille”, le shimmer dit “ça arrive”, le hero dit “tu es au bon endroit”. Chaque pattern de chargement communique un message différent.

6. entrance fader, l’apparition chorégraphiée

L’EntranceFader est utilisé sur les backlogs, les textes de breathwork, les citations motivantes, et le rooter principal. Chaque élément apparaît avec un délai calibré :

Premier élément : instantané
Deuxième : +200ms
Troisième : +400ms

C’est pas de l’art pour l’art. C’est de la hiérarchie temporelle. L’œil de l’utilisateur suit naturellement la séquence. Il lit le titre d’abord, le sous-titre ensuite, le contenu en dernier. L’animation guide l’attention, comme un chef d’orchestre qui fait entrer les instruments un par un.

La matrice temps × état

Voici comment on a mappé chaque technique à un moment précis du parcours utilisateur :

Moment	Problème	Solution BeeDone	Technique
Splash → Home	Coupure visuelle	Logo qui voyage	Hero Animation
Home vide	Écran blanc, angoisse	Formes des éléments à venir	Shimmer ciblé
Routine en cours	Attente perçue longue	Barre qui avance (jamais 100%)	Fake Progress Bar
AI génère une tâche	Rien ne se passe	Texte qui s’écrit lettre par lettre	Typewriter Effect
Bottom sheet ouvre	Apparition brutale	Slide + fade chorégraphié	Entrance Fader
Dialogue de loading	Spinner generic	Cercle jaune brandé	Circular Progress
Onboarding	Flood d’informations	Éléments séquentiels delayés	Entrance Fader

Le pattern est clair : chaque “temps mort” est une opportunité de design.

Ce que les refs disent

Je suis pas le seul à penser comme ça :

Sam Soffes (ex-Stripe) : “If you can’t make it fast, make it feel fast.” La perceived performance est plus importante que la performance réelle au-delà de 200ms.

Luke Wroblewski (Google) dans son talk Designing the Time Dimension : les états de transition sont les “moments de vérité” d’une app, c’est là que l’utilisateur décide si ton app est polie ou cheap.

Flutter Hero : le widget Hero existe spécifiquement pour ce problème. Il crée une animation partagée entre deux routes. La doc dit “A hero animation is a shared element transition that flies from one page to another”. C’est pas un gadget, c’est un paradigme de navigation.

Stripe : leur checkout est un masterclass. Le shimmer prend la forme exacte du champ de carte. La progress bar montre les étapes. Chaque micro-second est designée.

Airbnb : leur skeleton loading dans la recherche est probablement le plus copié de l’industrie. Chaque placeholder match la forme du contenu final.

Le piège : trop d’animation = motion sickness

J’ai failli tomber dedans. Quand t’as compris le pouvoir des transitions, tu veux animer TOUT. Chaque bouton, chaque texte, chaque icône.

Règle que je me suis fixée dans BeeDone :

Anime le contexte, pas le contenu, les transitions entre écrans, pas les boutons
Un seul hero par parcours, le logo voyage du splash à la home, c’est suffisant
Délais < 500ms, au-delà, c’est de l’attente, pas de l’anticipation
Jamais de bounce/elastic, c’est 2026, pas 2014. Les courbes easeInOut suffisent

L’objectif c’est pas que l’utilisateur remarque les animations. C’est qu’il les ressente sans les voir. Comme la musique de film, si tu la remarques, elle a échoué.

Ce que ça change concrètement

La v3 de BeeDone est pas “plus belle” que la v2. Elle est plus fluide. Et la fluidité, c’est ce qui sépare une app “qui marche” d’une app qu’on aime utiliser.

Le concept est simple : arrête de penser à tes écrans comme des pages dans un livre. Pense-les comme des scènes dans un film. Ce qui se passe entre les scènes est aussi important que les scènes elles-mêmes.

La dimension temps, c’est pas un bug à patch. C’est un canvas à designer.

Si ce concept te parle et que tu veux voir le résultat en action, BeeDone v3 arrive bientôt. En attendant, je partage le process de dev sur youcefelkamel.com.

Et toi, tu penses à la dimension temps dans tes apps ? Ou tu balances un CircularProgressIndicator au centre et tu passes à la suite ? 😄