For most design jobs, your portfolio is the first real interview. Before anyone speaks to you, a recruiter or design lead opens your link, often on a phone between meetings, and decides within a short time whether to look deeper. A strong portfolio does not need fancy animations. It needs clear evidence that you can understand a problem, make sensible decisions and explain them.
This guide covers what to include in a UI/UX portfolio, how to structure each case study and the mistakes that commonly get portfolios skipped. If you are just starting out, read how to become a UI/UX designer in India first.
What reviewers are looking for
Different companies weigh things differently, but most reviewers try to answer the same questions:
- Can this person think through a problem? Do they understand users, constraints and goals?
- Can they make and justify decisions? Not just “what” they designed, but “why”.
- Is the visual and interaction quality good enough? Clean layouts, sensible hierarchy, consistent components.
- Can they communicate? Is the case study easy to follow and honest about their role?
- Will they work well with others? Do they mention developers, product managers, feedback and trade-offs?
Every part of your UI/UX portfolio should help answer one of these questions.
Choose the right projects
Quality beats quantity. Two or three well-explained case studies are usually stronger than eight thin ones. Choose projects that:
- Match the kind of role you want (mobile app, SaaS dashboard, e-commerce, websites).
- Show different skills: one research-heavy, one visually polished, one with complex interactions or data.
- Include real users, research or testing, even if small.
- You can talk about confidently for ten to fifteen minutes.
If you have no client work yet, self-initiated projects are fine. Pick a real local problem (a clinic queue, a college event app, a small shop’s ordering flow), talk to real people and test your solution. That is far more convincing than a visual redesign of a famous app with no research.
Watch out: Respect confidentiality. If you show work from a job or client, get permission or remove sensitive details: blur names, change data, and describe the problem without revealing private business information.
A case study structure that works
Use a clear, predictable structure so reviewers can skim. Here is a template:
| Section | What to include | Length |
|---|---|---|
| Title and summary | Project name, one-line description, your role, team, timeline, tools, and the outcome | 3–5 lines |
| The problem | Who the users are, what was going wrong, why it mattered to users and the business | Short paragraph |
| Constraints | Deadlines, technical limits, budget, existing design system | A few bullets |
| Research | What you did (interviews, surveys, analytics, competitor review) and the key insights | Brief, with 2–3 key findings |
| Definition | Problem statement, personas or journey maps (only if they influenced decisions) | Short |
| Exploration | Sketches, wireframes, alternatives you considered and why you rejected them | Visual, with captions |
| Design decisions | The 2–4 most important decisions and the reasoning behind each | The heart of the case study |
| Testing and iteration | What you tested, what you learned, what you changed | Before/after visuals |
| Final design | Key screens, states, components, a prototype link | Visual |
| Outcome and reflection | Results (qualitative or measured), what you would do differently | Short paragraph |
Tip: Put the summary at the top. Many reviewers read only the first screen. If that tells them the problem, your role and the result, they are far more likely to keep reading.
Show decisions, not just deliverables
A common weakness is a case study that lists activities: “I did user interviews. I made personas. I created wireframes.” Reviewers already know what these are. What they want to see is how the activities changed your design.
| Weak | Stronger |
|---|---|
| “I conducted user interviews.” | “Interviews with six patients showed that most called the clinic only to ask about waiting time, so we focused on showing live token status.” |
| “I created a style guide.” | “Older users struggled with small text, so the body size became 16px and key actions use full-width buttons.” |
| “I made a prototype and tested it.” | “In testing, three of five people missed the filter button. Moving it next to the results count fixed this in the second round.” |
Each strong example connects evidence to a decision. Write your case study with that pattern: we learned X, so we did Y, which led to Z.
Be honest about your role and results
- On team projects, say clearly what you did and what others did. Interviewers will ask.
- If you have measured results, share them with context. If not, share qualitative outcomes: what users said, what changed in testing.
- Never invent metrics. A made-up “conversion increased by a large percentage” on a student project is easy to spot and damages trust.
- It is fine to say a project was a concept. Explain what you would need to validate it in the real world.
Presentation tips
Visuals
- Show screens at a readable size. Tiny screens inside elaborate device mock-ups are hard to see.
- Add short captions to every image explaining what to notice.
- Include messy work too: sketches, whiteboards, early wireframes. They show process.
- Show states: empty, loading, error and success, not only the happy path.
Writing
- Use headings, short paragraphs and bullet points so people can scan.
- Cut jargon. Write as if explaining to a smart friend outside design.
- Proofread. Spelling mistakes suggest a lack of attention to detail, which is a core design skill.
Website and format
- A simple personal site, a portfolio platform or a clean PDF can all work. What matters is clarity and speed.
- Make sure it works well on a phone and loads quickly. Compress images; see Core Web Vitals for designers.
- Check accessibility basics: text contrast, alt text for key images, readable font sizes (see web accessibility basics).
- Avoid password-protecting everything. If some work must be private, offer to walk through it in an interview.
- Include a short “About” section and easy contact details.
If you can build your own site in HTML and CSS, it doubles as proof of front-end skills. Our HTML and CSS tracks can help.
Common UI/UX portfolio mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Only Dribbble-style visuals | No evidence of thinking | Add problem, research and decisions |
| Very long case studies with no summary | Reviewers give up before the good part | Lead with a summary; trim repetition |
| Personas and journey maps that change nothing | Feels like box-ticking | Show how each artefact influenced a decision |
| Copied UI kits or tutorial projects | Easy to recognise; shows little originality | Use them for practice, not as portfolio pieces |
| Broken links and slow pages | Signals carelessness | Test every link on mobile before sending |
| Too many projects | Weak ones dilute strong ones | Keep your best two to four |
Preparing to present your portfolio
Many interviews include a portfolio walkthrough. Prepare one project to present in about ten to fifteen minutes. Practise out loud. Focus on the problem, your key decisions and what you learned, and be ready for questions such as “What would you do differently?” or “How did you handle disagreement?”. Our list of UI/UX interview questions will help you prepare.
Final UI/UX portfolio checklist
- Two to four case studies relevant to the roles I am applying for.
- Each starts with a summary: problem, my role, timeline, outcome.
- Each shows research or evidence and connects it to decisions.
- Process visuals (sketches, wireframes) as well as final screens.
- Honest about team contributions and results; no invented numbers.
- Readable on mobile, fast to load, all links working.
- Proofread, with clear contact details.
- I can present one project confidently in fifteen minutes.
Frequently asked questions
How many projects should a UI/UX portfolio have?
Two to four strong case studies are usually enough. Choose quality and relevance over quantity, and remove weaker projects that distract from your best work.
Can I include personal or concept projects?
Yes, especially early in your career. Make them realistic: research a real problem, talk to real users, test your designs and clearly label the project as self-initiated.
Should my portfolio be a website or a PDF?
Either can work. A website is easy to share and can show front-end skills; a PDF is useful for email applications. Many designers keep both. Make sure whichever you use is quick to load and easy to read on a phone.
What if my work is under NDA?
Ask for permission, or anonymise the project by removing names, changing data and focusing on your process. Alternatively, describe the problem and approach in general terms and offer a private walkthrough during interviews.
Do I need to show metrics in every case study?
No. Show measured results when you have them and can share them. Otherwise, describe qualitative outcomes, such as improvements observed in usability testing. Never make up numbers.
