Overview

Create a consistent design system for BrightHR to ensure a focused brand experience, a solid UI framework, and to help rapidly deployable and scalable project work for BrightHR and its family of products.

History and problem

BrightHR grew from a small startup in 2014 and, over the better part of a decade, expanded into several feature teams working on a variety components and styles – many of which were developed independently as projects demanded. Styles and components were becoming inconsistent; for example, a timepicker component on BrightHR's core product was different to BrightSafe's version. Ad hoc creation of components was a common occurrence, so it was long past time to consolidate.

1. Lack of centralised and official resources
   The lack of a centralised reference point often meant that developers often created their own –  often opinionated – styles that served immediate needs, or single-use UI elements for a project with little to no oversight from other teams. Faced with a lack of a centrally agreed upon approach to styles and component usage, developers would implement their own personal solutions.

2. Team silo mentality
   Multiple teams (up to 10 feature teams) would sometimes work on similar issues at the same time, but poor levels of intra-team communication meant that a lot of time was wasted with the duplication of effort. Nobody was speaking to each other and was identified as a problem with company culture as a whole.

3. No accessibility champion
   Lacking an accessibility focus was a noteworthy oversight of earlier projects, particularly when considering that a HR system should be egalitarian and open to users of all abilities.

Analysis

A major task was to identify all of the style and UI elements that could be consolidated and, where multiple versions of a component existed, agree upon which version should be the de-facto standard. Looking at the various products was time consuming but worth it. Taking the time to analyse which components worked well in which user specific context was fascinating work.

Solutions

Merely publishing a guide and enforcing consistency wasn't the best approach to the problem. Communication was the key, and bringing everyone along for the journey was important. Ideally getting everyone's buy-in from the outset is the best way to ensure adherence.

The first task was to establish a central project for the creation of a style guide. To ensure tight feedback loops we established weekly dedicated meetings to bring everyone up-to-speed with project progress. Further to this a dedicated Slack channel (#designsys) was created for group discussions.

The key tool of the UX & Design team was Figma. This design tool would be the main repository for the design elements. Developers, however, would also need their own code-specific version from which they could work. To that end, we decided to port components (once approved in Figma) over to Storybook JS for quick deployment of consistent UI elements. Once official and consolidated, faster deployment of user interfaces can be done.

Results & Key takeaways

Twelve months after rolling out the design system, project deployment time was cut by roughly 14%. User errors also decreased markedly. The system works!

The project – while highly effective in its goals – was a high-effort and time-consuming undertaking. Each component and element required a high level of detail, compounding design and development investment. The key leanings from this exercise were:

1. Complexity and effort. Designing a component framework is initially somewhat time consuming. Seemingly endless debates can arise from small design elements. Designing an element in a certain way can have unintended knock-on effects which all have to be accounted for. A design library can be very detailed and expansive, which can occasionally be a time drain for to learn and implement by all concerned. There is a high learning curve.

2. Localisation can be tricky. As BrightHR continued to grow into new territory, some UI needs to be flexible enough to respect local vocabulary, practises and settings. A prime example are date pickers: DD/MM/YYYY (common), MM/DD/YYYY (US standard) and YYYY/MM/DD (Japanese standard).

3. Project timing and resource management. Establishing UI library would've ideally been better served during the start-up phase of the business, not after the company has matured. Establishing better habits earlier on would have been better overall. Additionally, diverting skilled workers from their otherwise busy schedules proved less effective.

4. Always evolving. Style guidelines are constantly evolving as style and technology allow. Documentation can be a struggle to maintain if not planned well.

5. Finding appropriate accessibility advocates with sufficient knowledge of the subject matter can be a challenge.

Improvements in the future

Using the lessons learned, the design system is set to be expanded upon in the future with the incorporation of a companion vocabulary and UI microcopy guideline, written in cooperation with the marketing department.