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’.
of frontend time was spent
on rebuilding components
standardised web accessibility compliance
spent on additional engineering resources
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:
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:
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:
In response, we generated How Might We statements to reframe existing problems into potential solutions:
How Might We...
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
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
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.
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:
After researching best-in-class Design Systems and consulting my design network, I identified design philosophies that would guide our new approach:
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.
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.
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.
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:
The case for using a third-party
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.
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.
To support responsive displays, I defined a mobile-responsive typographic scale with a system font stack to minimise loading times.
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.
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.
Based on Beamery's current app as well as predicted future needs, I defined commonly-used styling attributes as design tokens.
I defined modern, accessible components while authoring usage and content guidelines to guide designers and developers alike.
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.
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.
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.
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.
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:
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.
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.”
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.
We were met with resistance throughout the project, but we succeeded through empathy, perseverance, and centering the needs of users.
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.