Blog Search
Press Shift + F on your keyboard to open the blog search on any blog page.

Solving Technical Challenges of Design Teams

Written by 
Jim Kalbach
January 20, 2017

Design is serious business. More and more, companies are realizing that good design isn’t a nice-to-have: it’s mission critical.

Yet changing an organization to be design-centric is no easy task. In additional to shifting perspectives and mindsets, there are logistical and technical challenges.

DesignOps” is a new field that looks at the tools and instrumentation needed for modern design teams to succeed.

We were fortunate enough to catch up with Dave Malouf, a thought lead in the area of DesignOps. Dave is a founding member of the Interaction Design Association (IxDA), and has held design leadership positions in several large organizations. He’s also the co-chair of the upcoming Enterprise UX Conference.


In this interview, he outlines what DesignOps is and why it’s important.


JIM: Great to have you join us for this interview, Dave! Thanks for you time.

DAVE: Thanks for asking me to do this interview. As you know, I'm a big fan not just of the MURAL product, but of the company behind the product as well. Y'all have been so incredibly responsive, and friendly to all my requests no matter how outlandish.

I also really appreciate both y'all's spirit of listening and for sharing back what you've learned from your customers. Thank you.

JIM: Thanks, Dave! Now, tell us a little bit about yourself and the various design leader roles you've had. And what are you up to these days?

DAVE: I think I'm best known for helping to found and lead one of the largest design organizations in the world--Interaction Design Association (IxDA). Through that work, my design leadership has been more focused on creating a design community of practice helping designers learn from each other.

Most recently I've been focused on design education through the Interaction Design Education Summit and working on my next plan for IxDA.

But I've been doing design work in digital domains since the mid 90s. I got my start during the first internet boom as a web designer turned UI designer turned producer turned information architect. At the close of the bubble (the first big pop) I was in my first leadership role.

After going into education for some time, I returned to industry in a new role as Head of Design Practice, and in my most recent position, I was back at being a principal leader. This time focusing more on strategy and insights, my role was to build a new practice into the organization itself in a way that helped infuse user-centered design into the organization.

Now I put all these puzzle pieces together. I'm working with organizations that want to level up their design teams whether by consulting on the operational aspects of a design team, working cross-functionally, building in new workflow or tools, etc.

It can also mean training, mentoring, and coaching teams; and/or, helping organizations strategize how they are going to build their design teams, assess future candidates, plan skill sets to roles, and do all of this against long range roadmaps.

Lastly, I help organizations create and achieve strategies against their most-desired outcomes.

JIM: What have you learned along the way in terms of what makes a successful team during your career?

DAVE: I have learned to trust the idea of focusing on a culture of learning over a culture of revenue and other funnel metrics. The more we can create operations that allow us to maximize learning from the work we are doing and then turn around those lessons into new execution, the more successful organizations will be.

This is a team sport for sure, and designers and beyond all need to work in sync to make a culture of learning take place throughout an entire enterprise.

DAY 1.02_40_34_06.Still118
Design is a team sport

JIM: Impressive! And thanks so much for all of your contributions to IxD and design education over the years. I'd like to zoom in on that last bit: design operations. You coined the term "DesignOps," didn't you? What is that exactly? How should we understand the concept?

DAVE: I'm not sure I coined the term. I'll let someone with better Google search capabilities determine that. But I would say I'm an early thinker/doer on the topic.

DesignOps is an attempt by some of us who have been most engaged in Cloud Computing and DevOps (Developer Operations) to take those same mindsets and apply them to Design, but do it in a designerly way. But it is all so new and even the voices talking about it are all talking about different parts of the Elephant (Eight blind monks describing a different part of an elephant).

DesignOps has many parts. (Image on 8 blind monks identifying an elephant from it's different parts).

JIM: What are some of the key aspects that fall under the term “DesignOps”?

DAVE: There are a few things to know about DevOps in order to understand DesignOps. Then there are a few more things about how design ops can make design execution better and make design execution tie back into DevOps more effectively/consistently.

For example, for the last 3 years I've been living cloud computing. My work at Rackspace and then at Hewlett Packard Enterprise (HPE) had me burrowing pretty deep into the rabbit hole that is both cloud computing and DevOps. A great place to start is understanding what application architects call 12-factor.

Without going into details, the 12 factors that make an application "cloud native" describe the operational and design elements of application so that it can not only be deployed as quickly as possible, but so that it can scale too.

JIM: Sounds technical and complex. Can you elaborate a little more?

DAVE: Yes, this is probably one of those moments when you shake your head and sense that we are just that much closer to the singularity.

12-factor applications have been used in DevOps circles as a certification system, but the more advanced DevOps people maintain it as a set of principles and have even expanded on it, sometimes offering more factors than the original 12.

When you look at the factors,they speak to operational needs, processes, tool descriptions, and sometimes even team management (implicitly). Their goal has been optimization but without cloud-native applications, organizations like Facebook, Amazon, Google, etc. couldn't move at the pace they do.

DevOps has become the life-blood of continuous deployment/continuous integration (CDCI) which in turn is the engine that drives lean hypothesis-based learning cultures.

THIS is when it became exciting for me and where I started thinking about a few of my own. The biggest one is "all deployed code needs to be instrumented." If we can't measure experience, we can't learn. Now great DevOps teams do this anyway, but as a researcher who wants to learn as much as I can from what is deployed, I have found that being instrumented has been the biggest stumbling block to continuous learning.

The tools are there, the processes are easy to deploy, but we need them in place if we are to learn.

JIM: So what exactly does all of this mean for DESIGN operations?

DAVE: Design has an obligation to be a part of the continuous delivery/continuous learning ethos that the best innovative organizations are driving forward. My interviews with folks over the last 2 years has seen little involvement from designers in this regard.

Yes, we are taking on Lean UX (YMMV), but we are seldom doing it as an engaged part of a DevOps team from architecture on up. THIS is probably way off in the future for most design organizations.

Moving downstream a bit, design operations is this idea that I experienced when working in an industrial design studio for a decade or more. It was a rare studio where the in-house ID team created an operational model where design controlled the outward facing experience no matter what.

Yes, everything was a collaborative compromise, but unlike other device shops where mechanical and electrical engineering would make decisions after design "was complete" and never reviewed the impact that had on surfaces until it was too late.

This means the team designed in one tool, but then transitioned to another tool that engineering worked in. While in that organization the digital design team tried to do something similar by taking advantage of what was coming out of Microsoft at the time (we were an MS shop).

With XAML and .NET4 designers had a markup language to control even fairly complex pieces of the surface, while the engineering team could attach that XAML code to C# or similar languages. Yes, it wasn't Lego simple but it did lead to a new compelling collaborative workflow process which directly impacted the ability of the design team to execute design intent at a higher ratio.

What I'm getting at here is that the interfaces between development and design need to be understood, codified, and principled. The easy way this has been done has been to say, "this is how developers want you to work, so work this way." AKA Do it in JIRA and GitHub. UGH.

JIM: What are some of the day-to-day considerations that go into DesignOps?

DAVE: On an everyday basis, the types of operations I'm thinking about are much more mundane. Design Systems for example have been all the rage, but having been an advocate of Pattern Libraries for a long time and having seen both these libraries and full design systems fail in organizations, I've taken a look at how these are another important step in the operations process.

Nathan Curtis of Eightshapes is my favorite thinker/doer on this topic, so I suggest people look up his writings, go to his workshops, etc. Here is a talk he gave at Enterprise UX on the topic last year.

But there are so many tooling, process, workflow, etc. questions that we haven't optimized to meet the needs of the accelerated digital native organization. Further, we haven't really taken advantage of digital and AI to facilitate better and accelerated design research either.

This last point was central to the work I was doing at HPE. The challenge is getting from data to insight in a way that the whole team/organization can equally understand that insight, or at least commit to following through on its truth. I really love Tomer Sharon's recent take on this.

In parallel, Tomer's team at WeWork and I have both used a tool called AirTable to collect, collate, and hopefully curate data into nuggets of insight. My personal goal is take a tool like AirTable which has a rich API and connect it to a visual information presentation tool like either MURAL or Smaply to create visual representations of nuggets in an accelerated digital way.

I've also hypothesized about how tools like Watson (IBM) or Vertica (HPE) could be used to apply an AI layer on top of collected data to surface the previously biased covered aspects of data collection to get to real insights.

Visualizing work in MURAL, in this case a Lean UX workshop with remote participants

JIM: Clearly, this changes the nature of design teams. What’s the impact on team development?

DAVE: How we build a team, grow them, connect them, assess them, etc. is a big operational area of concern and is probably, for me as an educator, the one that I am most attracted to taking on personally.

In the end, the question I'm trying to answer is, "How can we best set up designers and design teams, to have the greatest added value for the organizations they work for and for the humans who design on their behalf?"

Or more simply, "how can we set up designers for greatest success?"

I think the first "next step" is either for a community of practice, or even just a business to develop the principles for their design operations. I'd love to be a part of that.

JIM: OK, so there's a lot behind "DesignOps." But it seems to me that remote design collaboration - an increasing reality in many orgs - is also a complicating factor to consider. How does preparing for and improving remote design collaboration play a role in DesignOps as you see it?

DAVE: Oooo! This is a favorite topic of mine. There are some great thinkers on the topic of remote work, design or otherwise.
But when it comes to remote design, I don't think there are agreed-upon specifics.

On the flip side, I also don't see a lot of argument either. One place where there is agreement is that, while remote is a must have in almost every environment I have ever worked in (even in those that claim they are co-located), the tools all suck. Truly. I'm sorry to have to say this to you, who are working so hard on the problem space itself--and thank you for taking this on--but the reality is that almost all the tools for dealing with all manner of asynchronous and synchronous collaboration fail in some important regard.

The reason why this is so important to design is because design is subtle. I'm not suggesting that development and product management don't have their ambiguities, but the density of those nuances is substantially less. Design is emotional both in its creation and in its output and emotion is very difficult to communicate face to face, let alone over an abstracted piece of technology.

JIM: Can you give an example to help us understand that better?

DAVE: Let's take something simple like a wireframe of a single screen in a single state. One of the simplest units in digital design, right? But if I put up a wireframe say on AxShare, Invision or UXPin or other collaborative tool built for just this purpose, I could end up with a ton of side conversations outside the initial intent of why I was sharing in the first place.

These conversations become distractions (rabbit holes so to speak) that we get dragged into and then we hate the tool because it didn't focus us well enough.

Part of the problem of remote design, or even co-located design is that people don't or can't share passively. When I'm working with a team, the team will give me the best feedback, instruction, and even questions when they are part of the design process implicitly.

However, in remote contexts, and unfortunately too often in co-located contexts, we have leaned too heavily on digital collaboration tools to abstract those moments away to only points of invitation.

The classic error of the designer is to only invite interruption, interrogation, instruction, etc. when they are "ready". "Ready" is the sin of the designer. Review meetings, or "up for review" invitations are a necessity to drive people to criticism and review, but cannot be the only means of doing either.

When design wasn't digital, Graphic Design was done with X-acto knives, and industrial Design was done in blue/pink foam. It was all done out on tables where everyone could see everything going on. Interruption wasn't invited because it was inevitable.

Digital Design has caused us to focus on monitors and we have lost this "passive transparency" into the work going on around us that the studio was built on. People like Bill Buxton saw this happening early on and tried to create a means for everyone in co-located studios to see everyone else's desktop in real time on large panel screens.

About a decade later, I tried to take this on with a start up that would create a twitter/slack-like stream of our "studio's" work. I still think this is the model of remote collaboration, at least around the core task of crit and review, that is missing from our toolkit.

Design Studio template in MURAL to help with remote design (click to access template)

JIM: Let’s talk about about that toolkit a little more. How have tools enabled remote collaboration and what’s still missing from them?

DAVE: Putting aside my criticism of the existing tools, Invision, UXPin, etc. have advanced the abilities of the remote worker tremendously. Add in the prevalence of Slack (with its own set of signal:noise issues) and the remote or just abstracted product team can work better than ever. We are definitely better off today than we have been before.

My criticism focuses on two aspects:

  1. The lack of subtle communication in remote tools, especially those for reviewing design.
  2. And the 10min rule. All real-time conferencing software has a 10 minute lag on the start of their meetings until the technology is figured out. This can be expanded more generally to be about the technology not quite ready for prime time effect. Tools like boardthing, MURAL, realtimeboard, etc. are great, but each has technology and design glitches that make adoption across an organization difficult.

But as I've been remote in my last two positions, I have learned a few things that help design organizations generally:

Tools are the key. They have to be prescribed at the department level. Whenever design and product and development all use different tools it causes problems.

But the tools cannot be dictated by any one group. Invariably development wins because they are the largest group and that doesn't actually lead to the best tools for everyone. What happens when every team or person picks their own tools is that you end up with tool-itis. That is you enter the realm of "not another tool" way too often. This is where having a role of tools and operations comes in handy.

At HPE we had a tool-ambassador that managed all tool research for the design team. Otherwise, tools end up being adopted by whim as cultural shifts allow.

Don't rely on Slack. Use it. Its great. But it is a tool for extroverts and those who have figured out for themselves the special skill of managing signal: noise ratios. It really doesn't work for everyone.

Avoid MS Tools at all cost. I'm sorry, There isn't an MS tool for collaboration worth anything. They all fail and don't fall for the old "But we do everything on MS for scale savings" effect. It's more like "scale of disaster".

JIM: We agree that tools are only part of the challenge. So, what are some of the mindset and process challenges that go along with having the right tools for remote design?

DAVE: If one person is not in the room, no one is in the room. If you are going to allow remote people, or have people stretched across satellite offices, then everyone is officially remote. It is better that everyone meet at their own desk then to have 10 people in a conference room and 4 on a screen (no matter how awesome you think Cisco or Polycom are).

If one person isn't in the room, no one is in the room.

The people who are at their desks can't participate and the meeting's total value goes down tremendously. This is particularly important for any type of working meeting. If it is just a presentation, then it is less important.

Work needs to be posted all the time to spaces where teams have access to them. People need to work in these spaces instead of working locally and posting when they think it is ready. Real-time state changes need to be visible and available for comment.

Tools like Dropbox, Box, etc. are a good start, but former tools like Pixelapse and LayerVault had more of the story for designers covered. GitHub is building in some interesting designer actions, but isn't there yet. But whatever you use, work there. Sync passively. InvisionApp does a ton of this workflow well between PSD and Sketch files for example.

Tools like Slack and other streaming conversation tools are best for cultural engagement and less so for actual workflow engagement. This is both an undervalued important part of remote collaboration and a problem because people don't see this as valuable.

This problem is amplified if they work in separated offices, as opposed to all being remote. Offices create a sense of connection with the wrong team members.

Make time to "think" together and "work" together. This is where tools like MURAL have their biggest strengths. As visual thinking and collaborative working tools for both synchronous and asynchronous communication, they are essential for any type of separated teams.

I have noticed, though, that they work best for synchronous sessions as opposed to asynch models. I've tried, but unless the team is engaged around the tool it is hard to get asynchronous adoption.

In general, none of these tools has the fidelity of a digital whiteboard that I'd really want. A vector whiteboard with the ability to add objects, custom canvases, etc.

Lastly, I'll say, externalize your workflow. Articulate it specifically as a set of guidelines (not laws) that the organization follows. The workflow addresses roles (not people), activities, tools, objectives/end-points/gates, etc. Too often, these are left unsaid and especially your junior team members (or those who are onboarding) have no reference points for engaging the team.

So that's what I'll say today about remote design teams and generally remote teams, too.

JIM: A lot of what you just described - the instrumentation of products and tooling for remote work - sounds like it requires a developer. What should design teams do: hire a tech team just for DesignOps? How can teams get the right know-how to operationalize design they way you've described, or even just get started?

DAVE: As in all things, just getting started should be done as leanly as possible. Keep investments as small as possible, and do as much as you can with what you currently have.

If there is any single role I would hire for, it would be for outside help to make the organization understand its current strengths and weaknesses and help set a strategic plan for how to move forward. This person could then manage the tactical program of change management that will need to take place.

Regardless of how you resource design ops, someone needs to be assigned the role and responsibility for leading it.

The idea that your design operations will need extra support seems kinda obvious to me. Design has specific people who are called DevOps administrators who often have entire IT organization that they make service requests to, which then get budgeted back to the cost centers or to the global operations team. Most of what we are looking at is more administrative than it is engineering resources in terms of outside-of-design resources.

For example, to set up instrumentation is usually about choosing an off-the-shelf product that needs either consulting or IT resources to integrate it within your existing products and tools. Remote tools at most should need sys admin (security) to set up single-sign on protocols and then manage rights at the administrator level, so that design leaders can then manage downstream from there. Many younger organizations won't even need this.

The real work is the setup of governance and platform artifacts that will most likely have to be done by siphoning part-time resources from your existing design team or the creation of a product team dedicated to horizontal operations that works directly for the design, product, and development teams.

Look at the best practices for creating and managing design systems. The tooling is usually GitHub or similar. Someone has to manage the repository, the pull/push requests, comments and requests, etc.

Of course, GitHub doesn't allow for some core functionality that would make it even better for managing and creating design systems, but it does "enough" to start things up, create hypotheses and build alternatives slowly and leanly to learn what knobs make the best adjustments in amplifying the value of your design organization.

JIM: Start small, and grow into it - I like it. But what's the ROI (for lack of a better term) of DesignOps? Some organizations won't see the value, and designers may have to make a strong case for it, even for the minimal effort. What's the logic or business rationale that they can argue with?

DAVE: Totally a reasonable question and a question we all have to answer. This isn't just for its own sake b/c it sounds cool. This is about taking design of software to the same levels of digital transformation as the construction of software itself, or ideally about merging design and construction eventually. So what are the value propositions we are talking about in any digital transformation activity:

  • Optimization, which is just a multi-syllabic word for reducing costs.
  • Velocity-not for its own sake, but to be learning more quickly
  • Innovation-If we can use software to enhance our ability to capture, curate, analyze and synthesize data across the enterprise, our insights can be more accurate and relevant.
  • Engagement-engaged employees are better employees.
  • Accuracy-If done well, it will increase the differential between design intent and design execution.
  • Quality-If done well, like DevOps does, by creating a more direct line of accountability quality increases.
  • Customer value-If design, dev, product all run in top shape, the customer ultimately will benefit. Better value for customer will convert to better value for the business.

JIM: Thanks, Dave! Any final thoughts you want to add?

DAVE: Yes, the head of the curve of design maturity is figuring out how to provide the unique value of design without the rest of the organization feeling like it is draining value in other places.

The next stage of design maturity is to amplify design value because design is not seen as a separate part to be added on, but a valuable component of the organization's DNA.

Just like today we'd never consider a pencil or TV technology, but just a part of our lives, so tomorrow organizations will feel uncomfortable without design being a part of their natural state of being. Design operations as one of its goals is to reach to attain that state.

About the author

About the authors

Jim Kalbach

Chief Evangelist
Jim Kalbach is a noted author, speaker, and instructor in customer experience, experience design, digital transformation, and strategy.