StayEase
Concept de site de réservation hôtelière construit autour de sa barre de recherche : un sélecteur à cinq types de séjour, quatre champs qui conservent leur état, et une navigation par destinations pour les voyageurs qui n'ont pas encore choisi de ville.
- Type
- Projet conceptuel, initiative personnelle
- Rôle
- UX, UI et identité visuelle
- Plateforme
- Web responsive
- Outils
- Figma

La barre de recherche est le produit
Sur un site de réservation, tout ce qui est au-dessus de la ligne de flottaison est du décor sauf un composant. La barre de recherche est là où la session commence réellement, elle a donc été conçue en premier et le reste de la page s'est organisé autour.
Elle chevauche délibérément l'image hero au lieu de se placer en dessous, parce que cela place le contrôle le plus important au centre optique de la page plutôt qu'au bas d'une bande décorative.
Les quatre champs restent libellés et en permanence visibles : destination, arrivée, départ, voyageurs. Les réduire en un seul champ « Rechercher » paraît plus propre dans une maquette mais coûte immédiatement au visiteur la possibilité de voir ce qu'il a déjà rempli.



Type de séjour avant la destination
Une rangée d'onglets au-dessus des champs (hôtels, resorts, villas, appartements, maisons d'hôtes) définit le type de séjour avant tout le reste. Cet ordre compte : quelqu'un qui cherche une villa et quelqu'un qui cherche une maison d'hôtes effectuent des recherches différentes, et filtrer après l'affichage des résultats revient à ignorer une page de listings non désirés.
Les onglets sont un sélecteur plutôt qu'une autre puce de filtre pour la même raison. C'est un choix unique qui recadre toute la requête, pas l'un des multiples raffinements empilés.
Pour les voyageurs sans destination
Une barre de recherche suppose que vous savez où vous allez. Beaucoup de voyages ne commencent pas ainsi, c'est pourquoi « Explorez les meilleures destinations hôtelières » se place juste en dessous sous forme d'une rangée de cartes de villes.
C'est le même argument que l'app de livraison : offrir au visiteur indécis un point d'entrée qui ne nécessite pas de taper. Le reste de la page suit ensuite l'ordre dans lequel un visiteur en exploration pose des questions : qu'est-ce qui est proposé, pourquoi ce site, qu'ont dit les autres.
Ce que cela a produit
Un concept de page d'accueil avec une hiérarchie d'information fonctionnelle : type de séjour, puis les quatre champs de recherche, puis la navigation par destinations pour ceux qui n'ont pas encore décidé, suivie des sections de support qu'un visiteur de réservation lit dans cet ordre.
Aucune réservation n'a été prise et aucune n'est revendiquée. Ce que le projet démontre, c'est concevoir une page autour de son seul composant porteur plutôt qu'autour d'une image hero, et offrir au visiteur indécis un point d'entrée qui ne commence pas par un champ de texte vide.
Lectures complémentaires
- De Figma à React : un handoff qui n’est pas reconstruitPourquoi les handoffs de Figma vers React produisent du code qui finit réécrit, et le flux de travail (mapping des tokens, propriétés en forme de props, états réels) qui l’évite.
- Les 8 erreurs d’UI qui tuent votre produit (et comment corriger chacune)Les mêmes 8 problèmes reviennent dans presque tous les produits que j’audite : contraste, espacement, hiérarchie, états. Voici le correctif exact pour chacun, avec des tests que vous pouvez faire dès aujourd’hui.
- Les outils de codage assistés par IA en 2026 : ce qui change sur un projet clientLà où les assistants de codage par IA accélèrent réellement le travail front-end pour les clients en 2026, là où ils font au contraire perdre du temps sans qu’on le remarque, et comment la revue de code doit évoluer dans les deux cas.


