You don’t need more ideas, you should talk about DesignOps instead
Article, orginally posted on Livework's website (in portuguese), right here.
Ok, let’s not be so black-or-white about this ;)
Your organization might as well need some new oxygen flowing in the form of brand new ideas, but it’s more likely that the inability to move forward with the existing ideas and projects can be far more impactful than generating new ones. And here’s where I now begin (as many of us now do) advocating for execution, constant execution and obsessive execution!
Yes, I believe the lack of follow through on the ideas might actually be starting to hinder service design to go mainstream. Lots of ideas but poor implementation. In that sense, this article is here to shed some new light on a rather new issue among product/service developers, design, innovation and R&D teams alike:
What should happen after my ideation sessions or my design sprints?
In most organizations, especially the more structured ones, quick ideation initiatives like ‘design thinking workshops’ or design sprints have gained a lot of attention in the latest years, mainly because bring together teams that otherwise wouldn't. Also, they generate fresh conversations about existing problems and integrate people to solve challenges. Besides, they give the organization (especially top management) a comforting feeling of moving in the right direction...
However, since they don’t usually expose companies to virtually any risks, rarely go with a systematic process to funnel these the new ideas to the market nor it finds a user-oriented culture needed to put them forth, these workshops tend to have very little long lasting impact in terms of innovation.
The profusion of such workshops and sprints, while it spreads out the word about the design mindset, they usually end up leaving the teams feeling helpless when those new cool ideas never really got to see the light of day.
The organization may be truly committed to innovate but the process, the resources and, ultimately, the culture are just not in place yet to allow real execution.
But, for a moment, let’s suppose you, as the innovator-in-chief, were able to muster all the resources, the skills, the timing, and the culture of empathy and collaboration needed to put forth a proper design process and you even managed to deliver a nice piece of service blueprint, ready to implement. Let’s say you also got the means to actually deliver those products and services to the market, it will still seem as though you’ll have a hard time recreating this ‘perfect storm’ in a systematic way, in order to do proper design consistently over time.
And here’s where the discussion about DesignOps comes into play.
DesignOps: not the same as ‘Design Systems’ or ‘Design Management’
Although having multiple teams putting out designs that make sense with each other and working under a consistent process is an important premise, DesignOps is indeed a bit broader than setting up a 'design system'. It's not even managing the inner workings of the design teams. The sequence below illustrates the downstream path in which a certain piece of design reaches implementation in most of design-adopter organizations today, from defining the high-level design strategy all the way to product/service development. After that, line staffers pick-up from there and sustain its operations, following specific organizational structures.
Unlike Design Management and Design Systems which, respectively, seek to integrate design into corporate management practices and streamline the work within design teams, DesignOps is all about the interface between designers, developers (or technicians of every sort) and product owners to design and deliver a great user experience.
In that sense, DesignOps becomes a crucial discipline to put in place the tools, the environment, the group techniques in order to facilitate all those handovers, team-by-team, to make new design become a reality with more agility, less noise (from the original concepts) and more integration.
DesignOps is not a new design department. It’s “how” interfaces between design, product, engineering are managed. Also DesignOps is about creating a culture of user centricity and agility over time. It puts design not as just another step along the way, but as a continuous ritual of handovers and feedback.
Having said that, it is fair to say that DesignOps has the potential to be a game changer in the ‘design thinking’ game, putting into perspective that designing for businesses is much more that just ideation and design sprints.
If you feel like, please leave your thoughts down below and let's keep this conversation going! :)
Article inspired by talks with the greats Luis Alt and Doug Cavendish.
