Terme encore méconnu en France, aujourd’hui nous allons parler de DesignOps ; bien que ce terme pourrait sembler être un nouveau buzzword, il est pourtant le résultat d’un besoin concret dans les entreprises.
Le design a souvent été cloisonné avec pour objectif de répondre aux demandes du marketing, voire des équipes projets… Mais rare sont les équipes scrum par exemple qui incluent le design (UX et pas juste UI) directement au sein de l’équipe de développement.
Cela doit changer, le design doit impérativement voir ses murs se casser et devenir l’une des expertises des équipes de réalisation.
DesignOps : definition
Le DesignOps est la contraction entre deux termes : « design » et « opérationnels » ; ce terme fait référence à l’approche devops qui s’est incroyablement développé depuis son apparition en 2009.
Ce terme tout comme sa référence, veut amener à la reflexion de : comment casser les silos entre le design et l’opérationnel ? Des murs indispensable à faire tomber pour considérablement améliorer l’agilité de l’organisation.
Voici les question que cette approche veut qu’on se pose :
- comment travailler ensemble ?
- comment nous accomplissons notre travail ?
- comment notre travail créé un impact ?
DesignOps : aussi un rôle
Comme pour l’univers du devops, le designops est également représenté par un rôle au delà de la philosophie même. Ce rôle représente une personne qui a une expertise sur des outils particuliers qui sont complexes à prendre en main.
Cependant une question revient également sur ce rôle : n’est-il pas justement le rôle à éviter ? Ne risque t’on pas justement de garder des silos en ayant un rôle qui vient souvent se positionner comme une interface ? Une question légitime et pas dénoué de sens.
Mélangeons Design et Opérationnels
Et si l’idéal serait que le design devienne partie intégrante de l’implémentation ? Dans une équipe scrum par exemple, le product owner représente les « besoins utilisateurs »… Il serait logique que la partie Design représente une partie de l’implementation faites par l’équipes de développement (qui veut dire « réalisation » et non « de programmeur »).
Nos organisations aiment les silos et pourtant le scrum est la réponse à la fin de ceux-ci.
Pour d’autres organisations, un éventuel rôle designops devrait être plus un rôle de « coach« , qu’une interface comme cela le devient souvent. Les rôles « interface » n’amènent jamais à casser les silos… Ils amènent plutôt une impression d’évoluer en rajoutant même parfois un intermédiaire supplémentaire. Je vous recommande donc de faire très attention au positionnement d’un designops, si vous créez ce rôle dans votre organisation.
Soyez le premier à commenter