Comment recruter un designer UI/UX au Liban (guide de l'acheteur)

Entre « j'ai une idée d'application » et « j'ai une application », il y a une étape que la plupart des fondateurs libanais sautent, ou paient bien en dessous de sa valeur réelle : le design. Ils vont directement voir un développeur, décrivent l'idée en un paragraphe, et le développeur construit ce qu'il a compris de cette lecture. Les écrans sont refaits deux fois. Les boutons changent de place une fois que le client les voit en fonctionnement. Le projet prend plus de temps et coûte plus cher que ce que laissait supposer le devis initial, et personne n'avait défini à l'avance ce que « terminé » voulait dire.

Le travail d'un designer UI/UX est justement de retirer cette part de devinette avant qu'une seule ligne de code ne soit écrite : quels écrans existent, que se passe-t-il quand on touche chaque élément, et à quoi tout cela ressemble, validé à l'avance. Ce guide couvre ce que ce travail recouvre réellement, ce qu'une entreprise libanaise doit s'attendre à payer, et comment le recruter sans perdre le fil en cours de route.

UI, UX, et pourquoi la confusion vous coûte de l'argent

Les deux termes sont utilisés indifféremment, et cette habitude coûte de l'argent. L'UX (expérience utilisateur) est la structure : quels écrans existent, dans quel ordre, que se passe-t-il après avoir touché un bouton, où apparaît un message d'erreur et que dit-il. L'UI (interface utilisateur) est l'apparence une fois cette structure décidée : couleurs, typographie, espacement, icônes, le système visuel.

Sautez l'UX et allez directement à l'UI, et vous obtenez un bel écran pour un parcours que personne n'a réfléchi : un paiement sans possibilité de retour en arrière, un formulaire qui perd vos données si vous changez d'application, un écran d'accueil qui ne demande jamais la seule chose dont l'application a réellement besoin. La plupart des freelances qui se présentent comme « designer UI/UX » font les deux, mais demandez précisément : allez-vous cartographier les parcours utilisateur avant de dessiner un seul écran, ou allez-vous directement au visuel ? La réponse honnête à cette question est le meilleur filtre dont vous disposez avant de recruter quelqu'un.

Ce que vous devriez réellement recevoir

Une véritable mission UI/UX pour une application de petite à moyenne taille produit, dans l'ordre :

Les parcours utilisateur. Des diagrammes simples montrant chaque chemin possible dans l'application — inscription, l'action centrale pour laquelle l'application existe, les paramètres, les états d'erreur et les états vides. C'est ici que les écrans manquants sont détectés, avant de coûter cher à ajouter.

Les wireframes. Des maquettes d'écran basse fidélité, en niveaux de gris. Pas de couleurs, pas de contenu réel, pas de finition — juste où se trouvent les éléments et leur taille. Les wireframes sont peu coûteux à modifier et douloureux à sauter, car c'est à ce stade qu'on rattrape « attends, ce bouton devrait être où » avant que ce ne soit figé dans le design final.

Un kit de composants / système de design. Chaque élément réutilisable — boutons, champs de saisie, cartes, barres de navigation — conçu une fois, dans chacun de ses états (par défaut, pressé, désactivé, erreur), et réutilisé partout. Sans cela, un développeur construit le même bouton de cinq façons différentes parce que cinq écrans différents le montraient légèrement différemment, et rien dans l'application n'a l'air cohérent.

Les écrans en haute fidélité. Le produit final : couleurs réelles, typographie réelle, contenu réel (ou réaliste), conforme à votre identité de marque.

Un prototype cliquable. Les écrans reliés entre eux dans Figma (ou un outil similaire) pour que vous puissiez naviguer dans l'application avant qu'un développeur n'écrive une seule ligne de code. C'est la livraison la plus utile pour repérer les problèmes à moindre coût — un parcours cassé vous coûte un commentaire dans Figma avant le développement, et un sprint entier de reprise après.

Pour une interface d'application complète de 10 à 20+ écrans sur Furrsati, l'ensemble de ce forfait est facturé au projet, généralement 1 500 à 4 000 $, selon le nombre d'écrans, le nombre d'états requis pour chaque composant, et le nombre de cycles de révision inclus. Cela reste distinct — et d'une ampleur comparable — au développement de l'application elle-même : un MVP simple multiplateforme avec un ensemble de fonctionnalités limité coûte généralement 2 500 à 7 500 $ comme projet à part entière. Budgétez les deux étapes ; une application magnifiquement conçue dont personne n'a chiffré la construction est une déception courante et évitable. Notre guide sur le coût de développement d'applications mobiles détaille ce qui fait varier ce second chiffre.

Le brief qui fonctionne vraiment

Un brief vague produit un design vague. Avant de contacter quiconque, notez :

• À qui s'adresse l'application, en une phrase pour chacun de vos deux ou trois utilisateurs principaux — pas « tout le monde ».
• L'action unique que l'application doit rendre sans effort. Chaque application a une mission ; nommez-la. Tout le reste est secondaire.
• Les écrans dont vous savez déjà avoir besoin, même une liste approximative. Le designer trouvera ceux que vous avez oubliés, mais une liste de départ évite un cycle de découverte.
• Des applications dont vous aimez la sensation, et précisément ce que vous aimez — pas « faites comme Instagram », mais « la façon dont cette application confirme une action d'un simple toucher et d'une petite animation ».
• La plateforme : iOS, Android, ou les deux, car cela change certains schémas d'interaction (boutons retour, barres de navigation) même à l'intérieur du même design.
• Les éléments de marque déjà existants — logo, couleurs, polices — pour que le designer parte de votre identité plutôt que d'en inventer une en cours de projet.

Notre guide du brief propose un modèle plus complet si vous n'en avez jamais rédigé.

Lire une proposition, et qui possède quoi

Deux questions décident de la plus grande partie de la réussite d'un projet.

Recevrez-vous le fichier source, pas seulement des images ? Vous avez besoin du fichier Figma (ou équivalent) modifiable, pas d'exports PNG. Sans le fichier source, tout futur changement — un nouvel écran, un ajustement de couleur, un bouton différent — nécessite de revenir vers le designer d'origine ou de repartir de zéro. Confirmez la propriété du fichier avant le début du projet, pas après la facture.

Combien de cycles de révision sont inclus, et qu'est-ce qui compte comme un cycle ? « Révisions illimitées » semble généreux et signifie généralement l'inverse — cela invite à des ajustements mineurs sans fin qui ne convergent jamais parce que rien n'a jamais été validé définitivement. Une structure plus claire : deux cycles structurés par étape (wireframes, puis haute fidélité), chaque cycle correspondant à un retour consolidé livré en une fois, pas un flux de messages individuels sur deux semaines. Comparez les propositions sur cette base plutôt que sur le prix affiché ; notre guide d'évaluation des propositions approfondit comment lire les devis à conditions égales.

Structurez le projet en jalons plutôt qu'en un seul montant global : parcours et wireframes validés, puis le kit de composants, puis les écrans finaux, puis le prototype fonctionnel. Chaque jalon est quelque chose que vous pouvez réellement examiner et accepter ou renvoyer avec des remarques précises, ce qui est un bien meilleur point de contrôle que « 35 % terminé ».

La transmission à un développeur

Le prototype n'est pas la fin de l'étape de design — c'est le document de transmission. Un développeur travaillant à partir d'un vrai fichier Figma avec un kit de composants documenté avance plus vite et produit quelque chose de plus proche de ce que vous avez validé qu'un développeur travaillant à partir d'une description orale ou de quelques captures d'écran. Demandez à votre designer d'ajouter des notes pour le développeur directement dans Figma — valeurs d'espacement, tailles de police, couleurs exactes — afin que le développeur ne devine pas les valeurs en pixels à partir d'une capture d'écran. Si vous recrutez le développeur séparément, partagez le fichier Figma et le lien du prototype avant même le début de cette mission ; cela change la façon dont le développeur évalue et chiffre la construction.

Payer en toute sécurité

Furrsati retire le risque des deux côtés de cette transmission. Vous publiez votre projet, comparez les propositions de freelances vérifiés, financez un jalon et ne libérez le paiement qu'une fois le travail approuvé, les fonds du jalon étant conservés par Stripe jusqu'à ce que vous les libériez. Les frais de service sont prélevés côté freelance : seuls les frais habituels de traitement de carte s'ajoutent à votre facture, et les jalons financés par le portefeuille n'en supportent aucun. Les freelances vérifient leur identité avant de pouvoir retirer ; en tant que client, aucune vérification ne vous est demandée. Les paiements parviennent au freelance au Liban par OMT, Whish, virement bancaire ou USDT.

Votre prochaine étape

Notez l'action unique que votre application doit rendre sans effort, listez les écrans dont vous savez déjà avoir besoin, et rassemblez les éléments de marque existants. Puis recrutez un designer UI/UX sur Furrsati, structurez le projet en jalons du parcours jusqu'au prototype, et gardez votre paiement protégé jusqu'à ce que vous ayez un fichier que vous possédez réellement.

Foire aux questions

Combien coûte un designer UI/UX au Liban ?

Sur Furrsati, un forfait d'interface d'application complète de 10 à 20+ écrans — parcours, wireframes, kit de composants et prototype cliquable — est facturé au projet, généralement 1 500 à 4 000 $. La fourchette dépend du nombre d'écrans, du nombre d'états requis par composant, et du nombre de cycles de révision inclus.

Le design UI/UX est-il la même chose que le développement d'application ?

Non, et les budgétiser comme une seule chose est une erreur courante. Le design produit les parcours, les écrans et le prototype ; le développement construit l'application fonctionnelle à partir de ce design. Un MVP simple multiplateforme coûte généralement 2 500 à 7 500 $ comme projet distinct, en plus du coût du design.

Quels fichiers dois-je recevoir d'un designer UI/UX ?

Le fichier source modifiable (Figma ou équivalent), pas seulement des images exportées. Sans le fichier source, vous ne pouvez pas faire de futures modifications sans le designer d'origine ou repartir de zéro. Confirmez ce point avant le début du projet.

Combien de cycles de révision dois-je prévoir ?

« Révisions illimitées » signale généralement l'absence d'une vraie structure de validation. Une organisation plus claire est deux cycles structurés par étape — wireframes, puis écrans en haute fidélité — chaque cycle correspondant à un retour consolidé livré en une fois, pas des demandes ponctuelles continues.

Ai-je besoin d'un designer UI/UX avant de recruter un développeur ?

Pour tout ce qui dépasse un ou deux écrans très simples, oui. Un développeur travaillant à partir d'un fichier Figma documenté avec un kit de composants et des notes pour le développeur avance plus vite et construit plus près de ce que vous avez validé qu'un développeur travaillant à partir d'une description orale.