Building a System of Design for Your Product

In this post, I’ll discuss how you can go about building a system of design for your product so that anyone in the company, even those without design backgrounds, can design new features within minutes. Although design encompasses many things, for the discussion of this post, I’ve assumed design to only cover the UI/UX aspect of a product.

I’ve helped build such a system of design at WebEngage. Our system of design covers only the product dashboard (i.e everything the user sees once he or she logs in on www.webengage.com). It doesn’t cover the marketing website itself (i.e www.webengage.com). The marketing website is our static home page that tells you about us, what our product does etc. The marketing website is currently under revamp so I’ll keep that out of the ambit of this post.

What is a System of Design?

Why All Products Need a System of Design

Designers should design products and not individual pages or screens. And for this to happen, design needs to have as equal a seat at the table as the product and engineering folks. Design should get involved with feature and product creation from inception rather than get relegated to adding gloss once the feature or product specifications have already been finalized. It baffles me to no end to hear of companies where the design team’s role is reduced to putting the final touches to a mock or a wireframe created by the product manager. How do you create a great product unless design and product work in tandem?

Before we proceed, let’s take a quick look at the systems of design of two of the more popular SaaS companies — Mailchimp and Atlassian. While you can go through those links to understand their systems of design in detail, a quick view of Mailchimp’s system of design below shows us how well defined their HTML form elements are, for example.

Mailchimp’s Component Library

Any developer at Mailchimp who has to implement a form anywhere on their website or dashboard will follow the specifications under Form Elements. No more ad-hoc design of any form. Also, any change that is made on a certain page or screen will require a change in the component itself. This ensures that the change manifests seamlessly across all pages or screens that use that component.

How we Built a System of Design at WebEngage

However, I realized that the velocity at which WebEngage had built the product came with its own downside. Since the product had mostly been engineering driven till that point in time, design was lower down in the priority list. The product experience was sometimes inconsistent and some features lacked the necessary depth. When you are prioritizing ruthlessly in order to build a product at such a rapid pace, something’s got to give.

A couple of months on, my objective for the product at WebEngage was straightforward:

  1. Complete the existing feature functionality
  2. Build new features, and
  3. Build a beautiful user experience

Thus, also began the efforts at WebEngage towards building a system of design.

We started our user research, competitor analysis and exploring our own ideas to figure out the exact functionality to build for the existing features and for the new features. We also invested a lot of time in building wireframes to create a great UX. By early 2017, we knew exactly what we wanted to do — we had detailed specifications and wireframes for each of our features. Through this wireframing exercise, we realized that we were using a similar set of components repeatedly across all our features. We had started putting the basics in place towards building a system of design.

We decided to engage the good folks at Uncommon to help us improve our UX, create the visual designs and ultimately put together a system of design for us. Tejas at Uncommon (who now runs his own consultancy called 3SidedCoin) and I worked together on this for over 2 months to put everything in place. Tejas has also published a detailed post on how we revamped the dashboard design at WebEngage and also built a system of design in the process, which you can read here.

Anyway, here’s my take on how we went about it.

The first thing we decided to do was to finalize the design of 4 of our most complex pages/features without even thinking about any system of design. Our objective at this stage was to visualize what our end product would look like through these 4 pages.These complex pages were completely different from each other — one was heavy on the usage of forms, another was heavy on reporting and so on. We wanted the product to have a great design — a beautiful UI along with a seamless UX. Yes, it was as simple as that. We wanted to move from wireframes such as this:

to an actual mock of the page such as this:

Once the design of these 4 pages was finalized, we started putting together a list of components we had used on those pages. The other approach would be to build the components first before any pages were designed — which doesn’t seem practical as you would have no idea how a real page would look like unless you put the components together on a page.

The initial library of components included a mix of individual elements such as these:

Simple Components

and more complex components that use a mix of primary elements such as these:

Complex Component

As and when we built other pages, we made a concerted effort to use only the components from our initial component library. We would introduce a new component if and only if the existing components would not suffice. And as soon as we introduced a new component on a page, we ensured that this new component was included in the component library.

Over the course of 2 months, we designed more than 20 pages. However, by page 12, we realized that we were not adding any new components to the library anymore. The library we had created by the end of the design of page 12, was almost the same as the library we had once all 20+ pages were designed. It has been almost 9 months since we created this component library and we haven’t added new components to it, since then.

The system of design we created 9 months ago still works beautifully by helping us design new features very quickly. This system of design has drastically increased the velocity at which we move from feature inception to roll-out. It has made the UI and UX consistent and predictable. And most importantly, design is no longer restricted to an operational role, and has a more strategic role to play in the organization.

Sample of Design Component Library at WebEngage

Closing Thoughts

Systems of design should ideally cover all the customer touch-points. It should cover the dashboard, the marketing website, marketing collaterals etc. This is the next stage of evolution for us where we will further expand on our system of design as we go through the process of revamping our marketing website. I hope to circle back sometime in April once our shiny new marketing website is up and running.

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Principal Product Manager @ ThoughtSpot