Il y a beaucoup de malentendus lorsque ceux qui ont besoin d’une application web (les clients) communiquent directement avec les développeurs de l’application.
web app (the devs). Ils peuvent passer en revue tous les sujets importants, comme les exigences et le budget, sans être pleinement conscients des différences dans leurs langues : les mêmes mots mais des significations différentes. Parfois, nous avons besoin d’un peu d’interprétation entre le langage du client et le code du développeur. La discussion sur la conception du système front-end en est un exemple typique.
« Aucun design requis », « aucun front-end requis », « c’est du B2B donc aucun design UX requis », et la liste des souhaits des clients est longue. Comment doit-on comprendre le client ? Se souvenir des différences sémantiques, prendre les mots au pied de la lettre, tout cela est exclu. Alors allons plus en profondeur pour comprendre 1) ce que le client veut, 2) ce dont ils ont besoin, et 3) comment le communiquer aux développeurs dans leur langue.
Les contraintes budgétaires et le calendrier de développement, qui sont tous deux liés à la quantité de travail attendue des développeurs, sont des raisons courantes qui expliquent pourquoi il n’est pas nécessaire d’en faire beaucoup au niveau de la conception. En d’autres termes, les clients veulent économiser du temps et de l’argent – et qui ne le ferait pas ? Mais ces clients seraient-ils d’accord avec un site Web qui ressemble à un site bon marché et obsolète ? Peut-être, tant qu’il est facile à utiliser et à naviguer. Mais aucun bon développeur ne souhaite fournir une qualité moindre au client. Aucun bon développeur n’est fier d’une qualité qui n’a pas impressionné le client. Nous en concluons donc que, même au minimum, 1) les décisions de conception sont nécessaires parce que les blocs de construction de page ne tombent pas naturellement dans leurs emplacements, et 2) l’implémentation du design est nécessaire, le plus souvent avec des feuilles de style HTML + CSS, car un style unique ne peut pas être copié.
Voilà pour le sens littéral de « pas besoin de design », mais cela nous amène à poser une question plus pertinente : _combien_de_design_faut-il ? Un pari sûr est qu’un client qui n’a pas d’exigences en matière de conception ne s’attend pas à ce qu’un concepteur expérimenté mentionne de nouvelles polices, logos, combinaisons de couleurs ou quoi que ce soit d’autre dans son ensemble de compétences. Une autre supposition avisée nous dit qu’ils ont besoin d’une conception d’application web qui permet une utilisation facile et qui laisse vos yeux se reposer. Maintenant, nous pourrions être intéressés par les exigences minimales en matière de conception qui font d’
web app une application attrayante et conviviale, mais nous pourrions aussi bien sauter cette étape et sauter directement à la planification de la conception, en supposant qu’en faisant le bon type de travail de conception, nous pouvons répondre aux exigences minimales sans passer trop de temps sur des décisions de conception inutile.
Sans être spécifique sur aucun projet de développement web, nous nous en tiendrons à des directives de développement plus générales qui satisferont les clients sans exigences de conception.
- Des applications et outils de conception. Oublions tout cela, car nous n’avons pas de designer attitré qui travaille avec des outils de conception.
- Design réutilisable. Concentrez-vous là-dessus. Le web est plein d’open source, de free-to-usebits et de blocs faits par de vrais designers. Cela inclut les habillages de pages Web, les composants d’interface utilisateur, les polices, les icônes, les schémas de couleurs,…, les sélecteurs de date, les sélecteurs de gamme, les curseurs de lissage. Des implémentations appropriées pour n’importe lequel des frameworks JavaScript communs peuvent être trouvées en quelques secondes de recherche.
- Expérience antérieure. Tirez profit de ce que vous avez appris de vos projets passés. Apprendre à personnaliser le composant de l’interface utilisateur prend toujours du temps, ce qui peut inclure une bonne quantité de débogage et de test. La documentation du code libre est loin d’être parfaite et pas toujours à jour.
Vous ne vous sentez toujours pas en confiance ? Faites des captures d’écran et demandez au client de confirmer que les « Aucun design requis » sont toujours valables.
')}
