Le One-Hand Pattern
Designer pour une Seule Main dans un Monde en Mouvement
Sommaire
Vous designez pour un utilisateur qui n'existe pas
L'utilisateur assis confortablement, tenant son téléphone à deux mains, pleinement concentré sur votre interface — cet utilisateur est un fantasme. Dans la réalité, votre utilisateur est dans le métro, debout, agrippé à une barre avec une main, son téléphone dans l'autre. Il marche sur un trottoir bondé. Il mange un sandwich. Il porte un sac. 75% des interactions mobiles se font à une seule main, et pourtant la majorité des interfaces sont encore conçues comme si l'utilisateur disposait de ses deux mains et de toute son attention. C'est un échec fondamental de compréhension du contexte d'usage.
Position forte : si votre interface nécessite deux mains pour effectuer une tâche courante, vous avez perdu la moitié de vos utilisateurs avant même qu'ils aient commencé.
Les données : 75% d'utilisation à une main, et ce n'est pas un choix
Les études de Google (2020) et du Baymard Institute (2023) convergent sur un chiffre : environ 75% des sessions mobiles impliquent une utilisation à une main pendant au moins une partie de la session. Ce n'est pas une préférence utilisateur — c'est une contrainte environnementale. Les utilisateurs n'utilisent pas leur téléphone à une main parce qu'ils le veulent, mais parce que leur autre main est occupée. Cette réalité n'est pas un cas limite à traiter en fin de projet. C'est le cas d'usage principal à partir duquel il faut concevoir.
49% des sessions sont entièrement à une main (Hoober, 2017)
26% supplémentaires passent d'une main à deux mains selon la tâche
Les moments clés sont les transports (82% à une main), la marche (91%), et les repas (73%)
L'utilisation à deux mains augmente uniquement pour la saisie de texte longue et le gaming
Utilisation a une main
L'utilisation a une main n'est pas un choix — c'est une contrainte environnementale.
Le contexte d'usage : le facteur que 90% des designers ignorent
Le contexte d'usage n'est pas une note en bas de page dans un rapport UX — c'est le paramètre qui invalide ou valide toutes vos décisions de design. Un utilisateur dans le métro parisien aux heures de pointe est soumis à des vibrations, des mouvements brusques, un éclairage variable, et un espace physique réduit. Son pouce est moins précis, sa patience est moindre, et sa capacité d'attention est fragmentée. Designer sans considérer ce contexte, c'est comme tester une voiture uniquement sur circuit et prétendre qu'elle est adaptée à la ville.
En mouvement : précision du pouce réduite de 20-30% par rapport à une position statique
Luminosité variable : le contraste des boutons doit supporter des conditions extrêmes
Attention fragmentée : chaque tâche doit pouvoir être interrompue et reprise sans perte
Espace réduit : les gestes amples (swipe long, pinch-to-zoom) sont limités en environnement bondé
Le Bottom Sheet : le pattern roi du one-hand design
Le bottom sheet est devenu le pattern dominant du mobile pour une raison simple : il place le contenu et les actions exactement là où le pouce peut les atteindre. Apple Maps, Google Maps, Uber, Deliveroo — les apps les plus utilisées au monde ont fait du bottom sheet leur pattern de navigation principal. Le bottom sheet glisse depuis le bas, peut être étiré à différentes hauteurs, et concentre les actions dans la zone de confort du pouce. Il remplace avantageusement les modales centrées, les dropdown depuis le haut, et les pages entières pour des interactions secondaires.
Règle d'or : si une information ou une action peut être présentée dans un bottom sheet plutôt qu'une page pleine ou une modale centrée, choisissez le bottom sheet. Votre taux de complétion vous remerciera.
Les gestes de swipe : l'alphabet naturel du pouce
Le swipe est le geste le plus naturel pour un pouce opérant seul. Il ne demande ni précision de ciblage ni pression spécifique — juste un mouvement directionnel. C'est pourquoi les interfaces les plus réussies du mobile s'appuient massivement sur le swipe : Tinder (swipe pour liker/rejeter), Instagram Stories (swipe pour naviguer), Mail (swipe pour archiver/supprimer). Mais attention : le swipe horizontal est nettement plus naturel que le swipe vertical pour un pouce seul, car l'arc de mouvement du pouce est naturellement latéral. Les gestes verticaux doivent être réservés au scroll, pas aux actions.
Swipe horizontal : arc naturel du pouce, idéal pour les actions binaires (oui/non, suivant/précédent)
Swipe vertical : réservé au scroll — l'utiliser pour des actions crée de la confusion
Swipe depuis le bord : conflit potentiel avec les gestes système — à utiliser avec précaution
Pull-to-refresh : geste devenu universel, mais son origine verticale le rend moins ergonomique qu'un swipe latéral
Gestes adaptes a une main
La taille des cibles : 44px est un minimum, pas un objectif
Apple recommande 44x44 points. Google recommande 48x48 dp. Les WCAG 2.2 recommandent 44x44 CSS pixels. Ces chiffres sont des MINIMUMS pour une utilisation à deux mains dans des conditions idéales. Pour une utilisation à une main en mouvement, ces tailles sont insuffisantes. Les données de terrain montrent que le taux d'erreur de tap augmente de 40% sur des cibles de 44px lorsque l'utilisateur est en mouvement. Pour le one-hand pattern, la cible recommandée est de 56px minimum pour les actions fréquentes, avec un espacement inter-cibles d'au moins 8px pour éviter les erreurs de fat finger.
Ne confondez pas la taille visuelle et la zone tactile. Un bouton peut paraître 40px mais avoir une zone de hit de 56px grâce au padding invisible. C'est la zone tactile qui compte, pas l'apparence.
Les formulaires à une main : repenser chaque champ
Les formulaires sont le cauchemar du one-hand design. La saisie de texte force souvent le passage à deux mains, le clavier masque la moitié de l'écran, et la navigation entre champs demande une précision que le pouce seul peine à fournir. La solution n'est pas de supprimer les formulaires — c'est de les repenser radicalement. Chaque champ de texte libre doit être questionné : peut-il être remplacé par un sélecteur, un toggle, un slider, ou un choix binaire ? Les formulaires les plus performants en one-hand remplacent 60% de la saisie par des interactions de sélection (tap, swipe, toggle).
Remplacer les champs de date par des date pickers natifs (roue iOS, calendrier Material)
Utiliser des toggles et des radio buttons au lieu de dropdown selects
Grouper les champs en étapes courtes (1 à 3 champs max par écran) pour réduire le scroll sous clavier
Le bouton de validation doit rester visible au-dessus du clavier — jamais masqué en dessous
Auto-complétion agressive : réduire chaque champ à 2-3 caractères saisis maximum
Alternatives aux modales : arrêtez de bloquer l'écran
Les modales centrées sont un anti-pattern du one-hand design. Elles apparaissent au centre de l'écran (zone la plus difficile à atteindre avec le pouce), elles demandent souvent un tap précis sur un petit bouton "X" dans le coin (zone quasi inaccessible), et elles bloquent tout le contenu derrière un overlay. En one-hand design, chaque modale doit être remplacée par une alternative plus ergonomique. Le bottom sheet pour les confirmations. Le toast notification pour les messages courts. L'inline expansion pour les détails. Le swipe-to-dismiss pour les alertes non critiques.
Chaque fois que vous êtes tenté de créer une modale, posez-vous la question : cet utilisateur a-t-il vraiment besoin de quitter son flux ? Dans 80% des cas, la réponse est non.
iOS vs Android : deux philosophies du one-hand design
Apple et Google ont adopté des approches radicalement différentes du design à une main, et ces différences doivent informer votre stratégie cross-platform. iOS a fait le choix radical de déplacer des éléments historiquement hauts vers le bas : la barre d'URL de Safari, la barre de recherche de Spotlight, les contrôles de l'appareil photo. Android avec Material Design 3 a opté pour une approche plus conservatrice, gardant certains éléments en haut mais introduisant le "Large Top App Bar" qui se réduit au scroll. Le bottom sheet est devenu commun aux deux plateformes, mais avec des comportements d'interaction différents.
iOS : barre de recherche en bas, navigation en bas, Reachability intégré — philosophie "tout en bas"
Android : top app bar persistent, FAB en bas à droite, bottom nav optionnel — philosophie hybride
Bottom sheet iOS : swipe-to-dismiss natif avec détents multiples (quarter, half, full)
Bottom sheet Android : comportement de drag plus libre mais moins prévisible
Recommandation : suivre les conventions de chaque plateforme plutôt que d'imposer un design unique
One-hand et accessibilité : une convergence naturelle
Le one-hand design et l'accessibilité ne sont pas deux disciplines séparées — elles convergent naturellement. Une personne qui utilise son téléphone à une main parce qu'elle porte un café et une personne qui n'a qu'un bras fonctionnel ont les mêmes besoins ergonomiques. Les cibles larges, la navigation en bas, les gestes simples, les alternatives aux interactions complexes — tout ce qui rend une interface utilisable à une main la rend aussi plus accessible. C'est l'argument ultime pour convaincre un stakeholder réticent : le one-hand design n'est pas un luxe pour les usagers en mobilité, c'est un impératif d'accessibilité qui bénéficie à 100% de vos utilisateurs.
Le meilleur test d'accessibilité mobile ? Utilisez votre app d'une seule main pendant une journée entière. Chaque frustration que vous ressentez est multipliée par dix pour un utilisateur en situation de handicap.
Mesurer le one-hand design : les métriques qui comptent
Comment savoir si votre interface est réellement optimisée pour une main ? Les métriques classiques (taux de conversion, temps sur page) ne suffisent pas. Il faut des métriques spécifiques au one-hand design. Le Thumb Travel Distance (distance totale parcourue par le pouce pour compléter une tâche) est la métrique la plus révélatrice. Un parcours optimisé doit maintenir le pouce dans un rayon de 5cm autour de sa position de repos. Le taux de grip-shift (nombre de fois où l'utilisateur doit repositionner sa main) est un indicateur direct de friction ergonomique. Au-delà de 2 grip-shifts par tâche, votre interface force le passage à deux mains.
Thumb Travel Distance : distance cumulée du pouce par tâche — objectif < 15cm pour les tâches courantes
Grip-shift rate : nombre de repositionnements de main — objectif < 2 par tâche
One-hand completion rate : % de tâches complétées sans passer à deux mains
Tap accuracy in motion : taux de succès des taps en conditions de mobilité
Time-to-target : temps entre l'intention et le contact avec la cible — corrélé à la Loi de Fitts
Une main, un principe : l'empathie contextuelle
Le one-hand pattern n'est pas une collection de recettes — c'est une posture de design. C'est accepter que votre utilisateur n'est pas dans les conditions idéales de votre maquette Figma. C'est designer pour le pire scénario d'utilisation, parce que ce "pire scénario" est en réalité le scénario le plus fréquent. Le metro bondé, le trottoir en pente, la file d'attente qui avance — c'est là que vos interfaces sont réellement utilisées. Les designers qui intègrent cette réalité dès la conception produisent des interfaces qui fonctionnent pour tout le monde, dans toutes les conditions. C'est la définition même du bon design.
Designez toujours en tenant votre téléphone d'une seule main. Si vous ne pouvez pas utiliser votre propre prototype confortablement dans le métro, retournez à la planche à dessin.
Sources & Références
- [1]Hoober, S. (2017). Design for Fingers, Touch, and People, Part 1. UXmatters.
- [2]Google Design (2020). Designing for Mobile: Context and Posture. Material Design Blog.
- [3]Baymard Institute (2023). Mobile Usability: Touch Interaction Patterns.
- [4]Nielsen Norman Group (2023). Hamburger Menus and Hidden Navigation Hurt UX Metrics.
- [5]Apple Human Interface Guidelines — Tab Bars and Navigation (2025).
- [6]Material Design 3 — Bottom Sheets and Navigation Components (2025).
- [7]WCAG 2.2 — Success Criterion 2.5.8: Target Size Minimum (2023).
- [8]Wroblewski, L. (2011). Mobile First. A Book Apart.
- [9]Budiu, R. (2022). Mobile-First Is NOT Mobile-Only. Nielsen Norman Group.