1. Objectif: un produit fonctionnel que les gens utilisent

Un objectif si simple. Nous analyserons chaque mot, car il n'est pas simplement formulé par ces mots.

Faites attention au manque de mots de processus, tels que "création", "conception", etc. Les processus ne sont pas du tout un objectif. L'objectif ne peut être qu'un résultat, pas un processus. Mais les designers du monde entier tombent dans le piège mental des processus, donc les résultats de leur travail sont des artefacts de processus, pas des produits qui fonctionnent.

J'ai de tristes statistiques. Sur dix designers qui viennent «fabriquer un produit et l'influencer», l'un se concentre sur le résultat, le reste sur les processus. Cela vient longtemps, et bien, si ça vient du tout.

Avant que l'outrage ne vienne, je vais clarifier: je ne diminue pas l'importance des processus et je ne les comprends pas. Cadre, recherche, conception, méthodologies, spécifications, lignes directrices, systèmes de conception, logiciels professionnels, etc. Dès que le produit tombe entre les mains de l'utilisateur, tout cela n'a aucun sens: le produit fonctionne ou non.

Quoi qu'il en soit, revenons au libellé.

1. Un produit fonctionnel est celui qui peut être utilisé pour résoudre des problèmes. Il s'agit de la capacité technique à résoudre le problème en utilisant le produit.
2. Le produit est une sorte d'entité complète, entière, dans la quantité d'ingrédients qui a plus de valeur que tous pris séparément.
3. Utilisation - parle de demande et de commodité.
4. Les gens sont un concept plus large que «clients», «utilisateurs», «employés», etc. Lorsque nous travaillons pour des personnes, nous prenons en compte l'ergonomie et certaines normes.

Disons que le produit ne fonctionne pas. Tout est clair ici: ils ne seront pas utilisés (au moins pour leur destination).

Ou n'est-ce pas un produit: un ensemble de composants disparates qui ne sont interconnectés par aucun signe (cela arrive aussi).

Ou il y a un produit, mais ils ne l'utilisent pas (du tout). Échec également, ça pourrait être n'importe qui: le manque de marketing, inconfortable, ralentit.

Sinon, les gens l'utilisent ... alors, j'admets, il y aura des principes de conception complètement différents.

Cette idée est discutée sous différents angles lorsqu'ils parlent d'Agile, de livraisons fréquentes, de Scrum et de travail d'équipe, mais même avec de telles pratiques, les concepteurs se glissent parfois dans une ornière confortable de «processus». J'admets de telles raisons:

• Ils ne comprennent pas les technologies et leur influence sur eux,
• ne peut pas influencer le résultat (peur "ils n'écoutent pas", manque de motivation, subordination inventée "ils ne m'ont pas dit de faire ça")
• ne comprennent pas leur rôle
• une mêlée est exploitée sans comprendre le but, comme un cadre (voir aussi Cult of Cargo ) - alors ce n'est certainement pas mieux que la cascade (ou pire encore)
• disposer de petites cascades à l'intérieur de la mêlée :-) - "D'abord, design, puis front-end", au lieu de travailler au moins deux / deux. Cela, pour une raison quelconque, est particulièrement difficile pour les concepteurs et les développeurs (mais quand et si c'est le cas, ils ne veulent plus revenir au modèle mini-eau-eau, car il est défectueux dans tous les sens).

PS Liens vers les descriptions des méthodologies listées, Wikipedia:

• Agile (Agile) - Méthodologie de développement flexible
• Scrum (Scrum) - un cadre pour le développement de logiciels agiles (travail d'équipe)
• Kanban (Kanban) - un système d'organisation de la production et de l'approvisionnement, permettant de mettre en œuvre le principe du «juste à temps»

2. Le rôle du designer dans l'équipe Scrum

Souvent, le rôle d'un designer dans une équipe produit est exagéré car il pense en termes de processus et de séquence d'actions (cascade) au lieu du résultat.

(Penser correctement à partir du résultat, par catégories d'objectifs.)

Le développeur, après avoir tout fait conformément aux normes et spécifications, résoudra probablement le problème mieux que s'il passe par les maquettes du concepteur. Même les mesures d'épicerie seront probablement meilleures. En l'absence totale d'un designer.

«Nous attendons des mises en page» - si cela vous semble, alors les processus dans l'équipe ne sont pas organisés correctement.

(Hélas, de nombreux développeurs et concepteurs ne connaissent pas les normes - au moins le W3C pour le Web, et il existe de nombreux principes fondamentaux qui aident à créer une meilleure expérience. Par analogie, il existe des descriptions / normes pour les principales plates-formes mobiles et de bureau; iOS , Matériel .)

Faites attention aux startups - Facebook, Vkontakte, Odnoklassniki et Apple avec Microsoft: elles sont basées sur des solutions d'ingénierie (Wozniak, Gates), que les concepteurs ont ensuite rejointes. Ils ont créé des produits conformément à l'objectif.

Le premier est un produit fonctionnel.

(Beau, pour des raisons de justice, les gars idéologiques du laboratoire Xerox l'ont fait, mais l'ampleur des conséquences est complètement différente.)

•••

Quel est donc le rôle du designer?

Pour ajouter de la valeur .

Vous pouvez ajouter à quelque chose d'existant , faites attention.

Valeur aux yeux des clients, des utilisateurs.

•••

Souvent, la séquence est inversée et «attend le design». Cela, bien sûr, parle de l'immaturité de l'équipe et de la gestion inadéquate de cette même équipe.

•••

«Layouts» est un anachronisme, l'héritage d'une toile statique qui suivait l'esthétique et les processus de préparation des graphiques de magazines et de journaux. Dans la conception des produits, cela a cessé d'être pertinent, mais l'approche - en l'absence d'une autre - est restée, à la fois dans les processus et dans la conscience.

Commencez avec du code au lieu de mises en page.

Application - dynamique, mouvement, interaction. Par conséquent, les dispositions dans le travail du concepteur de produit sont souvent inappropriées et contraires à l'objectif.

C'est pourquoi les concepteurs avancés migrent vers des prototypes avec des données réelles. C'est bon? Je pense que c'est redondant - pourquoi programmer un prototype alors que vous pouvez (et logiquement) programmer immédiatement un produit?

Il est préférable de passer immédiatement du développement à la conception. Commencez avec le code - le prototype qui exécute la tâche du client de manière minimale. Un prototype qui peut entrer en état de marche (rappel plus tard sur le développement client).

(L'ouverture et la maturité des développeurs sont importantes ici - leur volonté d'expérimenter et d'améliorer le programme, voire de réécrire le code plusieurs fois. Je suis sûr qu'il existe de nombreuses solutions prêtes à l'emploi pour cela pendant longtemps.)

À emporter

Réalisez la tâche de l'utilisateur.

Commencez par développer. Travaillez en tandem avec le développeur (en tant que directeur artistique et rédacteur publicitaire).

Améliorez un produit fonctionnel au lieu de mises en page.

Pensez en termes d'objectifs, de résultats plutôt que de processus.

Le concepteur de produit crée le produit, pas les dispositions.

3. Méthode

Cette méthode, ainsi que la bibliothèque de composants, est devenue la base du système de conception bancaire .

Je propose de travailler dans l'ordre suivant:

1. Reconnaissez la tâche du client (utilisateur) et validez-la en tant que User Story.
2. Définissez des métriques. Comment comprenons-nous que la tâche de l'utilisateur a été résolue? Commit.
3. Formuler des hypothèses. Commit.
4. Carte du parcours client.
5. Un prototype fonctionnel. MVP Développement client.
6. Disposition. (Avec le travail d'équipe et le système de conception existant, vous pouvez vous passer de mises en page).

Tâche client

Tout semble clair ici, mais ce n'est souvent pas le cas. Les hypothèses d'interface sont confondues avec les tâches du client, elles sont données par la liste de souhaits du gestionnaire et sont généralement utilisées pour des manipulations d'équipe pas si belles.

La tâche du client est identifiée soit sur la base de plaintes («douleur client») ou de besoins de recherche.

(En passant, nous notons qu'une plainte et une tâche sont deux choses différentes, et il est important de garder la tête froide et de ne pas se précipiter pour «résoudre un problème» basé sur une plainte - la tâche peut être différente et la plainte est causée par des circonstances indépendantes. Livré avec l'expérience. Utilisez la méthode des «cinq pourquoi» - parfois, cela aide à aller au fond de la base sur laquelle une tâche objective peut être formulée.)

Lorsqu'une tâche est réalisée, elle est enregistrée en tant que User Story. De nombreux articles et livres ont été écrits à ce sujet, donc je ne vais pas me répéter ici - étudiez par vous-même.

Pour avoir un aperçu du problème, je recommande fortement le livre User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton et Peter Economy) .

Deux types de métriques (il est important de corriger les deux!)

1. La réponse formulée à la question "Comment comprenons-nous que la tâche de l'utilisateur a été résolue?" Ce que nous voulons obtenir sous forme de solution.
2. Numérique: valeurs relatives et absolues. Plus souvent sur les indicateurs quantitatifs (financier, vitesse, clients, temps). Comment comprenons-nous que la décision est réussie. Il y a un truc: souvent dans les présentations, les valeurs relatives sont cachées, exagérées ou perdent l'échelle objective de la décision. Par exemple, «la croissance de l'audience était de 3%» - est-ce beaucoup ou un peu? S'il s'agit de 150 000 personnes (une agglomération de type urbain, avec des écoles et des jardins d'enfants, des magasins et sa propre administration), c'est déjà un nombre impressionnant, même si cela semble être de petites choses. En revanche, «300% de croissance des bénéfices», si elle est de 300 roubles par mois, est déjà un indicateur douteux. Et encore une fois, si 150000 personnes sont une erreur statistique dans la taille de l'audience de l'ensemble du produit (par exemple, en visitant la page principale du moteur de recherche par an), alors ces tailles peuvent très probablement être négligées, bien que nous parlions de la population du même village de type urbain.

Il s'avère souvent que les mesures apparaissent après qu'un produit ou une fonctionnalité a déjà été fait. Pour le reportage et une belle présentation. C'est triste et ne montre pas d'habileté, mais, au contraire, gâche l'image et crée un faux sentiment de calme (le calcul se produit toujours). La situation est très bien illustrée par la plaisanterie sur le meilleur archer du monde.

Hypothèse - la réponse à la question sur le moyen le plus rapide de résoudre le problème de l'utilisateur

Il existe toujours plusieurs solutions au problème. Dans le développement (design) ne peut pas être limité à un! Personne ne sait à l'avance lequel fonctionnera le mieux.

Faites un travail mental et trouvez au moins trois solutions différentes.

Gardez à l'esprit que «développer» une idée sous la forme d'une mise en page qui change progressivement est une solution, pas trois (ou combien de mises en page différentes vous avez réussi à faire).

Pour plus de simplicité, essayez trois approches:

1. Solution d'interface. Il peut également y en avoir plusieurs.
2. Automatique (par exemple, une tâche est effectuée sur le serveur lors de la survenance d'un événement) - sans intervention de l'utilisateur.
3. Processus - ce qui peut être changé dans les processus afin que l'utilisateur ne rencontre pas du tout une tâche, mais reçoive une solution au bon moment.

La meilleure solution se trouve exclusivement de manière empirique (voir «Méthode scientifique»). Toute solution / idée, même la plus folle à première vue, doit être vérifiée. Les hypothèses doivent être vérifiées. Le cas idéal est de tester les trois hypothèses réalisées sous forme de MVP. Vous allez en faire un prototype.

La carte du parcours client plonge dans le contexte

Si vous avez un petit produit avec une seule fonction, alors CJM vous permet de voir l'ensemble du processus de résolution d'un problème par l'utilisateur et d'identifier les points douloureux, de réaliser la vraie réalisation de la tâche.

Si la tâche consiste à développer une fonctionnalité dans une application existante, CJM s'immerge dans le contexte et fournit une solution transparente et transparente au problème. Souvent, ignorant le contexte, les concepteurs et les chefs de produit créent une "nouvelle section", propageant les entités, compliquant la navigation et créant de la confusion dans l'interface.

Beaucoup a été écrit sur CJM, vous devez l'étudier vous-même et l'appliquer dans votre travail.

Vous pouvez commencer avec le livre " Custom Stories " de Jeff Patton.

Un prototype fonctionnel. MVP Développement client.

Arrangez-vous avec le développeur et faites un prototype fonctionnel pour tester chaque hypothèse. Ce ne sera pas nécessairement la solution idéale à la fois techniquement et esthétiquement - il est important de créer un produit minimalement viable ( MVP ), dans lequel les tests vous permettent d'impliquer des clients nouveaux et existants (développement client).

« . Lean Startup -» . .

MVP, . .

,

MVP . , — . , - , — - .

Takeaway

,

, / , . , .

.

, - , . , , . -. : , - , . , , , .

: , , . . , , .

, . ( ), , , , . , ( , «»; — ).

: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .

, .

, .

?

, / (), , , , . . , , .

, .

: ?

? ?

?

30 ? ?

? , ?

?

, ?

— , . .

, . — , : , . .

.

« », .

, . , . . , - . .

: .

? . ? .

. , — «» :-)

.

. : , , .

, , . ( ).

: , . : / .

:

1. , : , -, (// ). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

Total

1. — .
2. — .
3. «» .
4. , « » «» ( / ) — .

— , , . .

ePub