Image credit

Building DesignOps

This year in Jan, we marked our first year of DesignOps at talabat. I looked back and realised, ‘wow, we’ve come a looooooong way. It’s time to celebrate our achievements and share the learnings’.

Here I am, with my story of 15 months of trial, failure, frustration, success, and an ultimate joy that comes with helping others, but above all building absolute resilience, through this incredible journey.

DesignOps is a relatively new role, especially in the MENA region. Not many are familiar with what it entails. When I was offered to form and run DesignOps at talabat in Jan 2020, I was thrilled. The first thing I did was, call my family and share the good news. They were rejoiced. The second thing, I sat down Googling ‘what is designOps?’ and ‘how to begin establishing a DesignOps function’. I buried myself in EVERYTHING DesignOps — articles, books, podcasts, videos, and conferences. Dozens of articles/books/podcasts later, I had a pretty good understanding of what DesignOps meant.

So what is DesignOps?

Let’s get it out of the way so we could get to the real juicy stuff.

It’s no rocket science, trust me. Lemme tell you a story.

Once upon a time, there was an awesome team of 4 designers and 1 researcher who worked on building a seamless user experience for an online food ordering and delivery app. They were a happy bunch. They grabbed lunch and coffee together and talked through the problems they were solving. Each knew what others were workin’ on. Collaboration was smooth. Decision-making was breezy. They mentored each other to build new skills and grew together. Life was good.

Soon the company started scaling. The team was tripled — more designers, researchers, content writers and more distributed teams working on different parts of the experience. A much bigger team meant, catching up with each other wasn’t a no-brainer anymore. Collaboration was tough. Continuous alignment between teams became the biggest challenge to tackle. Communication gaps creeped in. Silos began to develop which resulted into duplicate effort and a user experience that was fast becoming fragmented. It wasn’t rainbows and unicorns, anymore.

The company soon realised that hiring great design talent was just the first step. In order to scale successfully, it was critical that Design be scalable across the entire organisation.

There you go. This is exactly what DesignOps is all about — a practice that’s aimed at making Design scalable and setting up larger design teams for success.

Hence, the company wisely decided to implement a DesignOps function.

And this, ladies and gentlemen, is the story of how DesignOps at talabat, supported the scaling of our design team from 5 to 17 awesome magic-makers, within the span of 12 months. Next, I’ll be sharing with you our key learnings through this incredible journey.

What we learned when scaling Design

Design doesn’t scale with a loose structure

Design, at talabat, is decentralised where our designers are embedded within cross-discipline teams called ‘squads’. Our squads are highly autonomous teams that focus on one or two specific features of the product. This enables us to move fast and ship quickly. But it also means that our designers are often working solo while solving problems specific to their areas. When we had only 5 squads, this wasn’t much of a problem. We leaned heavily on the raw talents of individuals and the close relationships that allowed people to easily share information across smaller teams. But when the squads doubled, we reached a tipping point where things suddenly became harder. New joiners brought in several different ways of working. Alignment between squads became a ‘thing’. Finding the source of truth, visibility, design guidelines, definition of done, and quality issues all became a real problem.

We realised that the very loose structure that helped us move fast before was slowing us down and lowering the quality of our work, as we scaled. We needed to be thoughtful about how our designers worked, communicated, and aligned together and outside Design. We needed to design our design org.

At this point, our DesignOps team is still an army of ONE. I needed to be clever about how to multiply the impact of DesignOps with just one role. I was in luck, as our design team is a bunch of really fab folks who are always eager to solve problems and lead initiatives.

Together, we formed a DesignOps task-force. This task-force ran a discovery exercise to identify our most pressing challenges and their root cause. We conducted interviews with engineers and product managers, sent out a survey, and ran a problem discovery workshop with the design team.

5 growing pains of scaling design

We uncovered many insights but decided to focus on the 5 most crucial pain points, to kick off DesignOps at talabat.

1. The team had grown so big, so fast that designers constantly battled to bring visibility and alignment with other designers. Their calendars were full of alignment meetings with very little time left to do the real work. With a large team, it wasn’t so easy for designers to just jam with fellow designers and co-create. It took too much time, planning and communication and they didn’t always have the bandwidth.
2. People outside Design didn’t really know what we were working on and what really went on behind scenes of a polished design solution. This not only meant we couldn’t get early feedback from our stakeholders (unless there was a 2 hours long meeting for that 🙄) but also faced a lack of empathy towards our process.
3. Our design debt backlog was growing steadily. The root cause of this was lack of established design standards and a common understanding of our design language.
4. Production was drifting away from design and quality issues were creeping in. Designers were spending too much time on UI reviews and engineers were doing too many iterations on their work, implementing feedback on petty issues like type, colours and spacing. This resulted in to a royal waste of our most valuable resource — the design+engineering bandwidth, as well as a poor relationship between Design and Engineering
5. Another big pain point was onboarding new hires. Although our ‘onboarding buddy’ program was a great success with new joiners, we got feedback that it took them over a month to get a good idea of how Design operated at talabat. This slowed them down as they’d waste their time trying to figure things out and understand who worked on what. It was a frustrating experience.

Where there’s a design-team problem, there’s DesignOps 😉

DesignOps aims to establish processes and measures that support scalable solutions for common design-team challenges. However, in reality the design team’s challenges are vast, so there are many potential focus areas for DesignOps initiatives. This broad landscape of possible starting points could be overwhelming. Therefore, we decided to define our DesignOps focus areas based on our biggest gaps and pain points …

The 4 pillars of DesignOps at talabat

We call these focus areas, the 4 pillars of DesignOps at talabat. They provide a structure and focus to the design team’s work.

Quick tip: We came up with a ‘How might we’ statement for each of our DesignOps pillars. This really helped us turn our challenges into opportunities.

1. Process and tools

How might we facilitate design quality through consistent toolsets and processes?

• Establish processes and tools that enhance speed and quality of execution
• Own and drive Marshmallow design system
• Establish and socialise design standards
• Create design playbooks

2. Spotlight

How might we make design visible and accessible to all?

• Drive find-ability and sharing of design knowledge and work
• Drive visibility: Product showcases, blog, internal and external opportunities
• Establish ways to measure and communicate Design’s success and to educate others on the role and value of design

3. People and culture

How might we ensure the best work environment for the design team?

• Design skills pairing, mentoring, and education opportunities
• Design bandwidths, squad allocations, hiring efforts
• Recruitment process, delightful onboarding
• Own team’s social activities

4. Design strategy

How might we drive design maturity in the organisation?

• Work with fellow design leaders to formulate strategy and direction
• Own program management of chapter initiatives
• Manage cross-functional communications

After establishing our DesignOps pillars, we conducted an ideation workshop with our key stakeholders to find solutions to address our immediate needs under each of the pillars.

In part two, I’ve explained each of those solutions in detail.