There’s plenty written about the role of DevOps in increasing cohesion within an organisation, speeding up innovation, reducing errors and increasing profitability. But what if these principles were applied to UX? At Codemotion Rome in 2019, we heard a fascinating presentation by people from design company Sketchin, Federico Rivera, Design Director, and Matteo Petrani, Technology Director, who shared how they were able to overcome operational inefficiencies through the implementation of DesignOps principles, employing a UX Engineer.
Sketchin has over 100 designers spread over 14 teams. They’re dedicated to a strong Agile practice, both within their developer team and large project transformation. Over the years, as Federico shared, “our belief is that any technology, any product that we push embodies the value of the designer that designed it.”
UX engineer in response to the challenge of the balance between design and development
The working relationship between developers and designers is not always smooth. As Federico explains, “We try to work with developers but if we have too much ego inside of the design or too much presence at design, development doesn’t go in the right way. At the same time, if there is too much engineering power to determine what kind of feature we need to develop first or in which way, the UX experiences suffer.”
Any software development practice agile practice is fully focused on having a problem and finding and developing a solution in response, with the focus on end delivery However the design focus is also for, as Federico discusses, “What is the vision? What’re the right things to do? What’s the right problem to solve first?”
Enter DesignOps and the UX engineer (DesignOps)
The idea of the UX engineer (UXE) was coined by Google, and it means to have one person who is both designer and developer. They are fully in charge to support the delivery team to build the solution with the best user experience as possible,” explains Federico.
The UX engineer has two faces – to both see the code side of a project and see the design phase of a project. “And what’s important here is that it’s not a designer who can code and neither a coder that knows how to design something. But it’s more someone that grew up in the middle of these two areas, trying to cause something trying to design something else. And what’s important here is not the hard skills. But the sensibility that these folks can bring to the table.”
As Federico elaborates, “We’re trying to find people that can judge design decision as well as coding and development decisions, people then can bring the values of the user as well as the feasibility of a project at the same table throughout the design process or the whole end to end creation of some products or services.”
Sketchin applied this approach during a range of projects – applications, single page, applications, mobile applications, services products of any kind. “And what we see here is that it works. It brings a lot of value and clients start to work recognise this value.”
Design systems plus design automation
According to Federico, something like a design system is perfect for a big company that has many touchpoints to handle to make, for example, distributed design teams to work together, as well as distributed development teams to work together and be coherent in the whole experience.
How do DesignOps work?
- Pair up with designers in order to find those patterns and modules that build up your design and try to normalise them as much as possible. “A UXE can really help a designer to narrow down the UI elements to those essential and to build only those that are useful they are going to be merged in a single design library.”
- In design operations, the aim is to get the right tools systems and practices in place to allow successful delivery at scale:
“Design operation is one of the core activities for us, inside the agile project are involved in Agile scale we have a team of 14 designers designing a whole suite of a software company. Our mission is to create currents, but we need to stay also inside the design development sprint for delivery. The UX engineer is inside the sprint of the development. The UXE is in touch with the design team and also to make 50% of the design choices that are not even been made by design team.”
Working off proof of concepts
Federico asserts that proof of concept is “not just something built maybe natively in some code language. It provides information also on what are the costs are running some application? What are the benefits in the long term?” Therefore a real proof of concept is “not just high fidelity design that are largely an artefact in order to represent some experience, some very nice and neat interaction. But it’s something more something that can bring to a customer, to a client, the whole picture without investing the big money.”
Federico shares, “So let’s say you want to test a specific feature of something or an extension of a service you already have. You do a proof of concept before an MVP, for example. In this way, you’re going to test and highlight everything that is required to run that feature.
So right now everyone is asking for a chatbot for customer support, for example, and okay, we can do a chat, but we can run some kind of artificial intelligence engine behind it. But what happens when I handle the user requests? Is there a chatbot or a real customer service answering customer service questions 24/7how much does it cost? Okay, so proof of concept is yes the widget that you put on your website for the chat, but it has to do highlight what functionality is expected behind the scenes in that single feature.”
In such instances, the UX engineer is in charge of the overall POC, and part of this is “We bring the technology, we experiment behind the scenes and we can send feedback to both the design and development teams. So I can say to the development team, hey, I tried to integrate this kind of technology, I learned X, or to design team, I see how the user interacting is interacting with this technology. I learned X, so this is the most important rule.”
