“I Stopped Designing Screens. I Started Designing Decisions.”

 

I Stopped Designing Screens. I Started Designing Decisions.

What changed when I stopped asking “What should this screen look like?” and started asking “What decision is the user trying to make?”

When I started learning UI/UX, I thought good design meant making interfaces look clean.

I focused on spacing, typography, colors, components, and whether a screen felt “modern.”

Those things matter.

But I eventually realized something uncomfortable:

A polished interface can still be a bad product.

The real challenge isn't creating a beautiful screen.

It's understanding what the user is trying to accomplish, what is getting in their way, and what the business needs to achieve at the same time.

That changed the way I design.

The screen isn't the problem

Imagine a user opening a health app before visiting a doctor.

At first glance, the problem might seem simple:

“They need a place to store their medical records.”

So you could design:

  • Upload button

  • Documents section

  • Search

  • Categories

  • Filters

  • A nice dashboard

Done.

But that's solving the visible problem, not necessarily the real one.

During my work on MediSync, I looked deeper into what happens before a doctor appointment.

The user isn't really thinking:

“I need to organize my documents.”

They're thinking:

“What happened last time?”

“Which prescription did the doctor give me?”

“Was that test before or after the medication?”

“What should I show the doctor?”

The actual problem is reconstructing context.

That changes the product completely.

Instead of designing a document storage system, I started thinking about:

Timeline → Health Event → Relevant Context → Original Evidence

The interface became a consequence of the product model—not the starting point.

Research changed what I designed

One of the biggest mistakes I made early in my UX journey was treating research as something that happens before “real design.”

I would think:

Research → Wireframes → UI → Prototype

Now I see it differently.

Research isn't just a phase.

It is a tool for making better decisions throughout the process.

For MediSync, research surfaced several recurring patterns:

1. Information was fragmented

Health information could exist across:

  • Gmail

  • WhatsApp

  • Hospital apps

  • Google Drive

  • Paper prescriptions

  • Lab portals

The problem wasn't simply access.

It was reconstructing the story.

2. More information wasn't necessarily better

When users weren't sure which records were relevant, they tended to collect everything.

That created another problem:

Information overload.

3. Trust required evidence

If a system extracted information from a prescription, users needed to know where that information came from.

That led to a simple principle:

AI extracts → User verifies → System saves

The AI could help organize information.

It shouldn't quietly become the authority.

AI should reduce work—not take control

AI has changed how quickly designers can explore ideas.

I use AI for things like:

  • Exploring product concepts

  • Structuring research

  • Generating alternative flows

  • Creating content variations

  • Exploring edge cases

  • Prototyping ideas

  • Building early interfaces

But I've also become more conscious of where AI should not make decisions.

For example, in MediSync, AI could:

Extract
Doctor name, date, medicines and dosage.

Organize
Connect a prescription to the relevant health event.

Summarize
Create an evidence-based appointment summary.

But it shouldn't:

Diagnose.

Recommend treatment.

Invent missing information.

That distinction matters.

Good AI UX isn't necessarily about making the AI feel intelligent.

Sometimes it's about making the boundaries of the AI obvious.

Design is also about business

Another shift in my thinking came from working on my own e-commerce business.

Running a business taught me something that design tutorials don't always emphasize:

Every interaction has a cost.

A confusing checkout can reduce conversions.

A poorly designed operations dashboard can waste hours.

A missing status can create unnecessary customer support.

A scattered workflow can become an operational problem.

When I worked on Tathya, my jewellery business, I experienced these problems firsthand.

Orders could come through different channels.

Inventory information could become unreliable.

COD orders could be missed.

Customer conversations could get buried in WhatsApp.

These weren't simply UI problems.

They were business problems caused by information and workflow problems.

That experience changed how I think about product design.

I now try to ask:

What happens to the business if this interaction fails?

And:

What happens to the user if we optimize this interaction for the business instead?

Good product design has to consider both.

My design process is becoming simpler

I don't believe every project needs a complicated design framework.

The process I currently use is closer to this:

01 — Understand

What problem are we actually solving?

Who experiences it?

What are they trying to accomplish?

02 — Investigate

Talk to users.

Study existing workflows.

Look for patterns rather than isolated complaints.

03 — Frame

Turn observations into a clear problem.

Define:

  • User needs

  • Constraints

  • Business goals

  • Product principles

  • Success criteria

04 — Model

Before drawing screens, figure out:

What information exists?

How is it connected?

What decisions does the user need to make?

This is where information architecture and user flows become important.

05 — Design

Only now do I start designing the interface.

Wireframes first.

Then interaction patterns.

Then components.

Then visual design.

06 — Test

Put the prototype in front of people.

Watch what they do.

Don't just ask:

“Do you like it?”

Ask:

“What would you do next?”

“What do you think this means?”

“What would you expect to happen?”

The difference is huge.

07 — Iterate

If users struggle, I don't immediately blame the user.

I go back and ask:

What did the design fail to communicate?

What I'm still learning

I'm not at the end of this process.

I'm actually becoming more comfortable with the fact that I don't know everything.

I'm still learning how to:

  • Make stronger product decisions

  • Connect UX decisions to measurable business outcomes

  • Run better research

  • Design for complex workflows

  • Use AI without outsourcing my thinking

  • Communicate design decisions more clearly

  • Build products instead of just designing screens

And that's probably the biggest lesson I've learned so far.

The goal isn't to become someone who can design any screen.

It's to become someone who can understand a problem deeply enough to know which screen should exist in the first place.

My current design principle

If I had to reduce everything I've learned into one sentence:

Don't start with the interface. Start with the decision.

What does the user need to decide?

What information do they need?

What prevents them from deciding confidently?

What does the business need from that interaction?

Then design the interface around those answers.

That's the kind of product designer I'm working toward becoming.

Comments

Post a Comment

Popular posts from this blog

What Running My Own E-Commerce Brand Taught Me About Product Design

  What Running My Own E-Commerce Brand Taught Me About Product Design I didn't learn product design only from courses. I learned a lot of it by breaking things in a real business. Before I started seriously pursuing product design, I was running an e-commerce jewellery brand. I was responsible for almost everything: Product photography. Catalogues. Packaging. Marketing. Customer conversations. Orders. Payments. Operations. At the time, I didn't think of these things as “UX problems.” I just thought: This business is becoming difficult to manage. Looking back, I realize I was experiencing product design problems every day. The first lesson: messy workflows create invisible costs Customers could reach us through different channels. Some orders came through marketplaces. Some came through Instagram. Some came through WhatsApp. Information was distributed across different places. That created small problems. A customer would ask about an order. I'd search through conversations....
Read more

Empathy Is Not Guessing What Users Feel

  Empathy Is Not Guessing What Users Feel I used to think empathy meant understanding how the user feels. Now I think it means something slightly different: Being willing to accept that I might be wrong about them. That's a much harder thing to practice. As designers, it's easy to look at a problem and immediately create a solution. A user can't find something. → Add a button. Users are confused. → Improve the copy. People aren't completing a flow. → Reduce the number of steps. Sometimes those solutions are right. But before designing them, there is a more important question: Why is this happening? Empathy starts with curiosity When I started learning UX, I often approached problems with assumptions. I thought I knew what users wanted because the solution seemed obvious to me. But users don't experience products the way designers do. They don't see our information architecture. They don't know our design system. They don't understand the reasoning behind...
Read more

AI Won't Replace Designers. But Designers Who Use It Will Work Differently.

  I used to think coding wasn't part of my job as a designer. My job was to understand users, design flows, create interfaces, prototype them, and hand everything over to developers. Then AI changed the workflow. Not by turning me into a developer. But by making the distance between idea → prototype → product much smaller. That's where AI workflows and vibe coding became interesting to me. I'm not trying to become a developer When I say I use vibe coding, I don't mean that I've suddenly become a software engineer. I still think like a designer. I start with: What problem are we solving? Then: What should the experience be? Then: How should the interface behave? The code comes after that. Tools like AI coding assistants, v0, and other generative tools allow me to turn those decisions into something interactive much faster. Instead of spending hours imagining how an interaction might work, I can sometimes build a rough version and experience it myself. That's a c...
Read more