Introducing Buildit’s Gravity design system

James Nash
Jun 15, 2018 · 12 min read
Image for post
Image for post
(Original image credit: NASA / JPL-Caltech)

The motivation

Buildit has had a website and a small number of internal web applications for some time. All of them had been designed and built independently and consequently looked and behaved quite differently from each other. There was, therefore, a clear case for unifying their UI code to create consistency and reduce the amount of redundant code that needed to be maintained.

  • Test new techniques and ideas on our own time, without putting client work at risk
  • Create an environment for new and junior colleagues to learn about and explore design systems

The beginnings

Work on our design system began in earnest in May 2017. There were a number of us who were in between client engagements and therefore had some spare time to work on this internal project.

Tech stack research

Buildit already had three projects that could potentially benefit from a design system: The Buildit website and two internal web apps.

Image for post
Image for post
Some of the questions from our questionnaire
  • One of the apps was written in React.js and had its styling code written in SASS.
  • The other app was written in Angular. It’s styling was also written in SASS but built on Bootstrap.
  • We’d initially only provide CSS (with SASS source code) as this could be used by all projects, regardless of their choice of JS framework or build tools.
  • We’d be opinionated about the HTML elements and attributes that should be used for components because we wanted to encourage good semantics and accessibility. We’d therefore use CSS element and attribute selectors as much as possible.
  • We’d use BEMIT conventions to organise our SASS code and name our class names.

Choosing a name

“Buildit design system” is a bit of a mouthful. Not to mention dull. We decided early on that we wanted to give our design system a name. To get inspiration we enlisted the help of all of Buildit by creating an online suggestion form with two questions:

  • Why should it be called that?
Image for post
Image for post
  • “Pangu”, the creator of all things in Chinese mythology
  • “Designy McDesignFace”
  • “Designsystemit”

Design principles

Successful design systems have a set of design principles to guide their work and decision making. Naturally, we wanted a set of our own.

Image for post
Image for post
Excerpt from our big design system principles comparison table
  • UI simplicity
  • UI usability
  • UI consistency
  • UI aesthetics
  • Don’t Repeat Yourself
  • Be universal
  • Be robust
  • Embrace each medium
  • Keep it tidy

UI inventory

We then conducted UI inventories of our website and apps. Unsurprisingly, each app had a very different look and feel from the others.

Image for post
Image for post
The team reviewing and collating components from the various UI inventories

The void

With our research done, we were raring to go. We set up a git repository for our UI library, set up a PatternLab build to generate a live pattern library and then… we stalled.

Image for post
Image for post
Nothing but tumbleweed (Photo credit: Jez Arnold)

The resurrection

In early December 2017, an internal project was kicked off to refresh the Buildit website. Based on our experience with Gravity and also some other internal projects that people had done “on the side”, we insisted that this had to be run properly, just as though it was a client project. That meant that the team would be assigned to work on the website for a certain amount of time and could not be snatched away for other things.

Image for post
Image for post
The relationship between the code for Gravity’s pattern library, UI library and Buildit’s website
  • Allows us to make more informed design decisions, since we inspect and evolve our UI within an actual browser and therefore can test not just visual appearance, but also accessibility, performance, progressive enhancement, interactive behaviours and more
  • Encourages consistency. Working within our pattern library (where we had used Atomic Design to organise our components) made it easy to find and re-use existing components rather than adding redundant variations.
  • Makes our design more systematic. Applying far-reaching changes, such as altering our colour palette or playing with the typographic scale, was trivially easy to accomplish — often as simple as changing the value of a SASS variable. Likewise, being able to zoom in on an individual component to make a very localised change and then zoom out to see the wider impact of that change on the overall look and feel helped us assess and maintain consistency and coherence in our designs as we went along.

The present

Gravity now has enough substance that we’re finally comfortable to tell the world about it. However, we still consider Gravity to be a nascent design system.

Image for post
Image for post
Viewing the page header component within Gravity’s pattern library

Developing a roadmap

There’s a lot of documentation still to write. There are bugs to fix, things to enhance and, as we support projects beyond our website, there will be more components to add. Furthermore, in Brad Frost’s analogy, what we have so far is mostly a “workshop”, but we’re still lacking a nice style guide website to act as Gravity’s “storefront”.

Refining our principles

While designing and building our UI components, we found that our initial set of design principles weren’t always helpful. We had hoped they would guide us when faced with tough decisions. For example, consider having to make a trade-off between better aesthetics or reduced code complexity for a UI component. Ideally, you want both. If that’s not feasible though, you need to prioritise one over the other — a good set of principles should inform that sort of decision in a consistent way.

  • Others overlapped a bit. “Don’t Repeat Yourself” and “Keep it tidy” for instance.
Image for post
Image for post
  • Guidelines should support or embody the principles.
  • While goals are fairly broad and abstract, guidelines are quite specific and concrete. Principles are somewhere in the middle.
Image for post
Image for post
Members of the Gravity team discussing the revised principles
  • Living case study — Continuously showcase Buildit’s design system expertise to clients and the wider Wipro organisation
  • Low maintenance — We are not a product company. Therefore, funding for an in-house design system will always be a tough sell, so let’s make our lives as easy as we can
  • Consistent Buildit look and feel — A basic raison d’être of any design system
  • Lean — Less is often more. Whether it’s reducing waste while working on projects, writing terse code, designing focussed UIs or just avoiding fluffy language when communicating, leanness is something we value at Buildit. Gravity should embody and support that as much as possible.
  • Robust — There is a lot we cannot control when it comes to digital products. We can’t decide what device, operating system, browser or settings people use when interacting with our products. Neither can we predict what the future might hold. And yet, the products we build need to embrace that uncertainty and handle all the diverse use-cases gracefully and reliably. Robustness is therefore an important principle for us to consider in everything we do for Gravity.
  • Considered — Everything about Gravity — be it design, tech or process — should exist for a reason. We should always be able to explain why something is the way it is. Wherever possible we should use data and research to drive our decisions. Failing that we should tap the experience and know-how of relevant experts. Finally, if something does boil down to a subjective decision, then we should note that and be prepared to revise it later if new information allows us to make a more informed decision.
  • Progressive — Gravity is an opportunity for us to constantly try new things. New design directions. New technologies. New approaches towards designing and building user interfaces. We should take full advantage of this and strive to be a leader rather than a follower on all fronts.

Securing funding

Perhaps most importantly, with Buildit’s refreshed website now live, we need to find new ways to fund continued work on Gravity.

buildit

we enable + accelerate engineering transformation

James Nash

Written by

Design system aficionado. Classically trained webmaster. Slayer of pixels. | https://cirrus.twiddles.com/

buildit

buildit

We are a global engineering & co-innovation consultancy specializing in solving highly complex business problems. We leverage engineering best practices, tools, methodologies and new ways of working to deliver true business outcomes.

James Nash

Written by

Design system aficionado. Classically trained webmaster. Slayer of pixels. | https://cirrus.twiddles.com/

buildit

buildit

We are a global engineering & co-innovation consultancy specializing in solving highly complex business problems. We leverage engineering best practices, tools, methodologies and new ways of working to deliver true business outcomes.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store