How We Built our Design System to Last

Before I onboarded at Yobs Technologies, the company hadn't had a permanent designer on their team. They had cycled thru some freelance UX Designers contracted for a few months at a time, to build our MVP. Despite working in an ambiguous space with little data to test theories as a startup that was still pinning down their market fit, our engineers and I collaborated on creating a design system that would stand the test of time.

 

 

When I was finally onboard as the first full-time designer, the company also recently pivoted their business model, rendering the previous designs *almost* useless.

So, I had my work cut out for me.

Defining the Main User Goals

The first task I set out to accomplish was to understand if and how the previous designs accomplished their needs. I started off with a design tear-down/review of our SaaS platform. I evaluated the purpose of each component on every screen lengthy discussion with the CTO, the engineers, the CEO, and the data scientists, and proceeded to strip out all the fancy interactions and then compiled a list of all the bare-bone components and actions needed for a user to complete their goal and why.

This helped us clarify which were rudimentary or necessary to our platform, and which were frills and lace disguised as necessities.

For example, I tossed the interactive function to drag a card from one list to another. Instead, I wrote down: "The ability to move a card from one category to another, so they can organize and prioritize their cards easily."

It's important here to write down how each component and action solves a problem for the user. If you can't write it how it solves a user's problem, it's probably not useful.

At the end of this task, we prioritized this list and was left with simple 3 bullet point list of a user's main actions, and 4-5 sub points on actions that help them accomplish that. (That was the birth of our first product & screen requirements list! A milestone in of itself.)

Brainstorming Designs: The Competition of Most Edge Cases

After having a simplified list of what our product required, we got to work on brainstorming the kinds of components we wanted to display our data. We didn't jump to the screens just yet as we had a tendency to feel attached the first usable one we saw.

For example, as a recruiting platform, our users first goal usually, was to create and open a new interview for a job position. After a user created one, we wanted to display each job as a card on a dashboard:

The edge cases we ran into:

1. The 1,000 Job Card scenario: How would they find the one they're looking for? Is there pagination? Do they need to see the department of the card? How are they sorted?

2. Editing/Deleting Cards: In-line editing? How do they delete?

3. No Longer Relevant Cards: What if they don't need this card anymore? What happens?

4. Long Titled Cards: If the title is really long, how is it displayed?

5.Ugly Responsive Cards: What would the look like super squished, or super stretched out?

With one hefty all-day brainstorm and 2 triple-shot expressos, I carefully weighed each of the solutions and the severity of impact edge-cases had on user goals and decided how the components would display our user's data. Then, I designed all the different states of all components I could think of. (empty, loading, overloaded, error, etc)

 

 

Laying Our Components on Artboards

Finally, we took our carefully designed components and began arranging them onto Sketch Artboards. Since we already created our screen requirements, it was just a matter of adding the components the screen needed and making sure the layout was intuitive for users to interact with. Thanks to our engineers who explained to me how resuable components worked to react.js, we designed ours in a similar manor. I made a rudimentary prototype to gather feedback the how effective and seamless the new designs were, went back for a few rounds of feedback, and came out with a 80% complete design system.

 

 

Defining standardized Colors, Animations and Interactions

Finally, we celebrated by adding the bells and whistles. As a team we decided on a color palette from a few I had picked out for them, defined crucial animations and interactions, like button or tooltip hovers and was well the way to publishing a style guide and a design system for our company. In a separate file, Should we need to re-evaluate the efficacy of a component, I saved all brainstormed elements so we could jump in right where we started.

 

 

Prioritizing for Implementation

The most valuable thing I learned in this process was how important it was to take into account your engineering constraints. At the end of this whole process, I had what I believed to be the best idealized version of our SaaS platform. In reality however, it could not be implemented in its entirely until a quarter and a half form now. So I went back to the drawing board and removed alll the low priority nice-to-have features and handed off a more realistic design that could be implemented immediately. So even after all of this, while the design system might last...needs and constraints will always be variable.