Aluku Kusouka - Utilisateur

Holoptisme : les documents de design, esperanto des projets web ?

Oric — Fri, 03 Apr 2009 00:53:00 +0200

Depuis quelques temps, la question des livrables, en particulier les documents de design tel que les personas, les plans de site ou les wireframes, devient de plus en plus pertinente, quand il s'agit de faire communiquer et converger les différents métiers du web en un tout cohérent, un projet, un site web.

C'est par le biais d'un billet d'Elie Sloïm, que je viens de découvrir le terme "holoptisme" via l'interview en vidéo Jean-François Noubel : "C'est quoi l'Holoptisme ?" (Expérience à Paris le 12 juin 2009)

[...Dans le cadre d'un groupe, une équipe] en holoptisme, on est à la fois en souveraineté individuel, on est soit même, on est complètement unique, dans notre zone d'expertise, qui est unique, et en même temps on sert le tout. C'est à dire qu'il n'y a pas de contradiction entre le collectif et l'individuel.

Je sais quoi faire. Je peux être en création, je peux être en réaction. Je peux être moi même et en même je sais quoi faire parce que j ai accès au tout et le tout se configure en fonction de qui nous sommes les uns les autres dans notre souveraineté [...]

Dans le même temps, Jean François Noubel lui oppose le panoptisme.

Ce terme, désigne les organisations pyramidales, un peu à l'image de "Big Brother", source de contradictions, d'opposition entre l'intérêt individuel et l'intérêt collectif, majoritairement vécu dans les équipes projet, car chaque strate n'a qu'une vision partielle de l'ensemble.

Ainsi, dans ce contexte de groupe, on distingue deux paramètres : la direction collective et les moyens collectifs.

Replacé dans le contexte d'un projet de site web, en me référent à la déclinaison des documents de design proposé par Dan Brown dans "Developing Web Site Documentation for Design and Planning", on peut alors définir ces documents comme le langage de l'holoptisme qui permet à chaque participant de s'exprimer dans sa zone d'expertise et en même temps dans l'intérêt collectif.

User Needs Documents
- Personas
- Usability Test Plans
- Usability Reports
Strategy Documents
- Competitive Analyses
- Concept Models
- Content Inventories
Design Documents
- Site Maps
- User Flows
- Wireframes
- Screen Designs

Feedback Forum : dîtes le !

Oric — Mon, 26 Jan 2009 01:01:00 +0100

Vous aurez peut être remarqué ce petit onglet "Feedback" sur le côté de l'écran.

Il s'agit d'un service en ligne que j'ai découvert récemment : Feedback Forum

Le principe est simple : vous, utilisateurs, donnez un feedback sur, par exemple, mon blog et ce feedback est noté par tous les autres utilisateurs. Des feedbacks vont alors ressortir du lot et trouver leur pertinance. Alors je (le propriétaire du feedback forum) donne à chaque feedback un status qui vous indique où en est sa prise en charge.

Pour cela, cliquez sur l'onglet "Feedback" de ce blog et soit votez directement pour les feedbacks proposés, soit ajoutez le vôtre en allant sur "Go to our feedback forum".
Par contre, je ne pense pas que la solution soit accessible...

Ca reste un bon concept pour mettre en valeur les besoins de vos utilisateurs, non ?

Paris Web 2008 - Internautes et robots des moteurs de recherche, mais comment font-ils pour s'y retrouver ?

Oric — Fri, 02 Jan 2009 17:08:00 +0100

Dans la liste des domaines qui se font connaître de plus en plus en matière de design, on trouve l'architecture de l'information.

Aujourd'hui on cite l'AI plus volontier dans les conversations mais à priori rare sont ceux capables de donner une définition claire de cette discipline interdisciplinaire qui se nourrie volontiers de sociologie, ethnologie, marketing, documentalisme...

Alix Lassaigne et Christophe Cotin-Valois tente d'illustrer le lien de plus en plus pertinant entre les l'architecture de l'information et la recherche liée aux moteurs de recherche, et son incidence sur le positionnement des marques par rapport à leurs clients.

Malheureusement, leur intervention manquait de rythme et d'assurance... Leur message s'est dillué dans les hésitations et les approximations... et pourtant, ils ont dit des choses intéressantes.

En résumé :

Le référencement permet l'accès au contenu. Pour cela il faut penser comme l'internaute
Le code HTML transporte des informations réelles
Identifier les contenus d'une marque et leur assigner des étiquettes, c'est définir le territoire de la marque et les services qui en découlent
Les pages avec trop d'informations rendent difficiles la navigation des internautes et sont difficiles à référencer
Dans l'organisation des contenus, un plan éditorial éditorial propose des parcours de navigation différents pour répondre à différents besoins, scénario de recherche de l'information etc...

Ce domaine, non technique, mérite amplement qu'on s'y intéresse car il est souvent négligé ou perçu comme la rustine qui redressera un projet mal conçu.

Pourtant, en s'intéressant à quels sont les contenus et comment ils sont organisés, c'est directement sur la performance du site que l'on va influer, car automatiquement on s'impliquera dans la définition d'une "marque" et sa "clientèle" qui sont uniques.

La vidéo de : Paris Web 2008 - Internautes et robots des moteurs de recherche, mais comment font-ils pour s'y retrouver ?

Jakob Nielsen : Bridging the Designer-User Gap

Oric — Wed, 08 Oct 2008 00:09:00 +0200

En essayant de rattrapper mon retard sur la lecture des articles de la newsletter de Jakob Nielsen, je suis tombé sur Bridging the Designer-User Gap (qui pourrait se traduire par "réduire le fossé entre l'utilisateur et le designer").

Summary:
Depending on how representative designers are of the target audience, a project might need more or less user testing. Still, usability concerns never go away completely.

En résumé, il décrit 3 cas qui induisent un espace allant de la petite faille à un gouffre entre utilisateur et designer lors du design d'un projet :

Le designer est l'utilisateur :
C'est le cas (le plus confortable) par exemple des projets open source designed by geeks, for geeks où le designer et l'utilisateur final partagent la même hyper-connaissance du domaine d'application. Pourtant, il lui faudra effectuer un minimum d'aller-retour pour recueillir des feedbacks et améliorer le design du projet initial.
Le designer comprend le produit :
L'article prend l'exemple du design d'un téléphone portable. Bien qu'il en utilise un lui même, le travail du designer sur un tel produit ne se résume pas à y intégrer sa seule expérience avec un téléphone portable. Il existe bien des utilisations que seule une série de tests utilisateur pertinents peut découvrir.
De plus, généralement, l'équipe de design est sur-compétente techniquement, ce qui l'empêche d'être impartiale dans la définition d'un produit qui doit toucher une audience non qualifiée.
Designer pour un domaine inconnu :
Le designer endosse le rôle du newbie et doit s'en remettre à l'expérience des experts d'un domaine qui lui est totalement inconnu. L'article suggère même le recrutement de personnes du métier pour découvrir comment elles travaillent, quelles sont leurs attentes etc... et travailler sur des prototypes papier pour tester les premières idées.

Dans tous les cas, on voit bien que le designer ne peut pas sortir un design de son chapeau magique. Il lui faut des données tangibles sur le produit et son environnement pour produire un design cohérent.
A méditer...