The Sticky Note Next to the Software

Observation #3 from The World Through a Product Designer’s Eyes.

When users create a workaround, don’t just fix the workaround. Understand why they needed it.

The Observation

I once noticed something interesting.

A sophisticated digital product was being used alongside a tiny sticky note.

The software had dashboards.

Filters.

Search.

Notifications.

Multiple screens designed to organize information.

The sticky note had a few handwritten words.

And yet, the person kept it right beside the screen.

At first, it seemed insignificant.

Then I started wondering:

Why does someone need a piece of paper when the software already exists?

That question is much more interesting than the sticky note itself.

The Workaround Is a Signal

When people create their own way of doing something, we often call it a workaround.

But I see it differently.

A workaround is user feedback in disguise.

It can tell us:

• Something is difficult to find.
• Something takes too long.
• Information isn’t available at the right moment.
• The workflow doesn’t match reality.
• Or the product requires users to remember something the system could remember for them.

The user isn’t necessarily resisting the product.

They may simply be adapting to it.

This Matters Even More in Healthcare

Healthcare professionals work in environments filled with interruptions.

A clinician may be reviewing information, answering a question, speaking with a patient, and switching between tasks within minutes.

In that environment, remembering everything isn’t realistic.

So people develop their own systems.

Sticky notes.

Paper lists.

Personal shortcuts.

Open browser tabs.

Mental reminders.

These aren’t random behaviors.

They’re attempts to reduce cognitive load.

And that’s where product designers should pay attention.

Don’t Design Against the Workaround

Imagine discovering that users are keeping sticky notes beside your product.

The first reaction might be:

“We should eliminate the need for sticky notes.”

But that’s not the first question I’d ask.

I’d ask:

“What job is the sticky note doing?”

Maybe it’s helping them remember something.

Maybe it’s giving them quick access to information.

Maybe it’s helping them prepare for the next task.

Maybe it’s simply visible at exactly the right moment.

Once we understand the underlying need, we can decide whether the product should support it.

That’s a much more valuable design conversation.

The Product Leadership Lesson

This is also where I think product leadership and UX intersect.

A feature request tells you what someone wants.

A workaround can tell you why they need it.

Those are not the same thing.

If we only collect feature requests, we may end up building more functionality.

If we study behavior, we may discover that the better solution is actually simpler.

Sometimes the opportunity isn’t to add another feature.

It’s to remove the reason the workaround exists.

What I Look For During Product Reviews

When I review a product, I don’t only look at the interface.

I look for signs of adaptation.

Where are users copying information?

Where are they opening multiple screens?

Where are they writing things down?

Where are they repeatedly going back?

Where are they creating their own shortcuts?

These small behaviors can reveal gaps that a traditional feature list won’t show.

The interface tells you what you designed. The workaround tells you what users actually need.

Final Thought

The next time you see a sticky note sitting beside a sophisticated digital product, don’t dismiss it as an old habit.

Look at it as evidence.

Someone is solving a problem your product hasn’t fully solved yet.

And sometimes, the smallest workaround can point toward the biggest product opportunity.

About this Series

The World Through a Product Designer’s Eyes is a weekly series exploring everyday observations and connecting them to human behavior, healthcare, product design, and leadership.

Because the world is full of design lessons. Most of them don’t happen on a screen.