Over the past few months, a series of conversations regarding design operations (DesignOps) has been gaining steam in some local channels. While many organizations, and even smaller teams, understand the need, many do not have a framework or structure within those organizations to produce operational structures for actively maturing design and research needs. Mostly noting these gaps due to a lack of senior experience, consistency in design/research credentials, and/or metrics befitting the business’s specific ROI rather than “design vernacular.” Developing or maintaining a structure for applying repeatable, profitable, and professionally traceable design operations is quite similar to discovering business models inside of a (hopefully, currently successful) business. However, upon such a structure, many businesses might find these structures also invite the prospect of what specifically disrupts their business model.

What follows is part of a series of notes speaking to structuring and shaping design operations.

sketch of potential framework for design ops

The Organizational Structure

The challenge for design operations, and research operations, doesn’t simply come from lack of a framework, but just a lack of attention to shepard its development. It is It’s more possible therefore that organizations wishing to implement some framework should probably start with a two-pronged approach: understand the needs on the project level from a macro standpoint, and then from the executive standpoint create structures that allow for validation, continual discovery, and the shaping around such framework skeletons.

  • Tasks
  • Management
  • Drivers
  • Decision Points
  • Delivery

Each of these areas have a specific shape. However, structure is going to depend on the ability of the organization to capture quantitative and qualitative activity in consistent manner. It’s possible that this comes from an executive facing posture. In this way, governance and deliverables for current projects are disrupted in a minimal manner. At the same time, activities happening on the project level are where task, drivers and delivery get their validation.

This list is conceptual, and mostly aspirational, but could also factor into what organizations want to put together in a near-immediate fashion.

This list also lives in a little bit more detail for some of the projects that we are looking to be engaged in. So some of the secret sauce will have to wait until a few case studies, or other future articles.

Chief Design or Chief Experience Officer

The executive office needs to be fully invested in this. This might not where the vision comes from (thinking: vision might be generated a level below, but the executive support is what drives org investment) but this is experience — measured, maintained, and design/research understood as a profitable member of the organization. And as such, the executive sponsor takes a three-headed view of operations, each sufficient on their own, but hooked into one another for the entire story.

  • Design
  • Experience
  • Research

Early thoughts have these being led by a single individual. Directly reporting to this person should be a team who are the vision makers, and who also hold the most responsibility and accountability for research outcomes, design experiences, and user/consumer safety. In the notes, leaders in these departments/practices are described as:

  • VP of Design / Design Principal
  • VP of Experience / Experience Principal
  • VP of Research / Research Principal

Now each of these roles seem pretty similar at one view, but they are definitely different and the arrangement of them should indicate this. Specifically for those folks who are call advocates, you could think of them as director-level, but with evangelist/principal influence (indeed, inspired by this tweet thread). This would be the non-management direction for those persons who are mid-level who are looking for senior-level roles.

On the other hand, vice presidents are to be more responsible for handling the business — governance, yes, but also the business. In order to make sure things do not fall away from the development needs, having liaison roles makes a good deal of sense, or at least it did when initially writing notes on this.

Connecting to thr Rest of the Org

Alongside those three would be a series of liaisons and advocates from other parts of the org which shape how design integrates into the rest of the business. These are described as:

  • Security Liaison
  • Accessibility Guidance Liaison
  • Research Advocate
  • Developer Advocate
  • Design/Experience(IxD) Advocate

There’s a bit more to this, but the shape of this team more or less looks like the top end of a professional ladder for those persons who are within design and research professions who end up becoming either managers or principals that have an influence on the operational aspects of design and research (that tweet thread again). A working assumption is that many organizations who work in unstructured spaces, or who are looking to leverage digital transformation (whatever that supposed to mean), could potentially use a model like this to not only improve design and research outcomes, but also create a path for maturing their people to be able to fulfill those operational goals.

What else is possible with this? Maybe a part two, maybe just let loose on a few orgs to build it (wink).