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.

Someone would ask about availability.

I'd check inventory.

An order would change.

I'd update one place and sometimes forget another.

None of these problems looked dramatic individually.

But together, they created friction.

And friction compounds.

A few extra minutes per order doesn't sound significant.

Multiply that by dozens of orders, customer questions, supplier conversations and operational tasks, and suddenly the business owner is spending their day managing information instead of growing the business.

I started seeing the difference between data and information

This became one of my biggest lessons.

Having information doesn't mean the information is useful.

Imagine an operations dashboard showing:

Orders: 27

Pending: 8

Shipped: 12

Delivered: 7

It looks useful.

But what does the user actually need to know?

Maybe the important question is:

“Which orders require my attention right now?”

That's a different problem.

The dashboard shouldn't simply display everything the system knows.

It should help the user understand:

What happened?

What needs attention?

Why does it matter?

What should I do next?

That's when I started thinking less about dashboards as collections of cards and more as decision-making tools.

The interface is only one part of the experience

This changed how I approached my Tathya case study.

Instead of starting with:

“What screens should I design?”

I started with:

“What does the operator actually do?”

I mapped the workflow.

Order received → Payment verification → Inventory check → Fulfilment → Shipping → Delivery → Return/support

Then I looked for points where information could disappear, become outdated or require unnecessary manual effort.

That exposed a more interesting design problem.

The opportunity wasn't simply to make the dashboard prettier.

It was to make the workflow easier to understand and act on.

Good design reduces cognitive load

One thing I noticed while running the business was how often I had to remember things.

Which customer?

Which order?

Which product?

Which supplier?

Which payment?

Which conversation?

The more the system relies on human memory, the more fragile the workflow becomes.

This is why I now pay much more attention to:

  • Clear status

  • Context

  • Grouping

  • Hierarchy

  • Defaults

  • Visibility of important information

  • Actionable states

  • Error prevention

A good interface doesn't make the user remember the system.

The system should remember for the user.

I also learned that constraints are part of design

Real products rarely have unlimited resources.

You don't always have:

  • A large engineering team

  • Perfect data

  • Unlimited research time

  • A clean technical architecture

  • Every feature you want

When you're running a small business, constraints are especially obvious.

You have to ask:

What actually needs to exist?

What can wait?

What creates the most value?

That taught me something important about MVP thinking.

An MVP isn't a smaller version of everything.

It's a focused version of the product that solves the most important problem.

Design decisions have consequences

This is probably the biggest difference between designing a concept and designing a real product.

In a concept project, a button can be wrong.

In a real business, a bad workflow can mean:

  • A missed order

  • A delayed shipment

  • An unhappy customer

  • Lost revenue

  • More support work

That changes how seriously you evaluate a design.

I started asking myself:

What happens if the user doesn't notice this?

What happens if the information is wrong?

What happens when something goes outside the happy path?

Those questions naturally led me toward designing edge cases instead of only designing the perfect flow.

It changed the kind of designer I want to become

Running Tathya didn't make me a better designer automatically.

It gave me something more useful:

Context.

I experienced what it's like to be the person affected by the workflow.

The person checking orders.

The person answering customers.

The person making decisions with incomplete information.

The person who doesn't have another team to solve the problem.

That experience influences how I approach product design today.

When I design an interface, I don't just ask:

“Does this look good?”

I ask:

“Does this make someone's job easier?”

“Does this help them make a better decision?”

“What happens when things don't go according to plan?”

“Is this solving a real problem or just adding another feature?”

From founder to designer

The funny thing is that I didn't start my e-commerce business intending to become a product designer.

But running it changed the way I see products.

I learned that:

A workflow is a product.

Information architecture affects business operations.

Every unnecessary step has a cost.

Every unclear state creates uncertainty.

And sometimes, the best design decision isn't adding something.

It's removing the thing that shouldn't have been there in the first place.

That's the mindset I'm bringing with me into product design.

I don't want to just design interfaces.

I want to understand the systems behind them—and design products that make those systems easier for people to use.

Comments

Post a Comment

Popular posts from this blog

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