Concept Redesigns That Actually Impress

A good concept redesign can be one of the strongest pieces in a portfolio. It’s often the only place where you show what you can do with no difficult client, no outdated brand guide and no NDA hiding the result. We’ve even suggested concept work ourselves, for designers whose client projects don’t reflect their real level.

The catch: without access to the product team, real users or real metrics, you have to prove your thinking differently. Here’s how to make a concept redesign that a reviewer reads to the end, instead of scrolling past.

Start with a problem, not a product

The weakest concept redesigns start with "I like this app, let me make it prettier." The strongest start with "this app has a real problem, and here’s how I’d solve it." Tips for choosing:

• Pick something you actually use. You’ll know the real frustrations, not imagined ones.
• Avoid the obvious giants. Redesigning Instagram or Airbnb invites comparison with teams of hundreds. A niche app, a local service or a clunky government site gives you more room and more credibility.
• Choose a product with visible pain. Low ratings, angry reviews, confusing flows. Our own client redesigns started exactly there: a trading card scanner users found hard to navigate, a cleaner app that kept getting rejected by Apple for looking like every other cleaner.
• Narrow the scope. Don’t redesign the whole product. Pick one flow: onboarding, checkout, search, booking. One problem solved deeply beats an entire app reskinned.
• Match the job you want. Applying for fintech roles? Redesign a banking flow. Want to design iOS apps? Make it a native iOS case.

Write the problem in one sentence before you open Figma. If you can’t, you don’t have a case study yet.

Research without access to the team

You don’t have analytics, a research team or a product manager. You still have more evidence than you think.

• App Store and Google Play reviews. A goldmine. Read the one- to three-star reviews, group the complaints into themes and count them. "34 of 100 recent negative reviews mention not finding the scan history" is real evidence.
• Social media and forums. Reddit threads, support complaints on X, community groups. People describe their frustrations in detail when they think nobody from the company is listening.
• Competitor analysis. How do three or four competitors solve the same flow? What do they do better, and what do they all get wrong?
• Your own usability tests. Ask five people to complete one task in the current product while thinking out loud. Note where they hesitate, misclick or give up. Five sessions are enough to spot the biggest problems.
• A heuristic review. Walk through the flow against basic usability principles: clear feedback, consistent patterns, error prevention, readable hierarchy.
• Platform guidelines. For mobile apps, check where the product ignores Apple’s or Google’s conventions. That’s often where users get lost.

Document it all in the case study. Research is what turns a pretty concept into a credible one.

Show the thinking, not just the after

A before/after slider is not a case study. Reviewers want to know why every change happened. A structure that works:

1. The problem. One clear sentence, backed by your research.
2. What you found. The key insights, with evidence: review quotes, test observations, competitor patterns.
3. Options you considered. Show two or three directions and why you picked one. This is where your judgment becomes visible.
4. The solution. Before and after, side by side, with short notes pointing at each change and the reason behind it.
5. Edge cases and states. Empty screens, errors, loading. They show you think like someone who ships, not just someone who decorates.
6. What you’d do next. More research, more flows, what you’d test.

And respect reality. A real product has constraints: technical limits, business goals, existing users who hate change. Mention them. A redesign that pretends the company has unlimited budget and no legacy reads like a student project. One that says "I kept the existing navigation so current users wouldn’t need to relearn the app" reads like a senior designer.

No real metrics? Show these instead

The biggest temptation in a concept case is to invent results. "Conversion +47%" on a product you never shipped fools nobody, and it makes reviewers doubt everything else in your portfolio. Here’s what you can show honestly:

• Hypotheses. "If users can see scan history from the home screen, fewer will complain they can’t find past scans." A clear hypothesis shows you think in outcomes.
• Your own test results. Test the old and the new version with the same five people. "Task completion went from 2 of 5 to 5 of 5, and average time dropped from 48 to 19 seconds" is real data, even if it’s small. Say how you got it.
• Fewer steps, fewer taps. Count the steps in the old flow and the new one. Concrete, verifiable, and easy for a reviewer to check.
• Accessibility improvements. Contrast ratios that now pass, larger touch targets, clearer labels. Measurable without any access to analytics.
• How you’d measure success. Which metrics you’d track if this shipped, and why. Activation rate, task success, support tickets, review ratings. This shows you understand how products are judged in the real world.

Small, honest numbers beat big, invented ones every time.

The honesty rules

Concept work is completely normal, and we value it. What damages trust is pretending it’s something else.

• Label it clearly. "Concept redesign, not affiliated with [company]" at the top of the case. Never imply the company hired you.
• Don’t fake results. As above: no invented conversion rates, no made-up user counts.
• Credit what you used. Icons, illustrations, UI kits, AI-generated images. Say where they came from.
• Be fair to the original team. They had constraints you can’t see. Criticize the design, not the people. "The checkout hides the total until the last step" is fine. "Whoever designed this had no idea what they were doing" is not.
• Be careful with brands. Use the product name and screenshots for critique and context, but don’t present your concept as an official new version of their brand.

An honest concept says: here’s a real problem, here’s how I’d solve it, here’s what I’d want to test. That’s exactly what a hiring team wants to see.