Posté par jc-QualityStreet le 26 février 2008
Le design d’interface, à l’instar du processus de développement qui l’englobe, ne peut être qu’itératif.
Plus qu’un constat, une réalité, à laquelle nous sommes confrontés tous les jours.
En effet, faire du design d’interface:
- C’est prendre le temps d’envisager plusieurs possibilités, plusieurs solutions, pour aboutir à la solution finale (souvent mélange des précédentes ou fruit d’un compromis). Que toutes ces solutions, ces essais soient parfaits est évidemment impensable !
- C’est aussi accepter que les besoins de nos clients, utilisateurs évoluent, le plus souvent en réaction à ce que nous proposons. Il est illusoire en effet de croire que nos interlocuteurs savent précisément ce qu’il veulent au tout début d’un projet.
- C’est enfin s’appuyer sur les autres et aller chercher le feedback pour comprendre, avancer, simplifier, améliorer les interfaces qu’on propose. La première interface est rarement la bonne.
Autrement dit, collaboration, feedback et contrôle du changement sont devenus des dimensions clés de nos métiers; des éléments qui ont du mal à s’exprimer dans des cadres trop rigides (tout est dans la mesure) ou trop cloisonnés…
Quand j’ai découvert les Méthodes Agiles il y a quelques années, j’ai immédiatement accroché la dessus … feedback (recherché, intégré … permanent), collaboration amplifiée, acceptation du changement, tous trois placés au centre des débats, identifiés dans plusieurs bonnes pratiques et “institués en tant que principes de base. Waou !!!
Il est clair que l’ergonomie, le design d’interface peuvent trouver dans l’agilité (XP, SCRUM, OpenUP) des leviers inespérés, alors pourquoi dans la pratique, design d’interface et Agilité ont-ils tant dans de mal à cohabiter !
Comment y remédier ?
Quelques éléments de réponse dans mon manifeste pour une ergonomie Agile…
Posté par jc-QualityStreet le 22 février 2008
L’un des premiers bénéfices des Personas est de proposer une vision partagée des Utilisateurs, mais les Personas permettent aussi d’orienter fondamentalement les choix d’interface…
Et c’est justement à ce niveau que l’Ergonomie Incitative (c’est à dire l’art de susciter un comportement, un désir) peut admirablement compléter, s’appuyer et appuyer, ainsi que prolonger la démarche engagée avec les Personas.
Quelques exemples:
ZYLOM

2 personas : Maria et Sophie dont les buts principaux sont de jouer en ligne, de récupérer une version du jeu pour pouvoir jouer offline et d’obtenir de l’aide si elles en ont besoin.
Impact sur le design d’interface : couleur, forme, taille, positionnement, agencement, structure de la barre de navigation
VISTAPRINT

2 personas : Nancy qui veut un site de confiance et un site où il lui est facile de créer ses outils marketing et Howard qui veut créer ses produits marketing le plus vite possible.
Impact sur le Design d’interface : Côté Nancy, couleur, forme, typographie, positionnement, promesse, visuel d’une personne pour se différentier et pour rassurer; côté Howard, une proposition structurée, une vue globale mais accessible, synthétique et visuelle de l’offre.
Les deux techniques, Personas et Ergonomie Incitative, sont trés complémentaires et toutes deux orientées buts / tâches: leur combinaison est donc plutôt efficace, quel que soit le degré d’incitation envisagé (fort, partiel ou par petites touches sur quelques éléments bien ciblés).
BANKWEST

MICROPLACE

Imaginons…
Vous avez 2 personas principaux dont vous devez satisfaire impérativement et en priorité les buts.
Votre démarche Persona, votre réflexion centrée buts et utilisateurs vous permettent d’identifier:
- leurs buts principaux
- ce qui va déclencher leurs actions
- ce qui peut les influencer
- ce qui peut les freiner ou les faire fuir
- ce qui peut constituer la bonne surprise…
Vous disposez dés lors des éléments nécessaires pour construire une bonne ergonomie incitative source d’efficacité et d’efficience, et pouvez jouer sur les leviers “incitatifs” les plus pertinents dans votre contexte:
- le positionnement, l’orientation,
- la surface, la taille
- la forme
- les accroches, promesses, mots clés, phrases clés,
- les visuels (notamment “humains” car suscitant plus facilement l’identification)
- les couleurs et effets (caractère chaud / froid, saturation, luminosité, contraste …)
- la typographie
- …
En somme, vos personas vous permettent:
- de définir quel comportement inciter
- d’identifier quels éléments de l’interface mettre en avant (ou au contraire masquer)
- et sur quoi s’appuyer pour susciter l’envie.
Ils vont guider vos choix de conception, à la fois sur la page d’accueil de votre service, tout au long d’un parcours Persona bien défini et sur les divers points d’entrée potentiels, pour au final maximiser l’efficience et assurer une fabuleuse expérience Utilisateur.
Cette pratique est résolument orientée Buts Utilisateurs … Les satisfaire, c’est pour beaucoup satisfaire ses propres objectifs business (susciter l’achat, l’adhésion), même si parfois, en fonction des contextes de communication, des arbitrages seront à réaliser sur le degré d’incitation souhaité.
Évidemment, l’ergonomie incitative n’a pas attendu les Personas pour peaufiner ses techniques, et se rendre indispensable dans l’univers Web actuel…
Voici donc pour terminer un petit “avant / aprés” au niveau des “boutons” d’action (appel à l’action typique) et quelques exemples de bonnes pratiques en la matière:
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 4 février 2008
Bon, il faut dire que je pourrais vous parler des personas pendant des heures: du pourquoi, du comment, des données, de la façon de les construire (sources, variables, catégorisation, assimilation), de les utiliser, des informations qui les composent et … du caractère essentiel du scénario (dire qu’avant je n’en rédigeais pas !).
STOP, Arrêtez-moi !
Mais cette fois, je voudrais seulement souligner à quel point les personas, sur certains projets, peuvent vraiment changer la donne, notamment dans le travail quotidien de l’Ergonome, ou du Designer d’interface.
Regardez mon cas:
- Avant : J’utilisais les “Profils Utilisateurs” (dans le cadre ou non d”une ISO 13407) pour décrire les utilisateurs sur mes projets de conception d’application … et croyez-le ou pas, ça n’intéressait pas grand monde
Ces profils résumaient pourtant les responsabilités, les tâches et décrivaient les classes d’utilisateurs en termes de données démographiques, comportementales, géographiques et psychologiques, sans éléments fictifs, sans scénario … Evidemment entretiens, questionnaires, tests utilisateurs ou doc. divers me servaient pour les établir. Mais au final, rien n’y faisait ; quand j’avais le temps de les faire (…), ça ne suscitait pas un engouement démesuré!
- Aujourd’hui : J’utilise les Personas pour décrire les utilisateurs cibles du produit à concevoir, et là ça n’a rien à voir. Ils sont au centre de toutes les conversations, on se les arracherait presque !
Les différences: la démarche de construction, plus transparente et plus collaborative, le format de restitution, la précision, ce côté spécifique (ce n’est plus “80% de femme”, “entre 25 et 35 ans”, c’est Sophie, 34 ans).
Ce qui change aussi : le visage humain, l’émotion que les personas suscitent, et le SCENARIO. En effet, même si les personas se fondent sur les même données, ils ont un vrai point fort le STORY TELLING, point fort… car les gens adorent raconter et entendre des histoires !.
Bref, croyez-moi, les Personas mobilisent les foules !!
De cette mobilisation naît le focus sur leurs buts et ce qui les distinguent !
Et là c’est déjà presque gagné… il vous suffit ensuite de valider vos personas, de les confronter sans cesse à votre interface (ce fil rouge dont je parlais) et d’impliquer de vrais utilisateurs en leur faisant évaluer régulièrement vos réalisations.
Pour ce dernier point, appuyez-vous sur les méthodes Agiles; voilà la boucle est bouclée !!
Posté par jc-QualityStreet le 30 janvier 2008
Le débat sur les personas resurgit depuis quelques mois, pour preuve ce dernier billet d’Eric-Superfiction, celui de Mathieu Collet ou mes propres billets “Quelles données pour vos personas” ou “Personas : mon retour d’expérience”.
Jamais une technique de conception centrée utilisateur n’aura suscité de manière récurrente autant de polémique (notamment chez nos amis anglo-saxons), d’émotions et d’interrogations, car pour beaucoup d’acteurs, la construction des personas relève du mystère voire du mythe !
Rappelons au passage que les PERSONAS, tels qu’on les entend, datent de 1999 (et oui déjà !), plus exactement du livre “The Inmates Are Running the Asylum” , le best seller d’Alan Cooper, même si des concepts très proches (ancêtres des personas), notamment les Profil Utilisateurs et les Scénarios sont apparus dans les années 80.
Les personas nécessitent donc selon moi une démarche CONSTRUITE mais toujours AJUSTEE en fonction des objectifs que l’on se fixe, des bénéfices que l’on attend, de l’application à concevoir, des données disponibles et du temps dont on dispose (car oui on peut bel et bien envisager de vrais personas dans un timing serré, et dans le cadre des méthodes Agiles).
Seulement PRUDENCE ! comme toute technique, celle des personas peut vous amener droit dans le mur. Voilà donc quelques lignes décrivant les principales causes d’échec d’une approche “Personas”:
- Pas de soutien, pas de support de la part des décisionnaires (c’est banal)
- Personas non crédibles et pas construits avec rigueur (vous me suivez …)
- Personas mal communiqués
- Personas pas ou mal utilisés par les équipes
- Pas de construction progressive, exploratoire
- Absence de réflexion orientée BUT
Mon challenge en tant que consultant est de mettre en garde contre ces dérives potentielles, de les éviter et de faire comprendre à mes interlocuteurs que le temps qu’on va passer sur nos Personas (notamment préparation et création) va valoir le coup !!!
Croyez-moi, les bénéfices sont réels : j’ai donc pas mal d’arguments… qui viennent alimenter ma démarche.
Posté par jc-QualityStreet le 17 janvier 2008
Je vous ai déjà parlé des personas au travers de mon retour d’expérience. Je vous les ai présenté comme un outil très performant notamment pour comprendre les utilisateurs et leurs buts, et pour guider les choix de conception.
Toutefois, une question revient régulièrement chez mes interlocuteurs: à partir de quelles sources, les personas se construisent-ils?
Ma réponse est sans ambiguïté : la construction des personas se fonde avant tout sur des données qualitatives issues de l’observation et d’entretiens réalisés auprès des utilisateurs (une bonne douzaine minimum, mais c’est évidemment très variable), en interne ou en externe (car de nombreuses et diverses sources externes sont disponibles et exploitables).
Alors, même si une approche quantitative (effectuée sur un très grand nombre d’utilisateurs à partir de questionnaires ou d’outils analytiques …) peut appuyer cette construction, crédibiliser l’approche vis à vis de certains ou valider certaines orientations, l’approche qualitative est la base, le minimum et ce qui va déterminer la suite des opérations. Évidemment, cela nécessite du temps, de l’énergie, de la technique.
On peut donc selon moi, dans une certaine mesure, se passer de données quantitatives, en revanche on ne pourra jamais faire sans, on a besoin obligatoirement des techniques qualitatives pour s’immerger dans l’univers des utilisateurs, et pour savoir:
- Quels sont leurs buts ?
- Quelles sont les tâches et activités associées, leur fréquence, leur durée, leur importance … les actions nécessaires pour atteindre leurs buts ?
- Qu’est ce qui déclenche leurs actions ?
- Comment les utilisateurs interagissent-ils les uns avec les autres, et avec les produits existants ?
- Qu’est ce qu’ils aiment et n’aiment pas ?
- Quel est l’environnement dans lequel ils évoluent ?
- Quels traits de personnalité ont-ils en commun ?
- Quels sont les influences ? les facteurs de décision ? les attentes ?
… en somme, tous ces éléments qui vont nous permettre de différencier et de construire efficacement vos personas. Bon au cas où vous ne l’auriez pas compris, les personas (les vrais), ça me plait …