When our team first began developing the HarvardSites Design System, the task felt monumental. HarvardSites supports Harvard’s web publishing platforms, including HarvardSites CampusPress and the newly developed HarvardSites Drupal. These platforms are used by a wide range of university stakeholders, from entire schools, to individual students and faculty, to create and manage their websites. With such a diverse user base, the need for consistency, accessibility, and scalability was clear. But where do you even begin with something so complex?
We were starting from nearly zero knowledge, and the sheer scope of the work—processes, governance, management—was overwhelming. I reached out to Ethan Marcotte, a respected figure in the industry known for his work on responsive design, for guidance. His advice was straightforward: “Read this book.” He recommended Design Systems: A Practical Guide to Creating Design Languages for Digital Products by Alla Kholmatova. This book became a turning point for our team. Kholmatova doesn’t just focus on UI component libraries; she emphasizes that design systems are about creating a shared language and fostering collaboration. She shares insights from companies like Airbnb and Atlassian, showing how they built scalable, lasting systems.
It's the "What-cha-ma-call-it"
After reading it, I brought the key ideas back to my team, and it became the foundation for our work. One of the most important lessons was the need for a shared language. Without it, communication breaks down. For example:
A user researcher might say, “We’re testing that… uh… component with the buttons.”
A designer might respond, “Oh, you mean the dropdown? I’m working on a new version of that.”
A developer might ask, “Wait, are we talking about the primary dropdown or the secondary one?”
These kinds of misunderstandings waste time and create confusion. A shared language ensures everyone—designers, developers, stakeholders, and users—understands the system in the same way.
This need became even more apparent during user research. We discovered that study participants were confused by the lack of consistency in naming a specific content type meant for sharing publications on their site. This is because our own team wasn't exactly sure what to call it. Sometimes it was referred to as “publication,” and other times "biblio" or "bibliography". What's funny is, going based off of the actual definition of what a bibliography is, the content type did not fit the build. To this day, I'm not entirely sure where that name came from but that's what makes the whole exploration and learning process an exciting journey.
This inconsistency not only confused users but also made it harder for them to use the platform effectively. It was a clear sign that we needed to define and standardize our terminology.
Establishing Our Shared Language
Kholmatova’s book reinforced this idea. A shared language isn’t just about naming components; it’s about creating a common understanding of principles, patterns, and goals. It’s about aligning the team around a unified vision.
To build this shared language, we started by:
Defining our core principles. What did we want our design system to achieve?
Creating a glossary. We documented every term, component, and pattern to ensure clarity and reduce ambiguity.
Collaborating across teams. We involved designers, developers, and stakeholders in the process to ensure the system worked for everyone.
The results were clear: fewer misunderstandings, faster decision-making, and a more cohesive team. That said, our team is still in the process of fully developing our shared language. It’s a work in progress, but we’ve already seen the benefits of taking these steps.
If you’re starting your own design system journey—or even if you’re in the middle of one—it’s never too late to define your shared language. The sooner you start, the sooner you’ll see improvements in communication and efficiency. And if you’re looking for a practical guide, Kholmatova’s book is an excellent resource.
Commentaires