Accéder au contenu principal

UX Team Of One

La vidéo est visible ici : http://www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one?type=presentation

Un spécialiste de l'expérience utilisateur a actuellement des responsabilité multiples: analyse de la concurrence, recherche, architecture de l'information, design, tests d'utilisabilité, prototypage, documentation

La vidéo se concentre sur le design et donne un ensemble d'aide pour une "Equipe d'un seul". Ces aides sont réparties en trois parties :

1 Beaucoup de brainstorming
générer beaucoup d'idées puis les raffiner (schéma ci-dessous).

Utilisez des cadres conceptuels (spectres 1D, 2DS, grilles)
*

Exemple de spectre: la familiarité avec le site de débutant à expert



utiliser une bibliothèque d'inspiration (screengrab plug in pour Firefox)

2 Rassembler une équipe "ah hoc" même si ce ne sont pas des specialiste de l'UX
Il va falloir s'aider des gens autour de vous et tirer parti de leurs idées.
Utilisation de "scketchboards"
Ouvrir des sessions de conception libre et fun (pizza ! :) )
Exécuter des ateliers basés sur un modèle
décorer votre espace afin de lancer des discussions.
Cet ensemble d'idées va surtout permettre de communiquer sur les besoins des utilisateurs et générer des idées.

3 Choisir les meilleures idées
Il faut avoir une "Etoile du Nord" pour se réorienter au milieu de l'océan d'idées générées.
Cette étoile peut etre:
Les besoins du business sont bons
+ les besoins des utilisateurs sont mieux
= Principes de conception
Ces principes de conception sont différents en fonction de chaque produit car chaque expérience utilisateur est différente.

Comment démarrer :
Faire des esquisses
Organiser des ateliers
mettre en place des principes de conception

En conclusion, la présentatrice met en avant l'importance d'avoir foi en ses idées. Cela augmentera votre confiance personnel, permettra de mieux vendre vos idées et vous rendra heureux.

Commentaires

Posts les plus consultés de ce blog

Summary of 'Words are windows, Introduction to nonviolent communication' by Marshall Rosenberg

Summary of 'Words are windows, Introduction to nonviolent communication' by Marshall Rosenberg “Words are windows” is an introduction to non violent communication (abbreviated as NVC). Marshall Rosenberg presents in this book the process that allows us to communicate more serenely with others as well as with ourselves. This mode of communication allows us to become more and more caring, authentic, and empathic with others. It can therefore be used in all interactions of everyday life: as a couple, with our children, at work … NVC is proving to be a very effective way to manage conflicts, and also to better identify our own needs. At the source of Non Violent Communication NVC has 4 four key components: Observation – specific facts/data, no evaluation/judgment Feeling – state how we feel (many failure modes here) Need – the need underlying this feeling Request – must be specific action to address need First we observe what is really happening in a given situatio

Summary of 'Clean Architecture' by Robert C. Martin

Summary of 'Clean Architecture' by Robert C. Martin Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software. Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book. Clean Architecture leaves me with the same feeling, even if it’s pushing the development world to do better, has some good stories and present robust principles to build software. The book is build around 34 chapters organised in chapters. Programming paradigm After some introduction, there is an overview of three paradigm of programming: structured programming which imposes discipline on direct transfer of control object oriented programming which imposes discipline on indirect transfer of control functional programming which imposes discipline upon assignment Uncle Bob tells us

Le développeur incompétent est un mythe

Sous ce titre complètement arbitraire et très clairement provocateur, je vais passer un contre pied aux derniers articles que j'ai lus sur le métier de développeur. Par exemple : http://patricelamarche.net/2011/05/24/lincomptence-des-dveloppeurs/  http://blogs.codes-sources.com/tja/archive/2011/10/04/etre-un-bon-d-veloppeur-c-est-aussi-une-question-d-attitude-personnelle.aspx  Ça tombe bien c'est juste avant la soirée du Paris JUG sur le métier de développeur ! Et comme on se plaint que les présentateurs ne sont pas de vrais (?) développeurs, je vais en profiter pour donner mon avis. Alors voila, d'après ces articles, un bon développeur connait ses fondamentaux. Ok soit mais quelle est cette liste de fondamentaux ?  Chez certains, c'est les maths et l'algorithmie pure, d'autres c'est C++ par coeur et savoir retourner une chaine de caractère en moins de 3 instructions et une seule allocation mémoire, d'autres c'est Java JEE, ses 100 jsr et fra