Billing Platform

Projects

BT Group: Billing Platform Transformation

Billing Platform Transformation

BT’s billing platform for small and medium businesses hadn’t been meaningfully redesigned in over 30 years. It was old, clunky and full of poor UX decisions that had accumulated over decades – a legacy system that was generating a significant volume of support calls and frustrating the businesses that relied on it daily.

I was brought in to lead a full platform transformation, starting as the sole designer and eventually building and leading a team of 30 as the project scaled.

My role

I joined as the sole Senior Product Design Specialist on the project. As the work grew in scope I was responsible for hiring and leading a wider design team, setting the standard for how the designs should look and feel, running design reviews and ensuring quality and consistency across everything the team produced.

I also drove the research approach – analysing over 2,000 customer support calls using AI to identify the most common pain points and themes on the legacy platform, then translating those findings into design priorities for the new platform.

User research

AI-assisted research analysis

Stakeholder workshops

Wireframing

UI design

Prototyping

Design leadership

Team management

Design system thinking

Multi-account UX

Bill management UX

Payment flow design

Direct Debit UX

B2B enterprise design

Key challenges:

A 30-year-old platform with no clear starting point

Challenge

The existing platform was legacy in every sense – outdated visually, poor UX throughout and built on assumptions about how businesses managed their billing that no longer reflected reality.

There was no modern foundation to build from.

Solution

I started by running workshops with key internal stakeholders to define the visual direction, set expectations and establish what the new platform needed to achieve.

These sessions gave the project a shared vision before any design work began and ensured the people closest to the business problems were part of shaping the solution.

Key challenges:

Understanding what was actually going wrong

Challenge

Without solid user research it would have been easy to guess at the problems rather than design for the real ones.

The platform had been generating support calls for years but nobody had systematically analysed what those calls were actually about.

Solution

I planned and drove an AI-assisted analysis of over 2,000 customer support calls, identifying the most common themes and issues users were experiencing with the existing platform.

Those findings directly informed the design priorities – every major decision in the redesign was rooted in real evidence of what was going wrong.

Key challenges:

Building and leading a design team mid-project

Challenge

Starting as the sole designer meant establishing the design direction alone.

As the project scaled and a wider team was hired, maintaining consistency and quality across 30 designers became a significant challenge in itself.

Solution

I set the design standard early and communicated it clearly as the team grew.

Design reviews, direction-setting and quality assurance became a core part of my role – making sure every designer on the team understood what good looked like and why, rather than just being handed specs to execute.

Key challenges:

Designing a complex multi-feature platform

Challenge

The billing platform wasn’t a simple one-purpose tool.

It needed to handle a wide range of tasks for SMB customers – many of whom managed multiple accounts and multiple sites simultaneously.

Solution

I designed the full end-to-end platform covering: monthly bill viewing, bill payment, outstanding bills, Direct Debit setup for both sole-signatory and non sole-signatory accounts, alternative payment methods, bill comparison, bill downloading, a bill predictor, multi-action functionality allowing users to select multiple bills and perform bulk actions, and full multi-account and multi-site support.

Each feature was designed to work consistently within the wider platform – not as a collection of disconnected screens.

Research:

AI-assisted support call analysis

I planned and drove an analysis of over 2,000 customer support calls using AI to surface themes and recurring issues. This gave the team a clear, evidence-based picture of what was frustrating users on the existing platform – without needing to start from scratch with a blank research slate.

Key themes from the analysis informed the design priorities throughout the project, ensuring we were solving real problems rather than assumed ones.

Research:

Stakeholder workshops

I ran workshops with key internal BT stakeholders to define the visual language and expectations for the new platform. These sessions established a shared understanding of the design direction and gave the business teams a clear view of what was being built and why.

Designs:

Dashboard and account overview

The landing experience for SMB customers – giving a clear overview of their account status, outstanding amounts and upcoming payment dates at a glance.

AI-assisted messaging surfaced the most relevant information proactively, flagging outstanding balances and predicted bill dates without users needing to dig for them.

Designs:

Bill viewing and comparison

Users could view their monthly bills in detail, compare bills across periods and download copies directly.

The information architecture was redesigned from the ground up to make billing data readable and navigable rather than buried in legacy formatting.

Designs:

Bill predictor

A forward-looking feature that gave SMB customers visibility of their expected upcoming bill – helping businesses plan cash flow and avoid surprises.

One of the features most directly informed by the support call analysis, where bill confusion was a recurring theme.

Designs:

Direct Debit setup

Separate flows designed for sole-signatory and non sole-signatory accounts – recognising that the authorisation process was fundamentally different depending on the account structure.

Each flow was designed to be as lean as possible while handling the necessary complexity.

Designs:

Multi-action and bulk billing

SMB customers with multiple bills needed to be able to act on several at once rather than repeating the same actions individually.

Multi-select functionality allowed users to choose multiple bills and perform bulk actions – a significant time saving for businesses managing complex accounts.

Designs:

Multi-account and multi-site

For businesses operating across multiple sites or accounts, the platform needed to handle that complexity without making the experience feel overwhelming.

Navigation and account switching were designed to make moving between accounts feel natural and fast.

Designs:

Payments

Multiple payment routes designed for – paying outstanding bills, setting up Direct Debits, making alternative payments.

Each payment journey designed to be as straightforward as possible while meeting BT’s security and data requirements.

Outcomes:

The results

The platform transformation was still in progress when I moved on in early 2025 – but the design foundations, team and direction were firmly established.

Over 2,000 support calls analysed to shape the design priorities. A 30-designer team built, led and aligned around a consistent design standard. A platform that hadn’t been touched in over 30 years redesigned from the ground up.

Billing Platform Transformation

I was brought in to lead a full platform transformation, starting as the sole designer and eventually building and leading a team of 30 as the project scaled.

My role

User research

AI-assisted research analysis

Stakeholder workshops

Wireframing

UI design

Prototyping

Design leadership

Team management

Design system thinking

Multi-account UX

Bill management UX

Payment flow design

Direct Debit UX

B2B enterprise design

Key challenges:

A 30-year-old platform with no clear starting point

Challenge

The existing platform was legacy in every sense – outdated visually, poor UX throughout and built on assumptions about how businesses managed their billing that no longer reflected reality.

There was no modern foundation to build from.

Solution

I started by running workshops with key internal stakeholders to define the visual direction, set expectations and establish what the new platform needed to achieve.

These sessions gave the project a shared vision before any design work began and ensured the people closest to the business problems were part of shaping the solution.

Key challenges:

Understanding what was actually going wrong

Challenge

Without solid user research it would have been easy to guess at the problems rather than design for the real ones.

The platform had been generating support calls for years but nobody had systematically analysed what those calls were actually about.

Solution

I planned and drove an AI-assisted analysis of over 2,000 customer support calls, identifying the most common themes and issues users were experiencing with the existing platform.

Those findings directly informed the design priorities – every major decision in the redesign was rooted in real evidence of what was going wrong.

Key challenges:

Building and leading a design team mid-project

Challenge

Starting as the sole designer meant establishing the design direction alone.

As the project scaled and a wider team was hired, maintaining consistency and quality across 30 designers became a significant challenge in itself.

Solution

I set the design standard early and communicated it clearly as the team grew.

Key challenges:

Designing a complex multi-feature platform

Challenge

The billing platform wasn’t a simple one-purpose tool.

It needed to handle a wide range of tasks for SMB customers – many of whom managed multiple accounts and multiple sites simultaneously.

Solution

Each feature was designed to work consistently within the wider platform – not as a collection of disconnected screens.

Research:

AI-assisted support call analysis

Key themes from the analysis informed the design priorities throughout the project, ensuring we were solving real problems rather than assumed ones.

Research:

Stakeholder workshops

Designs:

Dashboard and account overview

The landing experience for SMB customers – giving a clear overview of their account status, outstanding amounts and upcoming payment dates at a glance.

AI-assisted messaging surfaced the most relevant information proactively, flagging outstanding balances and predicted bill dates without users needing to dig for them.

Designs:

Bill viewing and comparison

Users could view their monthly bills in detail, compare bills across periods and download copies directly.

The information architecture was redesigned from the ground up to make billing data readable and navigable rather than buried in legacy formatting.

Designs:

Bill predictor

A forward-looking feature that gave SMB customers visibility of their expected upcoming bill – helping businesses plan cash flow and avoid surprises.

One of the features most directly informed by the support call analysis, where bill confusion was a recurring theme.

Designs:

Direct Debit setup

Separate flows designed for sole-signatory and non sole-signatory accounts – recognising that the authorisation process was fundamentally different depending on the account structure.

Each flow was designed to be as lean as possible while handling the necessary complexity.

Designs:

Multi-action and bulk billing

SMB customers with multiple bills needed to be able to act on several at once rather than repeating the same actions individually.

Multi-select functionality allowed users to choose multiple bills and perform bulk actions – a significant time saving for businesses managing complex accounts.

Designs:

Multi-account and multi-site

For businesses operating across multiple sites or accounts, the platform needed to handle that complexity without making the experience feel overwhelming.

Navigation and account switching were designed to make moving between accounts feel natural and fast.

Designs:

Payments

Multiple payment routes designed for – paying outstanding bills, setting up Direct Debits, making alternative payments.

Each payment journey designed to be as straightforward as possible while meeting BT’s security and data requirements.

Outcomes:

The results

The platform transformation was still in progress when I moved on in early 2025 – but the design foundations, team and direction were firmly established.

STERIS Collect & Deliver

Projects

STERIS: Collect and deliver

Collect and deliver

STERIS deliver specialist outsourced services to healthcare providers, including the collection and delivery of trolleys between hospital facilities and central cleaning warehouses.

When I joined the project, the entire process was being managed with pen and paper – and it was generating roughly 80 defects a week. Trolleys ending up at the wrong hospitals, delivery logs filled in incorrectly, porters trying to remember what they’d collected across multiple trips to a sixth floor ward and back.

I designed a native Android app for the Bluebird device that digitised the whole process – and the results spoke for themselves. 100% delivery improvement. 44% productivity increase.

My role

I was the UX/UI designer on the project end to end – shadowing drivers in the field, mapping user journeys, creating flows for both happy and unhappy paths, wireframing in Balsamiq, designing the full Android UI and conducting user testing sessions with the porters themselves.

The app was built for the Bluebird – a rugged Android handheld device with a built-in barcode scanner – and needed to work reliably in environments where hospital signal could be terrible.

User research

Shadowing

High level user journey mapping

User flows

Wireframing (Balsamiq)

Android native UI design

Prototyping

User testing

Offline-first design

Geolocation

Push notification design

Key challenges:

Trolleys ending up at the wrong hospital

Challenge

Trolleys have poor wheels and a habit of drifting between groups.

A well-meaning member of staff puts a stray trolley back in what they think is the right group – but it isn’t.

The porter collects it, delivers it to the wrong hospital, and another defect gets logged.

Solution

The app notified porters if they’d scanned fewer trolleys than expected for a collection, flagging the discrepancy before they left rather than after they’d delivered to the wrong place.

Not much I could do about the wheels.

Key challenges:

Delivery logs filled in from memory

Challenge

A porter arrives at a hospital with 10+ trolleys. They make 5+ trips to a sixth floor ward and back, dropping off clean trolleys and collecting dirty ones.

By the end of the shift they’re trying to remember exactly what they collected and where – and filling in paper logs from memory.

Unsurprisingly, things went wrong.

Solution

By scanning their location on arrival and scanning each trolley as they collected or delivered it, the app logged everything automatically in real time. No memory required.

After user testing, the porters’ biggest reaction was realising they didn’t need to go back to the van to fill in delivery logs – the app had already done it.

Key challenges:

Designing for poor signal

Challenge

Some hospitals have terrible phone signal, and the Bluebird is a mobile device.

If the app stopped working every time signal dropped, it would be worse than the pen and paper system it was replacing.

Solution

I designed a full offline handling flow. When the device lost signal, scanned trolleys were stored in an offline list and the app continued functioning normally – making the usual success sound so porters weren’t confused.

When signal returned, the database checked the offline list for errors and duplications and notified the user if any action was needed. Seamless.

Key challenges:

Fast track deliveries

Challenge

Occasionally a porter would get an urgent call mid-shift to collect a fast-tracked trolley for an emergency procedure – dropping everything and going immediately.

This was another point where trolleys could easily get mixed up.

Solution

Fast track requests pushed directly to the device as notifications, taking the porter straight to the relevant location and logging the collection separately so it didn’t get confused with their regular run.

Key challenges:

Multiple users, one device

Challenge

The Bluebird devices were shared across multiple porters.

Each user had their own preferred task setup and needed to be able to switch accounts quickly without losing their personalised configuration.

Solution

I added a Change User feature in Settings that let porters switch accounts in seconds, with each user’s task preferences saved to their profile so nothing needed to be reconfigured.

Research:

Shadowing

Before touching a wireframe I spent a day shadowing a porter on their actual shift – watching how the current pen and paper process worked in practice, where it broke down and what the real day-to-day frustrations were. Seeing the process firsthand was invaluable.

The high volume of trips, the difficulty of remembering collections across a full shift and the chaos of a fast track call all became immediately obvious in a way that no brief could have conveyed.

Research:

High level user journey

I mapped out a high level user journey covering the full path a porter takes during a typical shift – excluding fast track journeys, which were mapped separately. This gave the whole team a shared understanding of the process before design began.

Ideation:

User flows

I created two user flows – a happy path covering the standard collect and deliver process, and an unhappy path covering offline functionality and error states.

The offline path was just as important as the happy path given the signal conditions in older hospital buildings.

Happy path

After logging in, the porter lands on their personalised Tasks screen. They scan their location, then scan each trolley. Recognised trolleys are logged automatically with a success ping. Unrecognised trolleys trigger an aggressive vibration, an error sound and a blocking notification the porter must acknowledge before continuing.

Unhappy path

When signal drops, scanned trolleys are stored in an offline list. The app continues as normal – same success sounds, same behaviour – so the porter’s workflow isn’t interrupted. When signal returns, the database checks the offline list and flags any issues.

Ideation:

Flow chart

I produced a full flow chart giving a high-level view of the entire app – helping refine navigation logic and expected behaviour across all screens before wireframing began.

Designs:

Login and password expiry

Porters log in with their credentials on opening the app. A 10-minute inactivity timeout logs users out automatically – with a Remember Me option for longer shifts. Password expiry prompts users to update their password periodically for security.

Login design flow - enter user details (2 of 3)

Designs:

Collect

On arriving at a location, the porter scans the location barcode first, then scans each trolley. A success ping confirms each scan. An unrecognised trolley triggers vibration, an error sound and a blocking screen the porter must confirm before continuing.

Designs:

Hospital contacts

The contacts page populates automatically based on the porter’s shift – showing the relevant staff and delivery points for that day. If something goes wrong en route, porters can call the on-site manager or use the built-in maps to navigate around the problem.

Designs:

Favourite tasks

Porters can customise their Tasks screen by toggling jobs on and off depending on what they’re doing that shift. Phase 1 launched with Collect and Deliver, with further task types planned for later phases.

Designs:

Locations

The Locations screen showed a porter’s regular delivery points for the shift, with fast track requests pushing directly to the top as urgent notifications.

Settings:

Change language

The app was built with multilingual capability from the start – designed to support STERIS operations across multiple countries, with language selection accessible directly from Settings.

Settings:

Change user

Shared devices meant multiple porters needed to switch accounts quickly without losing their individual task preferences. The Change User feature handled this in seconds.

Settings:

Create new password

A straightforward password change flow – current password, new password, confirm, save.

3_Password expired login - create new password – 17

4_Password expired login - create new password – 18

Testing:

User testing

I ran user testing sessions with the porters directly – putting the prototype onto an actual Bluebird device so it felt as close to the real thing as possible. I wrote a scripted scenario asking users to log in, select the Collect task, scan a location and scan a couple of trolleys.

Initially the porters were a little cautious, but they picked it up quickly. The feedback was consistent – they loved how simple it was, but almost all of them instinctively felt like they needed to go back to the van to fill in their delivery logs afterwards. When they realised the app had already done it for them, they were genuinely delighted.

Outcomes:

The results

Delivery improvement

Productivity increase

Defect rate before the app

With roughly 382 trolleys being processed each week and around 80 of them resulting in defects, the target was clear – reduce errors, improve accountability and save time. The app delivered on all three.

Hospitals knew when their delivery was expected. Porters were notified of problems in real time rather than discovering them at the next facility. And nobody had to fill in a paper log ever again.

Collect and deliver

STERIS deliver specialist outsourced services to healthcare providers, including the collection and delivery of trolleys between hospital facilities and central cleaning warehouses.

I designed a native Android app for the Bluebird device that digitised the whole process – and the results spoke for themselves. 100% delivery improvement. 44% productivity increase.

My role

The app was built for the Bluebird – a rugged Android handheld device with a built-in barcode scanner – and needed to work reliably in environments where hospital signal could be terrible.

User research

Shadowing

High level user journey mapping

User flows

Wireframing (Balsamiq)

Android native UI design

Prototyping

User testing

Offline-first design

Geolocation

Push notification design

Key challenges:

Trolleys ending up at the wrong hospital

Challenge

Trolleys have poor wheels and a habit of drifting between groups.

A well-meaning member of staff puts a stray trolley back in what they think is the right group – but it isn’t.

The porter collects it, delivers it to the wrong hospital, and another defect gets logged.

Solution

The app notified porters if they’d scanned fewer trolleys than expected for a collection, flagging the discrepancy before they left rather than after they’d delivered to the wrong place.

Not much I could do about the wheels.

Key challenges:

Delivery logs filled in from memory

Challenge

A porter arrives at a hospital with 10+ trolleys. They make 5+ trips to a sixth floor ward and back, dropping off clean trolleys and collecting dirty ones.

By the end of the shift they’re trying to remember exactly what they collected and where – and filling in paper logs from memory.

Unsurprisingly, things went wrong.

Solution

By scanning their location on arrival and scanning each trolley as they collected or delivered it, the app logged everything automatically in real time. No memory required.

After user testing, the porters’ biggest reaction was realising they didn’t need to go back to the van to fill in delivery logs – the app had already done it.

Key challenges:

Designing for poor signal

Challenge

Some hospitals have terrible phone signal, and the Bluebird is a mobile device.

If the app stopped working every time signal dropped, it would be worse than the pen and paper system it was replacing.

Solution

When signal returned, the database checked the offline list for errors and duplications and notified the user if any action was needed. Seamless.

Key challenges:

Fast track deliveries

Challenge

Occasionally a porter would get an urgent call mid-shift to collect a fast-tracked trolley for an emergency procedure – dropping everything and going immediately.

This was another point where trolleys could easily get mixed up.

Solution

Key challenges:

Multiple users, one device

Challenge

The Bluebird devices were shared across multiple porters.

Each user had their own preferred task setup and needed to be able to switch accounts quickly without losing their personalised configuration.

Solution

I added a Change User feature in Settings that let porters switch accounts in seconds, with each user’s task preferences saved to their profile so nothing needed to be reconfigured.

Research:

Shadowing

The high volume of trips, the difficulty of remembering collections across a full shift and the chaos of a fast track call all became immediately obvious in a way that no brief could have conveyed.

Research:

High level user journey

Ideation:

User flows

I created two user flows – a happy path covering the standard collect and deliver process, and an unhappy path covering offline functionality and error states.

The offline path was just as important as the happy path given the signal conditions in older hospital buildings.

Happy path

Unhappy path

Ideation:

Flow chart

I produced a full flow chart giving a high-level view of the entire app – helping refine navigation logic and expected behaviour across all screens before wireframing began.

Designs:

Login and password expiry

Designs:

Collect

Designs:

Hospital contacts

Designs:

Favourite tasks

Designs:

Locations

The Locations screen showed a porter’s regular delivery points for the shift, with fast track requests pushing directly to the top as urgent notifications.

Settings:

Change language

The app was built with multilingual capability from the start – designed to support STERIS operations across multiple countries, with language selection accessible directly from Settings.

Settings:

Change user

Shared devices meant multiple porters needed to switch accounts quickly without losing their individual task preferences. The Change User feature handled this in seconds.

Settings:

Create new password

A straightforward password change flow – current password, new password, confirm, save.

Testing:

User testing

Outcomes:

The results

Hospitals knew when their delivery was expected. Porters were notified of problems in real time rather than discovering them at the next facility. And nobody had to fill in a paper log ever again.

Delivery improvement

Productivity increase

Defect rate before the app

Amethyst Design System

Projects

Gamma: Amethyst design system

Amethyst design system

When I joined Gamma, the UX team was in its infancy and the inconsistencies across the business were obvious – different products, different patterns, different ways of working, no shared language between designers or between design and development.

Nobody had built a design system before. I championed the idea, got buy-in and built Amethyst from scratch over 18 months.

By the time it was up and running, 9 designers were working from it and it was planned to roll out across all Gamma services.

My role

I was the sole creator of Amethyst – responsible for every part of it, from the initial concept and naming through to foundations, components, documentation, developer handoff and the processes that surrounded it.

I introduced ways of working that hadn’t existed at Gamma before – feedback loops, sign-off steps, tone of voice guidelines, Atomic Design methodology and a component library in Figma with boolean properties.

The team was small and the UX function was still finding its feet – I worked closely with three other designers at various points, getting their hands-on feedback to test and refine the system as it grew.

Design system creation

Atomic Design methodology

Figma component library

Boolean properties

Design tokens

Responsive grid design

Typography

Colour theory

Iconography

Illustration guidelines

Storybook

Chromatic

Frontify

Design documentations

Accessibility (WCAG)

Tone of voice

Developer handoff

Feedback loop design

Mentoring

Research:

Why Amethyst?

Naming a design system matters – it gives it an identity and makes people feel invested in it.

I ran a workshop to figure out what to call it, exploring acronyms like GTDS, telecoms-inspired names, plays on the word Gamma – Wave, Rays – and various other directions.

Amethyst won. The amethyst stone is often referred to as the inventor’s stone – fitting for a team of creatives building something new from the ground up. It also happened to match Gamma’s brand colour, which didn’t hurt.

Amethyst:

The problem

Gamma had multiple products and services being designed and built in parallel, but no shared foundation connecting them. Inconsistent UI patterns, duplicated work, no agreed visual language and no single source of truth.

Designers were solving the same problems independently, developers were recreating components from scratch and there was no process for ensuring quality or consistency across the board.

The solution wasn’t just a component library – it was a system. A way of working that connected design to development, gave everyone a shared language and meant that decisions made once could scale across the entire product suite.

Amethyst:

The foundations

Before building any components I established the foundations – the building blocks everything else would be built on.

Design tokens

The system was fully tokenised, making it straightforward to switch between light and dark mode across all components – a single token update cascaded through the entire library rather than requiring manual changes component by component.

Colour

A full colour palette covering brand, neutral, semantic and interactive states across both light and dark themes.

Typography

Type scales, weights and line heights defined for every context – headings, body, labels, captions.

Grid systems

Responsive grid definitions covering desktop, tablet and mobile breakpoints.

Iconography

A consistent icon set with clear usage guidelines.

Illustrations

A defined illustration style to ensure visual consistency across all touchpoints.

Amethyst:

Atomic design methodology

Amethyst was built using Atomic Design – starting with atoms, combining them into molecules, building those into organisms and assembling organisms into full patterns and templates.

Atoms

The smallest building blocks; buttons, inputs, labels, icons, checkboxes, toggles.

Molecules

Atoms combined into functional unites; form fields, search bars, notification components.

Organisms

More complex UI sections that are built from molecules; navigation bars, card grids, data tables.

Patterns

Full page templates and reusable layout structures built from organisms.

Every level was documented, named consistently and linked within Figma so designers could trace a component back to its constituent parts at any time.

Figma:

The component library

The Figma component library was built with boolean properties throughout – meaning designers could toggle parts of a component on and off in real time without needing to create separate variants for every possible state. This was entirely new to Gamma. Before Amethyst, designers were either creating components from scratch or duplicating and manually editing existing ones.

Boolean properties meant that a single card component could handle every combination of states – with or without an image, with or without a label, with or without a CTA – without the library becoming unmanageable.

Every component was built to cover all interactive states: default, hover, focus, active, disabled and error where relevant.

Storybook & Chromatic

Developer handoff

Amethyst wasn’t just a Figma library – it was designed to connect design to code.

We integrated Storybook for component development and Chromatic for visual regression testing, meaning developers had a coded mirror of the design components to work from.

This reduced the back-and-forth between design and development and gave both sides a shared reference point for what a component should look like and how it should behave.

Documentation:

The Amethyst design guide

Alongside the component library I wrote the Amethyst design guide – hosted in Frontify – covering everything a designer or developer needed to use the system correctly.

Each component entry covered:

When and how to use it: guidance on appropriate contexts and usage

Do’s and don’ts: clear examples of correct and incorrect usage

Accessibility considerations: WCAG compliance notes, colour contrast requirements, touch target sizing

Tone of voice: writing guidelines to ensure consistent, on-brand copy across all products

Developer notes: implementation guidance and links to Storybook components

The goal was for any designer or developer – new to Gamma or experienced – to be able to pick up Amethyst and use it correctly without needing to ask anyone for help.

Definition:

New processes and Ways of working

Building the system was only part of the job. Getting people to use it consistently required new processes that hadn’t existed at Gamma before. I introduced:

Feedback loops: structured review points where designers could share work in progress and get input from the team before moving to final designs.

Sign-off steps: a clear process for how components were reviewed, approved and added to the library, ensuring quality control as the system grew.

Mentoring: I worked with three other designers in the team through a mentoring programme, using their experience of the system to identify gaps, test new components and refine documentation.

Tone of voice: a writing framework applied consistently across all Gamma products and communications.

Outcomes:

The results

Built from scratch and operational within 18 months

9 designers working from a single shared system

Planned rollout across all Gamma services

Introduced Atomic Design, boolean properties, Storybook integration, Chromatic, Frontify documentation and structured design processes – all new to Gamma

Eliminated duplicated work and inconsistent UI patterns across the product suite

The patterns established in Portal Evolution became the foundation for Amethyst – and from Amethyst, they rolled out everywhere

User experience

Gamma: Portal evolution

Portal Evolution

Gamma Telecoms’ portal improvements make managing services and orders easier, enhance user experience, and support the move to digital communications like unified solutions and the PSTN switch-off.

My role

On the Portal Evolution project for Gamma, I led the design and development of a next-generation platform aimed at streamlining complex workflows and enhancing user engagement. My focus was on creating intuitive, scalable solutions that empowered users to navigate and manage their tasks with ease.

I collaborated closely with stakeholders to identify pain points and opportunities for improvement, conducting user research and usability testing to gather actionable insights. These findings informed the creation of personas, user journeys, and wireframes, which I shared with cross-functional teams to align on a clear vision. By leveraging a combination of research, design, and iterative problem-solving, I delivered a platform that not only addressed immediate user needs but also provided a foundation for future growth and innovation.

User research

Affinity mapping

Site mapping

Competitor analysis

User flows

Tree jack

Wireframes

Visual design

Prototyping

Key challenges:

Inconsistent, inefficient navigation

Challenge

The Portal’s overly complex navigation left customers struggling to locate the areas they needed to work on, resulting in frustration, wasted time, and decreased productivity.

This lack of intuitive design not only hindered users from completing tasks efficiently but also contributed to a negative perception of the platform’s usability and reliability.

Solution

I researched into all the sections and pages within the navigation to identify opportunities to separate, group, or merge them. The goal was to simplify the experience and make it easier for customers to find what they needed.

As a result, I created a streamlined experience where users could clearly distinguish between creating and managing orders within a single flow. Previously, these actions were split across separate links, which added unnecessary complexity.

Key challenges:

Fragmented user journeys

Challenge

Users of the Gamma Portal encountered inconsistent user interfaces and disjointed journeys when navigating the platform’s features, including reporting dashboards, ordering processes, and administrative tools.

These inconsistencies made the platform less accessible and efficient, ultimately affecting customer satisfaction and retention.

Solution

I explored specific ways to help customers streamline their ordering processes.

One key area I focused on was reducing friction by encouraging users to self manage within a profile area. This allowed customers to input their information beforehand, so when starting an order, they could simply select a profile. With one click, all the required fields would be automatically pre-filled, making the process faster and more efficient.

To further enhance usability, we added a convenient checkbox at the bottom of the form for users who hadn’t prepopulated their profile. This feature allowed them to transfer the information they entered on the form directly to their profile for future use.

For Channel Partners managing multiple customers, this approach was scalable, as users could easily select the relevant account to streamline their workflow even further.

Goals

Improve navigation across the platform

The navigation was excessively large, with over 147 individual links!! Users found it difficult to identify which links were relevant to their workflows and how to navigate to specific sections that were important to them when needed.

Simplify all journey flows

Throughout many order journeys, there was significant repetition and unnecessary mandatory fields that had to be completed when placing an order. Many customers believed this was a way for Gamma to collect data from them.

Although these input fields were mandatory, the system was unable to validate whether the data entered was correct. As a result, customers realised they could input anything into the fields to proceed to the next page in the flow.

Reduce pressures on support teams by allowing users to self serve on the platform

When users placed an order or needed to make any changes to their accounts, users were required to call the support line so an agent could make the necessary updates.

No matter how small the task, this was still required.

Research:

Site mapping

After gathering extensive feedback from users across the business, first-hand customers, and exploring the platform myself, I decided it would be best to create a site map.

This process allowed me to review all areas of the site and gain a clear overview of its structure. I also made rough notes describing the actions required on each specific page to better understand the purpose and layout.

Could any of the sections within the navigation be simplified or condensed, as there may be duplications throughout? Surely a navigation menu can be streamlined from 147 links!

Research:

Journey flows

Once I had gained more insight into the platform, I began mapping out the journeys users would take to create orders. Each time an order was created across the business, the user had to log in, select an account, and input their details—followed by additional steps specific to the type of order they wanted to make.

Key findings:

Site map

I wen’t through every page on the site, going through the navigation links and made a brief note of what each page required the user to do to complete the relevant task. (Yes! It was quite a job!)

Observations

There are numerous search pages, each requiring you to select a specific account and enter a unique identifier. However, the search functionality lacks clarity—typing in the search field either displays results or leaves the page blank. There’s no 'No results' message or any guidance on what can be searched for, making it unclear what specific information is allowed or expected.

There is inconsistent terminology used across the platform, along with numerous spelling and grammar errors. For example, buttons are labelled inconsistently as 'Continue', 'Next', or 'Proceed'.

The 'Download' button appears on search pages before the user has performed a search, which makes the page feel confusing and unintuitive.

There are numerous instances of unusual UX behaviour and inconsistent styling throughout the platform.

Key findings:

Site map overview

I grouped all the finding together. This gave me a breakdown of the main areas of focus to start improving.

Overview

54 pages involve 'searching'

31 pages involve 'Management'

11 pages involve 'Creating'

9 pages involve 'Bulk actions'

9 pages involve 'Notifications'

It was obvious just by looking at the numbers that areas needed to be streamlined, instead of having a page for every single area, lets have one global feature instead.

By streamlining the navigation, I thought it would be a great idea to see if every duplicate page could be removed, if there were reasons to keep that page, I would see if I could integrate that particular part in the grand design so functionality wasn’t being missed out.

Ideation:

Landing page

The idea was to create a landing page when the user logs in. Users can see their products, services, sites and locations easily.

The navigation has been completely stripped back and simplified:

One area for creating new orders

One area for managing current products and services

One of the main frustrations when creating a new order was the lack of flexibility to amend or change orders, upgrade services, or even update site details and equipment for each site.

Users had to phone or email to make changes to their account. The same process applied when placing an order: users would endure the laborious task of creating their order, only for it to be emailed to someone in accounts, who would then calculate the costs and send an invoice back to the user.

The whole process felt incredibly outdated and wasn’t very transparent.

Wireframes:

‘My products’ page

I created an area where users could easily self-serve and ‘Manage’ their active products manually, as well as a space where they could easily ‘Create’ a new order if they wanted to add another service.

The screen is split into two sections: the left side displays your active services at each site, while the right side dynamically updates to show specific information about whatever you’ve selected on the left. This could be site details or information about a particular service.

If nothing is selected, the screen provides helpful guidance to indicate that you can interact with the panels on the left.

Edit an active service

If a user selects a specific service, they can see the level of service they have, along with its location.

If the service or product is eligible for an upgrade, users can do this themselves by simply toggling the options on or off. Alternatively, users can also select any relevant bolt-ons for that particular service, with prices clearly highlighted for transparency.

This removes the need to wait for accounts to recalculate everything and get back to the user.

Edit a site

Similarly to selecting a service, the site details could be easily edited or adjusted, and users could view all the products and services active at a particular site.

They could also toggle a service on or off if it was no longer required.

Final design:

‘My products’ page

When the user logs into the Portal, the first thing they see is a breakdown of all the sites that the business has registered on they system.

Sites can be empty if they don’t have any active services. When services are active, you can see them on the page. Users can select the site as a whole or a specific service to update accordingly.

Edit an active service

When a service is selected, you can add bolt-ons or upgrade / downgrade and change settings accordingly based on the service thats been selected.

For transparency, you can see the cost difference for everything at a glance (none of that previous ’email / call’ in to get an updated price).

Edit a site

When a site is selected, you can edit the address and numbers, as well as toggle services on or off – the business has bought the service, so they can distribute the services however they wish.

Each site has it’s own equipment, the same as the site settings, these can be updated and toggled on / off.

Research:

Creating a new order

I began collecting first-hand information and insights on users’ opinions and behaviours of the current platform – specifically creating a new order as this was a common task that users did on the platform.

I noticed there were lots of similarities and repeated tasks for each flow – could I simplify this step in the journey somehow?

I asked users what they liked and disliked about the journey, while also making general notes. I organised these notes into categories:

Observations

Positive

Minor

Serious

Critical

Along the way, I also gathered suggestions on how the platform could be improved moving forward.

User interviews:

Step 1: Contact details

All users would have to start by entering their details – they would have to select their account, along with information such as email address, name, company name, phone and mobile numbers as well as selecting what the nature of the business was.

These fields felt very accessive and they had to be filled in every time users wanted to create a new order – if the details were linked to the account they’ve selected in the first step then surely the other details could be pre-populated based on the selected account.

Serious

Users often failed to provide the correct information in the Customer Contact Details section. This was primarily because they didn’t fully understand the information being requested. In many cases, the technical contact was from a different company and not local to the person completing the form, making it even more challenging to provide accurate details.

Minor

Some users questioned why certain information was being requested and expressed concerns that it might be a data capture exercise by the business.

Positive

Many users found it straighforward to complete the information in the form.

User interviews:

Step 2: Product details

Users then have to select what level of security they want for the product. The options were very jargon heavy and wordy – plus I don’t know what the difference is between each choice, what extra am I paying for?

I also noticed users kept missing the yellow “I confirm” checkbox and then clicked ‘Continue’ to progress with the order.

This felt like it used to be at the bottom of the page, but more and more information has been added to the page over time like the ‘Promotions’ section.

Serious

Multiple users mentioned that they would add a dummy broadband service in order to qualify for free SIP Trunk Call Manager.

Supporting comments:
The broadband service rental cost is typically lower than the SIP Trunk Call Manager cost because of the cost of DDI's etc, so even if it's not used we do have a couple where they have an existing ethernet circuit and we've put a broadband service in that's not even used just to get the free SIP Trunk Call Manager

Minor

Some users didn’t understand the differences between the Build Types and would rely solely on the information provided in the order form from their account managers.

Positive

A user explained that SIP Trunk Call Manager had been hugely beneficial during COVID, as it allowed customers to manage their own call diverts.

User interviews:

Step 3: Build details

The first yellow warning message at the top of the page say: “It is vital that CPE information is correct”, but lots of people mentioned that they didn’t know what a SBC / IP-PBX was.

Critical

Some users reported that when they entered a quantity in the Channel Count field and clicked 'Continue', then navigated back to the previous page, the quantity they had entered was automatically changed to 10.

Serious

Users often had to enter a dummy IP address because they didn’t have an IP address available at the time.

Many users would initially enter "2" in the Channel Count field and later go back to update it once the service had been configured.

Some users were unsure about the difference between "SBC in front of an IP-PBX" and "IP-PBX only."

Minor

Similar to the Contact Details page, users didn’t understand why Gamma was requesting such a large amount of information.

Supporting comments:
I've not always been accurate with the information and is hasn't caused me a problem

Observations

Users assumed that the address picker was linked to the 999 emergency details.

User interviews:

Step 4: Service configuration

Users would then have to set up their daily fraud limit by inputting a daily amount of their choice and select what calls they can block from being made.

Minor

Some users commented that the default fraud limits were set too high.

Users were unsure if they could enter multiple email addresses. Despite the form stating 'email address(es)', they were unclear about the correct format to use.

Users were unsure about the purpose of 'Fax (T.38)', but some chose to enable it regardless.

Positive

Many users felt that the Fraud Management section was a valuable tool.

Observations

A few users chose not to enable Fraud Management, as they had already barred Premium Calls and felt there was no need for both.

User interviews:

Step 5: Call manager configuration

This was an optional page, but users would select if they wanted to upgrade their product – however it didn’t tell the user what the cost was for the upgrade.

Critical

Many users chose not to add the service add-ons, feeling they were too expensive and not worth the cost.

User interviews:

Step 6: Number selection

When users could create phone numbers, they could select the area code they needed, along with the quantity they needed and if they needed to be a consecutive amount or just randomly ordered.

Minor

Many users did not understand the meaning of 'Incoming CLI rule'.

Observations

Users felt that 'Consecutive' should be selected by default.

User interviews:

Step 7: Order complete

The last page is literally where the user reads and accepts the terms and conditions.

Once that task is complete, then the order gets sent over to the accounts team for them to review and work out the total costs.

Observations

One user mentioned they would consider performing enhanced SIP testing, but noted that the downside is it takes 24 hours.

Research:

Journey mapping

Create a new SIP Trunk order

After sorting out the dashboard for Portal Evolution, one of the first projects I worked on involved redesigning and defining the user experience for creating a new oders, specifically for SIP Trunk orders (this was because it was one of the larger journeys.

My approach typically involves mapping out the current journey and documenting every interaction required to complete the task, including optional interactions. For example, I note that the user lands on the login page and needs to click on the email address input field to begin entering their email address.

This detailed process allows me to create a clear before-and-after comparison, where a reduction in clicks highlights a simplified and more efficient task, ultimately saving time for the user.

You might notice the term “Between” in the analysis – this accounts for the optional interactions users can make. For instance, the current flow in its simplest form required 52 clicks, while the redesigned flow reduced this to just 15 clicks.

Current click count: Between 52-88 clicks

Suggested click count: Between 15-30 clicks

Final designs:

Profile area

One of the larger pieces of work that fell out of these flows was to create a profile area for users to add or update their details.

Currently, there wasn’t anything like this on the platform – the aim of creating the profile area was for users to enter the details that were asked throughout the ordering flows.

These details could then be prepopulated during the order journeys, reducing the users need to constantly input information over and over again.

Account overview

TBC

Personal information

TBC

Payment methods

TBC

Orders overview

TBC

Notification settings

TBC

Login and security

TBC

Final designs:

Create your order

I noticed when users wanted to create a new order they couldn’t add multiple services to their order.

It was literally a case of having to add all the details and information into the system multiple times, depending on how many services they wanted to place in the order.

Phase 1 – Price transparency

One of the main points I kept hearing from users and team members was the absolute lack of transparancy around the pricing of products, services and add-ons.

When a user selects a service – a ‘reciept style’ section appears showing the price (before, the users only saw the cost days after submitting their order).

We also tried to encourage upselling and add-ons, so if a user added another product to their order, they would save more money.

Phase 1 – Reduced jargon

TBC

Phase 1 – Simplified order journeys

One of the larger pieces of work that fell out of these flows was to create a profile area for users to add or update their details.

Currently, there wasn’t anything like this on the platform – the aim of creating the profile area was for users to enter the details that were asked throughout the ordering flows, these could then be prepopulated during the order creation, reducing the users need to constantly input information over and over again.

Order flow - Contact details (Multiple accounts to select from)

Gymshark Workout App

Projects

Gymshark: Workout app

Gymshark workout app

Gymshark set me a design brief: concept a workout app targeted at social natives who wanted to train alongside their favourite Gymshark athletes, get tips on form and technique from the pros and track their strength and conditioning workouts.

The brief covered a home screen redesign, a free vs premium content badging system, onboarding improvements and a pull-to-refresh mechanism for dynamic content.

I added an additional layer on top of the brief – an interactive muscle map overlay showing which muscle groups each exercise targeted in real time.

I spent a few weeks on the project, and the concepts I developed closely mirror the direction Gymshark ultimately took with the product.

My role

I was the sole designer on the project – research, competitor analysis, observations, design solutions, UI and interactive prototype.

The brief asked me to demonstrate creative and conceptual skills alongside iOS knowledge, with user experience prioritised over visual polish.

I treated it as a full end-to-end design exercise.

Competitor analysis

User journey mapping

iOS native design

Accessibility auditing (WCAG 2.0)

Onboarding design

Empty state design

Content badging system

Interactive prototyping

Muscle map / body overlay design

UI design

Research:

Competitor analysis

Before touching a wireframe I analysed how the leading players in the activewear and fitness space handled their product experiences – looking for patterns worth adopting and gaps worth exploiting.

Gymshark already had a strong quick-add feature on their website – hovering over a product revealed size availability and added it directly to the basket, cutting out multiple clicks compared to competitors. A lean model worth carrying into the app experience.

Under Armour showed colour availability without clicking into a product, but still required additional clicks to select a size – less lean than Gymshark’s approach.

Nike used clean, simple imagery with colour breakdowns and prominent Add to Cart buttons – a familiar, functional pattern.

Lululemon required users to click into a product and then open a dropdown to select a size – two additional clicks, and if the size wasn’t available, a frustrating waste of time.

Boohoo took a smart approach by only showing sizes that were actually available for each product – removing the disappointment of selecting an unavailable size entirely.

Amazon used hover states to surface sub-categories quickly, detailed filtering and Best Seller tags – useful patterns for surfacing content efficiently.

Key takeaway

The most effective experiences were the leanest ones. Every unnecessary click was a potential drop-off point, particularly for users mid-workout or on the move.

Research:

User journey mapping

I mapped out the current Gymshark user journey against competitor journeys to understand where friction existed and where the app could learn from best practice.

Gymshark’s quick-add flow was already strong – but the app experience needed to carry the same lean principles through to workout discovery, tracking and content consumption.

Patterns from best-in-class experiences like Petco and Zumiez informed the approach – limited exit points once in a flow, descriptive CTAs that set expectations, guest access, and clear progress indicators.

Observations and suggestions:

About you

Observations

The gender selection only offered Male and Female – no Non-Binary or Prefer Not to Say option.

The Continue button’s active state changed from dark grey to black – a subtle shift that would be easy to miss for users with visual impairments.

Touch targets on the checkbox and buttons were below Apple’s recommended 44px minimum, meaning users could easily tap the wrong element.

Suggestions

Adding a Non-Binary and Prefer Not to Say option promotes gender inclusivity and reflects Gymshark’s audience more accurately.

Increasing touch targets to 44px prevented accidental taps and made the interface usable mid-workout.

Making the active state of the Continue button more visually distinct ensured users knew they could proceed.

Observations and suggestions:

Home screen

Observations

The “Create your first custom plan” element didn’t look like a button – easy to overlook entirely.

The “View Athlete Plans” link failed WCAG 2.0 accessibility guidelines – low contrast made it difficult to read for anyone with a visual impairment, and the tap target was too close to the button above it.

Suggestions

Redesigning “Create Your Custom Plan” as a proper button with a supporting icon made the action clear and consistent with the rest of the app.

Updating “View Athlete Plans” to match the bottom navigation colour improved brand consistency and made the link immediately legible.

Observations and suggestions:

Search empty state

Observations

First-time users were greeted with a completely blank search page – no guidance, no suggestions, no starting point.

A new user who doesn’t know what to search for has nothing to go on.

Suggestions

I replaced the empty state with onboarding copy explaining that no searches had been made yet, alongside curated “Get Started”, “Popular” and “Hot This Week” suggestions.

New users got a gentle nudge in the right direction. Experienced users could ignore it and search directly.

Observations and suggestions:

Onboarding

Observations

The Skip button was positioned centrally at the bottom of the screen – exactly where a user’s eye and thumb naturally land.

Users were unconsciously skipping onboarding without reading it.

Suggestions

Moving Skip to the top right of the screen – where it’s visible but not prominent – meant users were far more likely to read through the onboarding content before dismissing it.

A small change with a significant impact on how much information users actually absorbed.

Ideation:

Home screen

The home screen redesign brought together all of the research findings into a single cohesive experience — promoting new and existing workout content to a mixed male and female audience, surfacing shortcuts to previous activities, and providing a pull-to-refresh mechanism for dynamic content loading.

The screen was structured around three priorities: getting returning users back to where they left off quickly, surfacing new content from athletes they follow, and giving new users a clear path into their first workout.

Ideation:

Free vs Premium badge system

Gymshark planned to introduce a premium subscription tier – with some athlete content free, some premium only, some new and free, and some new and premium. Users needed to be able to tell the difference at a glance without it disrupting the browsing experience.

Taking inspiration from Strava’s badging approach, I designed a consistent visual badging system covering all four states:

Free
Clearly labelled, accessible to all users

Premium
Badged to indicate subscription required

Free + New
Dual badge surfacing both attributes

New + Premium
Dual badge combining novelty and premium status

Any content not marked as Free was treated as premium by default – keeping the system simple and consistent throughout.

Ideation:

Muscle map overlay

Going beyond the brief, I designed an interactive muscle map feature – an addition I felt would meaningfully improve the workout experience.

When a user selected an exercise, a body map overlay highlighted which muscle groups that exercise targeted in real time. Users could also tap a muscle group on the map to discover exercises that worked that area.

The design challenge was surfacing detailed, dynamic information without cluttering the screen or breaking the user’s focus mid-workout.

The overlay was kept clean, minimal and dismissible – information on demand rather than information by default.

What happened next

The brief didn’t lead to a role – but the concepts I developed closely mirror the direction Gymshark subsequently took with their workout product.

The muscle map, the content badging system, the personalised home screen and the empty state improvements all found their way into the product in some form. Sometimes the work lands even when the opportunity doesn’t.

Gymshark workout app

The brief covered a home screen redesign, a free vs premium content badging system, onboarding improvements and a pull-to-refresh mechanism for dynamic content.

I added an additional layer on top of the brief – an interactive muscle map overlay showing which muscle groups each exercise targeted in real time.

I spent a few weeks on the project, and the concepts I developed closely mirror the direction Gymshark ultimately took with the product.

My role

I was the sole designer on the project – research, competitor analysis, observations, design solutions, UI and interactive prototype.

The brief asked me to demonstrate creative and conceptual skills alongside iOS knowledge, with user experience prioritised over visual polish.

I treated it as a full end-to-end design exercise.

Competitor analysis

User journey mapping

iOS native design

Accessibility auditing (WCAG 2.0)

Onboarding design

Empty state design

Content badging system

Interactive prototyping

Muscle map / body overlay design

UI design

Research:

Competitor analysis

Before touching a wireframe I analysed how the leading players in the activewear and fitness space handled their product experiences – looking for patterns worth adopting and gaps worth exploiting.

Under Armour showed colour availability without clicking into a product, but still required additional clicks to select a size – less lean than Gymshark’s approach.

Nike used clean, simple imagery with colour breakdowns and prominent Add to Cart buttons – a familiar, functional pattern.

Lululemon required users to click into a product and then open a dropdown to select a size – two additional clicks, and if the size wasn’t available, a frustrating waste of time.

Boohoo took a smart approach by only showing sizes that were actually available for each product – removing the disappointment of selecting an unavailable size entirely.

Amazon used hover states to surface sub-categories quickly, detailed filtering and Best Seller tags – useful patterns for surfacing content efficiently.

Key takeaway

The most effective experiences were the leanest ones. Every unnecessary click was a potential drop-off point, particularly for users mid-workout or on the move.

Research:

User journey mapping

I mapped out the current Gymshark user journey against competitor journeys to understand where friction existed and where the app could learn from best practice.

Gymshark’s quick-add flow was already strong – but the app experience needed to carry the same lean principles through to workout discovery, tracking and content consumption.

Observations and suggestions:

About you

Observations

The gender selection only offered Male and Female – no Non-Binary or Prefer Not to Say option.

The Continue button’s active state changed from dark grey to black – a subtle shift that would be easy to miss for users with visual impairments.

Touch targets on the checkbox and buttons were below Apple’s recommended 44px minimum, meaning users could easily tap the wrong element.

Suggestions

Adding a Non-Binary and Prefer Not to Say option promotes gender inclusivity and reflects Gymshark’s audience more accurately.

Increasing touch targets to 44px prevented accidental taps and made the interface usable mid-workout.

Making the active state of the Continue button more visually distinct ensured users knew they could proceed.

Observations and suggestions:

Home screen

Observations

The “Create your first custom plan” element didn’t look like a button – easy to overlook entirely.

Suggestions

Redesigning “Create Your Custom Plan” as a proper button with a supporting icon made the action clear and consistent with the rest of the app.

Updating “View Athlete Plans” to match the bottom navigation colour improved brand consistency and made the link immediately legible.

Observations and suggestions:

Search empty state

Observations

First-time users were greeted with a completely blank search page – no guidance, no suggestions, no starting point.

A new user who doesn’t know what to search for has nothing to go on.

Suggestions

I replaced the empty state with onboarding copy explaining that no searches had been made yet, alongside curated “Get Started”, “Popular” and “Hot This Week” suggestions.

New users got a gentle nudge in the right direction. Experienced users could ignore it and search directly.

Observations and suggestions:

Onboarding

Observations

The Skip button was positioned centrally at the bottom of the screen – exactly where a user’s eye and thumb naturally land.

Users were unconsciously skipping onboarding without reading it.

Suggestions

Moving Skip to the top right of the screen – where it’s visible but not prominent – meant users were far more likely to read through the onboarding content before dismissing it.

A small change with a significant impact on how much information users actually absorbed.

Ideation:

Home screen

The home screen redesign brought together all of the research findings into a single cohesive experience – promoting new and existing workout content to a mixed male and female audience, surfacing shortcuts to previous activities, and providing a pull-to-refresh mechanism for dynamic content loading.

Ideation:

Free vs Premium badge system

Taking inspiration from Strava’s badging approach, I designed a consistent visual badging system covering all four states:

Free
Clearly labelled, accessible to all users

Premium
Badged to indicate subscription required

Free + New
Dual badge surfacing both attributes

New + Premium
Dual badge combining novelty and premium status

Any content not marked as Free was treated as premium by default – keeping the system simple and consistent throughout.

Ideation:

Muscle map overlay

Going beyond the brief, I designed an interactive muscle map feature – an addition I felt would meaningfully improve the workout experience.

The design challenge was surfacing detailed, dynamic information without cluttering the screen or breaking the user’s focus mid-workout.

The overlay was kept clean, minimal and dismissible – information on demand rather than information by default.

What happened next

The brief didn’t lead to a role – but the concepts I developed closely mirror the direction Gymshark subsequently took with their workout product.

Jungle Junkie

The Jungle Junkie

Available plants

Welcome to Jungle Junkie, your destination for vibrant, exotic houseplants! Specialising in stunning tropicals, we bring nature’s beauty into your home. Our curated collection is perfect for beginners and collectors alike, with each plant chosen for its unique foliage and easy-care charm. I’m passionate about greenery and committed to helping you create your own indoor jungle.

Tropical

Aglaonema
Pictum Tricolor

£15.00

The Aglaonema pictum ‘Tricolor’, commonly known as the Chinese Evergreen ‘Tricolor,’ is a striking tropical houseplant prized for its vibrant, variegated foliage.

Add to basket

Tropical

Pilea Peperomioides
Mojito (Variegated)

(1 Review)

£6.00

The Pilea peperomioides ‘Mojito’, commonly known as the Variegated Chinese Money Plant or Pancake Plant, is a rare and visually striking cultivar of the Pilea peperomioides.

Add to basket

Tropical

Tradescantia
Zebrina

£5.00

Commonly known as the Zebra Plant, Inch Plant, or Wandering Jew, is a popular trailing houseplant valued for its vibrant, striped foliage and easy-care nature.

Add to basket

Tropical

Ceropegia Woodii – String of Hearts

£10.00

The String of Hearts (Ceropegia woodii), also known as Rosary Vine or Chain of Hearts, is a charming, trailing succulent houseplant prized for its delicate, heart-shaped leaves and cascading growth.

Add to basket

Showing 1 of 4 Results

« Older Entries