Defining and Doing DesignOps at N26
Lessons and observations along the way
As a Design Operations (more popularly known as DesignOps) practitioner, I often struggle to properly explain what it is that I do. I’d usually resort to stating that my job is to enable designers to do their jobs well by taking care of existing and potential operational overheads, from software procurement to workflow streamlining. Quite a mouthful.
I have two bookmarked links that I like to keep on stand-by: DesignBetter’s DesignOps Handbook and Nielsen Norman Group’s DesignOps FAQ. Having this material readily available comes in handy when trying to explain what I do to those asking.
When I’m writing this, there is still a feeling of novelty associated with DesignOps, which seems to be one of the recurring themes in most publications. “The most exciting part about DesignOps is that you can be involved in creating a practice that didn’t exist five years ago. You are at the inception of a new role that you get to help shape”, writes Meredith Black in the DesignOps Handbook. Kate Kaplan argues that “because the field is being defined in real time, practitioners often have questions about what Design Operations means, and how to establish DesignOps practices” in the DesignOps FAQ article.
I feel privileged to have joined N26 last year as its first Operational Designer not only because the company is celebrated for its commitment to build a simple and beautiful user experience, but also because, well, I got the chance to help shape the field of DesignOps.
At the start of 2019, N26’s Design team had 21 talented people in its roster. It concluded the year with 50 talented people practicing various disciplines, scattered across 4 geographical locations (Berlin, Barcelona, New York, and Vienna). As the headcount went up, so did the complexity. DesignOps roles and practices were considered to help navigate through the complexity.
When I joined the team in the beginning of March 2020, I only spent a few days working out of our Berlin office before we shifted to working from home, in a move that was triggered by a certain world pandemic. While this might not have been the most ideal setup for starting a new job, I felt very welcomed and supported by the team.
Since I started the role, I’ve learned a great deal of lessons, some of which I would like to highlight:
- Combat Bias for Action
- Manage Expectations
- Design the Role
- Build a Support System
Combat Bias for Action
When starting a new role, it can be tempting to do anything that can leave a positive mark. One might want to impress their new colleagues, or simply pass their probation with flying colours. While those motivations are natural and understandable, I learned that it’s often wise to combat bias for action, especially during onboarding.
Designers have been taught to properly frame and understand problems before jumping to problem-solving mode. This rings true for Design Operations too. It has been argued that DesignOps is essentially about designing for designers, so I took my time to listen to my “users”, who in this case are primarily members of the Design team. Onboarding provides the best opportunity to do just that.
Because of the relatively high number of people whom I’d be working with, I knew it would be a challenge to sit down with everyone. However, because of the space and flexibility that were afforded to me, I managed to have 1:1 sessions with over 60 people in my first 6 weeks. In addition to speaking with researchers and designers, I also spent my time meeting with those working closely with the team, including Product Managers, Engineers, and Agile Coaches. This allowed me to better understand how the team and the company operate, while exposing me to the opportunities that DesignOps could tackle.
Manage Expectations
DesignOps being the novel field that it is, these 1:1 sessions needed to include an introduction to my role. I’d start the sessions by introducing myself before asking my 1:1 partners to do the same. I’d then ask them what/if they had heard about DesignOps. This question resulted in an interesting variety of answers. A few people thought that I was part of the similar, but different ProductOps function that already existed at the company. More people assumed that I would exclusively be maintaining our Design Systems, while most people hadn’t heard about DesignOps before and asked me for an introduction, which I gladly obliged.
I shared with them about my past DesignOps ventures; how DesignOps can revolve around everything and anything: from administrative tasks such as software procurement to big-picture undertaking like ways-of-working definition. This helped me introduce the field and the role. Furthermore, this helped me manage expectations of how I could support them.
Design the Role
Starting a new role in a newly-formed discipline can be daunting, but it can also be exciting and even beneficial. I realised that because the definition of DesignOps is still up for discussion, I get to shape the role and practices into what would bring the most value for the team and the company. This is where findings gathered through those 1:1 sessions come in handy.
By gathering and synthesising those findings, I started noticing a few recurring themes that DesignOps could work on. Things such as uncertainty around the Design System contribution process, questionable value in attending certain rituals, and lack of alignment across teams were some of the issues raised by many people. I shared these findings with the team leadership and agreed on initial scope of work and prioritisation. For instance, while recruitment support and event planning (e.g. meet-up) can well be beyond DesignOps’ scope of work, the restrictions that the world pandemic caused meant that it would be wiser to allocate more of my time and effort into establishing a better documentation system and meeting culture.
I’m quite confident that my role will evolve as the team’s needs evolve through time. At the time of the writing, I support the team through infrastructure management (ensuring the availability of tools that the team need to do their jobs), process improvement (streamlining workflow that supports cross-functional collaboration), community engagement (fostering an engaging and inclusive working environment to help drive team’s engagement and satisfaction), and knowledge distribution (making sure that all team members have relevant and timely information to do their jobs effectively).
Build a Support System
When compared to other functions such as Engineering and Product Management, Design organisation as we know it today (as partner, and not as service) is a more recent addition to the tech industry. If a company is bringing in a DesignOps practitioner for the first time, chances are there are already existing Ops roles assigned to other functions within the company (DevOps, TechOps, ProductOps, BusinessOps, etc.). While these different roles can be very different in responsibilities and scope of work, I learned that there are often shared Ops mindset and ways of working to benefit from.
As Design works very closely with Engineering and Product, I have a close working relationship with our Engineering Coordinator and Product Coordinator. Through our regular catch-up, we realised that we are essentially a phantom “team” established across these 3 functions. I personally reap twofold benefit from being part of this “team”. For one thing, we identify best practices and knowledge gaps across our own functions that need to be worked on for better cross-functional collaboration. Secondly, being a DesignOps practitioner can at times feel lonely, especially if it’s a team of one, as is the case with me. It helps to share with and learn from others in similar positions.
Looking at the next steps, I will be working closely with the team leadership on a range of high-impact initiatives such as career levelling refinement, collaborative Ops backlog, staffing up our Design System team, and so on. If you’re interested in working with our team, make sure to check our careers page for future openings.
As the field of DesignOps continues to mature, I expect to encounter more challenges of various types and magnitudes. I remain hopeful that these challenges will present many learning opportunities, and that’s just beyond exciting.
