Hello and welcome to this page. What follows is a 3 part email course that used to live as an email course behind DesignSystemsCrashCourse.com (now dead).

It has been featured on podcasts such as Python Talk, Freelancers Podcast, and UI Breakfast. I believe there is still a lot of value in the material, so I am making it available for free. If you are a designer or a developer who is new to design systems or UI component libraries, this can be a great starting point not only for getting some traction on the project, but learning how to sell it to management.

And on to the first email…

What follows in this course two actionable things you can do right now to realize huge savings in your project.

Before talking about those ideas, I wanted explain what the benefits of using Design Systems Engineering in your project.

  1. Foster better communication
  2. Play to your team’s strengths
  3. Avoid conflict between teams (such as Design vs. Engineering)
  4. Produce a better quality product
  5. More design consistency
  6. Less meetings

Yes, and that last one is no doubt going to save you headache and your organization money.

So this all sounds great, but how are we going to get there?

We are going to get there by creating a set of communication tools that allows interdisciplinary teams to quickly and clearly communicate their ideas or reference how something should be done.

This is no easy feat since teams often have objectives that overlap and perhaps agendas that can conflict with one another.

Let me illustrate this point with an example of how web development was done in the past (and continues to this day).

The design teams supplies the engineering team with a set of photoshop high fidelity mocks. There is a large meeting to discuss what each mock is and little details and nuances of how the interface is supposed to work. The engineers take notes based on this ephemeral conversation and return to their lair to hammer out the project.

Then there are the questions…

Hey, is this button is a different size?
What color is this grey?
How far is that spacing?
Why is it 17px here and 19px there?
Where are the icons?

And so the back and forth between design and engineering starts. It tends to be very detail oriented based on whatever template engineering decided to start with.

Even this decision is one that has a huge divide between the two teams. Design probably wants to see the most visually stunning page (often the home page) finished first, while engineering focuses on the page with the most complexity first, paying no attention to aesthetics.

And so, how are these questions answered typically? 

Meetings, meetings, and more meetings.
Designers talking to engineers. 
Pair sessions with designers sitting with the engineers.

And this is compounded because rather than going through the entire project looking for inconsistencies it is often approached in a template-by-template way.

This is a terribly inefficient process. The only way that products end up hitting that professional level is just a matter of throwing a huge amount of time and energy at it.

Eventually the project is complete and everyone has gotten everything to fit. 

But the final site might not resemble the original designs exactly and vice versa. 

Likely there have been some changes along the way and the only thing keeping your process together is the verbal history of your tribe.

If the unthinkable happened, and you had to start over with a completely new team, it is unlikely that anyone could decipher the mocks and the final project and figure out what had been done.

I am here to tell you that there is a better way.  And that better way is Design Systems Engineering.

Perhaps you have heard of Design Systems and even seen a few on the web. Perhaps you even have implemented (more or less successfully) a set of Design Systems at your own organization.

First off I want to dispel a myth.

A proper Design System for your organization does not need to look like the style guides published by MailChimp, Salesforce Lightning or Google Material Design. These are all beautiful, but they are just examples of how these organizations publicly share or draw attention to their process.

In a recent talk by Jina Bolton of Salesforce she said that, “Design Systems contain whatever your organization needs to communicate design decisions.

In my experience there are two ways to get started with creating a Design System that will work for an organization of any size. Even a web team of one.

These are 1. front-end code and 2. a living styleguide.

Both of these are what I like to call low hanging fruit. This means that you will be able to build these the fastest, with the least amount of effort, and they will have the biggest rewards.

In the next email I am going to talk about what I mean exactly in regards to front-end code, what my process is, and how this is going to help your team.

Until tomorrow.

-James Stone, Design Systems Engineering – ZURB Foundation Specialist

P.S. A little bit about me. My name is James Stone and I am an independent Design Systems Engineer and an Adjunct Professor at the College of Arts and Architecture at Penn State. For the past 4 years I have worked with diverse design and development teams on a variety of fast-paced projects. In these projects there is always the same goal: to bring world class level products to life in a short time frame. If you would like to learn more, a good place to start is my Featured Articles + Talks Page.

UPDATE 2019: I am now working as a Senior Software Developer at Futurice and the best place to learn more about me is on my personal website at JamesStone.com