the Ri-pple effect:

YADS

A design system is nothing new. Yet Another Design System (YADS) for the IBM Skills Network team, on the other hand, is completely new.

Contribution

  • User interface design
  • Implementation QA
  • Style guide
  • Wiki
  • Design tokens
  • Pattern library

Tools & skills

  • Figma
  • Docusaurus
  • Tailwind CSS
  • Javascript

Info+

  • For the IBM Skills Network team, 2024

The problem

As an agile software team, quick turnaround and development was key. I identified that one of the major factors slowing us down was the lack of guidelines and reusable design components so the wheel was being reinvented every time. Furthermore, our various products did not follow one design style despite supposedly being part of the same brand, a problem which magnified over the years due to the discrepancy between the team members’ interpretation the non-existent brand style.
Look how many shades are in the violet/indigo range just on the screen here:

Thus,

A system had to be created that could bring cohesion to the team’s existing and future products’ visual language, restricting interpretation but still allowing creative freedom. Methodologically, this system needed to enable designers to quickly iterated designs and then hand off to developers for development, with both designers and developers using a system they could reference as a source of truth. Additionally, as the team expands, it is important that the design system remains scalable but cohesive—guardrails must be put in place so that there was still creative freedom despite the restrictions.

So,

What if we had a centralized place for both designers and developers to reference when communicating design needs so to speed up the development process and eliminates redundancy and inconsistency?

Discovery

Understanding the existing system and processes were key to the successful development integration of YADS, which brings us to the key objectives:

  1. Create a design system that brought visual consistency to Skills Network products, and
  2. Optimize but not disrupt the existing production process.

Being a developer-focused team, I also had to cater to both designers and developers in these objectives.

And thus the process begun.

The first part of the process was understanding the existing design style of Skills Network. Once I understood the style, I began to consolidate.

Don’t forget the developers!

Beyond assessing components based off of visuals, I also referenced the Tailwind CSS code to ensure developers would have access to working code they could easily cross reference with the original Tailwind CSS code. I also included the pure CSS.

Laying out the foundations

Colors

Defining the primary, neutral, and semantic colors. A tokening system had yet to be introduced as a standardized system was a new concept for the team. Furthermore, as we were heavily relying on Tailwind CSS, it had yet to make sense for the entire team to migrate to a Skills-Network-specific token system.

Typography

Consolidating the typography system was one of the most difficult challenges due to the huge variance across all the products. The only aspect that was certain was to use IBM Plex Sans, since, you know, it's an IBM team. From a page of 12 fonts with different point sizes, leading, and even color, I was able to reach a point of standardization. In this process, I learned about creating a scalable and adjustable system, which you can read at the end of this case study!

Grid

Utilizing a grid was a new concept that I introduced to the team. Rather than relying on max-width, the team could be certain that each page utilized the same amount of space using a grid. Introducing this grid provided visual consistency across all of the pages without having to cross-reference each time a new page was created. The concept of "don't make me think" was signifiacntly utilized in creating this, as I provided all of the code necessary to establish and utilize the grid, as well as written guidance on how to utilize it if one were to think about it.

Supplying the components

Through my audit of the existing components in our products, I identified key components that had to be standardized. 
 With all design systems, components must be reusable. However, with this team there was an even more important aspect: integration with different programming languages. I was working very closely with developers so I knew the struggles they had with implementation.
So in this process, not only did I audit the visual aspect of these components, I also audited the code that these components were using. In our team's wiki, I outlined the basic HTML structure for each component and where to insert new code if needed (such as an input field for the text field, or a backend response on a button).
Here are just some of the component variants that I created in my time at IBM.

Toggle

Breadcrumb

Button

Card

Text field

Notification

Radio button

So how are designers designing now?

The past design process

  • Recreating components every time a new component or product feature was requested
  • Making independent decisions on what the primary color should be
  • Not having a standardized method of communicating feedback to developers or a SSOT to share with developers
  • Having to do manual accessibility checks for every new design
  • Guessing the dark mode equivalent of each color or just ignoring the dark mode design all together and hoping the auto dark mode does its thing properly

The new design process

  • Upon receiving a design request, check out a design system for existing components or guidance on designing
  • Make informed design decisions and no double-guessing the primary color
  • Providing feedback to developers and referencing a SSOT
  • Be confident that if not all, then most, designs following this system have good accessibility
  • Have dark mode variants ready to go without having to redesign from scratch

...And now, with a fresh set of eyes into the front-end development process:

The past development process

  1. Be told what to make by a stakeholder or manager
  2. Go on Tailwind CSS Components and copy a usable component (loosely defined)
  3. Make it fit the existing website layout without iteration or feedback
  4. Have a slightly-ugly and mostly functional product pushed to production, as they had to spend more time than necessary on the visual component.

The new development process

Rather than disrupting the existing workflow entirely, YADS would simply provided a better guideline for developers to follow.

  1. Be told what to make either by a stakeholder or manager
  2. Consult the designer
    1. The designer will pull components from the design system
    2. Eliminate the creative process for developers
  3. Go to the internal Skills Network Wiki and copy-paste code from there (which is based off of Tailwind CSS Component codes)
  4. Have an on-brand design and fully functional product ready for production.

By the way,

Remember that screen from the beginning? Check out what it looks like now:

Lessons in the making

Have no fear for change

When I was nearing what I thought was the end of this consolidation process, I was told by multiple team members that the typography settings were too small. At first, fear took over—What if I made a bad decision that will make the rest of the system seem illegitimate? What if this ruins the designer-developer trust?
Obviously, I was overthinking. An overall bigger font size was implemented and it elevated the friendly aesthetic. But, this made me realize the importance of having a system that can adapt for new scenarios. A rigid design system benefits no one.

I'm going to write more

But I'm a post-secondary student so it's currently in the works! Thank you for reading so far!