We’re working on updating our stylesheets this week. Excuse any interm glitches you might notice!

A starter kit for your design system
Starter kit examples

Try our open-source Starter Kits for mobile and web.

We asked what we thought was a simple question about a year and a half ago. That question led us to rethink our approach to Designs Systems for every product we build. It also inspired us to create a Starter Kit to serve as a framework for creating Design Systems and improve team collaboration and hand-off to engineering.

The question that started it all?

How do we, as a design team, work better with engineers?

Enter phase 1.

Phase 1: How do we capture the things engineers want to know?

Anecdotal evidence suggested that our design and engineering teams weren’t on the best terms when it came to building products.

The greatest indicators of this were:

  1. Designers getting frustrated because builds didn’t look the way they wanted them to and
  2. An abundance of uncomfortable meetings between design and engineering to answer questions (Why does this shadow look like this?!), seek clarification (Why wouldn’t we just use native functionality?!), and tweak designs (If you want to fix this, it’s going to drop our velocity next sprint, how important is this?).

Things got tense and teams were pretty misaligned. Basically, if designers were the Capulets, engineers were the Montagues. If designers were Coke, engineers were Pepsi. If designers were Jims, engineers were Dwights.

But we digress…

We were on a mission to make things better, so both parties met on a regular basis to figure out what our pain points were and how to move forward in a productive way.

What we learned was that we, as designers, didn’t always do the best job documenting things that the Montagues, er, engineers needed to know. Some of this was due to a lack of understanding on our end, and some of it was due to a limitation of our design tools (more on this later). We began to realize there was a pattern of pain points for engineers, with some of the greatest culprits being around colours and shadows.

So we took that learning, wrote it down, and created “rules” around it with the understanding that this was something we had to follow consistently to work better with our engineer frenemies.

Screenshot from the Starter Kit outlining how to make, name and organize colours within a design system

Phase 2: How do we capture the differences between platforms?

During our conversations with engineers, we were also reminded that there are some subtle but important distinctions between iOS, Android and Web that we need to keep top of mind. For example: the need for hover and pressed states that come with using a cursor on the web. So we added them as part of our framework (which was slowly evolving into the official Starter Kit we now love).

Screenshot from starter kit showing various button states required for web.

In speaking with iOS and Android engineers, we also learned that Sketch, our primary design tool, renders shadow and typography data points very differently than what is required by mobile devices. Because this is something we couldn’t solve given our current tooling, the mobile team ended up making Specly, a tool that allows designers to create shadows and typography within the native device itself and hand-off the data points that are used by the device to the engineering team.

Sidebar: Integrating good design thinking through Designer Notes

The process of creating a Starter Kit required us to debate design best-practices. The incredible outcome of this was that it aligned our design thinking and allowed us to solidify our philosophies and values as a design team within our organization.

In order to keep the momentum going, we captured these best-practices as “Designer Notes” within the kits. These notes turned out to be a great resource for new members of our team who were also new to product design and we highly recommend a similar process for your teams (albeit your best-practices may differ from ours depending on the nature of your work and the way you work with your teams).

Houston, we have a revelation

Things were looking good and we were making strides in closing the gap between design and engineering. We went from being on opposing sides to working as a dynamic duo. We were basically like Sonny and Cher. Or Calvin and Hobbs. Fraser and Niles. Maybe even Peanut Butter and Jelly.

Alas, we digress.

Somewhere along our mission we came to the realization that our work impacted teams outside of design and engineering. The more traction and recognition we gained for our work internally, the more we recognized we valued the input of other teams involved in the product development process.

For example, solutions architects had information about how backends were set up and what information would be surfaced on the front end – knowledge that impacted both design and engineering. Product managers wanted to understand how we could improve efficiency in the build phase by spending more time in the design phase to set out rules for engineering. As a result they were better prepared to communicate the benefits of our Starter Kits to our clients.

For the most part, these takeaways aren’t exhaustively listed in the Starter Kits because they are very nuanced and dependent on the organization and workflow of your team.

The exception to this is content.

We had major takeaways for content.

Phase 3: What pain points does the content team face?

At Intersect we work hard to keep UX writing top of mind during product development. We try to run content sprints in parallel with design and discovery and make an effort to keep lines of communication open between our content and engineering teams during development.

But there were definitely things we could define earlier rather than later for the content team.

For example, who is defining date and time formatting? Is it the writer? The designer? The business?

What are the casing rules? Do they vary depending on the platform? Who defines this? Are buttons always all caps, for example?

Are fields stacking vertically? What impact does this have on placeholder text? Is that impact magnified for other, longer, languages?

Screenshot from starter kit demonstrating how content can get cut off on smaller screens when fields are stacked horizontally instead of vertically.

Phase 4: The Launch

This is it. We’re here now. The final countdown. Allow us to introduce to you Version 1.0 of the Intersect Starter Kit. We’re over the moon about it 😉

The Intersect Starter Kit

The Starter Kit is available as a Sketch file for mobile or web. When you download the starter kit file you’ll see 4 pages. One has examples and designer notes, one has only examples, one has only designer notes, and one has neither examples or notes.

Which page you chose to work with will depend on how much guidance you are looking for in creating your design system.

For instance, you can use the examples to help you think about what considerations you may need to make for each component you are building as part of your design system.

Screenshot of starter kit showing rules and examples for "instructional text" components.

To help you get started, we’ve also included a quick video tutorial below.

Download the Starter Kit sketch files for yourself and let us know what you think. Do they help you build out your own Design System?

The people behind the kits 

Releasing V1 of the Starter Kit has been quite the journey for our team. To read some candid and first-hand accounts of the experience, check out our blog post on the Intersect website.


Member Login

Having troubles logging in? Contact us