Moving to a user-centric design model of product development

Here at uSwitch we're trying to change how we build product, and it’s a process that’s thrown up a fair few challenges. We’ve always done testing, but in recent years we’ve started to expand our UX toolkit.

Unfortunately, while user-centric design thinking has been playing an ever greater role, it’s never been communicated or planned properly, staying isolated to specific teams or projects.

We needed to start planning things out a bit more. What follows is a (not so) brief summary of how we started that process.

Focussing on customers over transactions

Attracting users to our site through organic, social, or paid search has been part of our success. We believe we have a great product that genuinely helps consumers; of course they'll want to use it!

Customers over transactions

Sadly, we’re not so great at keeping them on our site, or sending them to other parts of the site once they’ve got what they came for. Once they’ve left the site we find ourselves working hard to get the same people back. Wouldn’t it be better if we could retain our users instead of chasing them?

And when I say ‘users,’ I mean a diverse group of people all experiencing uSwitch in a slightly different way. In order to move quickly, we have small, self-sufficient teams to work through their own problems, using their specialised knowledge and Agile methodology to move quickly, work iteratively, and always link decisions back to data.

Teams building independent products is great for innovation, but challenging if you’re trying to create the consistent kind of brand that is the bedrock of good customer experience.

So, how do we change for the better without breaking what we’re so great at? We have a hunch that user-centric design broadly encompassed by UX methodology - already an important component of our business - needs greater prominence, but we also know it will challenge our business model. So what exactly needs to change, and where do we start?

Gathering themes

The first step to tackling any problem is to properly understand what you’re dealing with, to dissect it, or ‘reframe’ it using the UX parlance.

We started off by sending an email out to a core group of people - featuring designers, front ends, senior devs and analysts - asking them a surprisingly difficult, question:

The year is 2020. UX now plays a central role at uSwitch and in the product teams. What innovations and changes did we make that allowed this? What are some specific things we did differently?

That gave us a huge variety of responses, which we pulled together into a series of themes around which to frame our discussion:

How do you create a ‘uSwitch’ experience? Given that we want the user to experience uSwitch holistically, how do we move from an ‘energy’ or ‘broadband’ experience to a ‘uSwitch’ experience? Given our structure, how do we stay on top of what other teams are doing, and what they’re learning?

Customers over transactions

What is this new methodology? UX isn’t a pre-packaged methodology that we can adopt. Some teams already practice UX, but experience varies. What working practices do we introduce, and what do we drop, and what challenges does that throw up?

Who is the uSwitch customer? Who are our users, how do we understand who they are and what they need, so we can talk to them consistently and appropriately, and how does this tie into our marketing and brand positioning?

How do we know we’re doing the right thing? How can we objectively say that any changes we make are having a positive impact on the business? What does success look like and how is it different to what we’re currently doing?

Do we need any structural changes? Do we need to change the structure of teams? How do we work together, and how do we cater for different UX experience levels between teams?

How do we handle short-term vs. long-term tensions? How do we change our business to favour lifetime value over single transactions, and how do we prioritise user-driven product changes over commercial or technical changes?

Bashing heads

Gathering themes was the easy bit. Getting consensus around the actions we need to take, on the other hand, that’s a bit trickier. So, we arranged an away day, got the cards and post-its out, and made sure snacks and drinks were at hand to keep energy levels up.

We even played an A/B test game of ‘who won the A/B test’ to keep spirits up, whereby we showed everyone two versions of the same screen and asked them to guess which one had the higher conversion rate. Honestly, it’s more fun than it sounds (I didn’t win)

Because we had to get so many different people involved we decided to split into two teams, so we could ensure everyone’s voice was heard. This was great on the day, but made organising things, well, twice as hard! Thinking of doing this yourself? You will need:

  • One meeting room with a central divider (so you can ‘unite’ the teams at the end)
  • Two facilitators and two note-takers
  • A ‘coming together’ session at the end, moderated
  • Double the pens, pads and post-its
  • A serious amount of thought around how to divide the two teams
  • The patience of a saint

Top level outcomes

Amazingly, given the complexity of what we were trying to achieve and the sheer number of people involved, we got some great outcomes. Without getting into too much detail, here’s a quick overview of what we came away with:

Communication and visibility
We have talented people in separate teams, but a lack of communication and visibility. In order to build a ‘uSwitch’ experience, a consistent brand, and ensure we learn from each other’s successes and failures, product teams need to improve their communication skills and should prioritise visibility.

This could take the form of sharing skills amongst communities, inviting others to showcases, or developing a product calendar. We also need to encourage rotation and pairing, and get more critiques from outside our product teams.

UX process
We want to prioritise UX and better integrate it into our processes, but we have an uneven understanding of UX methodology, and some teams even lack access to basics, like templates.

Designers, and the product teams they work with, need a thorough UX toolkit for designers to use and evangelise the process. Important tools include how to write problem statements, how and when to test, running ideation sessions, workshop facilitation, sketching, and involving your team in the design process.

Cross-sell
We can encourage teams to pursue projects that promote cross-sell by developing an internal affiliates programme, and enhance consistency at a brand level by restarting ‘brand-Friday’ efforts, where we dedicate a time-slot to thinking outside of our product teams..

Metrics
It’s all well and good talking about ‘long-term customer value’, but we don’t all know what that means in practice, or how it impacts the bottom-line.

We should clarify this, and surface metrics that reflect long-term customer value and tie them into team and company level OKRs. These need to be accessible to everyone.

Customers
One of the prerequisites for user-centric design is an understanding of who the user is. We need to understand their stories, pains and behaviours to build products for them.

To understand our customers we should talk to them, and develop product and company level design personas/mind-sets. Research into customer needs, pains and goals should frame our projects in a much bigger way.

Community
To help establish a greater prominence of UX processes and practitioners, we should develop a self-supporting community amongst design/UX in the same way we’ve developed a dev community.

That involves growing the UX/design community, having them make their own OKRs and involving them in the hiring process to grow the team

Making it happen

We condensed the 29 individual actions we came away with down to get rid of overlaps, and divided them into tasks to be owned by the UX/design community, and those that belong to other teams. But how do we make them actually, you know, happen?

Objectives and key results

Here at uSwitch we use OKRs, a method of aligning work borrowed from Google. These objectives and key results are owned by product teams or communities, like the design community, and allow us to see across the business what teams are working on. We even have our own app to manage them.

It doesn’t mean we’ve changed our business model, or successfully integrated UX methodologies into the way we work. Some teams have, and are way ahead, others haven’t even started. But it does mean we have a clear way of tracking the progress we’ve made toward these targets, and that, we believe, is the first step.