Leading the design of Monzo’s internal product, the tooling that supports Monzo’s award winning customer support team.

My role: creating design systems & libraries, establishing rituals, product design, user research & testing, onboarding team members. I started as the sole designer, with a team of around 12 engineers, 2 PMs and a data analyst, I onboarded a further researcher and designer.

01_The brief
02_Scoping the problem
03_Setting foundations for growth
04_Rapid development
05_Measuring success

01. The brief

I joined Monzo as product designer number 6 and took on the challenge of setting up research and design in their internal product team. The team that builds the chat and banking tools that support Monzo’s customer operations (we like to call them “COps”) team. 

Our team’s brief is to help COps work as productively as possible. By helping to ensure rapid onboarding, and giving COps the tools to provide fast service to a high standard. Another key objective is to set the foundations for rapid scaling, so customer service doesn’t act as a costly break on Monzo’s growth.

02. Understanding the product & defining the user need

For the first 4-6 weeks I helped engineers with urgent work, but spent the rest of my time doing COp training and sitting with COps to get to grips with the best and worst of the product, understand the variety of use cases, and get an understanding of our users and their needs.

Understanding the product

Monzo had recently migrated from using Intercom for all communications with customers. They had originally built a number of plugins to sit alongside Intercom to house customers sensitive information and all the tasks COps needed to undertake to solve problems for customers. When I started the team had just completed building their own messaging product “BizOps” that would allow a more integrated approach.

BizOps supports many 100s of use cases, from a change of address or balance transfer, to raising complaints, verifying someone’s identity, or organising a loan. It is the most complex and powerful product I’ve worked with and it was daunting to get to grips with. While I sat with COps I mapped out common user journeys and the basic app and information architecture of BizOps. I also put together an audit of the main interaction and design patterns, the usability issues I noticed, and the frustrations raised by COps.

The product had been built by an incredible team of engineers, but without a lot of time dedicated to user experience. My main concern was density of information, with little grouping or hierarchy, as well as inconsistent design and interaction patterns. This early work helped me understand the product, as well as informing future work and prioritisation.

Understanding our users

As well as gathering feedback, I kept note of the background, experience and work hours of the COps I spoke with. I also requested anonymised information from our “people” (HR) team to understand our users, how we could best support them, and whether there were any constraints that should influence our product approach.

I also used this research to help adjust our product principles. Before I joined the team had tended to over-focus on feedback and requests from the small number of very experienced COps who were based in our London office. This had led to product principles that championed power user features over intuitive and inclusive design. I found that the majority of COps were working remotely, on irregular or part time shifts, and often balanced work with other jobs or responsibilities. These COps certainly needed a powerful professional tool, but didn’t fit the power user persona that our team was focusing on, and they didn’t feel empowered or supported by our tooling. The complexity of the tooling also meant that training was lengthy, and involved lots of mentoring support from more senior COps which was a huge overhead. 

It was also clear that the focus on power users meant that we were working against our business goals. Monzo’s support model was to rapidly onboard COps and bring them up to speed, focus on remote working to reduce costs, and even bring in temporary workers or outsource. This didn’t sit well with a product that required lengthy training and lots of support.

Adjusting our principles

Based on my research I encouraged the team to rethink our product focus. Pivoting away from typical power user features such as shortcuts, to focus more attention on usability and training. We still incorporated shortcuts but we started to prioritise other initiatives that helped a larger group of COps - and therefore helped us have a bigger impact.

Our product principles were adjusted to reflect the pivot, focusing on helping to teach and guide COps. We also introduced a principle to “prove it” to use more qualitative and quantitative data to ensure we made the right product decisions.

03. Setting foundations for growth

As well as working with the team on urgent sprint work, I spent as much time as possible establishing the foundations for rapid growth and success. The first step was to set to work on a component library to introduce more consistency to the product, and speed up myself and the team.

I built out a pattern library for BizOps, implementing rules around colour, typography, iconography and interaction patterns. I focused on those that were most essential to the product, and then expanded out to include those typically in design libraries. I worked with a developer to build out the library into a coded component library. This not only meant that the product was more consistent and intuitive to use, but it also helped both myself and the rest of the team work at speed.

I also introduced rituals to get the whole team involved in research and design. We had daily “design breakfasts” which were drop in sessions to discuss areas that needed improvement and map out solutions. We also started to have regular ideation sessions to get the whole team collaborating in the product process and thinking outside the box.

Most importantly, I encouraged the whole team to get closer to our users by frequently working alongside them “dog fooding”, as well as conducting user research and testing. I put together templates and guides on research techniques to help the team have more confidence to get involved, and I organise regular trips to Cardiff where our biggest team of COps are based. I’ve talked more about how we are all involved in research on Medium here.

04. Rapid development

Design and development happen incredibly rapidly at Monzo and I’ve had to adapt my ways of working to keep up while still observing a product process. We usually work in sprints of 2-3 weeks, identifying a problem based on handling time (aiming to help COps with queries that took the longest/are most frequent), undertaking research, running ideation sessions, prioritising on a matrix of value and effort, before getting going with the design and build.

With every project we work on we learn more about BizOps and our learnings are fed back into the component library which automatically updates components across the product.

05. Measuring success

We measure each sprint on the basis of qualitative feedback of COps, as well as the impact on COp productivity. We sit with COps to check understanding and see how the change influences their work, and tweak our build based on our findings. To measure productivity we gather handling time per query (based on manual and automatic tagging).

Improvements we’ve seen are that:

• productivity and quality assurance metrics (assessing COp outcomes) improve in the areas we work on;

• the component library has led to faster build time, and engineers commenting that BizOps is easier to contribute to;

• training has reduced from 2 weeks to 1; and

• we receive more frequent and honest feedback from COps (as we have a closer relationship).

For me personally, some of the best feedback I’ve had is that COps now prefer using BizOps to Intercom. When I started it was the other way around - and COps would lament being scheduled onto BizOps.

Advocating for accessibility

At Monzo I’ve also worked closely with the vulnerable customer team to help raise awareness of accessibility and provide training to designers and PMs. I also organised and spoke at an accessibility event hosted by Ladies that UX at Monzo. I’ve written more about accessibility on Medium here.