Operationalise product design to empower engineers to move faster

Investing in product design (i.e., user experience and user interface design) can lead to fantastic outcomes for product development teams of all sizes because it reduces the number of iterations required to produce a great product or feature. However, most product companies approach product design in manner that excessively slows down the development of new solutions and blows out budgets. This has led to product designers being ostracised from many initiatives and decision-making processes/rituals. By embracing a DesignOps approach to product design, companies can instead move faster and get more done with less resources.

Historically, user experience/interface design has been thought of as a distinct stage of the software development lifecycle. After an idea had been prioritised and outlined, and before development started, designers would conduct user research and visually design how a feature should work. This meant that the design phase could delay the engineering phase by weeks or months, frustrating management, product managers, engineers, and stakeholders. With the ascent of agile software development, many steps have been eliminated from the typical software development lifecycle in the spirit of spending as much time as possible building rather than planning, testing, and releasing. This industry-wide transformation has left product design in an awkward position. In most companies, it has either remained a distinct and anti-agile phase of the delivery pipeline, or it has been nearly eliminated from the process all together. Both of these approaches are bad for product development outcomes.

Product, engineering and design leaders have been slower to operationalise the product design process than they have other stages of the software development lifecycle. I believe this has happened because product and engineering leaders do not understand product design well, and many designers believe that design should be a distinct phase of the delivery pipeline. So, rather than adapting to agile development philosophies, many designers have instead fought to maintain the status quo of user experience/interface design. In contrast, the most effective teams I’ve worked with have all ratified the agile movement and moved towards DesignOps, a similar transformation to the DevOps movement.

DesignOps is a powerful approach because it allows teams to operationalise product design, which removes it as a roadblock in the development process. This benefits designers massively because it kills the perception that design is expensive and slows teams down, therefore giving designers more of a seat at the table than they ever have in the past. A product team that has fully embraced DesignOps is one that has established standardisation in every area of product design (as per DRY software engineering principles). They spend most of their time building tools, reusable design patterns, and guidelines that empower designers, product managers, and engineers to make great design decisions. This means that most design work is done outside of the software development lifecycle and is focused on building dependencies that help to speed up the process, rather than interjections that delay value delivery.

Getting started with DesignOps

Below are some principles that teams can adopt to move towards DesignOps.

First, lose the assumption that engineers cannot make design decisions. Product designers should want to get out of the way of the software development process. For this to happen, engineers need to make their own decisions around how interfaces should look and work. Enabling this is the goal of product designers in a DesignOps environment. They achieve this by building reusable patterns, best practice guidelines, and by coaching engineers and product management. This is easy for some organisations and very difficult for others.

Second, build a library of reusable design patterns. This is the most critical first-step towards design standardisation, and one that many teams have already adopted. The goal here is to have a single place where all design components can be found and used by developers, coupled with good documentation on how each component should be used. Your user interface should directly utilise these components from an upstream dependency, so that you can update once and immediately rollout everywhere (e.g., changing the colour of your call-to-action buttons across the entire application should be quick and easy). Modern front-end development frameworks (e.g., React) make this easy through their use of components.

Third, set the vision through concept design. Instead of designing each individual feature shortly before it is to be developed, I encourage designers to create and maintain a concept for how the overall application should look and function in the future. This is a North Star that development teams should iterate towards as they develop the app. Sometimes, engineers will intentionally build things differently to how they look and work in these concepts and that is OK. Concepts will evolve as each team, and the designers themselves, learn more through research and experimentation. This decouples design strategy from any individual initiatives and instead enables all initiatives to push the application design in the same direction.

Next, focus on learning through research. Traditionally, designers have conducted user testing for new features before they are built and/or before they are released, which interrupts the product development process. Instead, designers should focus on testing existing user interfaces to build a body of knowledge that challenges design assumptions that have already been made, with the purpose of improving the design system. This is possible because existing reusable patterns and guidelines are good enough to enable engineers to release features to customers without much direct input from designers. This research will result in initiatives to improve existing design patterns as well as initiatives for teams to redesign specific interfaces and workflows.

Finally, standardise everything. Beyond user interface design components, there is a lot more that product designers should work to standardise. For example, to ensure high-quality research, standard practices and procedures should be established (e.g., how to recruit customers, how to record feedback, how to outline problems to be addressed in the future, how to commit changes to long-term concepts).

The paradox of DesignOps, like DevOps, is that practitioners seek an unattainable goal: a way of working where engineers can be constantly delivering value with no speed bumps along the way. Inevitably, all teams must occasionally break the principles of DesignOps. Designers need to get involved in individual initiatives from time to time. By working towards this goal, however unattainable it may feel, designers can become ROI-multipliers whose work speeds up the development process, rather than slows it down. They can finally take their seat at the table by embracing agile development rather than fighting against it.