Operationalizing Design Operations

I have had the good fortune the last few weeks to be speaking with a lot of design leaders about design operations. Great learning opportunites both from my perspective of being forced to clarify my own point of view and from the point of view of learning about how these design leaders have so far thought about design operations, not matter what they’ve been calling it thus far.

Confusions

I have outted a few confusions on my part and clarifications on meaning from others.

Design Operations is not Design Project Management

When I first start these conversations with design leaders I have noticed that many think I’m taking about project management (PjM)for design. At Hewlett Packard Enterprise our UX team had a PjM on the team. She was awesome at cat herding, managing the JIRA tickets and being the front line of our intake system for new work (to name just a few of the things she did for us). While having a role like this is paramount to a well designed design operations system, it is not in and of itself design operations.

Part of the reason of this confusion is that the title Design Operations when you search on a job site invariably will turn up many roles in non-digital design spaces where operations is tied directly to roles focused on delivery. I totally get that interpretation, but I think a digitally transformed organization there is a role (and maybe design operations isn’t even the right title) that is a broader role.

DesOps is Not Really Parallel to DevOps

This is all my mistake. Part of it is that I do believe that a key part of successful part of DesOps is indeed about how to channel design more closely to the core operating systems that enable development to be focused on continuous delivery and continuous integration (CD/CI). I also see parallels in what 12-factor definers of cloud native apps are, to being good principles as a starting point for how we should be re-imagining design operations.

It is a mistake to equate the two for a few reasons.

1. Few designers know what DevOps really is.
2. DevOps is actually a combination of two operational areas: development/engineering and IT infrastructure. Though it could be said it is the operations of IT infrastructure for the benefit of the operations of development. But again, DevOps is a piece of the greater whole.
3. While there are parallels and lessons, if people don’t understand DevOps the analogies don’t help the conversation (see #1).

So what is Design Operations? (DesOps; just for fun then)

Goal(s)

The goal is quite simple and has two parts that are intrinsically related:

1. Set up your designers for ultimate success.
2. Amplify the value of your design investment.

Both are arguably the same thing with slightly different perspectives.

Different types of design leadership

The work I’m doing on the Enterprise UX conference has been an amazing opportunity to think about the different pieces of design leadership necessary to make a design team succesful. My friend and partner in crime on EUX, Uday Gajendar, used the great metaphor of different levels of craft when we were planning this year’s event.

• Tradecraft: The tangible crafting of the experiences themselves. Lead best by principals or player coaches.
• Stagecraft: Setting the scene, creating the immediate environment for success. Lead best by line managers who are driving execution.
• Statecraft: The act of diplomacy and vision. Lead best by executives who are breaking silos, creating relationships, creating a vision and gaining followership for it.

For designers tradecraft exists within our disciplines. Expertise in planning and making have focus within graphic design, interaction design, research, etc. Similarly stagecraft is the realm of the design manager, creative director, and in partnership with program/project managers (titles may vary).

But both of these roles are also focused in a fairly vertical way for the most part. Either at the feature level or the product level. This for smaller organizations might be all the scale they have. For more complex organizations though, there is a need for a horizontal leader. Not just who thinks about the platform or style guides of shared design resources.

So in essence, if a line manager is focused on getting tradecrafts people executing quality of strategic value for a single stage. There is a new leadership that I’ll call “festivalcraft” that is working across a multitude of stages for the benefit of a grander stage.

Transparency

A core component of a design studio is transparency. But in the contemporary digital world transparency is actually not made easier, but made more difficult. For operations to work well, transparency is required. Monitoring systems need to be put in place, that have good enough visualizations so that the right decisions can be made at the right time.

This is piece of the puzzle is not addressed in most design studios today and definitely not in most development environments where designers are working. Design needs similar transparency as engineering teams need and often get from their systems, but in different ways. They need to see each other’s work in real time. They need to see research in a short duration after it is completed and understood.

The pieces of design operations

What do we share?

Pattern Libraries & Design Systems
All your line managers are focused on their products. They have goals to meet for sure. They are starting to get intelligence though that their users are also using other parts of the system. This could be another product, or as simple as utilizing the marketing web site and the support system of a single product company. The different owners of these experiences are starting to argue and fight because a) they are measured on different things and thus have different agendas, and b) they don’t have a way to cross resources over to suppliment where the best resources should be where when it is most necessary. Further, they are hearing cries from users and customers about lack of consistency all over the place. Red buttons mean cancel/end/negative in one place but are positive calls of action in another.

So we all know about pattern libraries and design systems. These help at various levels of complexity of this problem, right? They allow us to control experience elements across channels or products and in essence start the beginnings of creating a platform.

The work of creating a design system is hard, complex, human activity. A good design system is a product in and of itself. It requires a team ideally full-time engaged depending on your scale.

What I mean by “human” is that to have a successful design system requires a ton of sales in order to be successful. Even if it is forced on everyone by some higher power, gaining alignment of goals and requirements. This is why haveing a design leader who can also act as a product manager is important, but it is also important that this person be a designer and not a product manager b/c this person needs to be as responsive to the needs of the design teams themselves as a knowledge broker (thought leaders) as much as a requirements gatherer.

Human Resources
This is a big bucket and has a few sub-buckets to it: recruitment, assessment, development, training.

The reason this is a horizontal is that a design practice across all the areas of your design organization need to be stewarded to maintain consistency, quality, guidance, focus, etc. You need to have your team members transferrable across projects, products, systems, etc. You need to have consistency so that you have clear communication in the roles and responsibilities that cross-functional team members have reliable expectations about how to work and who to work with.

Hiring
Job descriptions, training internal recruiters, assessing external recruiters, assessment criteria across all levels of the design practice, interviewing and candidate review methods, etc.

Onboarding
How team members enter your design practice needs to be designed. This is about how equipment is procured & allocated. Eg. at Hewlett Packard we decided that having a Mac was just too important. A great decision I agree with even though we were working for a Windows PC manufacturer. But the system for procuring non-HP hardware was not designed for. In fact, one could say it was purposefully designed to be a dark pattern. But I would also put back the onus on the design leadership for not designing a new system that they could control given IT’s resistance to support. In this way taking away the sting of entry which is already filled with uncertainty.

Other areas of on boarding include, introductions to IT, to your team, to your cross-functinal team. Being given a mentor to guide you — a go-to person for organizational culture issues, etc.

Would also be good to have a repository that contains the following:

• Links to all the applications you will need to install (if not pre-installed as part of your image). Also, links to any serial numbers you might need as well.
• Links to all the core knowledge bases around the design team, your product team, etc.
• Acronym Glossary
• Links to all the SaaS tools with instructions, tutorials, etc.
• List of training programs and time periods of expectations for how and when to take them.
• I’m sure I can go on. Let me know in comments what you think is missing in this list.

Assessment
I alluded to assessment of recruits, but there needs to be equal intentionality to how you assess your internal team of existing employees. They need to understand their growth path and what they need to do to reach for such growth. They need to understand the difference between goals set against bonuses and raises and objectives set to driving learning, innovation, and delivery. There needs to be a mechanism of fair and reasonable comparison of each other in the leveling of a designer against their expertise and their compensation as well.

Taken from the Rackspace Design Team Assessment Descriptions

A few details to note in the above image to give a bit of context(1):

1. Each role has number of years experience, but also number of years expected in that position before growth to next level.
2. We’ve plotted out where core qualities should fall on a spectrum of proficiency.
3. We’ve summarized each core quality with a simple quote that represents mastery.
4. We published all the levels and distributed them to Human Resources and Recruitment.
5. We also shared them with our cross-functional team leaders to help their teams understand expectations from different roles and responsibilities as well.

These areas + other areas in human resources need to be designed and managed (evolved). They require a feedback loop with collaborators, with HR, and with your team.

Tools

This is a tricky one. There are going to be some tools that are personal; some tools that are for a team; some tools that are for an organization; and some tools that are for an enterprise.

Why would a design team for example say that everyone needs to use the same combination of asset creation tools (Sketch, Adobe CC, Axure, etc.)? The one that always jumps out at me is interoperability. Can the files be used across different tools? The answer is definitely, “Nope!” That means a decision needs to be made if a team is going to be collaborative. If the team is going to create a stencil or library for their design system they will need to do that for every tool and maintain them accordingly. This is not efficient or I’d argue effective. It would be cheaper to train people on a single tool eco-system than it would be to deal with the long term management issues associated with cat herding these and other interoperability issues.

The other thing I get from this is expertise. My team can grow into a self-help mentoring train of experts, teachers, and learners all on a mission to turn their tools into augmented hands and minds.

But there are other tools in question that make up this eco-system that need some level of organizational or team consistency. Here is a small list:

• Collaboration — real-time, async, whiteboard/post-its, feedback systems
• Asset management
• Testing and data collection
• Knowledge management
• Version control
• Networked storage
• Project and resource management
• again, too many to list. Feel free to add in comments.

Too often, many of these tool decisions are delegated to non-designers like IT or development or are just legacy (aka debt) decisions. Look out for fake excuses that might come IT organizations to force you into tools that don’t fit for you. But sometimes, you just don’t have a choice, especially in heavily regulated environments and you need to be intentional in how you overcome these obstacles in your new operations models.

Practice areas: Research & Visual Design

These are interesting horizontal practices. Both from the usability testing side and the more generative research sides. It is different in that on the one hand it is its own practice and depending on your scale you may have these players assigned to product teams. On the other hand it is common to have these both run as services for products to borrow from usually for short stints due to the type of work they do.

Because of this, they need a more intentional in take system with projects, project management system, and more traditional studio operations. They also require practice leadership of their own to maintain quality, keep teams up-to-date, etc. They also have different tool needs.

Research Operations
Visual Design itself is more likely to be integrated into an interaction design or generalized UX role, while research is more likely to be a specialization due to how different its practice is. Research especially has its own operations needs from both a tools and procedures perspective:

• Intake systems
• Subject recruitment
• Client management
• Project management
• Asset management
• Proof of Concept IT management
• Protocols
• Reports
• Data management
• Innovation management

When I was at Motorola, we had a dedicated research team. One of the challenges we had was how do we get all the great stuff we know out into the enterprise? So I helped design and worked with a Drupal consulting firm to execute on the creation of a research data and reporting site that everyone in the enterprise had access to. Reports, Video, and other data behind the reports were all made available with filtering based on verticals, companies, products, etc. It allowed different product managers to gain access to the design research we did on a constant basis and apply the insights we reported to their product workstreams.

When I moved on several years later (several jobs later) we took this idea a step further because we acknowledged that the tool was more than a data consumption tool, but also a data capture tool. How do we get the customer insights from the field, from product manager, from research, from market analysis reports etc. into a single repository and then utilize that repository as a means to gain insights and make those insights actionable.

Unfortunately, I was not able to take this much further. But for a great and similar example, here is a link to the work by Tomer Sharon and his team at WeWork. Further attempts are the work by Nasdaq’s design team, and Aarron Walters when he was at MailChimp managed this with Evernote.

(1) Taken from The Guide to UX Leadership.

The culture

You can’t talk about DesignOps and ignore culture. This isn’t just about your design culture, but your organizational culture. Culture sets up your values. Things that will amplify the value of design are making sure that both learning and empathy can make themselves core values to an organization.

While many value curiosity which is a start. A culture of learning is more than just curious which is a passive trait. But needs to be scientific and intentional about learning as well. This is where Lean Startup ideals come in. Outing assumptions, creating hypotheses, and putting those hypotheses to test in experiments is one version of learning that is growing within organizations. A good one. A valuable one.

Another form of learning is getting outside of the building. Observing people in their world is another valuable tool for learning. This one also generates empathy and the more people who do it within an organization the more easily it gets aligned throughout.

Then there are other aspects to this, too. Data is everywhere these days, but you have to be capturing it, analyzing it, and utilizing it. In essence, it needs to be captured, processed, and integrated into your organization to be an effective tool for learning.

One of my soapboxes for maturing organizations is that if you want to speed up your learning you need to design in your instrumentation. This means, you need to have robust systems for capturing the availble data. These types of tools and system need attention from a design operator to make sure they are maintained, adjusted, coordinated, etc.

To help an organization adjust course from a business/ROI focused organization to one that is tolerant of risk and focused on what can be learned and how to integrate learning at pace is a huge cultural change initiative. Design’s skillsets are in a unique position to help with this culture change through workshop facilitation and other methods. This is the only way I have seen organizations move into become infused with learning and empathy.

The role of DesignOps

There are very few organizations that have a dedicated person who’s job it is to manage “Design Operations”. Also, some have defined “Design Operations” in different ways so even if you see it as a role it might not even be what I’m talking about here.

One organization that has this role is AirBnB and we are lucky enough that they talk about it publicly. I highly recommend you take a look at their take on this role. However, most organizations combine this role into other positions. At HPE, we separated out a lot of the above pieces (and this is not meant to be cumulative) amongst the team of indivdiual contributors and the manager. We were a small team of 10 at our height. I will say that things took a lot longer to get done and a lot of things just never did get done.

For an enterprise with enough scale, when some of the horizontal activies mentioned above start to come into place, you can at first split one of the management roles into this operations role. The manager who is responsible for horizontal parts of your product offerings would be in an ideal position to add to their team the more general focus of DesignOps.

As this role matures, the head of design would isolate this role and begin the process of converting them into a full-time role. The title of this role could be Design Operations, or it could be a role that is titled “Chief of Staff”.

I like the idea that there is a “chief of staff” role, I’ve also heard it called an XO (comes from military as the 2nd officer under a captain). The role is both subordinate to and a partner with the head of design.

I have been told, but isn’t this the role of the head of a design team to do. SURE! it is their job to make sure that it gets done. But their real focus needs to be on the following areas:

• Vision and message
• Evangelism, relationships
• Strategy
• Air cover
• Mentoring, developing leadership

The operations side of things is a drain on their attention. They need someone who has a strong design background who can deal with this side of things. They need a Design Chief Operating Officer for their organization.

Other areas that this role will cover as the team matures are the following:

• Team project management — PMs would report to this person, or the head of PM would report to this person.
• Team communications — mostly internal focused, but might include projects around external focus. It would also include mentoring speakers and community builders. Eventually a communications person would fall here. They might run an internal or even an external blog. They would manage the collaboration sytems like Slack or similar.
• Team culture management — They would keep the pulse of the team culture and play the roll of organizing team wide meetings, team off-sites, etc.
• Team wide critiques — It is important that a design organization has cross-project/product/service sharing on a regular basis, so that they learn from each other.

This is hard

What makes someone a good design operations person is a systems oriented mind, a lot of experience in different design contexts and relationship building tools.

Systems

The operations of scaling anything requires a mind that can map easily against different flows, different stakeholders, and different goals. They need to be able to understand this complexity, clarify it for stakeholders.

Design depth

Solutions are going to come from everywhere, so a connected designer with enough experience who can extrapolate their experience and their connected knowledge pool, against their organization’s specific contexts will have the greatest success.

Relationships

All leadership positions are positions that are about relationships and this is no exception. Nothing will get done with a wide net around your stakeholders.

Understanding & Alignment

Having the skills to be able to take very different points of view and bring them to understand the same system from a common perspective is a tall order. This ability to facilitate those relationships you’ve worked so hard on and bring them to an aligned understanding will be a vital skill for anyone who takes on this role.

Conclusion

For any organization that wants to truly get out of their design investment the highest value they can, needs to make sure that the same attention to operations in other areas of their organization is put intentionally into their design organization. The sooner you do it and with the most amount of intentionality the better your return on your investment will be.

If you have an existing team where moral is waning and too often complaints of obstacles are the norm, your design leader most likely needs help and asking for help is not a bad thing. Get them someone either permantly or even temporarily until your organization can scale, who can help that design leader (or leader of design) to amplify the value your design team produces.