How PMs Redesign an App Without Guessing
For Product managers redesigning an existing app · Based on Simplilearn UX/UI Design Thinking Fundamentals
// TL;DR
Product managers can use UX/UI design thinking to redesign an existing app without relying on stakeholder opinion or jumping straight into Figma. The process forces you to separate the client and internal stakeholders from the real end user, ground redesign decisions in research and personas, map user journeys to find friction, and validate prototypes with real users before development. Use it whenever drop-off, negative feedback, or a stalled roadmap signals the current design was built for the wrong person — the PM's preferences instead of the daily user.
Why do app redesigns so often fail?
Because teams jump straight into visual screens driven by stakeholder preferences instead of the end user's needs. In UX/UI design thinking, the client (or product manager) commissions the product but doesn't use it daily — the end user does, and their needs are frequently different. If your redesign is anchored in what the leadership team likes, you're optimizing for the wrong person. The first move is to separate, on paper, the internal stakeholders from the actual person who operates your app every day.
How should a product manager start a redesign?
Stop screen design and return to Step 1: explicitly define the end user. Write down their goals, environment, devices, technical literacy, and pain points. If you can't answer these confidently, you owe your team user research before another pixel moves. Consider a mobile banking app redesign where the team has been generating Figma screens: the correct move is to pause, identify real users like a 'First-Time Sender' and a 'Daily Trader,' and discover where they actually struggle — OTP entry friction, confusing navigation hierarchy — rather than where the PM assumes they do.
What research artifacts should I produce?
Run conversations, surveys, and observations, then turn them into research findings documents, competitive analysis, and interview notes. From that, build research-grounded personas — not assumption-based ones. Create empathy maps capturing what each persona Thinks, Feels, Says, and Does. Then map the full user journey, remembering it starts before the app opens — finding a password, switching to the SMS app for a code. These artifacts give you evidence to defend decisions against 'I don't like it' feedback from executives.
How do I prioritize what to fix first?
Use information architecture and interaction flows to decide what content lives on which screen and in what order — you cannot put everything on one screen, so prioritize ruthlessly by user goals. When you reach visual UI, apply Jacob's Law: put the transfer button where users already expect it from other banking apps, so you don't add cognitive load. Then run usability testing with real users via a tool like maze.co, documenting every point where users hesitate or make mistakes. Those are design failures, not user failures.
How do I balance the roadmap against user demands?
Advocate for users, but find the equilibrium with business goals, budget, and technical constraints. Not every user wish belongs in the next sprint. Produce iteration plans from your usability reports and prioritize fixes that address the highest-frequency pain points first. This is where PMs add unique value — you translate user advocacy into a viable, sequenced roadmap instead of an unbounded wishlist. A redesign grounded in research also gives you a defensible story for leadership: every screen change traces back to a documented user pain point.
Next step: Before your next design review, write a one-page definition of your true end user and audit whether your current redesign decisions map to research or to internal opinion. If they map to opinion, schedule user research this week.
// FREQUENTLY ASKED QUESTIONS
How do I convince stakeholders to invest in research before redesigning?
Frame it as risk reduction: research prevents you from shipping a redesign built for internal preferences that increases drop-off. Point to friction data — high abandonment at specific steps — and show that usability testing catches these before expensive development. Position personas and journey maps as decision-making tools that replace subjective 'I don't like it' debates with evidence.
What if leadership insists on a design the users won't like?
Your job is to balance user advocacy with business goals, not to win every fight. Present usability test data showing where users struggle, quantify the risk, and propose the smallest viable compromise. If leadership overrides evidence, document it. Often a research-backed prototype test with real users settles the debate more persuasively than any argument.
How do I know if my current app has a Jacob's Law problem?
Audit every standard element — login, navigation, back buttons, primary actions — against where users expect them from other apps in your category. If your app places them unconventionally, users must relearn your interface, adding cognitive load. Usability testing will show hesitation or errors at exactly those spots. Any deviation from convention needs strong justification.