From product design to DesignOps — a personal manifesto

Murilo Marks Hennemann
UX Collective
Published in
9 min readJun 25, 2021

--

I like to think of myself as someone who likes to draw. I can do some drawings and have fun with it but never in a professional product render style as my classmates used to do. They would bring this perfectly drawn shoe or camera in amazing disposition and angle. Have you seen professional product design renders? They are amazing and I love it, but it is not for me. I knew that. My professor, as soon as he saw my first lines, also knew that and this brings us back to one day when I was still in Korea.

An isometric cube designed in Figma. It has the light from top and some shadow. The image is all white with very low contrast to represent the nuance of craft.
For me, perfectly aligned and isometric drawings can only come from computer software and never from a pen in my hand.

I was waiting outside, in a small chair in a very cozy and well-illuminated room, waiting to talk with my sketch professor. Sketches were normally made out of six different types of pens, perfectly geometrical and symmetrical. Normally. But not mine. Mine was as shaky as my insecurities and my lines would be less stable than my anxiety in pandemic times. I was not someone who learned to sketch before and having classes about this subject in my masters with a designer who sketched for Apple was scary and nerve-wracking.

When I went into his room to talk about my sketchbook, that was the thing we talked about the least. He knew my struggle to draw perfect lines with a pen and how hard it was for someone like me to be compared with my classmates, most of whom had been polishing that skill for all their life.

Until today, what we talked about in that room still guides how I see the world. According to professor Chae, we, human beings, are all unpolished carbons and the only way we can grow is by getting in contact with other carbons, polished and unpolished, so we all can become our own form of a diamond.

Changing the atmosphere

Some might say I endured enough pressure and high temperatures to achieve a senior designer title. Earlier this year I moved from the position of Product Designer in Samsung R&D in Manaus to the role of DesignOps at Creditas, a Brazilian fintech unicorn evaluated at $1.75 billion. I grin as I drop these lines.

I don’t commit to a full smile because I was a trainwreck of nerves when I accepted the offer. It was one of the worst moments of the pandemic. In Manaus, where I was living, the city ran out of oxygens in the hospitals and we faced a healthcare collapse. Besides that, I was also 8h flight away from my family in the south of Brazil, both clueless about what DesignOps is.

Translating this new position to them was a challenge. It was time to refresh and redo courses from the past, such as the Design System & Ops from Meiuca and the DesignOps course from NN Group. With courses redone, reading personal essays online and medium posts gave even more help and guidance with a personal touch. It was in those that I finally started to see myself in this profession, recognizing that the work I used to do as a product designer also happens as a DesignOps. Feeling less like an impostor and more like that was the place I should be at.

I feel like most people become seniors in design after already being executing senior designers’ work but in reality, the work, in all levels of career, doesn’t reflect well on the job title. Therefore, we are expected to always overperform to indeed feel like we deserve the position we currently are in. This whole situation generates this damn impostor syndrome all around us.

Working against us is also our biggest tool: creativity. There is not a solid and replicable way to measure creativity nor how to use it to solve problems effectively since it is shown in different shapes and sizes in our design deliverables. Different problems require different solutions, efforts, and understanding.

After all the research I’ve done, the courses I retook, and coping with the unhelpful thoughts, I can say that the DesignOps role is about providing all the tools, processes, and people to all the design needs. Fortunately, it aligns with what our leader Raphaella Quarterone applies on our DesignOps squad in Creditas and, only if you want, read more about it. Mom and dad, in a nutshell, I am a creative problem solver and enabler for the design team and design itself.

Main differences between Design Ops and Product Design

Although it might be easy to explain the DesignOps role, it is in constant mutation. The design landscape is still being constructed and every place you look at you will see a different building and scenario. As such, each company has its own view of DesignOps and how it may empower its software, product, and services. Different from that, the role of a product designer is already well established within the design industry.

Product designers are seen as more of a generalist. In design terms, this is someone with a wide range of design skills and that can navigate in between different areas of design applying its understanding of the experience as a whole and translate it to visuals, delightment, features, and execution. In this role, the professional designer works for a product or feature and shares metrics with the engineering team having the user in the center. As a product designer, you focus more on craft and what you are designing and solving very niche-specific user needs to bring value.

As someone who used to be a product designer, I can say I already did design ops. I already scaled all my components, worked with design tokens, and developed a full integration between Figma and code using the platform API. Seeing problems in scale and their needs to be solved in a larger context. From the technical design standpoint, I was already solving creative problems of the work a DesignOps professional does. All I was missing was the right lenses to do so.

DesignOps is another mental model where we focus on how product and experience intersect, why we design this way and how we do it so we can have shared value for all the users of a system or process. You focus on different areas, your eye for detail becomes as sharp as a 12k monitor, zooming in different designers’ files and finding inconsistencies, broken components, and discovering new possibilities for the company design system. It is like jumping on a trampoline and seeing problems and design solutions from a bird’s-eye view and worm’s-eye view at the same time. When we jump, we see more than design.

A gray cat jumping to represent the jumps. Jumping from product to product and alternating different point of view.
We need to be able to jump around projects and points of view to know how our design will work and scale across all the brand experiences.

Seeing Ops only as someone designing operations is a mistake. Being part of a cross-functional team, the pain points of designers are important, but developers and products are also in the mix and we need to make sure they are being heard and taken care of.

Still, it is relevant to say that being a design ops professional is not about making everyone else’s work, but providing the best tools and resources for them to do so. It is more about holding hands with the development team, product, and design to make sure that, wherever we are going, we are going where the company wants. It is about following a vision and making sure everyone can see and follow it as well.

To make sure we are building the right product, system, or software we need to work in a common vision of the brand and share it to the seven seas — or in more modern and pandemic times, to all seven slack channels that anyone related to design could’ve been at to make sure everyone hears about it. We need to collaborate and put everyone on the same page, or at least give resources to help people identify and deal with the information in their own time.

A button needs to make sense in an interface and reflects in all other interfaces that need a button. To make that happen, we need to provide a lot of synchronous and asynchronous support for the team. The knowledge and understanding of how that component interacts and brings the whole experience of the brand and its ecosystem to the interface and user. The summed knowledge of components and their place in the brand environment ends up in a place called Design System.

Every component, line of code, every drop of sweat, blood, and tears invested in this system is made to be shared and used all across the company experiences using our whole team for feedback, making sure we are in the correct direction. If engineering, design, or product fails to collaborate or is not included by the Design Ops team in the Design System creation, we are faded to have a façade of a design system without real use.

Thus, we need to make sure components and molecules are well connected and easily used by any of our team members, for all the product designers to use in their craft and developers in their code. Next week, Felipe Marinheiro will write about this topic to help you all zoom in even further into the design system itself.

An isometric snapshot of our tab component hand off made in Figma. This type of file works to help us to show where the design tokens are and educate designers and developers how to use them.
Snapshot of one of our design components and how we document it.

To conclude, when you are a product designer, your main deliverables are centered around the User Experience (UX) and User Interface (UI) as a way of solving problems. The main idea behind those is how a user interacts with a screen and what value proposition they are getting from it. It is focused on what to design and normally the person behind this title brings a view of the problem they are solving, making decisions context-specific instead of considering the ecosystem of the product as a whole.

In the meanwhile, DesignOps is about the bigger picture. If we consider the definition from the NN group, it is about the process, people, and tools. It is about understanding how all the dots connect and teams intersect, on how and why we design. It has the objective of bringing problem solutions together with the company vision and objectives to the interface in the form of components, processes, and software in a scalable way for all.

It is about sharing a component in Storybook and documenting in Zeroheight so anyone in the team can use it and consolidate the path to that vision by importing it to Visual Studio and dragging it over in their Figma file. However, even with the most modern and automatic base of operations, you will always deal with people. So be ready to listen.

Connect, listen, and learn

You need to listen to other teammates and understand their pain points in covalent connections. Since you are aware of the bigger picture, you can translate expectations to work in a way that will empower and affect all the system as a whole network of peers. Or at least that is what is expected of you as a DesignOps personnel.

Working remotely has been one of the biggest challenges I face currently, managing others’ and my own expectations, making sure we are aligned on the same page. For that to work, we always have to communicate and pursue answers. That is why I always try to listen to others and get to solutions together.

Because in the end, DesignOps is about people. Product design is about people. Design is about people. And people, people are carbons, they need each other to become diamonds. All I hope is that I can be someone’s carbon and we can be, even as imperfect as we are, diamonds together.

The UX Collective donates US$1 for each article we publish. This story contributed to World-Class Designer School: a college-level, tuition-free design school focused on preparing young and talented African designers for the local and international digital product market. Build the design community you believe in.

--

--

Constant human prototype with a master's in Design Engineering writing about design and creative problem-solving.