Here’s What 20 Years of Pioneering Design Engineering Has Taught Us

(This was originally posted on December 31, 2025. It was our work anniversary.)

Wow…geezz…I’m honestly still kinda wrapping my head around the fact that we’re into the very final day of 2025. Well, if I can be so frank, this year has been a rather challenging & difficult year, so personally speaking, I’m just kinda glad for it to be over so that we can quickly move onto 2026. Why? Well, because there’s just so much more genuinely positive stuff for us to look forward to together.

But before we do that, today also happens to mark a really significant and important milestone for us in our career journey. Yes, today, we are officially celebrating our 20th anniversary as the pioneers that brought you the field of UX/Design Engineering. In fact, in just two days, I’ll also be celebrating the birthday of UX. Yes, that industry, UX. But hey, let us not get ahead of ourselves.

While we have you here now, I’m thinking we would take this time today to share FIVE of the most important lessons we have learned during our course of pioneering a totally new field on our own.

---

Lesson One: Labels Are Prisons Until You Build Your Own

When I created the first breadcrumb navigation back in 2006, there wasn’t a job title for what I was doing. I wasn’t purely designing — I was coding it. I wasn’t purely developing — I was solving user experience problems. I was doing something in between, something the industry didn’t have language for yet.

For years, this felt like a curse. Job applications asked me to check boxes: Designer? Developer? I was both. I was neither. I was something else entirely.

The local design industry rejected me repeatedly. Too technical for the designers. Too design-focused for the developers. An outsider who didn’t fit their neat categories.

Here’s what 20 years taught me: The label doesn’t create the value. The work does.

Recently, Andrew Hogan, the VP of Insights at Figma wrote about how traditional job labels fail to capture what people actually do. You can read the full article here on Shortcut. Twenty years later, the industry is finally catching up to what I learned the hard way: you can’t wait for permission to exist in a category that doesn’t exist yet.

Design Engineering is real now. Google was recently hiring for it. OKX is finally moving in that direction as well. The market is in it’s early days of looking into it. But it only became real because people like us did the work before the label existed.

The lesson: Stop trying to fit into existing boxes. Build undeniable value in the space between categories. The labels will follow — or you’ll create new ones.

---

Lesson Two: “Functional Design” Doesn’t Mean “Ugly Design”

For 20 years, I’ve watched the same miscommunication play out:

Developer: “We need functional design first.” Designer: immediately strips out all sophistication and creates wireframes

But that’s not what functional design means in Design Engineering.

Functional design means: sophisticated AND implementable.

It’s not about simplicity for simplicity’s sake. It’s not about removing visual polish to make developers happy. It’s about designing with implementation reality baked into every decision from the start.

A functionally designed component can be beautiful, complex, and delightful — AND it can be built without requiring three months of custom development or sixteen different states that no one specified.

Just yesterday, Gary Simon published a video regarding the upcoming UX trends of 2026. In it, he also addressed the communication breakdown between designers and developers during handoffs. The problem isn’t that designers make things too pretty or developers are too rigid. The problem is we’re still treating design and implementation as separate phases instead of integrated thinking.

This is why Design Engineering exists. We don’t choose between beautiful or buildable. We refuse the false choice entirely.

The lesson: Stop treating aesthetics and implementation as opposing forces. Master both languages. Design with your hands in the code.

---

Lesson Three: Innovation Doesn’t Come From Figma Tutorials — It Comes From Observation

Here’s the truth most UX professionals won’t admit: The best design insights don’t come from design tools. They come from watching people.

The first breadcrumb navigation I created in 2006? It didn’t come from a design pattern library or a UX course. It came from staring at a piece of shiny fridge sticker — a simple set of arrows showing process steps — and thinking, “What if we could show users where they are in a digital journey the same way?”

That’s observation. That’s the foundation of innovative design.

Ed Orozco recently wrote about understanding human behavior as the core of great UX. He’s right. But here’s what he didn’t say: you can’t learn human behavior from skillshare courses or certification programs. You learn it from decades of people-watching. From sitting in cafes, at airport lounges and watching how people interact with their phones. From noticing what frustrates them, what delights them, what they do when they think no one’s looking.

I’ve written before about the art of observation. It’s not a trendy skill. It’s not something you can add to your LinkedIn profile. But it’s the single most valuable capability a Design Engineer can develop. In fact, as I am sharing these lessons right now, I’m sitting in a quiet corner of a local foodcourt where it provides the perfect vantage point for me to observe people going about their day. That is what I love doing.

I love this quote by Fura Johannesdottir, Chief Creative Officer, Interbrand:

“Design is a way of seeing the world. It’s not just a job; it’s a kind of lifestyle.”

We live in an era obsessed with skill badges, certifications, course completions. Don’t get me wrong — technical skills matter. But they’re tools, not vision. Tools help you build what you see. Observation helps you see what’s worth building.

The lesson: Stop collecting badges. Start watching people. The next breakthrough UX pattern isn’t hiding in a tutorial — it’s in the world around you, waiting to be noticed.

---

Lesson Four: Why Big Tech Stopped Innovating (And Where Real Innovation Happens Now)

Michael Buckley recently wrote about the rise of “minimalist design” at companies like Google and OpenAI. But let’s call it what it really is: risk aversion dressed up as design philosophy.

These companies aren’t choosing simplicity because it’s better for users. They’re choosing it because it’s safer. Predictable. Less likely to make waves or require defending bold decisions to stakeholders who’ve never designed anything in their lives.

I’ve watched this shift happen in real-time over 20 years.

In my first decade (2006–2016), 80% of my consulting work involved solving novel design challenges. We were charting new territory — mobile interfaces, responsive patterns, touch interactions & interactive design solutions. Clients came to me because the problems they faced didn’t have established solutions yet.

Now? The tech industry has matured. And with maturity came comfort, but more dangerously, complacency. And with complacency, stagnation wasn’t that far behind.

Here’s what these billion-dollar companies won’t tell you: they’ve lost their appetite for pushing boundaries. I’d love for them to prove me wrong. But I’m also willing to bet they won’t. They can’t. Not without revealing their own state of stagnation.

This is why I’m turning my focus toward “deep tech” sectors — AI interfaces, FinTech/Web3, Cybersecurity. This is where the next generation of truly innovative design will emerge. Not because other sectors can’t innovate, but because most of their core design challenges? I already helped solve them over the past two decades.

The frontier has moved. The question is: who’s willing to go there?

The lesson: Innovation doesn’t happen in comfortable places. If you want to do groundbreaking work, follow the unsolved problems — not the established playbooks.

---

Lesson Five: Stop Chasing Portfolios. Start Chasing Purpose.

I’ve written about this before, but it bears repeating: Your portfolio is a byproduct, not the goal.

Too many designers and engineers are obsessed with building impressive case studies. They’re focused on the “what” — what did I build, what tools did I use, what does my Dribbble look like.

But here’s what 20 years of pioneering taught me: The work that matters starts with “why.”

When I created the first visual indicators back in 2006, I wasn’t thinking about my portfolio. I wasn’t seeking validation or waiting for permission. I saw a problem — users getting lost in digital experiences — and I genuinely believed it needed solving.

My mission statement was simple: “How can we make the web experience better for everyone using it?”

That mission drove everything. It’s why I kept building even when former superiors told me my ideas were “a waste of time” (real words). It’s why I continued when people said I was “crazy for even thinking of trying” (also real words).

They were wrong. Well, maybe not entire wrong (within the context of that time, maybe what I was doing does feel incredibly risky, maybe cuckoos even 🤪). Not because I was smarter, but because I was mission-driven, not validation-driven.

Today, that mission statement still guides me. I just swapped “web” for “digital” because our professional playing field has expanded. But the core purpose remains: make digital experiences better for everyone.

The lesson: Find your mission statement. Your “why.” Not for your LinkedIn bio — for yourself. What problem do you genuinely care about solving? What makes you build even when no one’s watching?

Answer that, and the portfolio takes care of itself.

---

Closing

You may already realized that none of my FIVE key lessons today touched on AI. Barely. Why? Well, because the more I look back on my journey and how we got here, many of these lessons remain some of the more fundamental ones. The same design challenges of the mid-2000s when we first start are still the same design challenges facing teams & companies today. It’s like we have innovated and progressed (technologically speaking), but the human side of it is still stuck in the past. Perhaps that is where the real problem is. And we gotta address that quickly.

Yes, AI is a huge game changer. I don’t think denying it will make it any less true. AI will upend and replace a lot of the repetitive work that we are used to doing for years. But it also a genuinely good thing if we understand how to work with it instead of against it.

As pioneers, we will continue to make it a part of our ongoing mission to lead the way when it comes to understanding the intersection between Design, AI and Engineering. And in time, we’ll share our in-depth findings and understanding with the rest of the design/engineering community.

Until then, I think these FIVE lessons should be good for at least next decade.

---

(You can read the full, original article that was first published on Medium, on December 31, 2025.)