Building Hydrocarbon was a career highlight and I couldn’t have picked a better team for my first Design System role. However, I had reached everything that the product needed and was keen to look for a new challenge to further my skills.`

The position at Phoenix Group was not short of new challenges:

All web applications were required to be fully responsive

Work on a system that supported web and native platforms

Provide consistency and cohesion to the fragmented product team

Not only was my role to be the single designer on the design system team, but the only person on the team.

Having come from Hydrocarbon I was able to hit the ground running in getting the project off the ground. My initial tasks involved:

Completing a component inventory of dozens of applications and platforms

Consolidating the inventory and North Star vision into an initial UI

Sourcing and setting up a documentation solution

Building a Figma component library and supporting the wider teams' learning

Guiding non-technical managers by agreeing on a technical approach with our off-shore development partners

A key difference in this role is that the design team development team would not be in-house but our offshore technical partner, TCS.

The development team are not currently in place, it was therefore my responsibility to provide initial plans for the possible architecture and approach that the incoming developers could use as a starting point.

Only once I was in this role, did I take it for granted how key it was to have developers in place at the early stages of the project. Their experience in architecture, technology and building quick prototypes can greatly streamline the initial foundational discussions.

Most design systems start with a component audit but when it came to Phoneix Group’s three child brands. Within each brand there were multiple legacy sites with a long legacy of styles, these are only a sample of the variations.

I took the pragmatic approach to initially tackle one brand, Standard Life, across both the web and native platforms. The learnings for this could then be rolled out into the other brands down the line.

Standard Life was selected as the native application UI was undergoing a revamp. This would become our North Star and the UI would be filtered out across platforms.

For many, their initial concept of a design system is to think of a library of UI components. And I believe most designers tackling their first design system would fire up a design tool and start to generate a component library.

In my experience, I have found centralising documentation early to be an even greater asset to teams. Even without any visuals capturing agreed rules on patterns, approaches and standardisations in one place is the first step to alignment, even for self-reference.

Phoenix Group, unfortunately, did not have any hosting solution and therefore we went for a SAAS solution. After researching a number of options we opted for Supernova, a new but fast-growing system focused on design system documentation.

It has become a key tool within the product team, not only as a location for our UI library but also our UX writing and Figma standards.

Our documentation is publicly available at compound.thephoenixgroup.com.

The next step was to carry out the audit of the existing website components. With over 200 micro-sites, web apps and sites this was an unrealistic task.

We opted to take the previous UI Sketch library and fill in the gaps from the common design system initially as a list of components but styled using the North Star as a reference point.

To achieve this I created a file called a “UI Workbench”. Essentially this allowed me to draught the rough components from the component inventory into a file with their own dedicated styles.

A key part of this process was to building our our initial palettes and design token structure. To speed up the process of trying colours palettes we created style blocks, groups of colours that were accessible and complimentary to a particular surface colour.   Setting these colours up as token aliases under a parent theme i.e. light and dark. We were able to quickly mock up a component in the light theme and use the Swapper plugin to quickly swap it to another style. This approach allowed for rapid ideation during this phase of exploration.

Working with a small steering group from the wider designer team, we we able to test and tweak our palette and styles quickly across our component set rapidly. Disconnecting from our production styles made sure there was no disruption to projects in flight too.

This took a number of weeks, however, key decisions were captured in our guidelines as we went. This quickly build up to create our decision framework and gave us a point of reference when we were blocked on any patterns.

By documenting as we went when we presented our first draught to the team, not only had we created a component library but also the supporting documentation. Coupled with a thorough contribution process we were quickly in a state build out the final library.

This was my fourth Figma component library build out so the steps required was familiar territory for me.

The added twist this time was that we were supporting web and native platforms. The initial approach was to create a component that worked on both platforms. However, we ran into maintenance issues and opted for two separate approaches per platform.

Web - A separate file per component for more flexibility

Native - A single file for iOS/Android platforms

Each approach was specifically tailored to how the design team used the components within the platform.

Moving to a design system as well as retooling with Figma was a big change for the existing team. To help with the migration I ran a weekly session with the team titled “Compound Catch-up”.

Each week we had a set agenda that covered three topics

Having the regular structure allowed the team to get familiar with how components would be created and think about the impact wider than their topic. Overtime, the show and share grew from components I was building out to feedback and suggestions from the team.

Likewise, our Figma clinic was a chance to not only cover the basics but jump into how to effectively use the tool in live projects.

Sessions were recorded and stored for future reference points or onboarding new members.

With the design fundamentals in place the key next steps in the system is to build out the developed components.

Without an in-house technical department, my role in 2023 has providing technical direction on a  a longterm approaches to building out a component library.

On the design side, advocation on contribution and using the system within projects are part of my daily role. As the team has scaled and we bring in third-parties or new team members, once again it has been crucial to have a central documentation site.

Compound is the working title for Phoenix Group’s design system. A design system that aims to support multiple child brands and both web and native platforms.

Compound is the working title for Phoenix Group’s design system which has the long term goal of being the system for all of their digital real estate.

The background on building Phoenix Groups design system

Compound Design System

The creation of a multi-brand design system

Design systems can vary in scale and depth and Hydrocarbon has aimed to be comprehensive yet lean. We provide teams with:

A central documentation site that covers approach, governance, design language and patterns

Our feature teams, and the team members, are distributed across many time zones. Our timing was impeccable as we released the majority of our systems as the working from home orders were set out across the globe.

By having the items outlined below teams were able to deliver continuously, and in some cases more efficiently than before.

Hydrocarbon is both the name of our framework and an agile team dedicated to the design and development of the library.

Within the team, as the sole designer, my role was to act as a bridge between design and development. My role extended to advocation, documentation and building and curating our Figma component library.

I had a solid starting point from the existing Sketch based component library created by the team of talented designers at Wood Mackenzie. Our component process facilitates the designers in the team to contribute updates and new items in a structured process.

Our Figma library has been critical to enabling our design team to work with their product teams in a more harmonious way.

We opted to build out our Figma components to use a naming convention and structure as close to the React components as possible. This enabled a design language for designers and developers to converse using the same terminology. This simple issue had put up huge barriers in our previous Sketch-based system.

Aside from building the library a part of my duties are to educate and give the use of our Figma library. I have enabled the design team to work faster through:

Regular Figma clinics tackling and demoing problems from the team

Supporting documentation on our internal website

As an experienced designer, you would think the majority of time was in design tools, like Figma. However, equally as much time has been spent in text editors and Storybook documenting our components and processes.

"Less is more" has been the objective and we continually refine our documentation to provide teams with the right amount of information in an accessible way.

With components, Figma libraries and documentation in place the missing part was collaboration. Design systems exist to enable teams to do what they need to.

I took a step back from our current process and looked at where we had problems and bottlenecks. We refined this down to a leaner approach that we published on our docs.

This allowed anyone within a product team to contribute a proposal to the system.

Our process is centralised on discussing and stress-testing proposals before we move forward to development. By loading the discussions earlier we were able to reduce the need for fixes and updates at release.

We then move each component addition or update through three stages:

As stated above design systems are more than just components. I build a Gatsby site under the domain design.woodmac.com as a central location to contain everything related to our system.

This serves as a one-stop-shop for team members to find access points to the library, design patterns, research approaches our Figma guidelines and much more.

As stated above design systems are more than just components. I built a Gatsby site under the domain design.woodmac.com as a central location to contain everything related to our system.

Design systems are more than just UI components that build interfaces, they are a centralised approach to creating user experiences.

Working on Wood Mackenzie's in-house design system, Hydrocarbon, has taught me it takes a number of factors and disciplines to deliver a comprehensive system. The design system is central to the build of their cutting-edge Lens product

Our goal is to allow teams to iterate and build their projects fast and consistently. To achieve this, a solid set of UI components also require centralised documentation, adoption by the production team and the creation of a design language.

Hydrocarbon is the design system of Wood Mackenzie, this case study explains how we built it.

Hydrocarbon Design System

At the time of working on this project, I was also building out the Hydrocarbon design system. I took my experience building Figma libraries to create two child libraries; Native and Web, that took their foundational elements from a parent library.

This was my first multi-platform design system and taught me a lot about setting up and managing Figma. The benefit of this approach is consistent both for the developers and users but also easier to manage as the sole designer.

One mistake I made going into this project was to focus on setting up a hard and fast design system too early. What I really needed was what I'd call a design toolbox; a palette, basic components and spacing rules. 

Having a rigid system approach helped get some momentum it was too early in this project to enforce. If I was to do it again I would have used the toolbox approach. Although having a system allowed the development team to make decisions on their own, without the backup documentation and component library it became difficult to implement consistently.


This project was on a deadline to deliver a v1 responsive web app at the time the Wodify subscription was delivered. This meant it was all hands on deck by the development team to get the project live.

I assisted the junior developers in delivering the frontend work getting deep into creating custom code, fixing issues with Bootstrap implementation or mentoring them through code changes.

It was refreshing to go back to my roots and work on deliverable front end code.

As the launch date came and the team delivered successfully on time it was nail-biting to see what the user feedback would be. There is a vibrant Facebook group that is quick to call out anything.

Thankfully the app was well-received and users were quick to share thanks, feedback and screenshots.

A primary goal for this project was to deliver a native application for users driven by the data from the custom platform. The dev team opted to use Nativescript to allow them to use a single code base but deliver compiled iOS and Android apps.

This was my first time working with a Hybrid platform so I did the groundwork and researched the docs and ran through a number of YouTube tutorial videos to get to grips with the platform. It was valuable time spent as there were a number of best practices around page layouts and asset management that were important to be aware of before firing up Figma.

There were a number of points to juggle when designing for NativeScript:

Balancing good information hierarchy with minimal layout nesting. Nativescript has a number of layout types and nesting these too deeply causes a number of performance issues.

Our page designs for the app would also be mimicked on a responsive website. Therefore all designs had to be considered for iOS, Android and the web served on three different platforms.

Styles and assets were shared between the web and Nativescript platform and each had its own set of media requirements.

This was the first time the development team built on Nativescript so it was a learning curve for all involved. In the end, the development team and Street Parking users were thrilled with the first release. The iOS app is available in the app store now with the Android version on the way.

There is a lot still to deliver, including the native application. But it has been uplifting to deliver a product that not only I use but thousands of other users do too.

With the effects of Covid, health is so important and being able to put such a great product in the hands of users on a daily basis that enhances their well being, is something to be proud of.

I love working out, years of sitting at a screen have taken their toll on my posture and I learned to counteract this with functional fitness and strength training. Four years ago I joined the Street Parking programme and community. The community has an extremely vibrant community and I shared a redesign of a similar fitness app.

At the start of the UK lockdown, their owners reached out as they needed a UX/UI designer to join their engineering team that was creating an MVP of their platform.

This was a passion project to be involved in, I was given the opportunity to design and resolve a lot of the issues myself and other community members were facing.

The technical team was already in place alongside a deadline to start receiving new customers on to the platform. Street Parking already had an existing customer base of over 35,000 home fitness enthusiasts but with lockdown forcing gyms to close, their customer base was growing over 10% per month.

The member base had existed across a number of platforms and services; Wodify, Square Space and Instagram. The goal of the team was to build a bespoke enterprise platform that could be tailored to suit their programs, promotions and fitness challenges.

The development team quickly grew from two Angular developers to a team of eleven. With a PO now at the helm, the platform went from being a web product to also delivering a native application on Nativescript.

As the only designer on the team, my coverage included the UX/UI for :

Nativescript application for members that would be delivered on iOS and Android.

With over 500 Street Parking workouts under my belt, this meant I had to rely on my own experiences along with the feedback I'd captured in the Facebook group to get an idea to market.

Until launch, user testing had been limited because the new product was under wraps. Beta access was given to long term users who provided initial feedback and testing. Fortunately, the overall experience was an improvement and I was able to deliver a design that was well received.

It should be noted that my work wasn't only to create the visuals for all of the platforms but the actual user flows.

Working with the PO and System Architect, who were also long time Street Parking users, we merged and streamlined the previous three platforms into a single flow that could be delivered to both the web and native applications.

The back and forth on this part of the project could fill a case study in itself.

Working with a remote development team to provide design for a bespoke fitness platform.

Street Parkin

Designing a bespoke, global fitness platform & apps.

The first stage of the process was to gather customer and business insights.

Customer Insights were gathered through reviewing comments left in our customer feedback tool, conducting a members survey and looking at the feedback that our support team received.

For business insights, we asked our racing trading team to send us their frustrations.

Getting stakeholders and Hippo's in a room for a few hours is not an easy task. For this project, we gathered stakeholders into a session.

Using techniques from Pete and I's Lumina Institue training we conducted the workshop in a few hours.

What's on Your Radar - We blocked out the key business goals for this project.

Affinity Clustering - Using the gathered insights above we broke the group into teams and asked them to group the insights into clusters, and put these clusters in the importance of primary, secondary and tertiary importance.

Buy A Feature - We asked the two HIPPO's in the workshop to use gold and silver stickers to call out what their priorities were.

Complexity Matrix - Finally we took the output of the above steps and created a matrix that set out the product owner's roadmap of work for the project.

The first page that we had to tackle was the meetings page. We set out to improve two KPI's:

Net Promoter Score through an improved navigation

Increase in turnover via regions outside UK and USA

Starting with web analytics we identified the top user goals of the page and again gathered insights into gaps in the page functionality.

The product team wanted to make sure the new page could support the ability to continually provide the appropriate racing over the 23 hour period in a number of countries. This led us to consider a rolling electronic program guide (EPG) of data.

We put a number of wireframes, for both mobile and desktop, through remote user testing using What Users Do (now part of User Zoom).

The wireframes performed well, as stripped back visuals with only links highlighted in colour. It only took two rounds of testing to get the results that we were looking for.

The next step was to move the wireframes through to UI.

Moving the designs onwards, I worked with the UI designers to integrate our pattern library and create a more polished UI. We took this high-resolution design back through to further tests in What Users Do.

The high-resolution mockups didn't test as well at all.

Users struggled with large amounts of content, conflicting colour combinations and clashing logic in the pattern library.

The biggest sticking point was the display of race times in the carousel in a scannable, efficient layout.

In the end, it took three rounds of tests to get a design to the point that we were confident would meet all the user needs.

We worked with our intelligence team to identify the personas of our users and it was clear that our older customers should be the focus of our work, being worth four times as much as the younger profile.

This led us to consider our older demographic our main users, and look at ways to educate the younger audience into using the provided information and media to improve their experience.

A key feature of our racing page is the ability for the user to select races from multiple meetings and countries and build their own racecard.

The feature on our previous pages was poorly implemented and this was a chance to improve it.

User testing told us that users wanted a clear CTA to trigger the function and that the counter of selections to be clearer.

I worked with the UI designer to tidy this up and prepared a Framer JS prototype to demonstrate to the development team. View the Framer Prototype

This project was in development when I left the company and no longer have access to the statistics. However, the page was delivered as designed * and William Hill continues to be a leader in horse racing betting.

You can read more about work on this project in Part 2.

* this link may not open outside the uk.

William Hill is a household name - not just in the UK, but across the betting world. They've transitioned to the world of online gambling very successfully, with horse-racing accounting for around £1.4billion of turnover in 2017 alone (and it's very much part of their history).

But in today's highly competitive - and lucrative - world of online betting, William Hill can take for nothing for granted. So when their then Director of Sportsbook (i.e. Head of Betting) challenged the online product team to deliver the 'best horse racing experience on the market', he meant it.

It called for smart user-centred design. It called for a presence to combat the promiscuity of punters with an average of two or three accounts across different bookmakers.

And it called for a willingness to knuckle down to get the job and that's what I did…

First phase of redesigning William Hill's horse racing product.

Willliam Hill Horse Racing - Part 1

Part 1 - Redesign of the horse racing section, starting with the meetings page.

This project actually started with a mobile prototype because we had a slot in our user testing lab coming up. In a change to our normal design process, we started with building our best guess. Because of the complexity of the prototype, I built out a functional race card in HTML/CSS using the Foundation for Sites framework.

The Product Owner had a strong view on how things should work, a clone of Racing Post, so I built out the Prototype and tried out the more traditional view in an alternative prototype.

I organised and moderated the two-day session in our London office with candidates that met our criteria. Acting as the moderator I was able to see first hand how they interacted with the product.

Results: Prototype 2 was the unanimous outcome as users found it more familiar. The product owner took this on board for the next stages along with the other feedback.

Getting early feedback from users on initial concepts made starting the design process a lot easier. Putting out two different ideas gave us a wide range of open feedback to work from. With such a clear winner and solid justification in the initial test, I had a solid backbone to start iterating through further concepts.

Users preferred a layout that was familiar with what they were used to, particularly if they had accounts with other bookmakers

Their research on what horses they would select was made offsite. All quoted using Racing Post, but further data on the cards helped them support their choices.

The user found value on the depth of information we presented but hoped the end product would be less cluttered and more balanced.

After thorough user testing and initial sketching, I went straight into Axure to start building the wireframes. The key issue was to include a comprehensive amount of live data into a small space

I remember reading this great story on how they built Twitter Video to get playing with the product in their hands was key to getting a great product.

Using Axshare I could quickly try interactions on my device and send it out to remote usability testings for feedback or to stakeholders for review.

Below are some of the screens, iterations and ideas for the main and sub cards that we trialled.

The focus was mobile first, as 80% of our business is now on mobile. When we scaled the designs up to desktop it failed, badly. Some reasons for this were:

There was more content in the surrounding frames that confused the users.

The media player on the right-hand column conflicted with the media content we were highlighted in the main area.

Controls, such as "show more" were in the wrong location when scaled up to a larger real estate. Desktop users are still high value in our racing product so I persevered and created four further rounds of iterations and testing to reach a design that was more usable for our users.

After rigorous testing, the final output delivered key improvements whilst retaining a structure that was familiar to customers.

Tabs were used to separate the race information and streaming. This UI pattern allowed for more race level features to be added in future.

The branding and instruction were given clarity and space to stand out.

The promotional content was clearly grouped and scaled if fewer offers were shown.

The structure of each selection was retained from the old card but information was rearranged, based on the research, to make better use of the available space.

This was such a critical page for the business, taking on average £3 million a day, and that the experience had to balance usage between novice and expert customers.

This project involved my first time moderating an in-person user research session. It was massively beneficial to be in front of users at an early stage but to be consistent, impartial and ask explorative questions is a tricky skill to master.

Getting a few ideas out in front of customers BEFORE starting the design process was a different way to iterating on a concept. We took a couple of ideas and came out with a mash-up of a baseline to begin from.

Mobile & Desktop Are Different Experiences

Scaling up a mobile design to desktop doesn't work. More content on the page reduces readability and users behave in a different manner.

This project was still in the development phase when I left the company. However, the rigorous testing with a wide spectrum of users gives me confidence that this will gain William Hill more wallet share from the avid horse racing customer and meet the goals of our initial workshop.

The project is now live and the majority of the work from from both of my case studies has been implimented. You can test it out for yourself and see what you think if you fancy a flutter.

The horse racing racecard. For anyone who's not a fan of racing, it's hard to underestimate its importance to the betting experience, whether offline at a meet or, here, online. It brings the runners and riders to life for punters - and it's worth over £1 billion in turnover for William Hill racing.

Every horse racing site features a racecard though. So our challenge was to make the William Hill racecard a key differentiator - a one-stop-shop for users to explore and validate their choices, make it easy to place bets while being able to use independent data for relevance (unlike other sites).

Be the first racing product to provide independent data from two sources; Racing Post and Timeform. This should increase bets placed per active based on previous data and analysis.

Fix a number of legacy issues on alternate markets; forecast/tricast, match bets etc. This will increase turnover on these markets.

We have seen that streamed events on all sports increases turnover, therefore, the signposting and labelling for streaming events should be clearly labelled.

Integrate multiple promotions and concessions for the user to opt-in to or be made aware.

The second part of the case study outlining the redesign of William Hill's horse racing section.

Horse Racing Part 2

Part 2 - Redesign of the racecards across breakpoints.

The time difference wasn't the biggest hump in this project. Although I usually had weekly calls or Instant Messages in the evening through to the early hours, the platform limitations and deadline were the biggest hurdles.

All Nevada gambling apps not only have to go through the Apple or play stores but also the Nevada Gaming Commission; all before the September NFL seasons, which make-up the bulk of the USA business.

The original developers were contractors who had taken months just to change colours. Thankfully the new developers were excellent, and we used the new tools and platform guidelines to work efficiently. We managed to get the MVP of our iOS app in around six weeks and Android app in a couple of months.

Slack, Sketch, Zeplin, and Invision were only just gaining traction at the time of the project, but they were the staple tools to work remotely quickly.

From the outset, the developer and I agreed to stick to the platform guidelines. That way, if they needed to build a feature and I wasn't around they could continue using the guidelines until I became available. Sketch and Slack were key to our cross Atlantic communications as I was able to knock-up variations, on the fly, during conversations and simply drop them in, all thanks to a great plugin.

InVisionApp was also key, at the time it was one of a few tools to illustrate a flow or prototype quickly, and it's live share app was indispensable for video calls.

Americans love the Scottish accent but the communication barriers didn't lie with my mother tongue. Instead, they were with the terminology differences between the USA and European gambling. Whereas in the UK you place a bet, Stateside it is a wager, one of many differences I had to learn along the way. I even had to swot up on handicappers and their terminology, just to make sure I tailored the user experience for their customer group.

With the jargon sorted, the next challenge was educating myself that native design was about views and not pages and, that there was a difference in each platform experience. Particularly challenging was the learning curve of Material design, which was only just released at the time.

Both apps included key functionality allowing customers to deposit from their device. The 2016 annual report indicated the apps helped to increase overall growth by 37% and new revenue by 5%.

Despite the challenges, this remains my favourite project at William Hill. I learned massively how much soft skills in written communication matter. I only had one visual call with our developer and struck up a great friendship with our team BA that I never saw or spoke to. On the product delivery side, we managed to deliver two great apps in a short time frame, and yet with no physical interaction.

Aside from the planned tasks I also brought in features such as detailed bet receipts, that hadn't originally been scoped, and provided concepts for pitching our B2B product to the major casinos.

After years of designing and building front-ends for the web, this was my first encounter with native apps.

Aside from popping my native design cherry, this project had the additional challenges of different time zones and betting terminology.

The task was to support the small product design team, in Nevada to build the iOS and Android Sportsbook apps. As Las Vegas is the only US state to allow legal gambling, the William Hill operation is more like a start-up. This was a great opportunity to work with a small, focused team on a new product. The team consisted of myself for UX and UI, one native developer, a systems architect, a business analyst and the product owner.

Aside from my design background, I was able to bring my experience from the European Sportsbooks to the table. And thanks to my Dad's love of the New England Patriots I also had the basics of what "football" meant on both sides of the Atlantic.

Native UX & UI design, working remotely with our Las Vegas team.

Native Sportsbook

Cards of Death is a simple Crossfit workout and my wife's favourite.

The idea behind this is for you to pick a card from a deck and do the exercises and pick another. When you pick a joker, you either double or half your next card. A lot of fun if you are a sadist.

Firing up Codepen I was able to knock out the first version ready for our Sunday morning workout in about an hour.

The idea was simple, load a JSON file of objects and randomise the output. This worked, and we blasted through a tough HIIT workout the next morning. View Game on Codepen or the sample below.

A personal project to improve my home workouts and JS skills based on a Crossfit workout.

Cards of Death

A personal project to improve my home workouts and JS skills.

Projects

Overview

Compound

Overview

Hydrocarbon

Overview

Street Parking

Overview

Horse Racing Part 1

Overview

Horse Racing Part 2

Overview

Native Sportsbook

Overview

Cards of Death

Overview

Virtual World

Overview

The Big Game

Overview

Ashes Top 4

Overview

Tipster App

Overview

Head to Head

Overview

MyPlay Enhancements