Redesigning a Product People Already Depend On

TxtCart hired us for one screen.

It was a trial run. They had an AI-native SMS marketing platform doing real numbers for thousands of Shopify brands, a design that hadn't kept up with the business, and no reason to trust some outside studio with the whole thing. So they gave us one screen and waited to see what we'd do with it.

That turned into a full rebrand, a thirty-page website, and a five-month overhaul of the entire platform, desktop and mobile.

I bring it up because the trial screen was smart, and because it shows what makes this kind of work different. Redesigning a product nobody uses yet is a design problem. Redesigning a product half a million people use every day just looks like the same problem from outside.

Every redesign costs the people who already know the product

This part usually gets missed.

When you redesign something people already run their business on, your best users pay for it on day one. They've got muscle memory. They know the thing they need is three items down in the second menu, and they stopped reading that menu years ago. They go by position, not by label.

Ship a cleaner layout and, to them, you just hid everything.

That's often worth it. But someone has to actually count the cost, and most teams don't, because everyone reviewing the new design is seeing it for the first time. Nobody in the room is the person who's been running their business through the old dashboard since 2021.

So "is this better" is the wrong question. The real question is: is it better enough to be worth what it costs the people who already had it working?

Figure out what's actually outdated vs what's just doing its job

CopeCart built one of the strongest payment and sales tools in Europe, over 500,000 vendors use it. The product just hadn't kept up with how big the system underneath it had gotten.

The temptation on a project like that is to treat everything as fair game. Old product, full redesign, rip it apart and rebuild.

That's usually a mistake, because two totally different things look the same from outside. Some of it really is outdated, old visual style, patterns nobody uses anymore, inconsistency that piled up over years of shipping features. But some of it is load-bearing. It looks weird because the business is weird, or because some workflow that matters a ton to a specific group of users needs to work exactly that way.

You can't tell the difference just by looking at the screens. You find out by asking what a flow is actually for, and seeing if the answer makes sense or not.

The redesigns that flop are the ones where a studio assumed a workflow was pointless clutter, and it turned out to be how a third of the customers did their job.

Density isn't the problem

There's this assumption floating around that if a product has a lot going on, it's confusing, and the fix is to simplify it. Sometimes true for stuff people use casually. Almost never true for stuff people use professionally.

Someone running checkout, payments, analytics, and vendor settings all day doesn't want less on the screen. They want the stuff they use constantly right there, and everything else easy to find without getting in the way. Density isn't what makes a pro tool hard to use. Messy density is.

The mistake, and it happens a lot, is designing a mature product around a first-time user's first twenty minutes instead of a daily user's next three years. First impressions matter, sure, but that belongs in onboarding and empty states, not in the actual layout of the screen someone uses to do their job every day.

Same idea applied to ecom.jobs, just from the other direction. Job boards are about as generic as products get online, usually a dense list, a bad mobile version, and zero personality. Density wasn't the issue there either. Boring, undifferentiated density was.

Mobile isn't just a smaller version of desktop

For TxtCart we built the full mobile product to the same standard as desktop, not some stripped-down version. Same deal with ecom.jobs, in both light and dark mode.

The usual approach is: build desktop first, then figure out what makes the cut for the smaller screen. That gives you a mobile product that feels like an apology.

What actually changes on mobile is the context, not what the product can do. Someone on their phone is doing one specific thing, with less time and one thumb. That should change what's front and center and how you interact with it. It shouldn't mean quietly cutting features, because users don't experience that as "thoughtful." They experience it as the product just not working when they need it to.

Quick note on light and dark mode, since it comes up every time: it's not just swapping colors. Contrast changes, charts and graphs need their own separate treatment, and depth cues that work in one mode disappear in the other. Doing this right across dozens of screens has to be planned from day one, otherwise it's a patch job that never really works.

What keeps things consistent over six months

Rebel Audio took six months. Dozens of screens across the whole platform, desktop and mobile, every step from recording to editing to publishing.

At that length, the real enemy is drift. Screens built in month one and screens built in month five, by different people on different days, slowly stop feeling like the same product. Nobody notices while it's happening. Everyone notices once it's done.

What stops that is locking in decisions early and not reopening them. Spacing, type sizes, how components behave, what happens when a table overflows, what an empty state looks like, how you word an error message. Those calls are cheap to make in week two and expensive to fix in month four, and every one you leave open is a spot where two designers will make two different, both-reasonable choices.

That volume of work is also where the boring screens live. Settings, permissions, billing history, the state where someone has one item instead of forty. Those make up most of a mature product, and they're where daily users spend their time. A redesign that looks great on the dashboard and got no thought on the settings page isn't done. It's just demo-ready.

Back to that trial screen

TxtCart had the right idea, and I'd tell anyone hiring for this kind of work to do the same.

Give them one real screen, not the pretty marketing dashboard. Pick something dense, with edge cases, that your power users actually live in, the kind of screen nobody would put in a pitch deck.

What you get back will tell you more than any proposal could. Did they ask what the flow was for? Did they think through the empty state without being told to? Did they actually get the workflow, or just make it look nicer?

That's a much cheaper way to find out than committing to a six-month project.