BPme

Project: Global App Development; iOS, Android

Role: UX Designer, Service Designer

Timeline: Feb ‘19 - May ‘20

My contribution:

UX Prototyping.png
Agile.png
Service Design.png
Design Strategy.png
Visual Design.png
Stakeholder Management.png
User Testing.png
Release Planning.png
User Research.png
Backlog Management.png
Design Thinking.png
Motion Design.png

In 2016, BP launched their first customer facing app in the UK, designed initially to help users find their nearest BP station. Today the app has been rolled out in 5 major markets, to over a million users worldwide, with a plethora of new features including paying for fuel, loyalty & rewards and preordering store goods.

The role

My role throughout the 15+ months I spent on the project was an incredibly multifaceted one; being responsible for taking features from inceptive design through to development and beyond. As part of a small but highly functional design team, I would not only be defining various parts of the global app, spending time deep in the weeds of both high level and detailed design, but was very much responsible for shaping our workflow.

This meant forming the basis of our design system, defining user stories with detailed acceptance criteria and technical information, working with product owners to better prioritise work, and collaborating with developers and architects to translate design information more effectively…and that’s just the shortlist.

 

The basics

When first joining the project, I was one of two designers producing all content for an app spanning two platforms (Android and iOS) and two markets. My first task was to tackle the newly conceived US Loyalty feature.

US Loyalty

US Loyalty

My general workflow in these early days was comparatively streamlined:

  1. Work with the US product owner (PO) to understand the following:

  • Business needs

  • Capabilities of loyalty partners and payment service integrators

  • Legal and branding requirements

image (21).png

2.

Draft initial wireframes and playback to product owner.

Much of my work as a UX designer involved finding the best way to communicate design. Often I would organise my wireframes into flows, and populate each on a shared Mural [left] for our PO to review and playback to key stakeholders before our daily calls.

3. Populate user stories with final designs, specs and acceptance criteria. Then triage with the development team.

4. Support the development and testing of the new designs and run design audit before public release.

 

Expanding the model

As the BPme app expanded, so too did the responsibilities of the team. Scaling to five different markets (UK, US, Australia, Netherlands & Mexico) meant adapting to cope with these increasing demands. Our small team of two eventually grew to over ten, and for myself, this meant two new dimensions of my role:

  1. Owning entire app features from end to end as we moved to a feature squad model, leading the design for all features allocated to my squad.

  2. Collaborating within the team to actively define better workflows and ways of working.

 

Part 1: Feature squads - the anatomy of work

Taking a single feature through the design process meant bridging the gap between business and development. In a squad with one designer and no business analysts, the entire creation process had to be fully informed. 

This meant understanding enough of the business requirements, architectural limitations, development tools and test plan to be able to design with the entire vision in mind, and using your visual and verbal communication skills to make sure everyone is on the same page!

Anatomy of a feature Copy 2.png

More features like this

Tutorials

Apple & Google Pay

Lazy Loading

 

Part 2: A collaborative effort - ways of working

More work means more workflow, and excelling as a team that spans regions means finding better ways to communicate, empathise and collaborate. Throughout the expansion of the project there were several ways that I managed to improve our ways of working.

 
IMB_Cegson.GIF

Redefining transitions

Getting animations and transitions right can be a tough task, often more so for developers. I spent several weeks with our dev team creating a workflow for defining these in the app. This included handing over the following items in addition to our design files:

  • Video files for each transition

  • A breakdown of moving components, and for each:

  • The transition time

  • The x:y movement

  • The transition speed curve

  • Size & opacity change

The result was an easier, faster, more seamless design to build workflow, and more accurate and consistent transitions overall.

 

Definition of ready

Working through fast-paced sprints in a strict Agile delivery timeline, it’s often tempting to cut corners, but I found huge returns in spending a little time structuring our design to dev handover. As part of this, I worked with our delivery lead and dev team to outline a definition of design ready, based on the following artefacts:

  • Designs uploaded to Zeplin and linked to user story

  • Video demo of any applicable animations

  • Detailed acceptance criteria for happy path and error scenarios

  • Attached technical info and service calls/integrations

  • User stories triaged and estimated

NB: As UX & Service Designer, it was my role to create, organise and populate everything mentioned above for the features I owned, even if this meant liaising with our architects, developers, service partners or product owners to understand more technical aspects.

 
DSM Showcase.png

A best-in-class design system

With our growing global design team and expanding app in mind, our central team of four, who governed design operations, set out to create a robust design system. As part of the discovery work for this, I took a deep dive into tools such as Invision DSM, and helped to create the following:

  • Instructional guidance on setting up DSM, creating permissions and adding components

  • A workflow for adding components and versioning

  • A taxonomy and structure for our component library

Without doubt, this design system and the corresponding UI kit had one of the most profound impacts on the consistency, speed, cohesiveness of the design team, and on the BPme app going forward.

Outcomes

Why does all of this matter? Through actively refining the way we communicated, the flow of work, and our general housekeeping, we experienced the following outcomes:

  • Ability to more easily scale the app from two to five regions.

  • Enablement of the spinning up of four additional squads, across the US, Australia and Romania.

  • A more cohesive global brand image for BPme, and consistent app styling.

  • Faster design and build of app features, and a higher quality app overall.

 

The last hurrah - Registration 2.0

Reg 2.0 Mockups.png

As my time on the project came to a close, high value features became the priority. My last task was to redesign the registration process from the ground up, defining the feature from initial high level design all the way to technical design and development.

IMG_8158.jpg

Early discovery

Working with the global PO, the first stage was to launch an initial discovery and assessment phase in which we:

  • Gained a common understanding of the purpose of the new feature, defined success and how we would measure it.

  • Critically analysed the as-is registration process, including key pain points for our user segments.

IMG_1297.jpg

Ideation

Using our key user segments, we launched into an ideation session to create the following:

  • A list of potential features, ranked by perceived value and feasibility.

  • Knowledge gaps and technical/business capabilities needed to enable change.

  • A first pass at the new registration journey.

Early wireframes - New user signing up via email

Early wireframes - New user signing up via email
 

Features and release plan

Naturally, when rolling out high impact features, businesses want to see value quickly. One of the key challenges we faced was how to deliver something impactful as soon as possible, so after outlining the optimal journey, I worked with the product owner, high level business executives, technical lead and service partners to break the new feature down into the following releases:

Release 1

Release 1

Release 2

Release 2 Copy.jpg

Release 3

Release 3 Copy.jpg
 
IMB_TNUxjQ.GIF

Detailed design & mockups

Over several weeks, I continued triaging with service architects, business stakeholders and technical leads to prototype a final implementation, broken down into releases. This included defining the technical enablers of the feature, back end integrations and error scenarios.

I mapped out all potential pathways and user scenarios, detailing the specs along the way, and laid these out visually for stakeholders and our dev and build teams to see. You can find much of this work in the board linked below.

 

NB: Due to the global pandemic, the project was downsized and the design team migrated internally before the new feature could be built and implemented. However the design work, specs and use cases still exist and are due to be rolled out in the near future.

The result, in restrospect

While working on the BPme app, an incredible amount changed. As a team, we achieved so much, including:

  • Expanding the app from two markets to five.

  • Growing the design team from two members to over ten.

  • Delivering 20+ features between five squads.

  • Going from around 200,000 global users to over 1.5 million.

  • Raising the app store rating by over a star on both iOS and Android.

  • Generating over £1m profit.

Previous
Previous

IBM Sustainability Platform

Next
Next

Audi Online