Design QA

Design QA : Contrôle des écrans intégrés au regard des maquettes, qui relève les écarts d’espacement, de couleur et de comportement.

Entrée de la famille « Produit et UX » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Où intervient Design QA dans un projet

Dans un projet d’application, Design QA sert à trancher : quelles fonctions entrent en version 1, dans quel ordre, et ce qu’on assume de laisser de côté.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

Comment l’écrire dans un cahier des charges

Un cahier des charges lisible relie « Design QA » à un utilisateur nommé et à une action précise : qui fait quoi, depuis quel écran, avec quel résultat visible.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

À la recette, « Design QA » se juge sur le parcours complet, pas sur un écran isolé qui fonctionne en démonstration.

• Utiliser l’application sur un petit écran, d’une seule main.
• Parcourir l’écran principal au lecteur d’écran, au moins une fois.
• Comparer les maquettes validées au résultat livré, écran par écran.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Erreurs fréquentes

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Valider des maquettes sans avoir écrit les critères d’acceptation correspondants.
• Empiler les fonctionnalités en version 1 au lieu de sortir un périmètre défendable.
• Repousser l’accessibilité à plus tard, ce qui revient à refaire les écrans une seconde fois.
• Découper le projet en sprints sans jamais rien mettre entre les mains d’un utilisateur.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Code téléchargé à distance
• MVP
• Onboarding
• Churn
• Wireframe

Questions fréquentes

Que signifie « Design QA » ?

Contrôle des écrans intégrés au regard des maquettes, qui relève les écarts d’espacement, de couleur et de comportement. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Comment le vérifier à la recette ?

Avec un critère écrit avant le développement, formulé de façon à pouvoir être refusé. « L’écran doit être agréable » ne se recette pas. « La liste vide affiche tel message et tel bouton » se recette.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.