Every so often, a designer, recruiter, or manager brings up the topic of a Design System—usually in the context of either:
- “What would be the best way to go about creating a, um… what do they call it… a Design System?” or
- “Hey, I see that you have years of full-stack experience… have you ever used a Design System?”
Having been in this field for years, I welcome these questions—because today, having a Design System in place is a necessity. When I see job postings that don’t mention the use of a Design System, I die a little inside.
So far in my career, I’ve built three from scratch and extended one. The first one, way back at Life Technologies, was before we fully understood what a Design System really meant. Before that, as a front-end “Themer,” I saw the early workings of such systems. And before that, the closest thing we had was brand and identity guidelines—a far cry from the comprehensive Design Systems we talk about today.
There are middleware solutions (like Storybook and Knapsack) that aim to simplify the process. But, in my opinion, they often stifle creativity and innovation—turning teams into paying subscribers locked into someone else’s system. They have their place, but proceed with caution. In many cases, it’s a better investment to ensure your teams (designers included) are fluent in Git on the command line. And please, don’t tell me “Figma has version control.” No, not in the way you think.
Here are some insights from thousands of hours spent yelling at technology—and another thousand trying to save myself (and my team) from unnecessary pain.
1. Technology Is Disposable
Before you even think about developing or implementing a Design System, you need to deeply understand that all technology is disposable.
If you don’t accept this as a foundational truth, you’ll never achieve meaningful scalability or transference. Your design system must be built for change—not just for the framework or trend of the moment.
2. Choose Your Namespace Wisely
Your naming conventions matter—a lot.
• If you’re in a startup, don’t name your Design System after the company name, the founder, or their dog.
• If you’re in an established company, choose something that acknowledges legacy.
For example, at Thermo Fisher, we used the word “Carbon” for testing searches because it was incredibly difficult to derive a specific context from it. So when IBM used “Carbon” for their Design System, I shuddered. Why would you choose a name that makes you invisible?
Was this system created by Richard Smith?
3. Be Practical About Semantics (Especially Text)
Bad naming conventions will come back to haunt you. Some of the worst offenders include:
• Terrible document names for downloads: Archive.pdf → just shoot me now.
• Website page titles that start with the site name (Why? Just… why?)
• Design system tokens that don’t scale: h1-font-large
• Non-polymorphic design system tokens: clinique-title-text, h1-title-homepage
• Websites that don’t put dates on blog posts (Okay, not a text convention, but top five on my annoying list.)
• Prefixing names with unnecessary context (same problem as the namespace issue).
• Asset directories starting with “com”—especially if you’ve never done work for a .org.
• Inconsistent underscore/dash usage.
• Use underscores to group related words together.
• Use dashes to separate content.
• Example: portfolio_paintings-john_zavocki-v_a-0001.pdf
Salesforce’s Lightning Design System naming conventions? Worth stealing.
4. Design and Development Must Work Together
Design and development should operate in synergy—not as opposing forces. Your development team must already have (or be working toward) detangling the front and back ends.
Your Design System strategy should incorporate:
• Various stages of development.
• Various technologies for implementation.
If you’re all-in on React and expect every front end to be built with that single framework, you’re short-sighted. A robust Design System should support Bootstrap, Vue, and even lightweight solutions for quick prototyping.
Not every designer wants to install Node.js and waste gigabytes of space just to build a single promo page.
And let’s be honest—modern designers can’t even hand-code an HTML table. Do you really think they’re going to touch the command line?
5. Don’t Forget the <p> Tag
Yes, you need to create a style for it. Don’t be lazy.
6. Audit Every Form Element
If you haven’t reviewed every form element and figured out how to implement it properly, you’re being careless.
Not everything is a text field.
7. Your Design System Must Ship with Production-Ready Client-Side Elements
If your Design System doesn’t include actual JS code to make components function, you don’t have a Design System—you have a style guide.
8. Document Form Implementation
A real Design System includes:
• Schemas for form data
• APIs to call
• Expected responses
If your system doesn’t cover how forms work, you’re missing a critical component.
9. Provide Clear Implementation Documentation
If junior, mid-level, or seasoned developers can’t follow clear documentation to implement components, guess what?
You don’t have a Design System.
A snippet library for VS Code or your preferred IDE is a must-have.
If your developers have to copy-paste CSS snippets from Figma, you don’t have a Design System.
10. Figma ≠ a Design System
• If your Figma Library is synced to a release path, but every time you update it, all text elements break, you don’t have a Design System.
• If your developers need to grab a CSS snippet from Figma, you don’t have a Design System.
Figma is a tool—not the system itself.
11. A Real Design System Uses a Shared Language
If you can’t communicate across business units, brands, and different tech stacks using:
• Token IDs
• Component names (parent and child relationships)
• Consistent terminology
…you have a short-sighted Design System.
Bonus Tip: PowerPoint is Your Secret Weapon
A PowerPoint version of your Design System—with fonts, copy-paste components, and layouts—is critical for non-technical teams.
Not everyone wants to learn Figma. Not every company has the budget for it.
But every business has PowerPoint—use it as your hidden design Rosetta Stone.
And Finally…
• UX, Content Writing, and Marketing have different objectives, but the ultimate goal is business profitability.
• Invite developers to creative meetings.
• Empower them to solutionize on paper—or even in ChatGPT.
Because at the end of the day, context and content must work together.
And did anyone mention analytics?
Portfolio Projects with Design System Elements
While I have done several Design systems – and have worked extensively with them, they were always a means to an end and not an end in of themselves. So, I never really bother to retain any substantial artifacts from that work.
On this page are images of presenations, excell spreadsheets, and mind maps that show a part of the process. Below, save for the Thermo Style Guide, are projects that hint at the work done.
