Building a DesignOps Practice for the Organization: Step 1 Determination of Pain Points

What is DesignOps? What are its objectives?

DesignOps, or Design Operations, refers to the operation of design in its simplest form. The main purpose of this methodology is to optimize the design operation, to make it more efficient, and to provide better designs by improving the workflow in accordance with the organizational culture. For this purpose, 3 basic questions are asked continuously; How We Work Together? How We Get Work Done? How Our Work Creates Impact?

How to Build a DesignOps Practice? What Steps Should be Followed?

When creating a DesignOps practice within an organization, the following should be considered:

• Evaluating the organization’s existing design processes and capabilities,

• Identifying the needs and pain points of the design team,

• Ensuring that the DesignOps application is compatible with the processes and culture of the entire organization.

A high-level DesignOps Practice can be broken down into three steps that need to be followed:

1. Research the Problem Space

2. Define DesignOps Value

3. Prioritize and Roadmap

In this article, I will focus on the first step, which is “Researching & Identifying Problems” in DesignOps practice.

Researching & Identifying Problems

This step is perhaps the most important one in creating a strong DesignOps practice. Because an undefined problem cannot be solved. Unsolved problems result in low productivity and low output quality. Therefore, problems should be identified in all aspects. In identifying the problems, all subjective ideas should be converted into data, and subjective ideas should be verified by conducting multiple studies across the organization. All studies should be documented.

So, which studies should be conducted and how?

1. Survey

An organization-wide survey should be conducted. With this survey, answers can be obtained on issues such as satisfaction with current design processes, output quality of the design team, pain points in workflows, and interaction of the design team with its stakeholders. The answers should be reported as organization-wide and teams specific. In this way, the problem area can be determined more accurately. While preparing the survey, the language should be used clearly and simply. For people to respond more transparently in the survey, descriptive information such as name, surname, and e-mail address should not be taken. It is recommended that the survey be tested with at least 2 test takers and get feedback before it is published in the entire organization. At the end of the survey, the overall survey report can be shared with the entire organization for transparency.

2. One-on-One Meetings with Stakeholders

One-on-one meetings should be held with all stakeholders of the design team. Stakeholders should be identified first. These stakeholders can be Product Owners, Front-end Developers, AR Developers, Quality Assurance Developers, etc. In the selection of people, care should be taken to ensure that the design team is the people that the workflow touches. Stakeholder interviews can also be conducted with Chapter Lead, Director, and C Level positions. In addition, interviews can be held with long-term employees who have a high level of knowledge about the organization or the product and know the team dynamics well. In one-on-one interviews, as in a survey, language should be used clearly and simply. It is recommended to test with at least 2 test participants and get feedback before starting the interviews. Generally, not all questions concern all stakeholders. For this reason, it can be planned which questions to ask which stakeholders before the interview. It is recommended that the interviews be scheduled for 15 or 30 minutes. Personal information should be kept confidential, and all answers should be reported anonymously. This confidentiality should be communicated to the interviewee so that he or she can answer the questions more objectively. Sharing these reports across the organization is not recommended in case they contain any clues to the identity of the stakeholders.****

3. One-on-One Meetings with Design Team Members

One-on-one meetings with all members of the design team should be conducted. If the number is not very high (eg +20), all members should be consulted completely. The points to be considered in these meetings are the same as in stakeholder meetings.

At the end of all this step, the survey, stakeholder interviews, and design team interview reports are combined. All data need to be cross-matched and verified. Comments from just one person or a small minority should be treated with caution. In most studies, the verified and identified problems and the reasons behind these problems (to the extent detected) should be reported in detail.

This way, the “DesignOps Problem Space Report” will be completed.