0 to 1: Leading the end-to-end design of a business account

CONTEXT

Teya offers a suite of products for businesses to run and grow. At the core of the product offering is payments - along with a number of add-on services like cash advance and loyalty. Currently, when a merchant Teya’s terminal to accept payments, the money is settled into an external business account like Tide, Natwest or Barclays.

Teya wanted to capture an additional piece of the pie by creating an in-house business account solution, so that the merchant’s money would stay within Teya’s ecosystem. This would add one more piece in the company’s quest to offer a one-stop shop for small businesses to manage their finances.

OBJECTIVE

The goal of the project was to launch a new product - a business account. This would have a number of benefits for the merchant: having one less external provider to deal with, receiving cashback from card spend, and having a competitive settlement cycle. For the business, this product would lead to an increase in revenue, and make the payments product stickier, thus leading to reduced churn.

Team: product designer (me), head of design overseeing the project, product manager, a team of engineers.

Timeline: due to unforeseen circumstances, the app launched 2 months after expected, for a total timeline of 8 months from conception to launch.

Scope: end-to-end design, including discovery, user research, design, testing and overseeing implementation.

In this case study, I will walk through each step of the process I went through, from conception to launch.

competitor analysis

As a business, we did not want to reinvent the wheel - we wanted to provide an experience that felt safe and familiar, so that merchants would trust us with their money.

I mapped out key flows across 5+ business banking apps, to understand the experiences and features these apps offered, including:

• Making payments

• Adding recipients

• Managing physical and virtual cards

DEFINING A MVP

Along with the product manager, I worked to define a list of features that we would need for the minimum viable product, and then set out to create wireframes to map out each of these features.

These wireframes provided engineering lead with a clearer scope of the project and enabled us to refine the user journeys without getting caught in the finer details.

I wanted to hear from the target users themselves: what pain points do they have, what features do they value.

Despite tight timelines, I managed to squeeze in some user research. Knowing that we needed a critical mass of at least 5 merchants, I came up with a research plan and ended up interviewing 7 merchants.

The goal of the research session was to understand how merchants use their current business account and what features are most crucial for them.

From this research, I learnt two crucial insights that influenced the second iteration of wireframes:

1. Merchants wanted the ability to manage (cancel, edit) their recurring payments.

2. Merchants make regular payments to a small group of suppliers, but there might be a fair amount of one-off payments.

The previous navigation structure lacked an intuitive way to access either of the above. I restructured the navigation so that we could have a tab dedicated to managing recipients and payments.

Several flows required deep dives, design jams, user flows and discussions with cross-functional stakeholders.

I went through several rounds of wireframes, discussing the flows and the scope with the head of design, PM and engineers. We drilled into and refined several flows, including the search and filter experience, as well as card management.

When we finally settled on an experience, I began translating the wireframes to high fidelity screens. There was also a major rebrand along the way, replacing the purple hues with a more techy black and lime yellow. I worked closely with the lead engineer to ensure that the app reflects the designs as closely as possible. We would jump onto long huddles on slack and smash out the changes one by one.

Moving into visual design

I explored a few variations for the visual design of the app, focusing on typography, white space and colour. After discussing with the team, we decided to run with option 3 that optimised for the number of transactions being shown on the screen.

We also went through a rebrand before launching, changing our colour palette and font.

Gathering more feedback through user testing

With the app in high fidelity, I conducted user testing with another set of 7 merchants, with the goals of (1) understanding if the basic functions of our app are intuitive and (2) assessing the importance of future features to help shape our roadmap.

Overall, I found that merchants found it easy to use the app and were able to complete key tasks like adding recipients and making payments.

However, while observing merchants interacting with the app, I noticed that they struggled to differentiate between cards in a scrolling list. I took this feedback, redesigned the card and added identifying details on the card itself, helping merchants to distinguish between cards more easily.

Merchants indicated that key features were missing.

The biggest learning from the user testing was that merchants felt like our app was lacking critical features that our competitors offer and that they would not be interested in using the product with its limited feature set. As one merchant said, “why would I buy a car without wheels?” My assumption was that there would be a low adoption rate even if we launched.

Although the team was already aware of the limitations of our product, I presented my findings and the risk of the product failing at first launch. Given the big push to release the app and the already delayed timeline, the team decided to launch as planned, get some hard data to validate this theory, and iterate on the product accordingly.

The pilot

We piloted the app with 7 merchants, 4 of which churned after a few weeks.

We launched our pilot with 7 merchants, relying heavily on their feedback to evaluate the app’s performance. In the first weeks following the pilot, there was a high activity rate in the app, and a steady growth in transaction volumes. We also received positive feedback about the onboarding flow being intuitive.

However, about a month into the pilot, we had 4 out of 7 merchants churn (1 due to an unforeseen tragedy). We saw the novelty of this product wear off, and the merchants opted to revert to their previous bank accounts that were more feature complete.

Although this is something that I had predicted through my user research, it was beneficial to have hard data to prove this theory, and this helped bring a sense of urgency in building specific features.

We also received feedback that it was critical to have bank statements, and that there are issues around merchants not being able to track when their physical card is delivered to them. Hearing from merchants using the live product is helping us reprioritise our roadmap with more confidence, and will result in a better product.

reflections & Learnings

• We should have failed faster. In my opinion, we waited too long to release the app. We could have gotten feedback from merchants at a much earlier stage that could have helped us reprioritise considerably.

• Real data > hypothesis. I had a hunch that there would be low adoption rates, however, it was only when we had actual product usage data that the team was spurred into action. Sometimes you have to launch knowing you are going to fail, and that’s just part of the product development process.

• Track from the start. Due to unforeseen circumstances including layoffs and ownership changes, the mixpanel dashboard to track analytics in the app was still not properly set up with clean data 6 weeks into the pilot. This meant that we were losing out on valuable data about how users were moving through the app and where they were getting stuck. If I could do it again, I would have pushed to get this set up before we even launched.