Winning Back a Rejected Redesign
A redesign pulled back weeks after launch, then relaunched on users’ terms, with 79% of users on it by May 2025.
I joined ResponsiBid in January 2024. Six weeks later, a redesigned UI I hadn’t worked on went live to every account. I spent my first year making it something users would keep.
Role
Lead UX Designer
Team
Duration
Jan 2024 - Dec 2024
A redesign that shipped before it was ready
The new UI went live as the default for every account in early 2024. It came with a new codebase, and there was real excitement inside the company about what it would make possible.
Then we launched it, and users told us right away how hard it was to use.
“
Y’all…I am so sorry but I hate the look and layout of this new interface. 😭😭😭 … I can’t find anything!”
Jessica M., user
“
There’s just too much going on … it’s overwhelming to look at.”
Brian B., user
“
It’s less user-friendly now.”
Anonymous user
The redesign had been built without dedicated design research. Support was overloaded, and some users lost confidence and left altogether. Users could switch back to the old UI, but the next page returned them to the new one. Less than four weeks after launch, we pulled it back, relabeled it “Beta UI,” and let every user make the old UI their default. The redesign stayed available, but it was no longer forced on anyone.
The rollback bought us time, but it didn’t fix anything. For months I watched defect reports pile up, some filed at emergency priority. One user couldn’t see their SMS history. Another couldn’t find bids that were right there in the old interface. Every report was a business owner whose workday ran on our software, and we’d let them down. My product manager and I worked through those reports together, deciding which design problems had to be fixed first.
The cost showed up in the business. May 2024 was the worst month for revenue churn in the company’s tracked history, 27% above May’s seasonal norm. It was one of the hardest stretches in the company’s history.
I was new to the team, the design wasn’t mine, and within a few months I’d be the only designer at the company, but fixing it was still mine to do.
The way out:
Switch to Old UI
Always within reach in the redesign, and the button users reached for when it got in their way.
Every problem cost users speed and control
I led 20 user interviews to understand why people were going back to the old UI. Three problems came up again and again:
01
Everything changed at once
Even seasoned users faced a steep learning curve, because there was no part of their daily work that looked or behaved the way it used to.
“
It definitely was a learning curve. It was like, oh, everything’s changed. I’m still finding spots where I’ll switch back to the old UI just because I know it better.”
Sarah K., during a user interview
02
The changes created new problems
Many of the changes introduced usability issues that hadn’t existed in the old UI.
“
It looks cleaner and I understand that, but for usability I like to have everything at a glance.”
Craig H., during a user interview
03
Modern felt cluttered
What was meant to feel cleaner and more current felt cluttered instead: boxes inside boxes, oversized cards, and too much scrolling to keep track of where you were.
“
I’m scrolling up and down in a box on a page that’s in boxes!”
Brian B., during a user interview
None of it was really about how the redesign looked. Each problem was a user losing speed at something they used to do without thinking, making them feel less in control of their own workday. Winning them back meant earning that control back, one fix at a time.
The roadmap waited until users would choose the new UI
The first decision was what not to build. I pushed for the roadmap to wait: step back, get the new UI right, and earn users’ trust back before giving them more features to get excited about. My product manager agreed. Nothing new would ship until the new UI was something users would choose.
Putting the page back in the page header
On mobile, the model was backwards. The global bar carried the page title, as a bid number that said nothing about who the bid was for, while the page header gave its space to a filled primary “Switch to Old UI” button. Users were getting disoriented, unsure whether they were on a bid or the customer profile, which looked very similar. I swapped them back. Mobile got the same navigation structure as desktop, the page header now says what the page is and who it’s for, and the switch moved into the settings menu as a muted button, where global controls belong.
On mobile:
Before
The top bar showed only a bid number, and the page header gave its space to a filled “Switch to Old UI” button.
After
The page title and customer move into the page header.
After
The switch becomes a muted button in the settings menu.
What users asked for wasn’t what they needed
Users missed one thing about the legacy UI: everything they needed was on one page. The redesign kept it on one page but buried it, with contact details, bid details and links in bordered rows nested inside cards, so they scrolled and hunted. The updated proposal, one of the most-used links, was buried with the rest:
“
Those buttons are super hard to find. I have to scan the entire page … I literally found that and clicked it and I was like, oh, this whole time I’ve been going back to the old one to find this.”
Ryan C., during a user test
My first move was to give users what they asked for. Several wanted the legacy collapsible cards back, so I tested collapsible cards, then true tabs to cut the scrolling. Both missed. Collapsing would have pulled us back toward the old pattern, and tabs split up the one page users valued most. What testers did agree on was the frame: nearly every one of them preferred two columns to the grid of cards. What went inside the columns stayed split.
Without a clear answer, I told my manager we shouldn’t ship any of the bigger layouts yet. We shipped what had consensus: the cleaned-up cards, a new page header, and an Updated Proposal button beside the breadcrumbs.
As launched
The page opened on a bare bid number, with contact details, bid details and links buried in bordered rows nested inside cards.
The first fix
Cleaner cards, a page header that names the bid and customer, and Updated Proposal pulled out beside the breadcrumbs.
I kept exploring through the spring, more than 20 layouts in all, and testers pointed to the answer:
“
Do I have to use the tabs or is the tab just helping me get to spots on the page? Like, is everything still available if I want to scroll up and down?”
Kyle W., during a user test
They hadn’t wanted collapsible cards. They’d wanted less scrolling without losing the one-page view. The final design puts the work in the main column and the customer details in a side panel, with anchor tabs so scrolling is optional instead of required.
The final design
The work in the main column, details in a side panel, and anchor tabs to jump between sections. The same pattern shipped on the job page later. The bid page is waiting on the roadmap.
Beyond the first two pages:
The dashboard
The redesigned home screen users land on.
The bids feed
Every bid in one list, one of the surfaces the launch had left out.
Making the fixes stick
Shipping smaller, testing bigger
The launch went wrong partly because it asked users to absorb everything at once, so we changed how we release. Small updates now ship incrementally, and larger releases go to small groups first, so usability issues surface before they reach everyone. It’s how the team still works.
Closing the gap between research and design
ResponsiBid wasn’t new to talking with users. My product manager had been meeting with them long before I joined. What was missing was a path from those conversations to the screen. Feedback reached the designers secondhand, and sessions showed individual components rather than whole pages, so users never saw the full experience until it shipped.
I changed both. I ran sessions myself, and we moved to task-based testing: instead of reacting to isolated pieces, users got a realistic scenario from their workday and completed it themselves in a full-page prototype. We ran 60+ user tests in a single year, and what users told us showed up in the next iteration.
Task-based testing:
Whole pages, real tasks
Remote sessions where users worked through full-page prototypes, from the bid page to the dashboard.
A shared foundation
To keep fixes fixed and stop new screens from drifting, I started a design system with another designer and our developers, built on MUI components and atomic design. It has since grown to cover our native mobile app, and that’s its own story.
Handoff and quality
About four months in, I became the only designer at the company, so handoff became mine too. I learned what developers needed and delivered it: detailed component states and specs, prototypes for anything interactive, and regular one-on-ones with engineers. I also held shipped work to the design through design QA.
Churn fell to the lowest quarter on record
The defects were largely resolved across June, July and August 2024. Revenue churn fell 43% from the second quarter to the third, going from the highest quarter in the company’s tracked history to the lowest. Those two quarters sit back to back and are the sharpest quarter-over-quarter improvement anywhere in the data.
Engineering resolved the defects and customer success repaired the relationships. The recovery was the team’s, and the diagnosis was mine.
As of May 2025, 79% of users were on the new UI, and every one of them could have switched back. Today new accounts start on the new UI, and that option is still there on every page.
The relaunch
79%
Of users on the redesigned UI as of May 2025, with the old UI always available
43%
Drop in revenue churn in one quarter, from the worst quarter on record to the best
↳ The research behind it
60+
User tests in 2024, plus 20 interviews
20+
Bid page layouts explored in 2024 before the final design
Owning decisions I didn’t make
Designing something new and taking responsibility for something that already exists are different skills. This project was the second one: someone else’s decisions, already in front of every customer, and my job to make them work anyway.
The change I’m proudest of isn’t a number. The rollback changed how the company ships, and user research is now a standard part of the process instead of something we reach for after users tell us something is wrong.
