The Redesign Trap: Why Unsolicited Redesigns of Swiggy and Zomato Hurt Designer Portfolios

Last updated: September 2026

Imagine opening a designer’s portfolio.

The first project is a “Swiggy Redesign.”

The second is a “Zomato UX Overhaul.”

The third is another familiar app with rounded cards, cleaner typography, smoother animations, and a sentence that says, “I improved the user experience.”

Everything looks good. And somehow, after five minutes, you still have no idea whether the designer can actually solve a product problem.

That is the redesign trap.

Unsolicited redesigns are not bad projects. In fact, they can be excellent exercises for learning UX, interaction design, visual systems, and product thinking. The problem is that many designers stop at the easiest part: changing what the screen looks like.

In 2026, that is increasingly difficult to defend as strong portfolio evidence.

Real product design involves incomplete information, competing goals, business constraints, technical limitations, user behavior, experiments, trade-offs, and uncomfortable decisions. A designer rarely gets a blank canvas and permission to make everything prettier.

I’m Riten, founder of Fueler, a skills-first portfolio platform building the career infrastructure for 100 million creative professionals. Fueler connects talented individuals with companies through assignments, portfolios, and projects, not just resumes or CVs. Think of it as Dribbble/Behance for work samples combined with AngelList for hiring infrastructure.

This article gets into the uncomfortable part of portfolio design: why a beautiful redesign can sometimes make your portfolio weaker, what is missing from most unsolicited redesigns, and how designers can turn these projects into credible evidence of how they think.

Why Swiggy and Zomato Redesigns Became Popular Portfolio Projects

There is a simple reason designers keep redesigning Swiggy and Zomato: everyone understands them.

You do not need to explain what food delivery is. A recruiter can recognize the home screen, restaurant listing, menu, cart, checkout, order tracking, and review experience almost instantly.

That familiarity makes the project easy to present. It also creates a dangerous shortcut: familiarity starts feeling like research.

• The product is instantly recognizable: A designer can show an existing interface and immediately establish context. That reduces explanation and lets the portfolio jump straight into the visual work. For a student or junior designer without client projects, this accessibility makes familiar consumer products attractive subjects for self-initiated UX case studies.

• There are many visible surfaces to redesign: Food-delivery products contain discovery, search, filtering, restaurant pages, menus, checkout, payments, offers, tracking, reviews, and post-order experiences. That gives designers plenty of screens to work on, which can make a project look substantial even when the underlying problem definition is thin.

• The interface provides an easy before-and-after story: Existing screen on the left, redesigned screen on the right. Problem solved, apparently. The format is visually satisfying because the reader immediately sees change. Unfortunately, visible change is not the same thing as demonstrated improvement.

• Popular products create comparison opportunities: A designer can discuss information hierarchy, navigation, personalization, accessibility, content density, or interaction patterns against something millions of people already use. Swiggy itself has publicly documented accessibility work across navigation, restaurant listings, menus, payments, and order tracking, showing how much deeper product design can go than visual rearrangement.

• The project feels more real than a fictional app: That instinct is understandable. Designing another imaginary “coffee app” can feel disconnected from actual products. But borrowing a real product does not automatically give the project real constraints. If the designer invents the problem, research, users, and success criteria, the project remains an independent concept exercise.

The Biggest Problem With an Unsolicited Redesign Is the Problem Itself

Before changing a button, card, navigation bar, or checkout flow, there should be a reason for touching it.

This sounds obvious. It is also where most redesign case studies become shaky.

If the problem is simply “the interface feels cluttered,” you have described an aesthetic reaction, not a product problem. Good UX work starts by understanding what is failing, for whom, and under what circumstances.

• Separate observation from evidence: “The homepage has too much information” is an observation. “Users struggle to find a previously ordered restaurant because competing content dominates the first screen” is a hypothesis about behavior. The second statement gives you something that can actually be investigated, tested, or challenged.

• Define the affected user clearly: Food-delivery users are not one uniform group. Someone ordering lunch from an office, someone comparing restaurants for a family dinner, and someone reordering the same meal have different goals. A redesign becomes more credible when it identifies the specific user situation it is trying to improve.

• Avoid diagnosing problems from screenshots alone: A screen can look complicated while performing extremely well. Conversely, a visually minimal interface can hide serious usability problems. Without behavioral evidence, usability testing, accessibility research, analytics, or another credible source of evidence, the designer should describe conclusions as hypotheses rather than facts.

• Write a measurable problem statement: Instead of saying, “The restaurant page needs a cleaner design,” define something testable: “Users need to compare delivery time, price, rating, and menu choices quickly before deciding whether to open a restaurant.” Now your design decisions have something concrete to respond to.

• Keep the original product’s complexity in view: Swiggy and Zomato are not simple UI galleries. They connect consumers, restaurants, logistics, payments, discovery, advertising, reviews, memberships, and other systems. Swiggy’s FY2024–25 annual report describes food delivery as part of a broader consumer ecosystem, which means a screen-level redesign can easily miss the larger product context.

A Better UX Redesign Starts With a Hypothesis, Not a Screenshot

A useful redesign does not begin with “Here is how I would make this screen better.”

It begins with “I think this particular user problem exists, and here is why.”

That small change completely alters the quality of the portfolio project. You are no longer pretending to know the company's internal data. You are showing how you investigate uncertainty.

• State what you know and what you do not know: You probably do not have access to Swiggy or Zomato's internal conversion data, customer-support logs, experiment results, or product roadmap. Say that. Strong designers understand the difference between evidence and assumption. Transparency makes an independent project more credible, not less.

• Use public evidence where possible: Public product documentation, company engineering posts, accessibility write-ups, interviews, app-store feedback, and observable interface behavior can provide useful context. Zomato has publicly described how it studied review behavior and redesigned review creation and consumption around user needs, demonstrating that apparently simple interface decisions can involve research, data, engineering, and product trade-offs.

• Turn assumptions into testable questions: Instead of claiming that a restaurant page is overwhelming, ask whether users can identify the information they need quickly. Instead of claiming search is broken, investigate whether people can complete representative discovery tasks. A good independent project makes uncertainty visible.

• Build a narrow research question: You do not need to “redesign Swiggy.” That is enormous. Choose one problem: restaurant discovery, repeat ordering, dietary filtering, menu comprehension, checkout clarity, or another specific journey. Narrow scope usually produces deeper thinking and a stronger case study.

• Document competing explanations: Maybe users are not struggling because of layout. Perhaps the issue is unclear labels, missing information, inconsistent content, slow loading, or the decision itself being difficult. Showing that you considered multiple explanations demonstrates product thinking that a before-and-after mockup cannot.

Why “I Made It Cleaner” Is Not Enough for a UX Portfolio

“Cleaner” is one of the most dangerous words in a design portfolio.

Cleaner according to whom?

A designer can reduce elements, increase whitespace, simplify navigation, and produce a beautiful interface. But if those changes remove useful information, increase taps, weaken discoverability, or make comparison harder, the redesign may actually be worse.

• Design is not decoration: Visual hierarchy matters because it helps users understand what deserves attention. Typography, spacing, color, imagery, and layout are tools for communication. A portfolio should explain what information became easier to understand and why that matters to the user journey.

• More whitespace is not automatically better UX: Removing information can make a screen look sophisticated while making decisions harder. On a restaurant page, users may genuinely need price, ratings, delivery estimates, cuisine, offers, dietary information, and menu details. The designer's job is not simply to remove information but to organize it effectively.

• Fewer steps are not automatically better: A shorter flow can create ambiguity or force users to make decisions without enough context. Good interaction design considers cognitive load, error recovery, confidence, and the consequences of each action rather than celebrating a smaller number of screens.

• Consistency has a purpose: Changing components because they look dated can introduce unnecessary inconsistency. A redesign should explain which patterns were standardized and why. This is particularly important in large products where reusable components can affect many journeys simultaneously.

• Accessibility belongs in the redesign conversation: Accessibility is not a decorative checklist added at the end. Swiggy has publicly described research with users with disabilities and changes involving navigation, menu selections, payment, order tracking, and assistive technologies. That is a useful reminder that “better design” includes people who may interact with an interface differently from the designer.

The Missing Ingredient in Most Redesign Portfolios: Constraints

Real design becomes interesting when someone says no.

The engineer says the animation is expensive. The PM says the experiment must ship this month. Legal says the copy needs changing. Marketing wants a promotional element. Analytics shows something unexpected. Users behave differently from what the team expected.

That friction is not a problem with product design. It is product design.

• Technical constraints change solutions: A concept can look perfect in a prototype and become impractical during implementation. Even when you cannot work with engineers on an independent project, you can identify technical assumptions and explain how implementation complexity might influence the final solution.

• Business goals compete with user needs: A food-delivery platform may need to help users discover restaurants while also supporting promotions, advertising, memberships, retention, and order frequency. Swiggy's public materials describe personalization, recommendations, advertisements, memberships, and an integrated consumer platform, illustrating the broader business context behind the interface. 

• Every design choice creates a trade-off: Bigger restaurant images may improve visual appeal while pushing useful comparison information below the fold. More filters may improve control while increasing complexity. A good case study shows the trade-off instead of pretending the final answer has no downside.

• Constraints make your reasoning visible: If you cannot access internal analytics, explain how you would validate the design after launch. If you cannot test with thousands of users, conduct a small usability study and clearly state its limitations. The goal is not to fake real-world conditions. It is to demonstrate how you think under incomplete information.

• Hiring managers explicitly care about constraints: Nielsen Norman Group's portfolio research recommends showing the problem, role, constraints, iterations, research, and reasoning instead of only polished final screens. Its guidance also notes that unrealistic student constraints can make projects less convincing when they resemble fictional exercises rather than real-world work. 

Why Hiring Managers Can See Through a Beautiful Redesign

A portfolio is not an art gallery.

The person reviewing it is trying to answer a practical question: “If I put this person on a real problem, what will they actually do?”

That requires more than visual taste.

• Show the thinking behind the screen: Hiring teams need to understand why the final design exists. A strong case study explains the problem, relevant research, explored directions, rejected ideas, design decisions, and expected outcome. The final UI becomes evidence of a process rather than the entire argument.

• Make your contribution obvious: If you worked with someone else, say what you owned. If you did everything yourself, say so. Ambiguous ownership makes even strong work difficult to evaluate because the reader cannot distinguish your design ability from someone else's contribution.

• Show imperfect work: Early wireframes, failed approaches, discarded flows, usability issues, and revisions can be more informative than another glossy mockup. They reveal how you respond when the first idea does not survive contact with the problem.

• Design the case study for scanning: Recruiters and hiring managers often review multiple portfolios. Nielsen Norman Group recommends making portfolio content scannable and focusing detailed case studies on a small number of strong projects. A long case study is useful only when every section helps the reader understand your decisions.

• Remember who is evaluating you: The first person reviewing a portfolio may not be a designer. NN/g's 2026 discussion with design recruiter Hang Xu specifically highlights that recruiters, founders, and product managers may evaluate candidates before a design specialist does. Your case study therefore needs a clear story, not just design vocabulary.

How to Turn a Swiggy or Zomato Redesign Into a Strong UX Case Study

You do not necessarily need to delete the redesign from your portfolio.

You need to change what the project is trying to prove.

Instead of presenting yourself as the person who “fixed Swiggy,” present yourself as the designer who investigated a specific product question and developed a reasoned concept under clearly stated assumptions.

• Start with the problem, not the homepage: Open with one sentence explaining the user situation you investigated. Then explain why you selected it. This immediately gives the reader something to evaluate and prevents the project from becoming a gallery of redesigned screens.

• Create a research section: Include your methods, sources, participants if you conducted interviews or testing, and important limitations. If you relied on public information and your own observations, say exactly that. Never manufacture research participants or pretend assumptions are validated findings.

• Show the journey from evidence to design: Connect each major design decision to a finding, hypothesis, or requirement. If you changed navigation, explain what prompted it. If you changed information hierarchy, explain which decision users needed to make and how the new structure supports it.

• Include alternatives and trade-offs: Show two or three directions you explored and explain why one survived. This is where your design judgment becomes visible. A recruiter learns much more from “I rejected this because it increased cognitive load” than from another perfect final screen.

• End with validation and next steps: If you tested the prototype, report what happened. If you could not test it, describe the experiment you would run. Include the metrics you would monitor after launch, such as task completion, search refinement, checkout completion, or error rates, without inventing results.

What a Strong Unsolicited Redesign Portfolio Project Should Actually Prove

A redesign should answer a simple question: what does this project prove about you that another pretty interface cannot?

If the answer is “I can make mobile interfaces look modern,” the project has limited value.

If the answer is “I can investigate an ambiguous product problem, make assumptions explicit, explore alternatives, work within constraints, and communicate design decisions,” you have something much stronger.

• Problem framing: The project should demonstrate that you can turn a vague complaint into a specific problem worth solving. Good problem framing prevents designers from jumping into Figma before understanding what they are actually trying to improve.

• Research thinking: Even a lightweight independent study can demonstrate curiosity and discipline. The important part is distinguishing observed behavior, public evidence, assumptions, and personal opinions. This makes your portfolio easier to trust and easier to discuss during interviews.

• Interaction and visual craft: The interface still matters. Typography, spacing, hierarchy, interaction patterns, accessibility, responsive behavior, and visual consistency demonstrate craft. The point is not to minimize visual design. It is to stop visual design from carrying the entire project.

• Product judgment: Strong designers understand that there is rarely one perfect answer. They consider user needs, business objectives, technical feasibility, operational complexity, and measurement. Showing those considerations turns a UI project into a product-design story.

• Communication: A portfolio is itself a design problem. The reader needs to understand your role, problem, process, decisions, outcome, and limitations without hunting through twenty screens. If the case study is confusing, the work can feel confusing too.

The Redesign Mistakes That Quietly Weaken Designer Portfolios

Some portfolio mistakes are obvious.

Others look impressive until someone asks one uncomfortable question: “How do you know?”

That question separates evidence from decoration.

• Inventing user research: Saying “users found this confusing” when you never spoke to users is one of the fastest ways to damage credibility. Use language such as “I hypothesized,” “I observed,” or “I tested” accurately. Your limitations are completely acceptable; fabricated evidence is not.

• Claiming business impact without data: You cannot say your redesign “increased conversions” because you redesigned a checkout screen in Figma. You can explain the metric you would measure and why the proposed change could plausibly affect it. Expected impact and measured impact are different things.

• Treating the original design as obviously bad: Established products have reasons behind many decisions that outsiders cannot see. The designer may not know the technical, commercial, legal, accessibility, or experimentation context. Critique the experience respectfully and frame conclusions according to available evidence.

• Showing too many screens: Twenty-five screens do not automatically demonstrate twenty-five times more skill. If ten screens communicate the entire reasoning clearly, adding fifteen more can dilute the story. Portfolio reviewers need signal, not a Figma file disguised as a case study.

• Making the redesign about personal taste: “I prefer minimal interfaces” is not a product strategy. Explain the user need behind your design choice. Personal taste can influence craft, but it should not pretend to be evidence.

Should You Remove an Unsolicited Swiggy or Zomato Redesign From Your Portfolio?

Not necessarily.

The better question is whether the project demonstrates the kind of designer you want to be hired as.

If it is only a collection of polished screens, it probably should not be one of your strongest case studies. If it contains thoughtful research, clear hypotheses, realistic constraints, iterations, testing, accessibility considerations, and honest limitations, it can become a useful independent project.

• Keep it when it fills a genuine gap: Students and early-career designers may not have access to production products. A carefully framed independent project can demonstrate skills that their current experience does not yet provide. The key is being transparent about its independent nature.

• Rework it when the visuals are stronger than the reasoning: You do not need to throw away months of work. Go backward. Define the problem, identify assumptions, conduct appropriate research, test the important interactions, and rewrite the case study around decisions rather than screens.

• Remove it when stronger evidence exists: If you have a real client project where you solved a meaningful problem, collaborated with others, handled constraints, and learned from actual users, that project may provide more credible evidence. Portfolio space is limited, so every case study should earn its place.

• Keep the project focused: You do not need to redesign the entire product. A narrow study of one meaningful journey can demonstrate more depth than an enormous “complete redesign” covering fifty screens without meaningful evidence.

• Treat independent work as independent work: There is no shame in saying, “This was a self-initiated concept project.” The problem is pretending you had access to information you did not have. Honest framing gives the reviewer the right context for judging your work.

How Does This Connect to Building a Strong Career or Portfolio?

A strong portfolio makes your execution visible. It shows not only what you made, but how you approached uncertainty, constraints, feedback, and decisions. That becomes proof of work rather than a collection of attractive images. Documenting projects carefully also creates material you can discuss in interviews, assignments, and future applications. Platforms such as Fueler are useful in this broader proof-of-work approach because the work itself can become evidence of capability. The goal is simple: make it easier for someone to understand what you can actually do.

Final Thoughts: Stop Redesigning Products, Start Demonstrating Judgment

The problem with unsolicited Swiggy and Zomato redesigns is not that designers redesign popular products.

It is that many projects stop exactly where the interesting design work should begin.

A polished interface shows taste. A well-documented case study shows judgment.

You do not need access to Swiggy's internal roadmap to demonstrate that you can think like a product designer. You need to be honest about what you know, investigate what you can, define your assumptions, respect constraints, and explain your decisions.

The strongest redesign is not the one that makes the original product look worse.

It is the one that makes the designer's thinking impossible to miss.

Frequently Asked Questions About Unsolicited Redesigns and UX Portfolios

Are unsolicited redesigns good for a UX design portfolio?

They can be useful, especially for students and early-career designers, but only when they demonstrate more than visual redesign. A strong project explains the problem, research, assumptions, constraints, alternatives, decisions, validation, and limitations.

Should designers include Swiggy or Zomato redesign projects in their portfolios?

There is no universal rule. They can work as independent UX projects when framed honestly and supported by meaningful reasoning. They become weaker when presented as proof that the designer definitively “fixed” a real product without access to its internal evidence.

What should a UX redesign case study include?

A strong redesign case study should include the problem, target users, research or evidence, hypotheses, constraints, user journey, design exploration, important decisions, iterations, prototype testing, limitations, and proposed success metrics.

How do hiring managers evaluate UX portfolios?

They generally need to understand what problem the designer solved, what role they played, how they reached decisions, and what happened as a result.

Can a self-initiated project prove UX design skills?

Yes, but its claims need to match its evidence. A self-initiated project can demonstrate research, interaction design, visual craft, prototyping, accessibility thinking, and product reasoning. It cannot honestly claim production outcomes or internal business results that were never measured.

Why 100,000+ professionals use Fueler

Fueler helps professionals showcase proof of work through projects, assignments, case studies, and achievements.

• Thousands of professionals use Fueler to create their digital portfolio

• Thousands of projects are published on Fueler. Check here

• Startups and Companies hire through proof of work on Fueler

• Used by freelancers, creators, marketers, video editors, writers, designers, and product managers

Our mission is to help the next 100 million professionals build a verified professional identity through proof of work