“50 shades of blue” or how I approach a design system.

problem.

the UI wasn’t always consistent at all. On one hand, multiple designers were working on different parts of the site. Each one of them wanted to innovate and no one was following any common patterns. On the other hand, existing issues with handing over designs to engineers created even more inconsistencies as they were lacking a clear reference and each time were building from scratch. Rarely reusing what other teams have done.

There were instances when we would use different fonts, colors, not to mention completely dissimilar components. The situation has gotten so out of hand so quickly that we would joke about the product’s new codename – “50 shades of blue”. It became apparent we need definitive & clear guidelines.

my role.

My role & responsibilities grew with time. To begin with, I was given the difficult task of auditing the platform and applications and map irregularities as well as follow up on projects currently in design and work with my colleagues on ensuring an identical look & feel throughout the product. And over time this turned into me building consistency by devising a Design System, maintaining it, and coming up with strategies and processes of updating it.

To do this I had to work closely with the design team, onboard and educate newcomers on the usage of the design system and how to maintain it. Collaborate closely with engineering & architecture to build live components which we can reuse during development. But also earn buy-in from the business.

process.

I began by pulling everything we were using into one place and tackling three key areas:

• Reducing the number of colors to create a clearer, more consistent brand presence (there was a brand book, but it wasn’t being used—or even discoverable to the Product Design team).
• Auditing and consolidating components to replace multiple similar-looking solutions with a single source of truth.
• Building what started as a UI kit for designers and scaling it into an organization-wide reference point.

challenges.

Getting everyone on board with using a style guide was not an easy task.

Some designers saw a design system as “too many rules” that would limit creativity. UI engineers sat within the team, but collaboration was minimal—everyone worked in silos.

So I started by auditing the product (often via browser inspector) and pulling designers and engineers into quick working sessions to untangle what we actually had.

The hardest part was convincing the business to invest in dedicated designers, UI, and back-end support to build a live pattern library of reusable components—scalable across 7–8 product verticals (Sportsbook, Casino, Bingo, etc.). Most stakeholders didn’t care about button colors as long as revenue was strong.

beginning.

Still in Photoshop land, after my initial review, things were starting to look a bit like that. Loads of colors with no apparent reason as to why they are different. And the issues were not only with color but inconsistent and uneven spacing. My role was to work on the new structure and pass it on in the form of a guide we should use.

design system.

We had switched from Photoshop to Sketch. There were plenty of tools we could now work with such as Craft, inVision, Sympli.

We found inspiration in Foundation, Bootstrap, Material guidelines, Atomic design, etc in regards to the structure of the guide, the information we needed to include, even down to naming conventions we should use, etc.

I conducted a series of workshops, along with the engineers and my manager, to get the ball rolling, set up processes, and figure out the mechanics of it all. But most importantly keep the conversation fresh and get everyone on the same page. We started by implementing it to the most complex product – Sportsbook with the idea to roll it out to other verticals.

rebrand.

We were moving along well. We had a plan. All of a sudden the company decided to do a rebrand. We were working with a UK based agency to come up with the new look and feel of the brand and, more relevant to me, how it will be applied to the Sportsbook product.

The good news was, by having a semi-working pattern library in Sketch, helped us immensely to adopt the new brand.

progress.

With a long and bumpy road behind us & a rebrand, there was eventually a team of front and back end engineers dedicated solely to developing the pattern library. Designers were (more or less ) on board and using the guide.

process.

It was not all rainbows and butterflies yet. We were a long way to go to developing a fully-functioning, well-oiled design system. The main issue now was updating and sustaining it. After a few trial and errors we came up with the following process:

• Agreement on new components on a Product design level
• Getting components signed off by UI, business, and product with dev being made aware of the changes as well
• Specking the new components by the UI design team
• Creating a new version of the UI kit with a log of all the changes
• Get estimates on delivery from Engineering
• Product designer – UI Engineer handover
• Design working with Engineering, Project Managers, and Scrum Masters to ensure development.

• Aligning UI and Product roadmaps
• Following pattern library basics and consistency
• Defining the components – naming conventions, global components, and/or sportsbook specific, etc.
• Signing off designs
• Specking
• UI kit and log creation
• Allocating into sprints

adaptive vs responsive.

A few years before I joined it had all started as a responsive site and as things started to come together, we decided we need to move on to an adaptive approach. Seeing more and more touch devices, convertible and 2-in-1 laptops, phablets, etc. it was tough to maintain consistency across different platforms and operating systems.

Working on a responsive website is always challenging. Switching from responsive to adaptive on an already developed and quite a content-heavy site is definitely not an easy task.

problem.

The desktop site was a stretched-out version of the mobile

We were serving mobile content onto desktop screens and it did not look pretty. Moreover, desktop users were struggling to find the markets they were looking to bet on due to the content being too stretched out and not at all optimized for their screens.

It was crystal clear the website had to adapt in order to serve better-organized content.

Looking at the data, we found out users did not seem to scroll much on the page and going any further than the “fold”. So it was an absolute must to look into content density and try to fit more information above the fold. After all, if users could easily get to the markets they wanted to bet on, it meant they would place more bets on our platform.

in product.

I also had to consider not only what we currently had on the site, but everything that was soon to be included. I had to learn a lot about betting on different sports and even the rules of the game so I’d know how to prioritize and group the information. Last but not least, consider the way users will scan for bets they want to place.

We managed to improve content density by having at least 3 more market templates above the fold which we had set as a goal and optimize the views across devices.