Building Software for Dinosaurs' Needs

Technology moves fast. People? Not so much.

As developers, we want to build the future. We want to use the latest frameworks, the sleekest UIs, and the most modern paradigms. But sometimes, your users are stuck in the past. Like, “Windows 95” past.

Here is the story of how I learned to build software for “dinosaurs” without going extinct myself.

The Windows 95 Hangover

I recently took on a project for a medical group. I was excited… until I saw their current software. It was a relic. A 30-year-old application that looked like it belonged in a museum.

Here’s the kicker: They loved it.

They didn’t want a modern dashboard. They didn’t want “streamlined UX.” They wanted that software, but “newer.” Same clunky menus, same dense information density, same shortcuts.

My first instinct? “No way. This is bad design.” I wanted to burn it down and start fresh.

But here’s the thing about User Experience: It’s not about what I think is good. It’s about what they can use. These doctors had decades of muscle memory built into this ancient system. Forcing them to relearn everything wasn’t “innovation”—it was disruption.

Finding the Balance

So, how do you innovate when your users hate change? You compromise.

I realized I couldn’t just clone the old system (because it was terrible), but I couldn’t build a spaceship either. I had to find the middle ground.

1. Respect the Workflow

The old system required them to manually type out symptoms. They were used to it. They trusted it.

My solution? I kept the text input they loved, but I added a smart list. They could click a symptom to auto-populate it, or they could type it manually if they preferred.

It respected their legacy workflow while subtly introducing a faster, better way. And guess what? Once they saw how much faster clicking was, they started switching.

2. Iterate, Don’t Revolutionize

You can’t boil the ocean.

Instead of a massive “V2.0” launch that changed everything, we moved in steps. We kept the familiar layout but cleaned up the typography. We kept the workflow but removed the bugs.

We boiled the frog slowly. (Sorry, doctors).

The Lesson

Building for “dinosaurs” isn’t about compromising your standards. It’s about empathy.

It’s easy to mock outdated users, but they are the ones doing the actual work. Our job isn’t to force them into the future against their will; it’s to build a bridge so they can walk there themselves.

So next time you’re frustrated by a legacy requirement, remember: You’re not just coding functionality. You’re coding trust.

If you enjoy the content, please don’t hesitate to subscribe and leave a comment! I would love to connect with you and hear your thoughts on the topics I cover.