ANATOLY IVANOV / MÉTHODES / PROCESSUS DESIGN

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 une réaction binaire — «j’aime» ou «j’aime pas» — le design introduit des considérations beaucoup plus objectives et complexes: la stratégie commerciale, le positionnement de produit, la culture d’entreprise, l’architecture de l’information, l’interaction avec l’utilisateur final, 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.

Des méthodes au pluriel, car un seul processus de design ne conviendrait pas à tous les projets de design: ils diffèrent par leur support, leur envergure et leur niveau d’implication du client.

D’après mon expérience de 25 ans, 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 les plus substantiels, et de la part du designer 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;

répétées jusqu’à l’accord commun… ou jusqu’à l’épuisement du délai / budget. 😀

1.3 / Production

2 / PROCESSUS DE DESIGN D’IDENTITÉ VISUELLE

Les systèmes d’identité visuelle combinent les logos, les couleurs, les grilles typographiques et l’ensemble de polices de caractères 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 j’adapte le processus de web design, plus robuste.

3 / PROCESSUS DE WEB DESIGN

3.1 / La complexité et l’inconnu

Aujourd’hui, un site web, bien que virtuel, 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 sommaires et statiques vers des présences riches et vivantes de ce qu’apporte 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, les fournisseurs et la presse. Même une entreprise individuelle ne se résume plus à une page. Même lorsqu’elle est appelée une SPA (Application Web Monopage).

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, même le produit commercialisé. C’est la raison pour laquelle ces projets durent des mois et requièrent une approche très collaborative.

La nature intangible d’internet ne simplifie pas les choses. Il est difficile d’évaluer les fonctionnalités d’un site web avant de les utiliser. Souvent, des idées apparaissent après la mise en ligne.

Et bien sûr, nous devons encore faire face aux défis typiques du design. Quels sont les véritables besoins des utilisateurs? Comment le design résout-il les défis commerciaux du monde réel? Qui, dans une entreprise de 500 personnes, prend les décisions esthétiques pour tout le monde? Comment chiffrer et planifier le design, un processus de création, vague et insaisissable?

Toutes ces questions et paramètres amplifient la complexité et l’inconnu, consomment de l’argent, des efforts et du temps.

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: éliminer l’inconnu avec des prévisions détaillées

Notre réaction habituelle à l’incertitude? Se poser pour imaginer le futur, l’encadrer dans 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. Souvent, sans idée précise du code qui génèrera la chose — «ils ne sont pas programmeurs!»
  • Le client valide le design.
  • Les développeurs écrivent le code du site: HTML et CSS; JavaScript et ses innombrables bibliothèques et frameworks (React, Vue, Svelte, HTMX); SSRs sur Node.js ou même le bon vieux PHP; fichiers Markdown, APIs JSON ou bases de données SQL, 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 se rend compte que certaines fonctionnalités devraient être modifiées et d’autres ajoutées ou supprimées.
  • Les chefs de projet réécrivent les spécifications du cahier des charges. Les graphistes ajustent le design. Les programmeurs modifient le code.
  • Pourtant, le client demande des révisions supplémentaires. Les retours des utilisateurs révèlent des problèmes que personne ne soupçonnait. Les souhaits, les exigences continuent 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 reproches et la douleur 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, ma façon de travailler 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 immédiatement.
  • Un système de coûts flexible permet au client de décider les fonctionnalités à implémenter.

Résultats:

  • conscience situationnelle 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 traverse 2 systèmes:

  1. niveau macro: étapes du projet
    (barres noires sur le diagramme de Gantt du projet-type ci-dessous)
  2. 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.

L V M D M S J SEMAINE 1 SEMAINE 2 SEMAINE 3 SEMAINE 4 SEMAINE 5 SEMAINE 6 SEMAINE 7 SEMAINE 8 SEMAINE 9 SEMAINE 10 SEMAINE 11 SEMAINE 12 SEMAINE 13 SEMAINE 14 SEMAINE 15 SEMAINE 16 SEMAINE 17 SEMAINE 18 SEMAINE 19 SEMAINE 20 SEMAINE 21 PROLOGUE ANATOLY IVANOV ET LE CLIENT ANALYSENT L’ENTREPRISE ET LES BESOINS DU CLIENT ANATOLY IVANOV ÉCRIT UNE PROPOSITION DE SOLUTIONS ANATOLY IVANOV ET LE CLIENT AMÉLIORENT ET NÉGOCIENT LA PROPOSITION DE SOLUTIONS ANATOLY IVANOV ÉCRIT LE CONTRAT ANATOLY IVANOV ET LE CLIENT AMÉLIORENT ET NÉGOCIENT LE CONTRAT ANATOLY IVANOV ET LE CLIENT SIGNENT LE CONTRAT LE CLIENT PAIE 20% DU FORFAIT DE JOURS/HOMME SCÉNARIO INTERACTIF ANATOLY IVANOV CRÉE LE SCÉNARIO INTERACTIF: PROTOTYPE OPÉRATIONNEL DU SITE SANS DESIGN GRAPHIQUE (NOMBRE DE JOURS FIXE) ANATOLY IVANOV ET LE CLIENT TRAVAILLENT SUR LE SCÉNARIO INTERACTIF (NOMBRE DE JOURS ÉLASTIQUE) LE CLIENT SIGNE LE SCÉNARIO INTERACTIF LE CLIENT PAIE 15% DU FORFAIT DE JOURS/HOMME PLUS LES JOURS SUPPLÉMENTAIRES ÉVENTUELS CONCEPTION GRAPHIQUE ANATOLY IVANOV CRÉE LA CONCEPTION GRAPHIQUE (NOMBRE DE JOURS FIXE) ANATOLY IVANOV ET LE CLIENT TRAVAILLENT SUR LA CONCEPTION GRAPHIQUE (NOMBRE DE JOURS ÉLASTIQUE) LE CLIENT SIGNE LA CONCEPTION GRAPHIQUE LE CLIENT PAIE 35% DU FORFAIT DE JOURS/HOMME PLUS LES JOURS SUPPLÉMENTAIRES RÉALISATION TECHNIQUE ANATOLY IVANOV COMBINE LE SCÉNARIO INTERACTIF AVEC LA CONCEPTION GRAPHIQUE POUR CRÉER LA RÉALISATION TECHNIQUE DU SITE (NOMBRE DE JOURS FIXE) ANATOLY IVANOV ET LE CLIENT TRAVAILLENT SUR LA RÉALISATION TECHNIQUE (NOMBRE DE JOURS ÉLASTIQUE) LANCEMENT DU SITE LE CLIENT PAIE 30% DU FORFAIT PLUS LES JOURS SUPPLÉMENTAIRES ÉVENTUELS

3.3.1 / Étapes du projet

3.3.1.1 / Prologue

Lors de l’étape du prologue, nous:

  • discutons et analysons l’industrie, l’entreprise et les besoins 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

Lors de l’étape du scénario interactif, je construis un site web fonctionnel très proche de la version finale. Le scénario interactif est un site web en HTML 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 ni les couleurs, ni les formes, ni les images de la version finale du site

Résultats :

  • Un site web 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 HTML 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 — dans leurs navigateurs préférés qui leur sont familiers — et de réagir à leurs retours 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.

  • Presque toujours, 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:

    1. le gabarit de la page d’accueil générale (la home)
    2. le gabarit d’une page d’accueil d’une section (produits, contact)
    3. 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 rapide 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, clarifie la plupart des 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.
    • Souvent, le client se rend compte d’un besoin en photographies, vidéos et textes additionnels et dispose du temps nécessaire pour les produire — en interne, ou en me proposant de contribuer à travers d’autres compétences que je maitrise depuis des décennies (comme réalisateur / opérateur, photographe, concepteur-rédacteur…), ou bien en ouvrant le projet aux prestataires externes supplémentaires.
  • Je représente la conception graphique par des «écrans aplatis»: des reproductions exactes, sous forme d’images JPEG, ou, pour les clients plus techniquement avertis, des écrans Figma, à 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 Figma ou Adobe Illustrator 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 HTML / CSS / JavaScript totalement interactives nécessitent beaucoup de programmation, d’achat de licences de polices, de positionnement graphique et d’optimisation d’images. Toute modification implique des changements chronophages dans le code, les images sources et les termes d’utilisation des images et illustrations.

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 HTML 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 HTML
    • de code CSS
  • Selon le site, j’ajoute également des technologies «côté client»:
  • Pour la majorité des sites web, je génère une proportion importante d’images, de HTML, de CSS et de JavaScript «coté serveur» au moyen de PHP, Node.js, d’une variante de base de données SQL, ainsi que des règles de réécriture, de mise en cache et d’équilibrage de charge de Nginx.
  • Bien sûr, je peux m’adapter à n’importe quel stack technique que votre organisation utilise déjà — peut-être un React SPA ou un système Shopify — tout en suggérant des améliorations. Mon objectif principal reste la satisfaction de vos clients. Oui, l’expérience développeur (DX) est importante, mais l’expérience utilisateur (UX) l’est encore plus.
  • Eh oui, je suis et designer, et photographe… et j’écris et déploie mon code front- et back-end (full-stack), seul ou avec une équipe… aussi proche des principes de minimalisme «vanille» que le projet le permet. Je suis pour la pérennité technologique, la Livraison Continue, de commits précis, le typage fort, des tests rigoureux et une documentation claire. Depuis mes premières lignes de Pascal, à l’âge de 9 ans, en 1989, j’adore la programmation. Cela fait 35 ans de «pourquoi le faire manuellement quand je peux…» et d’autres aventures qui souvent influencent mes idées de design. 😂

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, nous permet de planifier, d’évaluer et d’ajuster — à tout moment — la durée et le coût global de la conception du site.

Ce 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) impacte le budget de manière la plus significative. Le montant total de cette rémunération de création dépend du nombre de jours/homme travaillés:

  • Plus de jours/hommes j’investis dans le projet — changements, ajustements, peaufinages — plus élevé sera son coût total.
  • Plus le site web augmente en complexité — des animations et interactions UI/UX sophistiqués, des solutions de bases de données, des systèmes de paiement international — plus il exige de jours/homme de design et de programmation. Ce qui augmente son coût.
  • Autre paramètre qui influe le coût des jours/homme: le 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 oranges 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 (barres orange).
  • 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 dans la qualité prémium du site.
3.3.2.3.2 / Tâches collaboratives
  • La durée des tâches collaboratives reste élastique pendant le projet (barres vertes).
  • 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:

  1. 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.
  2. 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 approximative du budget n’est pas très rassurant, pour ne pas dire effrayant. Donc, lors 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épond à 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. Avec prise en compte des pourcentages de chaque type de tâche. 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.

Au fur et à mesure 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 un investissement aussi considérable 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 à la 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ées (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 jeter un coup d’œil à la plupart des sites web que j’ai créés lors de mes 25 ans dans le domaine — souvent illustrés par mes propres photographies — dans mon portfolio de design. Certains sont désormais de véritables pièces de musée, sélectionnées et préservées dans des publications de Taschen et autres, comme des contributions significatives à l’histoire du design.

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.

SUIVANT : ANATOLY IVANOV / MÉTHODES / COUVERTURE GÉOGRAPHIQUE

ASTUCE: Pour imprimer les images, cochez «Imprimer les fonds» dans les préférences de votre navigateur.