Un développeur doit-il réaliser des maquettes d'interface utilisateur s'il n'y a pas de concepteurs dans le projet?

57

Je travaille avec une petite équipe qui crée une application Web propriétaire et l'UX n'est pas une priorité, car ce sont nos propres employés qui l'exploiteront, mais nous essayons de leur faciliter la tâche.

Devrais-je, en tant que développeur, créer une maquette d'interface utilisateur avant de créer un nouvel écran? Rien d'extraordinaire, surtout la disposition générale pour en discuter avec des collègues et avoir un modèle de référence. Je le comparais à la création de diagrammes UML avant de plonger dans l'écriture de code à l'aveuglette.

Un de mes collègues a dit que c'était absurde et que ce n'était pas à moi de le faire.

Konstantine
la source
51
Si vous n'avez pas de concepteurs et que ce n'est pas le travail des développeurs, alors qui est censé le faire? Le concierge peut-être?
GrandmasterB
10
Peut-être que vous pourriez le faire, mais c'est loin d'être inhabituel et certainement pas "absurde" comme le dit votre collègue trop dramatique. Selon la situation et l'environnement, vous ferez peut-être mieux de faire une maquette volontairement grossière plutôt que de faire quelque chose qui ressemble trop à un produit fini. Balsamiq est un bon outil pour cela, tout comme dessiner votre maquette sur papier ou sur un tableau blanc.
Joe Ballard
3
Je suppose que vous voulez vraiment dire "maquette?" Une "maquette" est autre chose .
Robert Harvey
23
User Experience Design ne se limite pas à rendre les choses plus jolies. Les programmeurs devraient être très impliqués avec cela.
JeffO
2
ce qui est absurde, c'est la réaction de vos collègues. c'est très commun
Claudiu Creanga

Réponses:

74

Je travaille très souvent dans de tels projets, et la réponse est un OUI retentissant, et le plus tôt possible.

Les gens trouvent qu'il est beaucoup plus facile de critiquer certains brouillons que de trouver une solution à partir de zéro. Je commence donc tôt la rédaction pour deux raisons:

  • Donnez aux experts en la matière une impression sur la manière dont l’information pourrait être présentée.
  • Montrer ma compréhension actuelle du problème et des structures informationnelles.

Dans de rares cas, il était également agréable de pouvoir prouver que j'ai bien livré ce que nous avions convenu ...

Stefan Schmiedl
la source
16
Et honnêtement, il est tellement plus facile d’écrire le code si vous avez au moins un croquis de serviette assis devant vous.
Kathy
9
Le point 2) est terriblement important si l’entreprise n’est pas anodine!
bigstones
4
En tant que personne qui a travaillé UX pendant 3 ans, il est extrêmement utile et important d’avoir un aperçu pour parler aux gens (développeurs, clients, utilisateurs finaux). Cela vous fera gagner beaucoup de temps sur la route lorsque vous n'avez pas besoin de refaire complètement le site parce que quelqu'un est frustré!
Gnomejon
39

Les maquettes sont fantastiques et il n'y a aucune raison qu'un développeur ne les fasse pas. (Cela peut même être pratique pour un développeur de faire un brouillon d'une disposition d'interface utilisateur, même si vous avez des concepteurs d'interface utilisateur dans le projet.)

Je recommande vivement de ne pas créer de maquettes ressemblant à des écrans réels. Si vous les partagez avec des utilisateurs finaux, ceux-ci se concentrent souvent sur des éléments sans importance, tels que les couleurs et les thèmes. Je vous recommande de créer des croquis dessinés à la main sur papier ou au tableau blanc. Ou, si vous les voulez dans l'ordinateur, utilisez quelque chose comme Pencil Project ou Visio ( voici quelques gabarits Visio d'un Jonathan Abbett qui ont l'air dessinés à la main.)

Matthew Whited
la source
6
Vous pouvez même dessiner à la main les superpositions, les dialogues, etc., les découper avec des ciseaux et les placer au-dessus de l'écran principal dessiné à la main lorsque l'utilisateur appuie sur un bouton dessiné à la main. Très rapidement, donnez une idée de ce qu’ils trouvent intuitif, du nombre de boutons dont vous aurez réellement besoin, etc.
RemcoGerlich
C'est juste une folle conversation ... en train de faire du storyboard. En route vers la vieille école pour ces nouveaux gars: P
Matthew Whited
1
"Ne faites pas de maquettes qui ressemblent à des écrans réels" est une idée très profonde.
Andrew Myers
1
Je me souviens d'une anecdote selon laquelle les utilisateurs jugeraient de l'achèvement d'un projet en fonction de la finition des captures d'écran qui leur étaient présentées. Conserver un croquis est très important pour les utilisateurs non techniques qui ne font pas la différence entre présentation et fonctionnalité. Communiquer "cela n’est pas fait".
Matthieu M.
1
@ Andrew ... c'est l'une des choses que j'ai apprises lorsque je me moquais des applications dans Access et VB. Vous montrez à quelqu'un quelque chose qui ressemble à une capture d'écran et ils s'attendent à ce que vous puissiez l'expédier :)
Matthew Whited
11

Oui absolument.

Ne laissez pas quelqu'un d'autre vous dire comment faire votre travail. Et vous avez raison, c'est un peu comme faire de l'UML pour votre modèle de données. En supposant que vous soyez développeur, votre travail consiste à fournir un logiciel de qualité. Si les maquettes vous aident à le faire, cela fait partie de votre travail.

Faites des maquettes basse fidélité - ne les faites pas ressembler à de vrais écrans. Vous perdrez trop de temps à ajuster les polices, les pixels et les bordures, et vos utilisateurs seront obsédés par ces détails plutôt que de se concentrer sur les fonctionnalités. Quelque chose comme balsamiq est idéal pour cela, il existe sans aucun doute d'autres outils similaires. Avec la maquette en main, il devient beaucoup plus facile de discuter des caractéristiques du projet avec vos utilisateurs et avec les autres membres de l'équipe de développement.

Bryan Oakley
la source
Bien sûr, comme vous le dites, je parle de maquettes basse fidélité. Personnellement, j'utilise draw.io comme une solution très légère et qui facilite le partage entre collègues.
Konstantine
10

Lors de la conception d'un "nouvel écran", vous souhaitez d'abord discuter de l'idée approximative de l'interface utilisateur avec un utilisateur et / ou vos collègues. Vous ne pouvez pas en discuter avec un utilisateur "en code" ou "en UML", cela ne fonctionne tout simplement pas (cela ne fonctionnera même pas entre programmeurs). Et vous devez vous attendre à devoir jeter vos deux ou trois premiers accès, ou au moins réorganiser les éléments de l'interface utilisateur fortement.

Donc, si vous avez un outil de conception d'interface graphique qui vous permet de le faire rapidement, il est logique de l'utiliser. Toutefois, si vous devez coder manuellement les éléments de l'interface utilisateur et qu'il faut beaucoup d'efforts pour les supprimer ou les réorganiser, il est évidemment plus logique de ne pas "coder" l'interface en premier. Il sera beaucoup plus efficace de créer des maquettes séparées, soit en utilisant un outil de dessin graphique, soit simplement en utilisant un crayon et du papier.

Doc Brown
la source
5

Pas nécessairement. Il existe au moins deux raisons pour lesquelles les maquettes sont peu utiles.

Premièrement, s’il existe des pratiques bien établies au sein de l’industrie en ce qui concerne ce que vous êtes sur le point de faire, vous pouvez simplement aller de l’avant et faire exactement cela. Vous ne ferez pas progresser l'art de la conception d'interface utilisateur, mais c'est tout aussi bien.

Deuxièmement, vos utilisateurs finaux ne savent souvent pas ce qui est bon pour eux et pourquoi. Ils ne peuvent tout simplement pas savoir jusqu'à ce qu'ils commencent à utiliser le programme (avec des données réelles ou factices). Aucune quantité de maquettes statiques ne vous aidera.

Avec un cadre Web modeste et flexible, pour "juste un autre écran de l'interface utilisateur, comme les écrans N précédents", vous pouvez commencer avec un prototype fonctionnel et le réorganiser au fur et à mesure. Faites une maquette et discutez avec vos collègues chaque fois que vous êtes sur le point de faire quelque chose d'extraordinaire.

Eugene Ryabtsev
la source
Semi-vrai sur les utilisateurs finaux ne sachant pas ce qui est le mieux. Mais vous ne pouvez même pas dire honnêtement que vous savez ce qui est préférable avant de voir la présentation et le déroulement de l'application. Le plus gros problème lié à l'utilisation de l'interface utilisateur comme maquette est l'attente que vous définissez. Les gens voient quelque chose et se plaignent des petites choses qui importent peu ou se demandent tout simplement pourquoi vous prenez autant de temps pour tout le reste.
Matthew Whited
@ MatthewWhited Est-ce qu'ils se plaignent de petites choses quand vous venez discuter de l'interface utilisateur ou est-ce qu'ils s'en plaignent quand vous proposez d'utiliser le produit pour accomplir leur tâche? Je m'attends plutôt à ce que le dernier cas soit plus constructif, et cela se prête bien à une application Web interne avec une base installée de 1.
Eugene Ryabtsev
3

TOUJOURS!

Je travaille pour une petite entreprise et je suis le seul informaticien "soft". Je fais toutes les exigences, la conception, le codage, les tests (bien que quelqu'un vérifie toujours mes tests), la conception de la base de données, etc.

NE COUPEZ JAMAIS LES COINS SUR LES ÉTAPES DE LA CONCEPTION - vos utilisateurs finaux vous en remercieront. Vous vous remercierez aussi, car vous finirez par le retravailler pour rendre les utilisateurs finaux heureux. Même si votre maquette n'est rien d'autre qu'un morceau de papier griffonné à la main, cela leur donne une idée de ce à quoi s'attendre. Prendre 10 minutes pour gribouiller quelque chose peut faire économiser une semaine de travail (été fait, fait ça)

Cela vous aide également dans votre codage. Cela vous donne la possibilité de réfléchir à ce que vous devez faire, au moyen le plus efficace de le faire et aux obstacles éventuels.

Par exemple, vous trouverez peut-être que le rapport "simple" que vous devez créer est plus difficile que vous ne le pensiez parce que vous ne capturez aucune date sur la table xyz. Il élargit également vos horizons et montre à votre équipe, à vos supérieurs, ou même qu’il peut être utilisé pour de futures opportunités de carrière que vous faites plus que le strict minimum et que vous pouvez sortir du cadre de "Ce n’est pas mon travail" (<--- sérieusement, Ne le soyez pas, nous le haïssons tous) ou cela vous donnera une chance d’apprendre davantage.

Jon Milliken
la source
2

Regardons ceci d'une manière plus générale:

  • La création de brouillons est-elle une bonne idée?
  • Qui devrait créer les brouillons?

La création de brouillons est-elle une bonne idée?

La création de brouillons offre principalement deux avantages. Premièrement, il fournit une orientation, ce qui accélère le travail en cours. Deuxièmement, il est beaucoup plus simple de discuter de l’orientation des travaux avant leur achèvement.

L'inconvénient de la création d'un brouillon est qu'il utilise du temps. Cela fait peu de sens de passer 2 heures à créer un brouillon élaboré pour quelque chose qui prend 4 heures à créer.

Dans votre cas, le niveau de la maquette doit prendre en compte la quantité de travail estimée nécessaire au projet et les avantages de l'ébauche. En fonction de cela, votre maquette peut être n'importe où entre un gribouillis de 10 secondes sur un post-it et un site Web entièrement interactif. Pour des projets très volumineux et coûteux, il n'est pas rare de voir des équipes entières travailler sur un brouillon pendant des semaines et créer des brouillons à cet effet.

Qui devrait créer les brouillons?

Pas besoin de réponse détaillée ici: si vous créez un brouillon, vous créez un brouillon. Si vous bénéficiez que quelqu'un d'autre rédige un brouillon pour vous, demandez à quelqu'un d'autre de le faire pour vous.

Peter
la source
Vraiment beau point sur l'importance de comparer les temps de création. Inutile de doubler le temps requis simplement parce que nous avons fait des brouillons.
Konstantine
-2

Votre collègue est absolument correct. Les applications internes ont généralement un aspect prédéfini. Également pour de telles applications, les utilisateurs ne recherchent pas une interface utilisateur de pointe. Tout ce qu'ils veulent, c'est quelque chose qui fonctionne et qui est relativement facile à utiliser. Sauf si vous envisagez de modifier radicalement l'interface utilisateur (ce que je déconseillerai fortement ... pour les applications internes), suivez simplement l'apparence existante. Les maquettes sont excellentes, mais dans votre cas, cela ne fera qu'augmenter votre douleur.

Kshitij Upadhyay
la source
1
Les maquettes ne servent pas à créer une interface utilisateur de pointe, mais à se moquer de la disposition et du comportement d'un écran. En fait, dans la plupart des cas, ils ne sont vraiment pas si jolis. Je ne suis tout simplement pas d'accord
Kieren Johnstone Le
3
J'ai trouvé les maquettes utiles pour une application interne particulière que je développais. L'idée n'était pas de concevoir le look ou d'inventer un nouveau paradigme d'interface utilisateur (comme vous le dites, ce n'était pas nécessaire), mais d'indiquer aux utilisateurs quelles sont les exigences, car une interface utilisateur vous donne une idée concrète à discuter.
James_pic
@KierenJohnstone Je suis tout à fait d'accord avec toi. Cependant, il dit lui-même que "l'UX n'est pas vraiment une priorité". À moins qu'il ne soit un membre raisonnablement senior de l'équipe, ses récompenses ne seront pas à la hauteur des efforts déployés (création de maquettes). Les maquettes sont excellentes. Mais pas dans sa situation.
Kshitij Upadhyay
Je ne suis pas d'accord - les maquettes sont vraiment utiles dans cette situation - dans la plupart des situations - pour voir comment l'application fonctionnera, si cela se justifie et si l'exigence est comprise par le développeur - avant que la partie coûteuse ne se produise (écriture de code)
Kieren Johnstone
1
Notre équipe est composée d'environ 3 personnes. Il y a un membre senior / chef d'équipe, et moi et un autre gars qui avons été engagés pour travailler sur le projet. Le projet a principalement été conçu pour discuter du nouvel écran avec le chef d’équipe. De plus, il n’y avait pas d’apparence prédéfinie, car le but du nouvel écran était d’améliorer un écran existant qui était difficile à utiliser, de sorte que tout devait être refait.
Konstantine