Concept: Conception centrée sur l'utilisateur
La conception centrée sur l'utilisateur consiste à concevoir des applications en privilégiant les besoins et l'efficacité de l'utilisateur final.
Description principale

Qu'est-ce que la conception centrée sur l'utilisateur ?

Il n'y a pas de consensus clair sur ce qui constitue la conception centrée sur l'utilisateur. Toutefois, John Gould et ses collègues chez IBM ont développé dans les années 80 une approche appelée Conception pour la convivialité [GOU88] qui couvre la plupart des définitions les plus communément admises. Le développement a été fait à partir de l'expérience pratique d'un certain nombre de systèmes interactifs, plus particulièrement le système de messagerie IBM des jeux olympiques de 1984 [GOU87]. Cette approche comprend quatre composants principaux, décrits ci-dessous.

Concentration sur les utilisateurs

Gould suggère que les développeurs décident du profil des utilisateurs et de les impliquer au stade le plus précoce possible. Il suggère un certain nombre de moyens pour se familiariser avec les utilisateurs, leurs tâches et leurs exigences :

·    Parler avec les utilisateurs.

·    Visiter les sites des clients.

·    Observer les utilisateurs au travail.

·    Filmer les utilisateurs au travail.

·    S'informer sur l'organisation du travail.

·    L'essayer vous-même.

·    Demander aux utilisateurs de penser tout haut en travaillant.

·    Participer à la conception.

·    Inclure des utilisateurs experts dans l'équipe de conception.

·    Analyser les tâches.

·    Utiliser des sondages et des questionnaires.

·    Développer des objectifs testables.


 Dans le processus Rational Unified Process (RUP), les ateliers sont utilisés à différentes étapes clés, mais doivent être complétés par les types d'activités que Gould décrit pour se faire une image précise de la situation. (Ceci en partie parce que les gens décrivent fréquemment ce qu'ils font d'une manière bien différente de la manière dont ils le font réellement. Les tâches les plus communément effectuées et les détails apparemment sans importance, comme le placement du travail ou l'existence de mystérieux bouts de papier, sont souvent oubliés ou omis parce qu'ils ne font pas officiellement partie du processus en cours.)

Intégration à la conception

Les tâches d'utilisation doivent être effectuées en parallèle et très tôt dans le développement. Les tâches doivent comprendre l'esquisse de l'interface utilisateur et les projets de guides de l'utilisateur et de l'aide en ligne. Gould a également indiqué que la convivialité devrait être la responsabilité d'un groupe.  

La caractéristique importante de la conception intégrée est que l'approche globale, l'infrastructure, pour une conception détaillée de l'interface utilisateur est développée et testée de manière précoce. C'est là une importante différence entre la conception centrée sur l'utilisateur et les autres techniques purement incrémentielles. Elle garantit que la conception incrémentielle réalisée durant les phases ultérieures s'adapte d'une manière transparente à l'infrastructure et que l'interface utilisateur est cohérente dans son apparence, sa terminologie et son concept.

Dans le processus RUP, cette infrastructure peut être établie en utilisant un modèle de domaine pour s'assurer que toute la terminologie et tous les concepts qui apparaîtront dans l'interface utilisateur sont connus et compris dans le métier en général et par les utilisateurs en particulier. (Il y aura également des sous-ensembles du modèle de domaine qui ne sont pertinents que pour des groupes spécifiques d'utilisateurs. Une attention toute particulière doit être portée pour que le modèle de domaine soit organisé de manière à ce que ces sous-ensembles soient facilement identifiés.) Avec la progression de la conception de l'interface utilisateur, plusieurs classes de domaine seront représentées comme éléments de l'interface utilisateur. Les éléments d'interface utilisateur et leurs relations doivent être cohérents avec le modèle de domaine et doivent être représentés d'une manière homogène à travers toutes les parties du système en cours de conception. (Ceci afin d'aider les utilisateurs, mais également d'améliorer la réutilisation des composants de l'interface utilisateur.)

Test utilisateur précoce

Des tests utilisateur précoces se traduisent par la création de storyboards très tôt dans le processus et par le développement précoce de prototypes généraux. Des prototypes détaillés suivront ultérieurement en cours de processus.

Des storyboards peuvent être utilisés en conjonction avec les cas d'utilisation pour rédiger des scénarios concrets d'utilisation du système en cours de conception. Ceci peut prendre une forme narrative, narrative illustrée (en utilisant les maquettes de l'interface utilisateur pour l'illustrer), ou bien prendre la forme de storyboards, de visites guidées (avec des utilisateurs), et de groupes de concentration sur l'utilisateur, qui sont des approches inhabituelles pour de nombreux développeurs de logiciels. Toutefois, elles sont de toute évidence plus rentables que le risque de découvrir qu'une conception est inappropriée ou que des exigences ont été mal comprises, en cours d'implémentation.

Conception par itération

Le développement orienté objet est devenu synonyme de processus itératif. La conception par itération est bien appropriée à des problèmes nécessitant un affinement de la compréhension et ayant des exigences changeantes. Il n'est donc pas surprenant que la conception par itération soit un composant essentiel de la conception centrée sur l'utilisateur. Ceci est partiellement dû aux changements des besoins des utilisateurs à travers le temps, et également à la complexité inhérente à la production de solutions de conception répondant à des besoins divers.

Notez que pour une méthode centrée sur l'utilisateur, la conception itérative se fait dans le cadre d'une structure intégrée. Nous avons délibérément évité le développement incrémentiel, en dehors d'une infrastructure établie, et pouvant conduire à une solution "mosaïque".

Pourquoi opter pour une conception centrée sur l'utilisateur ?

Répondre aux besoins de l'utilisateur

Les systèmes itératifs reposent sur leur capacité à intégrer les besoins des utilisateurs pour réussir. Ceci signifie non seulement l'identification des diverses communautés d'utilisateurs, mais également la reconnaissance de l'ensemble des compétences, des expériences et des préférences des utilisateurs individuels.

Alors qu'il est tentant pour les développeurs et les responsables de penser qu'ils comprennent les besoins des utilisateurs, ceci est rarement le cas en pratique. L'attention est souvent portée sur la manière dont les utilisateurs devraient effectuer les tâches plutôt que sur la manière dont ils préféreraient les réaliser. Dans de nombreux cas, le problème de la préférence est bien plus que le simple fait de sentir la maîtrise, même si ce fait est un problème en lui-même. La préférence sera également déterminée par l'expérience, la capacité et le contexte d'utilisation. Ces questions sont considérées suffisamment importantes dans le processus de conception pour garantir la conformité à la norme internationale, [ISO 13407], processus de conception centrés sur l'homme pour les systèmes interactifs. La norme et les questions annexes à la norme sont traitées d'une façon générale ci-après.

Conception de l'interface utilisateur

Les utilisateurs appréhendent un système et interagissent avec lui à travers son interface utilisateur. Les concepts, les images et la terminologie présentés dans l'interface doivent correspondre aux besoins de l'utilisateur. Par exemple, un système qui permet aux clients d'acheter leurs propres billets serait bien différent d'un système professionnel utilisé par le personnel de vente de billets. Les différences principales ne résident pas dans les exigences ou même dans les cas d'utilisation détaillés, mais dans les caractéristiques des utilisateurs et les environnements dans lesquels le système peut fonctionner.

L'interface utilisateur doit également tenir compte d'une large variété d'expériences, comportant au moins deux dimensions, l'informatique et le domaine, comme indiqué dans la figure 1 ci-dessous. L'expérience en informatique comprend non seulement les connaissances générales de l'ordinateur, mais également du système en cours de développement. Les utilisateurs ayant peu d'expérience soit dans l'informatique, soit dans le domaine, représentés dans le coin gauche de la figure, auront besoin d'une approche radicalement différente de l'interface utilisateur que celle des utilisateurs experts, représentés dans le coin droit.

Diagramme décrit dans le texte d'accompagnement.

Figure 1 : Effets de l'expérience relative à informatique et au domaine sur la facilité d'apprentissage par rapport à la facilité d'utilisation

Gardez-vous bien de conclure que les utilisateurs inexpérimentés deviendront experts avec le temps. Un certain nombre de facteurs peuvent se liguer contre cette issue favorable, comme la faible fréquence d'utilisation, la faible motivation ou la grande complexité. Inversement, certains systèmes peuvent avoir une prédominance d'utilisateurs experts. Les facteurs qui agissent ici peuvent être la formation, la fréquence d'utilisation élevée ou la grande motivation (dépendance professionnelle). Certains de ces points, avec leurs effets sur la conception de l'interface utilisateur, sont présentés dans le tableau 1.

 

Relativement faible

Relativement élevée

Expérience informatique

Simple question-réponse, simple remplissage de formulaire, style d'interface Web (liens hypertexte) ou style d'interface par menus

Remplissage de formulaires complexes, style d'interface Web (liens hypertexte) ou par menus (des questions-réponses ou des formulaires simples seraient très frustrants pour des utilisateurs expérimentés)

Expérience dans le domaine

Terminologie et concepts courants

Terminologie et concepts spécifiques au domaine

Formation

Concentration sur la facilité d'apprentissage (cohérence, prévisibilité, mémorisation facile)

Concentration sur la facilité d'utilisation (directe, personnalisable, non intrusive)

Fréquence d'utilisation

Facile à apprendre et à se rappeler, style d'interface simple

Facile à utiliser, plusieurs raccourcis et techniques permettant le contrôle par l'utilisateur

Motivation

Facile à utiliser, puissant sans paraître complexe.

Elaboré, avec plusieurs fonctionnalités avancées et personnalisables.


Tableau 1, Quelques facteurs affectant la conception de l'interface utilisateur

Les systèmes interactifs doivent être conçus pour intégrer une gamme appropriée d'expériences utilisateur et de circonstances, ou bien des dispositions doivent être prises pour restreindre le champ de la conception. A titre d'exemple, la formation peut être utilisée pour réduire l'exigence de la facilité d'apprentissage pour un système complexe. L'autre alternative consisterait à réduire le champ du système pour qu'il réponde mieux aux exigences de base de ses utilisateurs (suggestion faite par Alan Cooper dans son livre The Inmates Are Running the Asylum [COO99]).

Législation et normes

Dans le cadre de la conception centrée sur l'utilisateur, nous aurons besoin de considérer les compétences et les attributs physiques des utilisateurs. Ces points sont de plus en plus intégrés à la législation. Il s'agit surtout de faciliter l'accessibilité pour les utilisateurs handicapés. Rendre les systèmes accessibles à une large gamme d'utilisateurs est généralement bénéfique à la communauté des utilisateurs dans son ensemble.

Le tableau ci-après présente la législation et les ressources pertinentes pour de nombreuses zones géographiques :

Description Site Web

AUSTRALIE

 
Disability Discrimination Act (Loi sur la discrimination à l'encontre des handicapés) http://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm
Droits des handicapés http://www.hreoc.gov.au/disability_rights/index.html

EUROPE

 
Forum européen des personnes handicapées http://www.edf.unicall.be

ROYAUME-UNI

 
Disability Discrimination Act (Loi sur la discrimination à l'encontre des handicapés) http://www.hmso.gov.uk/acts/acts1995/1995050.htm
New Deal for Disabled People (Nouvelle chance pour les personnes handicapées) http://www.disability.gov.uk
Digital Access Campaign (Campagne d'accès à l'informatique) http://www.rnib.org.uk/digital/welcome.htm

NATIONS UNIES

 
Règles standard des Nations Unies pour l'égalité des chances en faveur des personnes handicapées http://www.un.org/esa/socdev/enable/dissre00.htm
Informations sur le développement social sur Internet http://www.unescap.org/esid/psis/disability/index.asp

ETATS UNIS

 
Americans with Disabilities Act (ADA): US Department of Justice (Loi sur les américains handicapés) : Ministère de la justice) http://www.usdoj.gov/crt/ada/
Section 508 of the Workforce Investment Act: US Department of Justice (Section 508 de la loi sur l'investissement humain : Ministère de la justice) http://www.usdoj.gov/crt/508/508home.html 
US Access Board Electronic and Information Technology Advisory Committee (EITAAC) (Comité consultatif pour la technologie de l'informatique et de l'électronique auprès du conseil américain de l'accès) http://www.access-board.gov 
World Wide Web Consortium Web Accessibility Campaign (Campagne d'accès au Web du consortium World Wide Web) http://www.w3.org/wai/ 

AUTRES RESSOURCES

 
Ressources Internet relatives aux handicapés http://www.disabilityresources.org

 Tableau 2a, Législation relative aux handicaps par pays, par région ou par organisme

Législation mise à part, la conception centrée sur l'utilisateur et la conception des interfaces utilisateur font de plus en plus l'objet d'une normalisation, comme indiqué ci-après.

Description Site Web/Normes

ANSI

www.ansi.org

ANSI

ANSI-HFES

ANSI-NSC

L'ANSI et l'organisme Human Factors and Ergonomics Society ont publié un certain nombre de normes communes. L'ANSI a également la norme ANSI-NSC Z365 qui se rapporte au contrôle et à la prévention des troubles liés au stress cumulé (également connus sous le nom d'atteinte par sollicitation répétitive ou RSI).

L'ANSI élabore également des normes concernant l'interaction homme-machine, dans le cadre du panel des normes de l'infrastructure informatique (IISP).

ISO

www.iso.ch
ISO 9241 Vaste série de normes traitant essentiellement de l'ergonomie des stations de travail, mais comprenant également des lignes directrices pour la convivialité (partie 11). Ces normes sont à la base des normes ANSI-HFES 200, en cours de développement.
ISO 10075: 1991 Principes d'ergonomie concernant le travail intellectuel
ISO 17041-1 : 1995 Contrôle du curseur dans l'édition de texte
ISO 11581 Série en cours de développement traitant des icônes et des pointeurs.
ISO 13407 : 1999 Normes pour les processus de conception centrée sur l'homme pour les systèmes interactifs.

 Tableau 2b, Normes ANSI et ISO concernant la conception des interfaces utilisateur et la conception centrée sur l'utilisateur

La conception centrée sur l'utilisateur dans le processus RUP

Le développement de systèmes adaptés aux besoins de l'utilisateur implique un effort important dans l'analyse des exigences. Dans la conception centrée sur l'utilisateur, cet effort est concentré sur les utilisateurs.

La modélisation métier couvre la modélisation des travailleurs métier (au sein de l'entreprise) et celle des acteurs métier (à l'extérieur de l'entreprise).

Toutefois, le point le plus important dans la conception centrée sur l'utilisateur réside dans la compréhension des exigences des personnes réelles qui rempliront les rôles décrits dans les produits mentionnés ci-dessus. En particulier, il faut éviter de sombrer dans la facilité qui consiste à concevoir un système pour des personnes hypothétiques. Les produits décrivant les utilisateurs ne doivent être rédigés qu'après un contact approfondi et sur place avec les utilisateurs. Dans la conception centrée sur l'utilisateur, ce contact sur place constitue une partie d'un processus parfois appelé enquête contextuelle. Hugh Beyer et Karen Holtzblatt (dans leur livre intitulé Contextual Design, [BEY98]) décrivent les prémisses de l'enquête contextuelle comme étant :

"...d'aller où travaille le client, d'observer le client au travail et de parler au client au sujet du travail."

(Quelques exemples concrets ont déjà été énumérés sous Concentration sur les utilisateurs.) Cette approche est utilisée non seulement pour avoir une meilleure compréhension des exigences du système, mais également des utilisateurs eux-mêmes, de leurs tâches et de leurs environnements. Chacun a ses propres attributs et, pris ensemble, ils correspondant au contexte d'utilisation. Ils sont détaillés dans la norme ISO relative à la conception centrée sur l'utilisateur, décrite ci-après.

Contextes d'utilisation

La norme ISO sur les processus de conception centrée sur l'Homme pour les systèmes interactifs [ISO13407] identifie la première étape de la conception comme étant la compréhension et la spécification du contexte d'utilisation. Les attributs proposés sont :

Contexte Attributs

Tâches

Objectifs de l'utilisation du système, fréquence et durée des performances, considérations de santé et de sécurité, affectation des activités et étapes opérationnelles entre les ressources humaines et technologiques. Les tâches ne doivent pas être décrites uniquement en termes de fonctions ou fonctionnalités offertes par un produit ou système.

Utilisateurs (pour chaque type ou rôle différent)

Connaissances, compétences, expérience, niveau d'études, formation, attributs physiques, habitudes, préférences, capacités.

Environnements

Matériel, logiciels, supports, environnements matériel et social, normes pertinentes, environnement technique, environnement ambiant, environnement législatif, environnements social et culturel


Tableau 3 : Contexte d'utilisation dans la norme ISO pour la conception centrée sur l'utilisateur

Il serait utile de diviser le contexte de l'utilisateur en ses deux parties constitutives (type d'utilisateur et rôle de l'utilisateur) puis de considérer les relations entre les quatre contextes :

Diagramme décrit dans le texte d'accompagnement.

Figure 2 : Relations entre les contextes

La figure 2 montre que chaque tâche est effectuée dans un rôle accompli par un utilisateur dans un environnement donné. Ces contextes correspondent aux produits RUP comme indiqué dans le tableau 4.

Contexte ISO 13407 Produits RUP

Environnements

Utilisateurs

Rôles

  • Haut niveau :
    • Acteur métier (utilisateurs externes) 
    • Travailleur métier ou système métier (utilisateurs internes)
  • Détails :

Tâches


 Tableau 4, Contextes de la norme ISO sur la conception centrée sur l'utilisateur et produits RUP associés

Chacun de ces contextes peut avoir un impact significatif sur la conception de l'interface utilisateur appropriée. Par conséquent, nous nous trouvons face à un nombre potentiellement important de permutations. Même pour un petit système, il peut y avoir 2 environnements (bureau et site client), 3 types d'utilisateurs (débutant en vente, expert en vente et direction) et 6 rôles (assistant de vente par téléphone, représentants commerciaux externes, etc.). Ce qui signifie jusqu'à 36 variations potentielles par tâche, même si le nombre de combinaisons réalistes est habituellement beaucoup plus limité.

En clair, les tâches doivent être décrites individuellement, mais une seule description ne conviendra pas pour toutes les permutations. Une des approches consiste à prendre en compte les contextes de l'utilisateur et de l'environnement dans la description des rôles. C'est la solution adoptée par Constantine et Lockwood [CON99]. Elle implique la proposition d'un "rôle utilisateur" séparé pour chaque permutation significative de rôle, utilisateur et environnement, puis de nommer le rôle utilisateur qui en résulte par une phrase descriptive, plutôt que par un simple nom. Comparez par exemple le rôle "Client" aux rôles utilisateur "Client occasionnel", "Client Web", "Client régulier" et "Client avancé".

Chaque description de rôle utilisateur comprend les détails du rôle lui-même, plus ses utilisateurs (désignés par titulaires du rôle) et l'environnement. Cette approche peut être adoptée dans le processus RUP en choisissant les acteurs qui correspondent aux rôles utilisateur.

Scénarios, cas d'utilisation et cas d'utilisation essentiels

Les termes scénarios, cas d'utilisation et cas d'utilisation essentiels présentent un degré de chevauchement déroutant et sont utilisés dans différentes approches de conception pour signifier des choses légèrement différentes. Dans le processus RUP par exemple, "scénario" signifie une instance de cas d'utilisation (un chemin spécifique à travers les flux de base et alternatifs possibles). Toutefois, il est commun de trouver des méthodes de conception centrées sur l'utilisateur et de conception de l'interface utilisateur décrivant les scénarios comme étant des descriptifs d'utilisation, contenant beaucoup plus de détails que le simple flux des événements. Tout en étant non pertinentes dans les phases ultérieures de la conception, ces informations supplémentaires font partie de la compréhension des utilisateurs, des tâches et des environnements. Par conséquent, les scénarios peuvent être utilisés de manière extensive (dans des storyboards ou des jeux de rôle) dans la discipline de modélisation métier. En revanche, dans la discipline Exigences, on s'intéresse davantage aux cas d'utilisation.

La figure 3 montre la nature de ce chevauchement. L'échelle du haut intègre un certain nombre de facteurs différents qui tendent à varier ensemble. Par exemple, au fur et à mesure que l'objet se déplace plus vers les exigences, la structure devient habituellement plus formelle. Les cas d'utilisation essentiels apparaissent à droite des cas d'utilisation génériques parce que les rôles utilisateur les rendent légèrement plus spécifiques (voir la section précédente) et ils présentent une structure plus formelle.

Diagramme décrit dans le texte d'accompagnement.

Figure 3 : Chevauchement des concepts entre scénarios et cas d'utilisation dans la conception centrée sur l'utilisateur

Les différences entre les cas d'utilisation système et les cas d'utilisation essentiels sont mieux illustrées par l'exemple.  Le tableau 5 montre un cas d'utilisation provenant de "Software for Use", de Constantine et Lockwood [CON99]:

Action utilisateur Réponse système
insérer une carte lecture de la bande magnétique
demande de code personnel
saisir le code personnel vérification du code personnel
affichage du menu des options de transaction
appuyer sur une touche affichage du menu compte
appuyer sur une touche invite pour le montant
saisir le montant affichage du montant
appuyer sur une touche restitution de la carte
retirer la carte délivrer les billets
prendre les billets  

Tableau 5 : Cas d'utilisation générique pour le retrait d'argent dans un distributeur automatique

Cet exemple détaille la séquence d'événements entre l'acteur et le système, avec la ligne verticale entre les deux colonnes représentant l'interface utilisateur. Notez qu'alors que Constantine et Lockwood recommandent ce style pour les cas d'utilisation essentiels, ce cas d'utilisation particulier n'est pas un cas essentiel. La raison en est qu'il est basé sur un détail syntaxique de l'interaction. C'est-à-dire sur la manière dont l'interaction se déroule. Un cas d'utilisation essentiel est centré sur l'objet de l'interaction (appelé la sémantique). Le tableau 6 représente la version essentielle de l'interaction.

Intention de l'utilisateur Responsabilité du système
s'identifier vérifier identité
présenter les choix
choisir délivrer les billets
prendre les billets  

Tableau 6 : Cas d'utilisation essentiel pour le retrait d'argent dans un distributeur automatique

Ce cas d'utilisation capture l'essence de l'interaction de retrait d'argent. Les en-têtes Action de l'utilisateur et Réponse du système ont été remplacés par Intention de l'utilisateur et Responsabilité du système, pour refléter le changement du centre d'intérêt. Une bonne conception de l'interface est centrée sur les objectifs et les intentions de l'utilisateur ; souvent cachés dans les cas d'utilisation conventionnels. Les cas d'utilisation essentiels sont particulièrement utiles dans les situations suivantes :

  • il y a peu de contraintes de conception (si par exemple la contrainte de conception implicite concernant l'utilisation de cartes bancaires est fausse)
  • le système peut être amélioré pour utiliser d'autres moyens d'identification (tel qu'un accès Internet sécurisé)
  • il y a un désir de créer des cas d'utilisation sans contraintes de conception, pour une éventuelle réutilisation dans des projets dénués de ces contraintes.

Les cas d'utilisation essentiels ont toutefois leurs inconvénients. Les cas d'utilisation parfaitement rectilignes, comme celui présenté dans le tableau 5, peuvent donner lieu à un important débat lorsqu'il s'agit de distiller leur essence. Par exemple, est-ce que l'insertion d'une carte identifie le client ou le compte ? Dans la plupart des distributeurs, c'est le compte qui est identifié, même si Constantine et Lockwood ont choisi d'interpréter ceci comme étant une identification du client. Ceci a pu être une décision délibérée à la lumière des technologies les plus récentes, comme le balayage de la rétine et l'identification par les empreintes digitales, ou a pu être une erreur. La conséquence dans ce cas, c'est que les clients qui ont plusieurs comptes auront à faire un choix supplémentaire.

L'autre difficulté est que les cas d'utilisation essentiels ne sont pas adaptés à une revue avec les utilisateurs et autres parties prenantes en raison de leur nature abstraite. Pour une part, ce problème réside dans l'obligation de retraduire les cas d'utilisation en une forme concrète représentant les actions de l'utilisateur. Une fois le modèle de conception disponible, ceci peut être fait par la rédaction de scénarios décrivant l'interaction en termes concrets (similaire dans leur concept à la réalisation du cas d'utilisation, même s'ils portent plus sur l'interaction utilisateur-système que sur la collaboration des objets internes).

En résumé, la création de cas d'utilisation essentiels n'est pas adaptée aux situations suivantes :

  • les technologies d'interface utilisateur sont intentionnellement hautement contraignantes (par exemple, le système doit accepter les cartes bancaires)
  • le temps nécessaire à l'utilisateur pour comprendre des cas d'utilisation plus abstraits est compensé par les avantages escomptés.

Cas d'utilisation essentiels dans le processus RUP

Le processus RUP ne se réfère pas explicitement aux cas d'utilisation essentiels, mais dans Activité : Concevoir l'interface utilisateur, les cas d'utilisation essentiels sont considérés comme point de départ, puis développés et complétés avec les exigences de convivialité pour créer des storyboards, comme expliqué dans Instructions : Storyboard.  

Ceci signifie la suppression de tout le détail de la conception ou de l'implémentation courante de manière à ce que seule la sémantique, la signification de l'interaction, demeure. Puis, au fur et à mesure de l'exploration de diverses alternatives de conception, le détail sémantique (comment l'interaction se déroule) est ajouté au cas d'utilisation essentiel, sous forme de type de réalisation.  (Chaque conception alternative est en effet une réalisation du même cas d'utilisation essentiel.)

Les storyboards peuvent alors être utilisés comme entrée pour Activité : Prototyper l'interface utilisateur afin de développer le prototype de l'interface utilisateur.