Harry Potter and the Notepad of Doom
The year is 2014. I am in university, and I am very, very busy. I’m a member of the Student Union. I am flexing my artistic talent by making campus event posters in Photoshop. Those Facebook cover photos, t-shirt designs, or the big vinyl banners in front of the building—that was all me. I was heavily involved, highly productive, and fiercely committed to doing absolutely anything—and I mean anything—except actually going to class. My professors, naturally, rewarded this dedication with an “F”—which, as we all know, stands for “Fantastic.”
Seeing my obvious “potential,” a senior dragged me into a web development study group. That was when everything changed. It was the first time I could create a visual design using nothing but text. The feeling was magical. I was basically Harry Potter, casting my spell in Notepad.
Then, they handed me the ultimate magic wand: Bootstrap. Suddenly, I could cast btn to make a button out of a dull, lifeless rectangle. Slapping on btn-primary turned that pale button into a majestic blue. col-lg-4! My layout magically split into columns! col-md-6! It snapped perfectly on a tablet! I was building sites left and right, and every single one of them was a work of art. I was so ready for that owl to bring me my Hogwarts letter.
But the fog of excitement eventually faded. I looked around and realized a horrifying truth: every single website I built looked exactly the same. Rounded cards. Blue buttons. My masterpiece had turned into just another Bootstrap template. So, I did what any reasonable person would do: I customized. I went in and changed the default blue to my blue, and tweaked the shadows to my shadows. And let me tell you, it was fun at first… but the feeling vanished in about three days. Because even with my specific blue, it was still just Bootstrap wearing a fake mustache. I wasn’t impressed with myself anymore.
So, I resorted to doom-scrolling in search of new toys. I popped into Bulma to try on some modern layouts. I browsed through the heavy-duty enterprise world of Foundation. I spent some time with Semantic UI. I was trying on different frameworks in hopes of getting that dopamine rush back.
Suddenly, some genius at Facebook bestowed upon us a grand wisdom:
THOU SHALT USE REACT.
And we did. Everyone I knew was talking about it. So, I looked at my beloved AngularJS, packed its little bags, and threw it right out the window to jump on the hype train. The old frameworks followed. Bootstrap became React-Bootstrap. Semantic UI became Semantic UI React. You wrote btn-primary no more; it was now <Button variant="primary"/>. It felt incredibly sophisticated at the time.
If Google Made a Toaster, My Boss Would Buy It
Right around this moment, Google descended from the mountain holding an Android-powered stone tablet, and on it was written: “Material Design.” It was their grand attempt to bring the physical world into the digital world. It was their Design Language. Everything had to be made of paper. Everything had to have a shadow. It is the sole reason that when you open some random app on your iPhone today, it makes you feel like you are using a cheap Android device. And I blame Google.
Naturally, the React community responded with Material UI, a tool that made building Material Design web apps feel like putting on a cozy sock. And luckily for me, my boss at the time was a massive Google fanboy. If Google had released a line of branded kitchen appliances, he would have bought the toaster. So, we chose yet another Google-lookalike setup for our app.
I’ll admit, I was nervous at first. Design Language? Never heard of ‘em before. I looked at the documentation and thought, “What the heck is this? Is Material Design going to be entirely different from Bootstrap? Will I need a physics degree to understand these paper shadows?” I ran yarn add material-ui (yes, Yarn was still good at the time), imported the button, and after spending a few hours with it, breathed a massive sigh of relief.
It was the exact same thing.
<Button variant="primary"/> turned into <Button color="primary"/>. Who would have thought that a sacred Design Language is just one component prop away?
As the years went by, the JavaScript community kept doing what it does best: churning out new tools every five minutes. Ant Design, Mantine, Chakra, Tailwind, shadcn—I tried them all. I spent hours sitting in the dark, playing with them until I understood their deepest, darkest secrets. And by the end of it, my mental model was locked in. To me, design was just a game of configuration. Pick a UI style, pick a tool, tweak the config file, and boom, you win.
Armed with this worldview, I spent years wandering the office like a missionary, helping people set up their projects left and right.
“Oh, you want your MUI theme to match your branding? Step aside, I’ll configure it.”
“Oh, your designer came up with six levels of spacing and you want it in Tailwind? Let me handle it for you.”
I was preaching the gospel of design consistency, and with every person I helped, my ego grew three sizes. I was incredibly confident.
Then, one day, my boss called me in. He looked at me and said, “We’re assigning you to a new team. Your mission is to improve our design system.”
I was a little surprised. I thought, “Well, obviously. They have seen my brilliance. They are probably ashamed of watching me give out free advice and want to officially crown me the King of CSS.” So, I accepted the challenge. I was ready to walk in there completely and utterly convinced that I was going to bless this project with my genius.
But there was one small problem. It is always this one thing that stops humans from achieving greatness. The ultimate antagonist of all success stories: The Process.
You know how it goes. I had to wait for the kickoff. Management had to approve the funding. The Big Boss hadn’t replied to an email. Suddenly, the King of CSS was benched.
With a gaping hole in my schedule, I decided to kill some time. I mean, I’ve been working with “design systems” for a decade, I thought. Material UI, Ant Design, Tailwind, shadcn—been there, configured that. So, I figured I would just hop online and do a little light “research” before the real work actually began.
You know the saying, “Great minds think alike.” And since I obviously had a great mind, the industry giants must be doing exactly what I was doing. I just needed to see my own rock-solid mental model reflected back at me on some fancy corporate blog.
I puffed out my chest, cracked my knuckles, opened a new tab, and dove headfirst into the search bar. “Popular design systems,” I typed.
The results flooded the screen. I scrolled past the “sponsored ads that keep Google running” section and glanced at the list. Material Design? Already know what it is. IBM’s Carbon? Not interested.
Then I found it. My very first victim: Pajamas Design System.
Pajamas is GitLab’s design system. Now, GitLab is famous for having the most Bootstrap-looking UI on the planet. Naturally, I expected this so-called design system to be a mirror image of the Bootstrap documentation. I clicked the link without a second thought.
But to my surprise, the landing page of Pajamas greeted me with completely unfamiliar terms: “Brand.” “Product.”
There was no sidebar packed with UI components. No code blocks ready to be copied and pasted. And why the hell was the Getting Started section full of philosophy and principles? Don’t get me wrong, it’s nice knowing why they design their product a certain way. It tells a designer everything they need to know. But…
WHERE THE HELL IS MY INSTALL COMMAND?
Why waste my time with this design philosophy nonsense that has absolutely nothing to do with rendering a component? This wasn’t like Bootstrap at all, despite the fact that their actual UI looked almost exactly the same. A proper doc should have three things: a command to install, a list of components, and code to copy. That’s what these things are for, right?
Or perhaps… AM I WRONG?
Nah, that couldn’t be. After all this time working with various frameworks, I knew documentation always had slight variations. This had to be one of those weird edge cases. The code was there; it just took a few more steps than usual. I was sure if I looked at a few more examples, it would align exactly with what I expected.
Why Does a Button Need a Literary Editor?
I took a look at the list once again, and one design system stood out to me. It was the design system from the company whose products have been worshipped by agile coaches all around the globe—the holy grail of agility that requires you to shape your entire world around THE TICKET.
Atlassian.
I was very curious about what Atlassian used to build the software that has caused so much pain for us developers. Driven by a volatile combination of PTSD and Stockholm syndrome, I clicked on the link and the page began to load.
Just like Pajamas, Atlassian greeted me with a landing page sporting a massive headline: “Better teamwork by design.” Sure, whatever that means. Let me see where your code is. And it was going to be different this time; I came prepared. I knew exactly what I was looking for.
And of course, because it was a landing page, there was no code. Continuing to push my denial to the absolute limit, I started hunting for the word “components.” I clicked it.
“IT IS THERE!”
I practically screamed at my monitor, scaring my dog. A bunch of cards appeared with those beautiful, comforting words: “button,” “calendar,” “checkbox.” Ah, yes. The good stuff. I ignored all the surrounding text like it was a software terms-and-conditions popup. I spent the next hour acting like a snobby art critic, staring at their button source code and whispering, “Mmh, exquisite packaging strategy. Majestic component composition.” I was a tech lead inspecting a fine wine, completely blind to the trap I was walking into.
But you know, something was bugging me. It was that elephant in the room, staring right at me, begging for my attention. An elephant called GET STARTED.
Fine, let’s see what it is. I clicked. No code again.
Instead, the sidebar listed Design, Develop, Content Design, and a bunch of other disciplines. Fascinating. Drawing rectangles wasn’t enough—we apparently needed an entire separate department just to write the text. I clicked on Content Design, expecting some generic copywriting tips. Sure, “voice and tone” makes sense. “Inclusive language”? Very trendy.
But then my eyes hit a section that absolutely broke my brain: Content guidance for individual components.
WHAT?!
Each individual component has its own dedicated manual on how to write words inside it? Why on earth does a button need a literary editor? Is there a correct, highly emotional, and spiritually inclusive way to say “Submit”?
Then I saw another section: “About the Atlassian Design System.” It was a massive manifesto detailing their brand vision, core values, and corporate principles. None of this was for developers. It was a holy scripture for product identity.
That was the exact moment my supreme confidence evaporated, replaced by pure, sweaty panic. The red flags I had been ignoring for days finally collapsed on top of me. I realized this wasn’t some weird edge case. I spent days frantically digging through a mountain of corporate design systems, and I uncovered a universal, three-layer psychological operation:
- Layer 1: The Gaslighting (The What and Why). Before they let you touch a single line of code, they force you to read their manifesto. They brainwash you into their “culture” and “vision” with strict philosophical guardrails, making sure you feel emotionally aligned before you dare to color a rectangle.
- Layer 2: The Periodic Table of Grays (The Foundation). This is where they hide the visual DNA. Colors, fonts, and “design tokens.” Let’s be real: design tokens are just variables meant to make a Software Engineer feel like a NASA scientist for picking
#F3F4F6. - Layer 3: The Copy-Paste Buffet (The Asset). The actual Figma files and code blocks. The only part I ever cared about. The part where you
Ctrl+C,Ctrl+V, and pray nobody asks you how it actually works under the hood.
Looking back, the irony is thick enough to choke on. When I was a university student making posters, the “theme” was god. If we threw a gritty, post-apocalyptic survival party, I couldn’t put Hello Kitty on the poster in a pastel pink font. I understood design philosophy back then!
But modern tools like MUI, shadcn, and Tailwind did their jobs too well. They are the Hot Pockets of the frontend world. They made UI building so mindless, fast, and effortless that they essentially lobotomized the “why” right out of my brain. They took all the deep, painful, creative strategy of actual design and reduced it to a giant JSON configuration file.
They made me feel like an absolute engineering deity. Five minutes of modifying a config file, and boom—a flawless, gorgeous website. I was convinced I was a creative genius, completely ignoring the fact that I was just a microwave chef slapping a piece of parsley on a pre-cooked TV dinner and expecting a Michelin star. It gave me the illusion that I was a competent designer.
This discovery was a physical slap to the face. For 12 years, I had built a career on configuring other people’s work, walking around the office like a frontend Messiah, handing out free configuration tips to the peasants. My ego had its own zip code.
And that corporate, red-tape, email-ignoring monster called “The Process”? The one I blamed for stopping my greatness? It wasn’t my enemy. It was a tactical security guard that tackled me to the ground right before I ruined the company’s entire design language. It benched the “King of CSS” just long enough to prevent a massive disaster. It gave me the downtime to realize that while I still don’t entirely know what a design system is, I finally know what it is not.
And honestly? Realizing you’re completely clueless is the first step toward not getting fired on Monday. With any luck, it’s enough to keep me from ruining the project on day one.