Digital has changed the rules of the game. User experience is the main criterion for attracting and retaining users, not the size of the company. Delivering interfaces at the high standard is required for the survival of organizations.
Design is an activity often perceived as elitist, reserved for a small number of actors acting in closed rooms. Once the experience is designed, it is finally revealed to the teams responsible for the implementation.
DesignOps accelerates user experience prototyping cycles through better collaboration between stakeholders. The result is an increased performance of the customer experience and the organization.
Émile Aublet was a Lead Designer and put DesignOps into practice in a variety of organizations. He shares with us his experience and advice on this key theme of DesignOps:
- The profession of Design and UX
- The definition and motivations of DesignOps
- The methodologies of DesignOps
- The added value and management of DesignOps
- The organization and actors of DesignOps
- How to initiate a DesignOps approach
- The skills of Design Ops
Join the QE Unit to access more exclusive content from the community.
About Émile Aublet
Émile Aublet has more than 12 years of experience in the field of Design. He is based in Montreal, Canada. He has won several awards for design and user interfaces.
He started his career at TC Media as an Interactive Designer before moving to Nurun, occupying the positions of Web Designer and then Art Director. It later evolved as that Interactive Art Director at Frank + Oak before Interactions & Design Manager at Aldo Group. He most recently held the positions of Lead Interaction Design UI then Lead Design Ops at the National Bank of Canada. He is currently working as an Engineer at Shopify.
Antoine: Can you start by introducing yourself?
I live in Montreal, I am a Designer, DesignOps and Front-end Developer. I have spent the last 12 years mainly on design and interactions. Today, I am focusing a little more on the front-end part, with a desire to learn a little more on the technical side. I am convinced that it is essential to my job and to the theme of this interview.
Antoine: What does the job of UX, design consist of? What priorities are you addressing?
The Design, UX and front development are mixing more and more. The goal is to create interfaces that are primarily user experiences. There is more and more talk of building experiences in collaboration with developers. We try to create accessible, easy-to-use, memorable experiences.
The design and interaction work revolves a lot around people. Whether by performing user-testing directly with users to test the interfaces, or even in some cases with a physical presence. The design profession is changing a lot. Ten years ago we were printing models; today we code and test them directly.
DesignOps has a direct impact both internally and externally, which can facilitate the life, work and collaboration of stakeholders.
Antoine: The acronym DesignOps aroused my curiosity. We feel a parallel with DevOps in a global dynamic of acceleration. Can you tell us a little more? How does this fit into Quality Engineering?
DesignOps has many common roots with DevOps. It is a set of practices that already existed in part. Its emergence is linked to the increased collaboration of designers with other actors in the design process. If once a designer worked alone with models in Photoshop, this is no longer possible. Designers cannot know, know or predict everything on their own. They must therefore collaborate as early as possible and regularly with the relevant players in order to be able to deliver quality user experiences.
DesignOps allows designers to seize opportunities in the ecosystem and facilitate collaboration with stakeholders. Like DevOps, it’s not just about tools or processes, culture and skills are important. A designer must know how to communicate his ideas, the realization is more and more carried out in the team.
Antoine: How is DesignOps different from traditional Design approaches?
We can already define what a traditional approach to design is. I usually think of a designer working in agile mode, for example with sprints. The main difference is that the designer is very focused and focused on his context, perspective and goals, like in a silo. It therefore has little interaction with the rest of the ecosystem at the risk of having integration problems later.
Another traditional approach is to carry out the design and the technical implementation in separate stages. A designer will work 6 months to build a certain number of elements which will then be taken care of by a development and content team. In both cases, we must take a step back from the positive and negative aspects of these approaches.
I was able to set up a DesignOps approach in these 2 contexts. DesignOps is ultimately the glue between all the activities of the Designer so that he is able to have a better visibility, a better distance and confrontation of his ideas. We avoid spending months building a black box then revealed as a surprise to the rest of the team. Internal actors and partners are an integral part of design iterations.
Formalizing DesignOps helps clarify the structure and governance.
Antoine: So there is a real pillar of culture and interactions within DesignOps. Beyond testing their design more quickly, it is also putting it to music earlier, sharing it and having transverse feedback on several levels.
Yes exactly, especially in a business where the user experience is differentiating. It’s so expensive to manufacture a product that you have to reduce the risks and develop the right priorities. These tests and value checks are subtle in design; we talk a lot about emotions, attachment, satisfaction. These are difficult variables to measure factually. To make the task more complex, the interpretations depend on the context.
For example, it is difficult to test the accessibility of a website. Each person is in a different context, with different equipment and parameters. We want to reduce the bias as much as possible. DesignOps helps minimize variability in assessment by testing quickly and in an integrated manner across the rest of the ecosystem. We must be able to test several ideas per day.
Antoine: What foundations for DesignOps? What concrete practices for DesignOps?
The principles decline differently depending on the context. I can share a concrete case where I was in a bank with a team of designers and developers. We had several digital products. These products regularly needed relatively standard components. A first priority was to create libraries of these objects to easily reuse them in other applications.
This first library step allowed us to better communicate and share with other teams on recurring needs. We have more easily converged on a common vocabulary, accelerating the collaboration between different actors. Like any human problem, the crux is often the communication that wastes our time and money.
In addition, these libraries have guided us towards a product approach of our components, facilitating versioning, maintenance and evolution. Over time, these practices have transformed into elements of the culture of our team. Big actors realized it in advance; Google with Material Design, Shopify with Polaris. Developers are familiar with these components, it is easy to integrate them into applications.
The common culture has evolved through the common language, the library of components and their documentation facilitating their use. The concrete gain is the reuse and acceleration of the creation of Design which are quickly tested. The level of requirement has also been increased on all components to achieve the same ease of use. The teams want to be able to iterate quickly on all the components.
In our case, we have always focused on having real components integrated into applications. We can think of using Framer or InVision to imitate components with mockups. The problem is that the integration will be complicated, slowed down and the tests not necessarily relevant. It is therefore important from the start to have an integrated approach to DesignOps throughout the chain. It also creates a stronger empathy between designers and developers.
Antoine: The challenge is to test the idea and its implementation until the end to validate the ability to achieve and improve the UX thereafter.
The Design System is a double-edged knife. It should be seen as a toolbox, not as handcuffs. The line is fine, we can quickly switch to an extreme. For example, using only standard components, one will end up creating limited and repeated experiences by being locked into the available choices. The risk is to optimize our process by forgetting the user perspective, which, depending on the context, has different needs.
DesignOps is constantly looking for a sweet spot, between a product that is simple enough, flexible and scalable, while both structured and standard to guarantee its maintainability and robustness.
Antoine: What contributions and value creation have you seen realized, or seen for both Business and IT?
DesignOps first materializes through better collaboration with teams. This results in reduced design and development times over much shorter cycles. A product that comes to life quickly contributes to clearer expectations for stakeholders earlier. The teams will have seen a concrete integrated product, which makes it possible to validate many more hypotheses.
For the customer, the value is in the experience. We can look at the big players like Google, Facebook, Microsoft; once familiar with an application you can easily use the whole. This is the case with Gmail and the collaborative suite, Outlook and the Microsoft suite, Safari and applications under Apple. There is a uniformity of applications, resulting from a DesignOps approach. At the same time, the application is relevant for its use cases and has transverse consistency to facilitate the use of the overall suite. Users who understand an interface do not need any documentation or help. The intuitiveness is such that users know how to use the tools themselves, satisfied with their experience.
A high-level user experience has an impact on the performance of the company. This can result in an increase in turnover, margin, customer indicators. The ease and satisfaction of interacting with a brand, its products and services support the attraction and retention of customers. The most successful companies have a real culture of Design and continuous improvement.
Design is not just for designers. We sometimes have a too elitist vision of the activity, as for developers. The whole organization must be made aware of the design, its value, its processes and its complexity. Stakeholders must understand the need for the necessary investments, iteration and validation times. This knowledge of other professions helps us create solutions that require less back and forth. The actors are made aware of the needs and difficulties, they naturally integrate certain information through this capital of empathy. Each actor is responsible for his work, and each person is responsible for facilitating collaboration and cross-functional communication.
Antoine: Stakeholders are important for a design culture. We have identified the designer, the product owner, the developers. Who are the players in a DesignOps process?
DesignOps can be hard to sell to a business. It can be seen as a pure expense with no return on investment. However, this discipline is already being implemented in the design teams, it often only remains to formalize it and standardize the methods. DesignOps becomes everyone’s business when it is well in place, supported by governance that expands over time. We do not necessarily need a “hero designer”, the skills and activities are ultimately transverse to the organization. We need people who can collaborate and accelerate the organization globally, not just on their individual prism.
You have to start with a small nucleus, a small team of which this is their main priority. The number of actors must be well selected and remain limited to keep iterations short and efficient. We too easily forget the actors responsible for the content, they find themselves having to integrate somehow the elements at the end of the chain, having only content references. However, a user experience that is enjoyable and easy to use depends a lot on content. It is therefore essential to integrate these actors from the start of the process.
“DesignOps becomes everyone’s business through shared governance and corporate culture.”
Émile Aublet.
Their contribution will also be more relevant with more adapted, integrated and revised content as soon as possible. For example, the text of a confirmation item could be “Continue”, “Continue”, “OK”. Sharing designs, development and content directly will raise this need and be clarified much earlier. The likelihood of rework and change is drastically reduced thereafter. This example seems trivial but happens frequently. On a larger number of elements, the loss of time becomes significant.
DesignOps being a cultural issue, I have often had to push it to levels that go beyond that of operational teams, for example to VPs. The allocation of 3 people for several months working on this approach is a real investment for a company. The results are medium and long-term, not short-term, you need people who are influenced and convinced. As with DevOps, you need an initial setup before you can reap the benefits. At first, it is difficult to measure the gain. Subsequently, we can more easily measure the gain and also the impact of no longer having these practices in place.
Antoine: What do you recommend to an organization wanting to initiate this process? What good practices to follow or errors to avoid?
It’s easier to set up DesignOps if you’re starting out on a new team or a new project. There is less complexity, we can gradually create our library of components and adapt them as we go. The skills and collaborative capacities of the actors are in fact the most important in this context.
For existing teams that already have other priorities and mechanisms, there must be a problem to resolve. You have to start by proving yourself with early victories that are easier to achieve by picking the “low-hanging fruits”. There are always typographies, form elements. These are elements that are often used and in direct contact with users. They can already be standardized and centralized in a documentation portal. This is a subject of organization, structure and shared processes.
One must also have a champion, a DesignOps referent who will be our ambassador to extend the process. He must be the privileged point of contact for all stakeholders for any questions or questions. It is up to him to guarantee the methods, processes and organization of DesignOps. It is necessary to act at the same time on the processes, the technology, the priorities, the organization and the competencies.
We can then start to extend our practices to other teams. Besides, we don’t need to integrate everyone into the same team. It is here that the culture, a sharing of repositories and practices allows us to extend more widely in the organization.
By rapidly developing prototypes between the different actors, we focus the discussion of stakeholders on a common and shared objective: to build a user experience that meets the various quality criteria.
Antoine: DesignOps needs real foundations, from methodologies to the organization of tasks. We are not necessarily on the use of the latest technologies. You have to start with the fundamentals and iterate on value creation.
Less is more. You can often do a lot of things with the tools you have, this is rarely the problem. The brake is more often that of the mindset. For example, we can start with the library of shared components and realize that we have 140 to do, without knowing where to start. By applying an 80/20, we can certainly focus on the 10 most important first, measure their value, adapt them and improve them.
Prototyping is difficult because of the mindset. Designers can be biased by what they know about prototypes, depending on their skills. It is the same for developers, they will tend to limit the possibilities of implementation to what they know how to do.
“To reach the sweet spot, players must therefore know how to compose their expertise and act outside their comfort zone.”
Émile Aublet
A prototype will very often be thrown away and not used. The goal is to quickly validate a real idea that can be experimented with to validate the creation of value. We can then move on to the industrialization stage. You can use images for a large part of the screen for prototypes. If you only want to test a transition or the fluidity of the changes, no need to waste time on the rest. This is an example of DesignOps in practice, you have to know how to use shortcuts where you do not impact the measure of value. It’s a real balance, designers must be a little more technical, developers a little less demanding on their code.
Antoine: For a designer, what skills do you identify as the main ones to approach DesignOps?
Technical skills are important. In this world of interactions and experiences, it is necessary to be able to act in transversality. I am not sure that this aspect is necessarily addressed in official and more traditional training. It is very important to me. For freelance designers, knowing how to code can also be more lucrative.
I also draw a parallel with my mother who was a designer on physical print. It is impossible to design print without knowing how it will be printed, how the machine works, what constraints it has. It’s impossible. You must know the ink, the paper, the type of printing among others. Both the printer and the designer must understand their needs and constraints. In interaction design, it’s the same, we have to maximize our knowledge of the entire chain.
DesignOps therefore requires the composition of expertise. You have to have a balance rather than an extreme on certain skills. We fall too easily into a siled optimization, losing sight of the users. People and collaboration are essential elements of DesignOps, and the creation of user experiences with added value.
Antoine: Thank you very much Émile for this decryption, sharing of experiences and recommendations on DesignOps. A very good example of a practice applying the Quality Engineering paradigm, constraining its set of processes to the continuous delivery of valuable software. We have the steps to start and interesting parallels with other practices. Thank you very much for your contribution and good Design(Ops)!