When I speak about my work as a Design Operations lead I often focus on the three pillars of design operations to help ground the conversation in the framework of Process, People, and Projects and the partnerships that unlock more effective ways of working. This is a helpful framework because it outlines the distinct areas of focus albeit broad, and begs the question of designing for change that lasts. As we at Automattic shift to a singular emphasis on the customer we must then accelerate internal alignment which in turn allows us to become more agile, motivated, and energized. As a design leader coming into an organization that is beginning to leverage the value of design, the question I ask myself is – now that a practice of customer centered thinking has been established, how do we start to shift from opportunity identification to design and development? What I do know from having helped client partners shift towards new models of thinking, is that it takes a village.
John Maeda as Head of Computation Design and Inclusion at Automattic, has spent a good part of the past two years focusing on shifting organizational mindset towards utilizing design thinking as a foundation to how we approach our product work. By building a centralizing “force” named Muriel (after the unrivaled Muriel Cooper) the design organization has been able to start to focus on what it means to be principled around Craft, Data, and Inclusion, but also what it means to go through a continued customer centric process of Discovery (learn), Hypothesis (Test), Deliver (Build), Listen (Observe.)
This was well underway when I joined the company, but as I began to move into my own hypothesis phase, eager to move to delivery, my first thought was how can we begin to extract the work that has been done within Muriel to build out a common language that we could leverage in which the entire organize would be able to galvanize around. And so began the work of Muriel as a Design Language System (DLS).
We quickly moved Muriel from a general concept to Muriel as an Automattic-branded Design Language System built with the foundational elements of Material Design. Even though we continually discussed that this would be a non-code-based DLS, I knew that would not be a sustainable model as I had never worked in situ like this before. This could not a design lift alone — engineers needed to be there from the start.
We were fortunate enough to have the Google Material team host our first design sprint. So the internal conversations around who needed to attend and what could we bring to Google to help them understand us better began to take shape. This is where I started to hear music taking shape in the conversations between design and development within Automattic and the WordPress core. Amazing questions like, how can I help, have you thought about leveraging this, how can we best collaborate?
The excitement was palpable before the sprint kicked off, but it was an even bigger rush when we entered the studio at Google with our motley crew of 50/50 designers and developers to the delight of the Material team. So much was learned and shared in those few days, but some of the most salient moments were the connections between our development team and the dev champions for design work at Google.
One of the key exercises we did before the sprint was to come together and focus on our shared objectives and what success would look like. Interestingly enough we were incredibly aligned. For all of our collective efforts we got to place of cohesion, understanding, and focus on a shared goal.
Looking ahead and as we continue to wade through the DLS-building process, I realize how it’s a centralizing point from which transformation can emerge. In my experience, a good Center of Excellence will speak to the company’s vision so that we can all rally around a north star — a place where results can be shared in terms of how it can be implemented. This can shift cultural mindset and ways of working, while fostering a sense of community across all disciplines. It is all of these components which will ultimately free us up to think more broadly about the tools we utilize on a day to day basis to enable new ways of working.
Building a Design Language System is not about design, it’s about partnership, with shared language being the linchpin. At Automattic, we have begun to see design and development speak the same language, much like what was witnessed with the Google design team, and this is by far the most delightful, and sustainable, “shipped” part of the work to date.
Automattic Design 