Pourquoi les concepteurs devraient utiliser des diagrammes C4

Les concepteurs n’ont pas besoin d’être des architectes, mais dans des systèmes complexes, la plus grande victoire de conception pourrait provenir d’un diagramme C4 partagé.

Les concepteurs n’ont pas besoin d’être des architectes. Mais les intelligents collaborent avec eux.

Dans les systèmes complexes, FIGMA seule ne vous fera pas clarifier. Les diagrammes C4 seront.

Votre plus grande victoire en conception pourrait ne pas provenir d’un seul écran. Il pourrait provenir de s’asseoir avec un architecte de plate-forme, des boîtes à dessin et des flèches.

Le contexte est complexe

Lorsque vous construisez des plates-formes d’entreprise à grande échelle, la plupart des décisions clés ne sont pas prises au niveau de l’interface. Ils sont fabriqués au plus profond de l’infrastructure, bien avant que quiconque ne parle de flux ou de fonctionnalités.

Dans des domaines complexes, l’architecture façonne tout: pipelines de données, sécurité, intégrations du système et protocoles. Ces systèmes sont construits pour la fiabilité et les performances en premier. Cela signifie que UX arrive souvent en retard, après que des décisions majeures sont déjà prises.

Dans la construction, les architectes sont des concepteurs et des ingénieurs. Dans le logiciel, l’architecte est généralement un ingénieur logiciel avec la propriété du système et l’autorité de prendre des décisions techniques.

À moins que les concepteurs ne comprennent cette pensée au niveau du système, ils sont bloqués en concevant des contraintes qu’ils n’ont jamais eu la chance d’influencer.

Que sont les diagrammes C4?

Un diagramme C4 est comme Google Maps pour votre base de code. Il montre votre système à différents niveaux de zoom – de la vue d’ensemble des détails au niveau du développeur.

Voici comment cela fonctionne:

Niveau 1: contexte
C’est le monde dans lequel votre système vit. Qui l’utilise? Quels autres systèmes interagissent-t-il? Ce niveau aide tout le monde à comprendre pourquoi le système existe et quel travail il soutient.

Niveau 2: conteneurs
Ce sont les principales parties à l’intérieur du système: applications WEB, API, bases de données, services. Il montre comment les responsabilités sont réparties à travers l’architecture.

Niveau 3: Composants
Zoomez dans un conteneur pour voir de quoi il est fait. Vous trouverez les éléments de construction internes: modules, services ou pièces d’interface utilisateur qui fonctionnent ensemble.

Niveau 4: Code
Il s’agit de la couche d’implémentation – classes, méthodes, attributs. Souvent généré directement à partir de votre éditeur de code.

En tant que designer, votre travail vit souvent au niveau 1 et 2. Si vous avez fait des recherches UX, demandez-vous:

• Cette perspicacité utilisateur est-elle visible dans les diagrammes C4?
• Y a-t-il des diagrammes disponibles?
• Sinon, pouvez-vous aider à les créer ou à les mettre à jour?

C4 n’est pas uniquement pour les ingénieurs. C’est une carte partagée. Assurez-vous que vos idées de conception sont là-dessus.

Vous voulez en explorer plus? Visite c4model.com.

Le moment où Draw.io Battre Figma

J’ai fait exactement ça.

Je travaillais comme leader de conception mondiale sur une nouvelle opération à distance et une plate-forme IoT dans l’industrie pétrolière et gazière. Notre défi? Créer des logiciels qui permettraient aux opérateurs de travailler à partir du bureau au lieu de la plate-forme. Cela signifiait la gestion des flux de données en temps réel, la connectivité des bords et l’intégration avec un mélange d’applications nouvelles et héritées.

J’ai eu une excellente relation avec l’architecte de la plate-forme, et c’est à ce moment-là que j’ai rencontré les diagrammes C4 pour la première fois. Au moment où il m’a traversé un, j’ai pensé: Attendez, c’est mon travail!

Il cartographiait les mêmes systèmes et flux de travail, mais d’un point de vue technique. Et j’avais des informations supplémentaires – ce que les utilisateurs essayaient de faire, quels outils ils ont utilisé aujourd’hui, comment nous devons nommer des choses.

Nous avons réalisé qu’en collaborant tôt, nous pourrions couvrir le problème des deux extrémités. Le design pourrait éclairer l’architecture et l’architecture pourrait guider la conception. Cela a facilité le travail de tout le monde. Moins de surprises. Meilleur alignement.

J’ai passé plus de temps dans Draw.io que je l’ai fait à Figma. C’est là que la magie s’est produite.

Influencer l’impact

Aller sur un roadshow avec un architecte était nouveau pour moi. J’ai dû intensifier mon jeu.

Une plongée profonde technique n’est pas la même chose que la construction d’un parcours conceptuel des utilisateurs. Et dans beaucoup de ces ateliers, je ne savais pas ce que signifiait la moitié des acronymes.

Mais l’avantage de collaborer tôt était que je pouvais poser des questions aux bons moments. Ce sont de grandes décisions techniques avec des conséquences à long terme.

Et même si je n’avais pas les réponses, je pouvais apporter des preuves, soulever des préoccupations des utilisateurs ou contester des hypothèses qui n’avaient pas encore été remises en question.

Je n’étais pas là pour repenser le système. J’ai aidé à le façonner.

Et parce que je travaillais côte à côte avec l’architecte, j’avais l’une des voix les plus fiables de l’organisation de mon côté. Il avait des décennies de crédibilité. Il connaissait le domaine. Il avait vu ce qui avait échoué auparavant et pourrait nous aider à éviter de le répéter.

Dans les projets antérieurs, je n’avais pas ce genre de collaboration. Il y avait des tensions et des malentendus. Cette fois, le partenariat a tout changé.

Et ce que j’ai réalisé, c’est le suivant: lorsque les concepteurs aident à façonner les bases techniques, le travail de l’interface utilisateur devient plus facile plus tard. Parce que la fondation est plus forte. Et il est construit en pensant à l’utilisateur.

Comment commencer

Si vous êtes un designer, commencez par découvrir qui est en charge de l’architecture. Ce pourrait être un architecte. Ce pourrait être un développeur principal.

Allez leur parler. Demandez comment ils visualisent l’architecture. Demandez s’ils utilisent des diagrammes C4. S’ils le font, demandez à le voir. Dites-leur que vous souhaitez collaborer et construire une carte partagée du système.

Lorsque vous expliquez les conceptions, utilisez leurs diagrammes. Mettez-les dans des critiques de conception ou des séances de planification de sprint. Se référer à eux dans le raffinement.

Vous pouvez également l’esquisser vous-même, en particulier les niveaux 1 et 2. Si vous avez fait des recherches sur les utilisateurs, vous savez probablement déjà qui utilise le système, ce dont ils ont besoin et comment ils interagissent avec. C’est un contexte et un aperçu au niveau des conteneurs.

Planifiez une session avec le propriétaire de la conception du système et partez ensemble. Vous n’essayez pas de faire leur travail. Vous essayez de créer une compréhension partagée.

Même si vous ne dirigez pas de stratégie ou profondément impliqué dans l’architecture, aider à visualiser le système gagne la confiance. Cela aide tout le monde à rester sur la même longueur d’onde – même si tout ce que vous faites est Rendez leur diagramme bien.

Si vous êtes un architecte ou un développeur qui lit ceci: invitez le concepteur.
Parcourez-les à travers votre diagramme C4. Demandez ce qu’ils voient. Demandez ce qui manque. Les concepteurs apportent des modèles de recherche, de langue et mentale qui amélioreront vos diagrammes.

Que vous conceviez du code ou que vous concevez des flux, vous concevez toujours un système. Vous n’avez pas besoin d’un nouveau processus. Collaborez simplement. Partager. Se souciez de faire les choses à tous les niveaux.

Clôture: pensez en couches

Une grande architecture se produit lorsque la conception et l’ingénierie fonctionnent ensemble.

Dans les systèmes complexes, vous avez besoin de clarté. Vous devez voir ce que vous construisez. Vous avez besoin d’une carte.

Les diagrammes C4 sont un moyen puissant d’y arriver. Ils aident les équipes à collaborer à travers les rôles, à zoomer sur le code en cas de besoin et à tout attacher au contexte.

La clarté est le fondement de grands logiciels. Et lorsque les architectes et les concepteurs co-créent, vous aidez à connecter chaque couche – de l’infrastructure à l’interface.

C’est ce que signifie penser en couches. C’est ainsi que vous concevez de meilleurs systèmes.

Couche comme un dev.