We built a Starter Kit to help you build your own Design System, improve team collaboration, and build products more efficiently.
Intersect is a services company that designs and develops several digital products.
We asked what we thought was a simple question a while back. 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 friends.
Image: We created rules around greys and colours to improve hand off to engineering teams.
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).
Image: We documented the need for hover and pressed states for buttons on websites so we could keep them top of mind when designing and handing off specs to web engineers.
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. Frasier 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 realized 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?
Image: Stacking fields horizontally can have a negative impact on how content is displayed on smaller screens.
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.
Image: How examples work: The left side of this image highlights “Instructional text” as a component that makes up Form Fields. The right side shows an example of a rule for Instructional Text and examples of how Instructional Text components can be stacked with other Form Field 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 behind-the-scenes blog post.
Want to hear more about our design systems work, or see how we can help you build yours? Get in touch.