Et les projets de photographie et les projets de design dépendent de l’appréciation esthétique du client.
Mais alors que la photographie produit, essentiellement, un «j’aime» ou un «j’aime pas», le design complique les choses avec des considérations pour la stratégie commerciale, le positionnement-produit, la culture d’entreprise, l’architecture de l’information, l’interaction, l’utilisabilité, l’ergonomie et encore d’autres paramètres, souvent très utilitaires et pragmatiques.
C’est pourquoi des méthodes de travail efficaces sont encore plus cruciales pour la réussite des projets de design que pour des projets de photographie.
Mais un seul processus de design ne conviendrait pas à tous les projets de design. Les projets de design différent par leur support, leur envergure et leur niveau d’implication du client.
D’après mon expérience, les projets de design destinés au support imprimé, tels que la publicité et les brochures, requièrent les processus les plus simples et les plus courts. Les projets d’identité visuelle, comme les logos et les systèmes typographiques, se trouvent au milieu de l’échelle de la durée / complexité. Les projets de web design, quant à eux, demandent des investissements de temps et d’énergie substantiels, et de la part du graphiste et de la part du client.
1 / PROCESSUS DE DESIGN POUR LE SUPPORT IMPRIMÉ
Le processus du print design est relativement simple:
1.1 / Prologue
- Anatoly IVANOV et le client analysent:
- l’entreprise du client
- les besoins du client
- l’industrie du client
- Anatoly IVANOV et le client déterminent les buts du projet.
- Anatoly IVANOV et le client définissent le budget (création et production).
1.2 / Création graphique
Itérations de:
- Anatoly IVANOV crée le design;
- Anatoly IVANOV et le client examinent et améliorent le design;
jusqu’à l’accord.
1.3 / Production
2 / PROCESSUS DE DESIGN D’IDENTITÉ VISUELLE
Les systèmes d’identité visuelle combinent les logos, les couleurs, les grilles régulatrices et la typographie pour exprimer l’essentiel de l’entreprise. La complexité de ce type de projets fondamentaux dépend de la taille de l’entreprise. J’utilise donc soit le processus de design pour le support imprimé, plus simple, soit le processus de web design, plus robuste. Ou encore, je réunis les deux processus.
3 / PROCESSUS DE WEB DESIGN
3.1 / La complexité et l’inconnu
Aujourd’hui, un site web reflète l’intégralité de l’entreprise réelle, avec tous les détails du monde réel. Les sites ont évolué des vitrines virtuelles vers des présences virtuelles d’un ensemble des individus de l’entreprise.
Tout passe en ligne. Les valeurs, l’histoire et la vision. Les idées, les services et les produits. Les relations avec les clients, les investisseurs, les employés et la presse. Même une entreprise individuelle se résume rarement en une page.
Parce qu’un site web représente l’entreprise avec autant de détails, les choix de ce qui sera publié, et de quelle manière, impliquent de nombreuses décisions stratégiques. J’ai été témoin de plusieurs projets de web design qui ont redéfini la stratégie commerciale du client, et parfois, le produit même. C’est pour cette raison que les projets de web design durent des mois et requièrent une approche très collaborative.
La nature intangible de l’internet ne simplifie pas les choses. Il est difficile d’évaluer les fonctionnalités d’un site avant de les utiliser. Souvent, des idées de fonctionnalités apparaissent après le lancement du site.
Et bien sûr, nous devons toujours traiter avec les difficultés typiques du design. De quoi ont vraiment besoin les utilisateurs? Comment le design résout les challenges réels de l’entreprise? Qui, dans une entreprise de 500 personnes, prend les décisions esthétiques pour toutes les autres? Comment chiffrer et planifier le design, un processus de création, vague et insaisissable?
Tous ces questions et paramètres créent de la complexité et de l’inconnu qui consomment du temps et de l’argent.
3.2 / Deux approches face à la complexité et l’inconnu: la prévision contre l’adaptation
3.2.1 / L'approche la plus répandue: renier l’inconnu avec des prévisions détaillées
La réaction naturelle à l'incertitude est de faire des prévisions, d’élaborer un plan, puis de le suivre, étape par étape:
- Pour compenser l’inconnu, les chefs de projet développent un cahier des charges extrêmement détaillé. Ses 100 pages définissent les fonctionnalités du site web, précisent le calendrier et allouent un budget fixe.
- Le client valide le cahier des charges.
- Les graphistes utilisent le cahier des charges pour créer l’apparence visuelle du site: un ensemble d’écrans types, non-interactifs, des futures pages web.
- Le client valide le design.
- Les programmeurs se mettent à coder le site: XHTML et CSS; JavaScript ou Flash; PHP, JSP ou ASP; XML ou bases de données, etc.
- Après des mois de travail acharné, le client et les utilisateurs peuvent enfin essayer un site qui fonctionne. C’est alors, en naviguant sur le nouveau site, que le client réalise que certaines fonctionnalités devraient être changées et d’autres ajoutées ou supprimées.
- Les chefs de projet réécrivent le cahier des charges. Les graphistes ajustent le design. Les programmeurs modifient le code.
- Pourtant, le client demande des révisions supplémentaires. Le feedback des utilisateurs révèle des problèmes dont personne ne soupçonnait l’existence. Les spécifications n’arrêtent pas de changer.
- Avec chaque nouvelle modification, le résultat final correspond de moins en moins au cahier des charges initial. Les délais s’allongent et le budget explose.
- Les accusations, la douleur et la frustration s’installent. Pas très beau à voir… Et pourtant, c’est ce qui se passe trop souvent dans l’industrie du web design et du développement de logiciels.
3.2.2 / Mon approche: accepter l’inconnu grâce à l’adaptation
Mon processus de web design accepte l’inconnu comme quelque chose que nous ne pouvons pas changer ou contrôler. Inspiré par les idées de la programmation agile, mon processus de web design s’adapte en permanence à l’incertitude. Je redirige l’énergie qui aurait servi aux prévisions et au contrôle vers la création et l’expérimentation:
- Je ne produis pas de cahier des charges exhaustif et détaillé.
- Je déplace la conception graphique à un stade ultérieur.
- Je commence par un prototype du site qui fonctionne tout de suite. Essayons-le dès le début. Voyons ce qui marche. Présentons le site aux utilisateurs finaux pour entendre leurs avis très tôt dans le processus.
- Aucun document ne restreint notre créativité. L’absence de cahier des charges ouvre la possibilité d’imaginer des fonctionnalités et de les tester tout de suite.
- Un système de coûts flexible permet au client de décider les fonctionnalités à implémenter.
Résultats:
- conscience permanente de ce qui marche et de ce qui ne marche pas
- feedback fréquent des utilisateurs finaux
- compréhension du coût de chaque fonctionnalité
- liberté de choix pour le client
3.3 / Comment ça marche?
Mon processus de web design s’écoule à travers 2 systèmes:
- niveau macro: étapes du projet
(barres noires sur le diagramme de Gantt du projet-type ci-dessous)
- niveau micro: tâches du projet
(barres bleues, oranges et vertes sur le diagramme de Gantt du projet-type ci-dessous)
NB: les explications détaillées du diagramme de Gantt suivent après le schéma.
3.3.1 / Étapes du projet
3.3.1.1 / Prologue
Pendant l’étape du prologue, nous:
- discutons et analysons l’entreprise, les besoins et l’industrie du client
- négocions et nous nous accordons sur une proposition de solutions qui décrit en grandes lignes notre collaboration
- signons un contrat qui définit notre collaboration en termes juridiques
3.3.1.2 / Scénario interactif
Pendant l’étape du scénario interactif, je crée un site web opérationnel qui ressemble de très près à la version finale. Le scénario interactif est un site en XHTML, accessible en ligne, qui:
- représente l’architecture de l’information du site final
- contient toutes les pages du site final
- inclut tout le contenu textuel du site final, dans toutes les versions linguistiques
- inclut tous les liens hypertexte: ces liens sont cliquables et mènent aux autres pages du site tout comme dans la version finale
- dispose de tous les principes et éléments de la navigation du site: boutons, menus déroulants, formulaires…
- suggère le placement des images sous forme de rectangles gris
- omet tout élément de design: du point de vue graphique, c’est un site «nu», il ne présente pas les couleurs, les formes ou les images de la version finale du site
Résultats:
- Un site tangible, concret, qui se concentre sur les fonctionnalités, le contenu et la navigation.
- Comme le site du scénario interactif ne comporte pas de design graphique, il reste en XHTML très malléable. Je peux rapidement et simplement changer son contenu, déplacer les pages, rajouter des liens, etc.
- Le scénario interactif nous permet de tester le fonctionnement du site par des utilisateurs finaux et de réagir à leur feedback très tôt dans le processus.
- Le scénario interactif s’adapte parfaitement à la collaboration intense et stimule la création itérative et fluide.
3.3.1.3 / Conception graphique
Pendant l’étape de la conception graphique, je conçois l’apparence visuelle du site, son interface graphique, au moyen des formes, des couleurs, des images et des typographies.
- Toutes les pages d’un site se répartissent en plusieurs types qui partagent les mêmes éléments graphiques et la même disposition du contenu. Par conséquent, un gabarit (un modèle) peut être utilisé pour chacun de ces types de pages afin de créer un nombre illimité de pages.
Exemple: un site s’étend sur plus de 30 pages, mais requiert seulement 3 gabarits:
- le gabarit de la page d’accueil générale (la home)
- le gabarit d’une page d’accueil d’une section (produits, contact)
- le gabarit d’une page de contenu (description détaillée d’un produit)
Le contenu de chacune de ces 30 pages change, mais les 3 designs restent les mêmes. Résultat: cohérence visuelle, identification de la marque et navigation aisée.
- L’étape de la conception graphique se concentre sur la création des gabarits.
- L’étape précédente, le scénario interactif, résout beaucoup d’inconnues et apporte de l’aide à la conception graphique:
- Nous pouvons décider du nombre de gabarits dont nous avons besoin, parce que nous venons de créer l’architecture de l’information et tout le contenu: l’architecture de l’information et le contenu révèlent les types de pages.
- Nous pouvons nous concentrer sur l’aspect esthétique du site tout en améliorant son ergonomie, parce que le scénario interactif a déterminé les caractéristiques du site et ses fonctionnalités.
- Nous savons précisément comment le design graphique devrait fonctionner avec le contenu du site, parce que le scénario interactif a spécifié le type et la longueur des textes, ainsi que le nombre des photographies.
- Je représente la conception graphique par des «écrans aplatis»: des reproductions exactes, sous forme d’images JPEG à l’échelle 1:1, de chaque gabarit de page rempli par du contenu type. Les «écrans aplatis» montrent tous les éléments de navigation, les textes, les photographies, les formulaires, etc., tels qu’ils apparaîtraient aux visiteurs du site. Bien sûr, les «écrans aplatis» omettent des liens cliquables ou tous autres éléments interactifs. Mais parce que nous avons déjà défini ces fonctionnalités pendant l’étape du scénario interactif, nous pouvons les utiliser comme un moyen plus efficace de travailler sur la conception graphique:
- Il est beaucoup plus simple de façonner les gabarits des pages dans Adobe Fireworks et de les enregistrer sous forme de JPEGs. Je peux réagir rapidement au feedback du client et des utilisateurs finaux et modifier le design graphique.
- En revanche, les pages en XHTML / CSS totalement interactives nécessitent beaucoup de programmation, de découpe et d’optimisation d’images. Toute modification demande beaucoup de temps pour apporter des changements au code et aux images sources.
Résultats:
- Les «écrans aplatis» de chaque gabarit de page représentent le design graphique du site final.
- Nous contournons l’inconnu, nous nous concentrons sur la recherche esthétique, nous facilitons la collaboration et nous réduisons les dépenses.
3.3.1.4 / Réalisation technique
Pendant l’étape de la réalisation technique, je combine la conception graphique avec le scénario interactif.
- Je réutilise le code XHTML du scénario interactif et je rajoute les «écrans aplatis» de la conception graphique pour créer un mélange:
- d’images optimisées pour le web
- de code XHTML
- de code CSS
- Selon le site, j’ajoute également des technologies «côté client»:
- Pour la majorité des sites, je génère les images, le XHTML, le CSS et le JavaScript sur le «coté serveur» au moyen de PHP, MySQL et mod_rewrite.
Résultats:
- Un site parfaitement fonctionnel, esthétique et très proche de la version finale.
- Nous pouvons encore améliorer un détail ici et là.
- Nous soumettons le site aux utilisateurs finaux une fois de plus pour obtenir leur feedback et corriger d’éventuelles lacunes passées inaperçues malgré le scénario interactif et la conception graphique, ainsi que pour éliminer des bogues résiduels.
- À la fin de la réalisation technique, nous ouvrons le site final au public.
3.3.2 / Tâches du projet
Les tâches subdivisent les étapes du projet en des blocs de travail plus faciles à gérer.
Mon système des tâches, flexible et basé sur l’approche gagnant / gagnant, permet de planifier, d’évaluer et d’ajuster la durée et le coût global de la conception du site, à tout moment dans le processus.
Le système des tâches s’appuie sur 5 concepts:
3.3.2.1 / Jours/homme
La rémunération de création (rémunération de mise en œuvre) constitue l’essentiel du coût global du projet. Le montant total de la rémunération de création dépend du nombre de jours/homme:
- Le plus de jours je travaille sur un projet, le plus le coût total du projet est élevé.
- Si le site exige des solutions complexes de bases de données, j’unis nos forces avec un programmeur spécialisé dans les technologies d’arrière-boutique. Plus le site est complexe, plus il demande de jours/homme de programmation, ce qui augmente le coût.
- Le calcul des jours/homme dépend du type de tâche.
3.3.2.2 / Types de tâches
Toutes les tâches du projet se regroupent en 3 catégories:
3.3.2.2.1 / Tâches administratives
- Barres bleues sur le diagramme de Gantt du projet-type ci-dessus.
- Exemples: discussion du contrat, paiement.
- Je ne prends pas en compte ces tâches pour calculer mes jours/homme.
3.3.2.2.2 / Mes tâches
- Barres orange sur le diagramme de Gantt du projet-type ci-dessus.
- Exemples: création du design graphique.
- Je travaille seul sur ces tâches.
- Le calcul de mes jours/homme par rapport à la durée de ces tâches se base sur 100% de charge de travail pour moi.
3.3.2.2.3 / Tâches collaboratives
- Barres vertes sur le diagramme de Gantt du projet-type ci-dessus.
- Exemples: travail collaboratif sur le scénario interactif.
- Le client et moi travaillons ensemble sur ces tâches, de manière synchrone (réunions, brainstormings), ou de manière asynchrone (ajouts, révisions et modifications par le client puis par moi).
- En moyenne, le calcul de mes jours/homme par rapport à la durée de ces tâches se base sur 60% pour moi et 40% pour le client.
3.3.2.3 / Ajustement de la durée des tâches pour influencer la qualité et le coût
3.3.2.3.1 / Mes tâches
- La durée de mes tâches reste fixe pendant le projet.
- Mes tâches forment les noyaux durs du projet. Ils créent les bases pour le travail collaboratif qui les suit.
- Je calcule le nombre de jours/homme minimum nécessaire à leur exécution.
- Avant que le projet commence:
- Le client peut demander de réduire le nombre des jours/homme alloués à mes tâches, mais il risque de baisser fortement la qualité du site.
- Le client peut également demander d’augmenter le nombre de jours/homme alloués à mes tâches s’il préfère investir davantage dans la qualité du site.
3.3.2.3.2 / Tâches collaboratives
- La durée des tâches collaboratives reste élastique pendant le projet.
- La durée des tâches collaboratives dépend du nombre et de l’étendue des changements, révisions et modifications demandées par le client.
- À tout moment:
- Le client peut décider de réduire la durée des tâches collaboratives, et donc, de réduire les coûts. Toutefois, le client devra également réduire le nombre de changements, révisions et modifications. Coût plus bas, moins de peaufinage.
- Le client peut décider d’augmenter la durée des tâches collaboratives pour augmenter le nombre de changements, révisions et modifications, afin de se rapprocher le plus possible du site idéal. Toutefois, des tâches collaboratives plus longues augmenteront aussi le coût. Coût plus élevé, plus de peaufinage.
3.3.2.3.3 / Budgets extrêmes
Aux 2 extrêmes budgétaires, le client peut obtenir:
- Budget le plus bas:
- Un site web créé par moi sans aucune intervention de la part du client.
- Mes tâches (orange) uniquement.
- Le client aime ou n’aime pas mon design.
- Budget le plus élevé:
- Un site web dont la création prend beaucoup de temps, avec des modifications fréquentes demandées par le client.
- Tâches collaboratives (vertes) uniquement.
- Le site final satisfait le client à 300%.
3.3.2.3.4 / Budget médian
L’approche la plus raisonnable se situe quelque part entre les 2 extrêmes.
3.3.2.4 / Engagement sur un forfait de jours/homme
Je pense que commencer un projet aussi long sans une idée même approximative du budget n’est pas très rassurant. Donc, pendant l’étape du prologue, nous décidons avec le client la durée de mes tâches et la durée des tâches collaboratives. Ce qui nous donne un nombre global des jours/homme et le coût total.
J’applique des remises progressives pour des projets à long cours. Plus long est le projet, plus bas est le prix d’un jour/homme.
Comme nous négocions en utilisant le principe gagnant / gagnant, personne n’est forcée d’accepter la première proposition. Nous restons ouverts et trouvons un équilibre entre:
- vos besoins (fonctionnalités du site)
- mes besoins en temps pour construire le site qui réponds à vos besoins (débit et durée)
- votre budget (coût du site)
En pratique: nous nous rencontrons et essayons différentes combinaisons dans un logiciel de gestion de projet qui calcule la durée et le coût du projet en temps réel.
Une fois que nous avons convenu d’un nombre total des jours/homme, je m’engage sur un forfait de jours/homme:
- À la fin de ce forfait, je m’engage à fournir un site esthétique, fonctionnel, viable et utilisable en ligne de suite.
- Je communique sur l’utilisation de ce forfait de jours/homme une fois par semaine au moyen du diagramme de Gantt et de la feuille d’utilisation de ressources.
3.3.2.5 / Au-delà du forfait de jours/homme
3.3.2.5.1 / Que se passe-t-il si le client exige plus de jours que nous avons programmés dans le forfait?
Je comprends et j’anticipe la volonté du client de créer le meilleur site possible. Même si nous nous sommes entendus sur la durée optimale des tâches collaboratives, je laisse au client la liberté totale de les rallonger et de demander autant de révisions et de changements qu’il lui semblerait nécessaire.
Au-delà du forfait de jours/homme, j’applique le même tarif journalier que celui utilisé pour le forfait:
- Un projet avec un forfait de jours/homme plus long et donc avec une remise plus conséquente, aura un tarif par jour plus bas.
- Un projet avec un forfait de jours/homme plus court et donc avec une remise moins conséquente, aura un tarif par jour plus élevé.
- Dans certains cas, il serait moins coûteux de s’entendre sur un forfait de jours/homme plus long dès le départ plutôt que de commencer avec un forfait plus court et ensuite de payer les jours supplémentaires à un prix plus élevé.
- Je communique sur l’utilisation des jours/homme supplémentaires une fois par semaine au moyen du diagramme de Gantt et de la feuille d’utilisation de ressources.
- Je facture les jours supplémentaires à la fin de chacune des 3 étapes du projet.
Mes 25 ans d’expérience dans le web design me confirment que les clients ont tendance à sous-estimer le temps nécessaire aux tâches collaboratives. C’est pourquoi je conseille généralement d’anticiper et d’étendre les tâches collaboratives lorsque nous nous accordons sur un forfait de jours/homme.
Pendant que nous travaillons ensemble sur le site, le client et moi développons une idée assez précise du nombre de jours nécessaires pour tel ou tel changement. Nous pouvons donc souvent estimer les besoins en jours/homme supplémentaires avant de poursuivre.
3.3.2.5.2 / Que se passe-t-il si le projet prend moins de temps que ce que nous avons programmé dans le forfait?
J’avoue que je n’ai jamais vu un tel scénario se produire en 25 ans de travail sur des projets de web design. Mais si cela arrive, je préférerais rembourser le client tous les jours/homme non utilisés.
3.3.3 / Sorties de secours
Le web design est un processus long, coûteux et complexe qui implique beaucoup d’interaction entre humains. Il se peut que nous soyons en tel désaccord que nous préférions mettre fin à notre collaboration.
Cependant, je me sentirais vraiment triste si vous deviez jeter par la fenêtre ce grand investissement de temps et d’argent.
C’est pourquoi mon processus de web design prévoit des sorties de secours:
3.3.3.1 / Paiement progressif
Vous payez au fur et au mesure de l’avancement du projet, au début / fin de chaque étape.
3.3.3.2 / Refus et résiliation
Je laisse au client la liberté de refuser le scénario interactif ou la conception graphique ou la réalisation technique et de mettre fin à notre collaboration.
Dans le cas de refus et résiliation, toutes les sommes versées auparavant resteront définitivement acquises à Anatoly IVANOV, mais aucun autre paiement, par exemple, pour des étapes non-entamées, ne sera demandé.
3.3.3.3 / Possibilité de réutilisation
Si vous souhaitez réutiliser le travail accompli jusqu’ici, je vous céderais volontiers les droits d’exploitation si:
- La partie du forfait de jours/homme plus les jours supplémentaires de toutes les étapes finies et entamées sont payés (je ne demande pas le paiement des étapes non-entamées).
- L’intégrité de la conception graphique est garantie, dans le cas où vous souhaiteriez utiliser celle-ci.
- La mention de paternité (mention de copyright) est maintenue.
3.4 / Une réponse complexe à une question complexe?
Oui, mon processus de web design peut sembler plus complexe que l’approche traditionnelle, parce que j’accepte la complexité inhérente au web design.
Mais la description détaillée de mon processus de web design prend plus de temps à lire qu’à mettre en œuvre.
Ce qui est surprenant c’est la sensation d’agilité, de naturel et de confiance que génère ce processus. Et pour le client, et pour moi.
De plus, à tout instant, nous connaissons l’état d’avancement du projet et son coût.
Est-ce que ça marche? Bien sûr! Même la page que vous êtes en train de lire est le résultat de mon processus de web design. Vous pouvez également regarder dans mon portfolio de web design les autres sites que j’ai créés.
4 / D’AUTRES QUESTIONS?
Je suis toujours ravi de répondre à vos questions et de discuter les détails de mes processus de design: contactez-moi.