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

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.

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 ...

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.)

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.

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.

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.

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.

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.

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.