The problem

Too much time spent sweating the small stuff

In May 2020, Beamery was a 180-person strong company with an Engineering, Product, and Design (EPD) team of over 90 people. However, we lacked a clear set of design and engineering standards to guide our work. This hampered our ability to deliver features in a timely manner, leading to high levels of stress and low morale. Meanwhile, our inconsistent visual language frustrated users and prevented them from reaching their goals.

‍Designers reinventing the wheel
‍Without a standardised design language, designers reimagined basic components every time we worked new on features. Instead of focusing on high-level problems, we squandered our time on pixels and custom CSS.
‍
Engineers going rogue
‍Engineers repeatedly rebuilt components from scratch, leading to slow development times. Without a shared component library, engineers ‘went rogue’ and delivered independent solutions without internal alignment.
‍
Users experience tarnished
‍With different teams implementing their own solutions, Beamery no longer felt like one cohesive product. We started losing prospective and current customers due to ‘poor and outdated UI’.

50%

of frontend time was spent
on rebuilding components

standardised web accessibility compliance

£700,000

spent on additional engineering resources

My goal

My goal was to create a new Design System consisting of reusable components, styles, and standards that our EPD team could use to build better products at speed. We hypothesised that the new Design System would:

Drive product quality.
Improve user experience.
Increase team efficiency, morale, and collaboration.
Be actively adopted across all development teams.

My role

Our entire Design team kicked off this project together with a weeklong workshop. To champion the rest of the project, I teamed up with a Frontend Engineering Lead..

Over two months (from May to July 2020), we succeeded in:

Researching industry best practices and leading technologies.
Defining and designing System foundations.
Building consensus within the EPD team.
Proposing an implementation plan.
Securing executive approval and investment in the System.

Kickoff

Design System Team Workshop

To understand the extent of the problem, the Design Team participated in a weeklong Design Sprint-inspired workshop. We gathered feedback on our existing product:

'The colours are dark and gloomy.'
'There's too much information and not enough white space.'
'It doesn't feel like the same product.'

In response, we generated How Might We statements to reframe existing problems into potential solutions:

How Might We...

Auditing existing layouts and patterns

Next, we audited existing patterns in the app and found several inconsistencies. This increased users' cognitive load while slowing down their workflow. To make Beamery more learnable and usable, we needed to build consistency and cohesion.

How many shades of grey?

I audited all of the color and typography values in our app (while a fellow designer audited components) and found 32 shades of grey and 26 varieties of body text. That added up to hours that engineers spent hard-coding values.

These audits helped stakeholders visualise how messy a product can become without set standards, while also identifying commonly-used values that could be incorporated into the new System.

The 'silo effect' harms cross-team collaboration

What caused led to these disjoint inconsistencies in our product? Our teams were prone to operating with a 'silo mentality,' where we would work on features independently and with limited visibility into other teams’ work. Even with regular review sessions, designers could not ensure that we were all aligned due to the sheer pace of development at Beamery. Unknowingly, we were repeating work and reinventing similar interactions over and over again, leading to a confusing user experience while magnifying UX and technical debt.

Source: 'Silo Mentality: The Bane of Most Teams,' Douglas Gerber

Uniting under shared principles

To frame our new direction, we crafted a set of guiding design principles. We went wide and thought about what makes Beamery great, as well as our own design philosophies, before convening and narrowing down on our new principles. These principles would unite all designers while serving as key criteria to measure our work against.

Design System Principles

The difficulty of sustaining momentum

After the workshop, our normal priorities took over and we started to lose momentum. It was suggested that we put the Design System on hold and pick it back up another time.
‍
After seeing the costs of our current approach, as well as the benefits of a new solution, I was committed to seeing the project succeed. To drive product quality and efficiency, we needed to prioritise fixing internal issues over releasing new features. To champion this project, I teamed up with a Frontend Engineering Lead.

Hypothesis-driven design

We hypothesised that a new Design System would drive product quality, user and employee experience, and increase team efficiency. To measure the success of a new System, we set conservative and reach goals along several parameters:

The process

Guiding design philosophies

After researching best-in-class Design Systems and consulting my design network, I identified design philosophies that would guide our new approach:

Constraint-based design

Designers at Beamery were spending too much time on low-level decisions, such as spacing values, text sizes, and colours. Constraining these decisions frees up designers’ time to focus on people and problems, rather than pixels.

Sub-atomic design

Feature teams tended to design custom components without building alignment with other teams. With sub-atomic design, all designers share a base set of core elements that can be arranged in virtually infinite ways to create a comprehensive, yet cohesive, Design System.

Design tokens

After auditing our app, I found that Beamery contained hundreds of variations for similar colours, fonts, and spacing values. Design tokens can store all of these values in a platform-agnostic manner.

Build from scratch or use a third-party solution?

A key decision was whether to build the System from scratch or harness a third-party library. We evaluated different options in terms of efficiency, performance, and scalability.

The case for building from scratch:

Complete control over component behaviour and styling.
Consistent API that is easier for developers to work with.
No dependency on other parties if components need fixing.
Showcasing our Design System would be a great employer branding and exercise.

The case for using a third-party  solution:

Robust libraries come with excellent documentation, as well as built-in accessibility, animations, logic, and validation rules.
It's easy to customise third-party components with our own styling.
Open-source libraries are maintained by active communities of contributors.

My FE Lead estimated that building basic components from scratch and supplying adequate documentation would take at least six months. Thus, we recommended launching the System with a robust third-party library like Chakra UI. This way, our designers and developers would start with the same 'foundation' while thorough documentation would ease adoption.

System foundations

Laying the foundations for a new Design System

To help executives visualise how a new Design System could improve our product, I designed a set of ‘foundations’ for our new System. In my design specifications, I included interaction states, usage examples, and content guidelines to maintain consistent standards across different development teams.

Typography that scales

To support responsive displays, I defined a mobile-responsive typographic scale with a system font stack to minimise loading times.

A fluid, responsive grid for every device

To optimize our app for responsive displays, I designed fluid and fixed grids while expressing breakpoints as design tokens that can be easily updated as industry standards evolve.

A modern, accessible palette...

I crafted a new colour palette based on our marketing rebrand, which users loved. I defined semantic functions and ensured that all contrast ratios complied with WCAG AA standards.

Styling with design tokens

Based on Beamery's current app as well as predicted future needs, I defined commonly-used styling attributes as design tokens.

Beautiful, modern, and accessible components

I defined modern, accessible components while authoring usage and content guidelines to guide designers and developers alike.

Patterns that can be built out-of-the-box

These are examples of patterns that can be built out-of-box with minimal custom code. I envisioned a future where designers and developers can build interfaces side-by-side, thereby increasing collaboration and reducing bottlenecks.

Building consensus

Enthusiastic but cautious stakeholders

While my research and designs were met with praise and excitement, executives were still apprehensive about the project. A new Design System would be costly to set up and it would take a long time to properly implement. As such, only a small (but vocal minority) of people at the company supported the project.

Stakeholder Map

We were at a complete standstill, and this was one of the most challenging parts of the project. I realised that we were focusing too much on decision-makers at the top, and not enough on the actual users of a future Design System: our Engineers, Designers, and Product Managers.

Amplifying employee experience

Our executives weren’t swayed by metrics, research, implementation plans, and designs, so I decided to appeal to their human element. Beamery was dealing with cultural challenges, and managers were eager to find ways to increase employee satisfaction and retention.

Internal interviews

Over 5 days, I conducted 12 internal user interviews with Engineers, Designers, and Product Managers to understand their workflows, expectations, and frustrations, while also offering transparency into the project and building early team consensus. From their responses, I generated 5 user personas:

User personas

Connecting the dots

My findings revealed several pain points that could be improved by a Design System. Designers and engineers wanted more guidelines surrounding component use, while our entire team faced mounting technical debt, excessive component-related bugs, and a time-intensive peer review process.

Crowdsourcing the way forward

To learn from our employees’ experience and expertise, I surveyed respondents on what factors would lead to the success and failure of a new Design System at Beamery. This served as the basis for the implementation proposal that we presented to executives:

“Having great documentation is just as important as the components”.

“Trying to quantify a Design System’s costs and benefits can be just as expensive as actually doing the work.”

"Expecting everyone to own the Design System results in no one owning it.”

The impact

Success after painstaking persistence

On my final day at Beamery, I presented my internal interview findings to our executives and Product leaders. They were moved and saw that a Design System could not only drive product quality and efficiency but also improve team culture and morale.
‍
After two months of painstaking persistence, our executives agreed to invest in a dedicated Core UX team that will build, support, and implement the new Design System as well as overhauling our frontend structure. The team is currently being recruited and will start operating in early 2021.

My learnings

We were met with resistance throughout the project, but we succeeded through empathy, perseverance, and centering the needs of users.
‍
Storytelling wins.
Humans are drawn to stories; they help us make sense of the world and share our experiences with others. Where metrics, forecasts, and research insights fail to persuade stakeholders, try storytelling and crafting a compelling narrative.

Treat engineers like users.
Engineers, designers, and product managers are full of valuable insights and relevant experiences. Taking the time to understand their needs yielded insights that changed the course of this project.

Deliberating is expensive.
To work in an agile manner, deliberating the costs and benefits of a project is just as costly as actually doing it. Experimenting, testing, validating, and iterating is more valuable than deliberating.

Scaling product growth with Beamery's first Design System