Free Checklist · Indian School of Skills

UI/UX Portfolio Review Checklist

Last reviewed: September 2026

Reviewers often decide in the first minute whether to read a case study properly. This checklist helps you fix what they see first, then what they check when they read closely. Tick each item honestly; anything unticked is your to-do list.

Tip: ask a friend who is not a designer to open your portfolio on their phone and tell you, after 60 seconds, what you do and what problem one project solved. If they can't, start with sections A and B.

A. First impression (the 60-second skim) — 8 points

  • The top of the home page says what you do and the kind of role you want (e.g. "Product designer focused on fintech and research-led UX").
  • Two to four case studies are featured, your strongest first. More is not better.
  • Each project card shows a clear title, the problem in one line, and your role.
  • Thumbnails show real interface work, not just mock-up devices or stock images.
  • The site loads quickly and works on a phone (many first looks happen on mobile).
  • No broken links, "lorem ipsum", or unfinished pages.
  • Contact details, LinkedIn and a résumé link are one click away.
  • The URL is simple and professional (a custom domain or a clean Behance/Framer/Notion/Webflow link).

B. Case-study structure — 12 points

  • Opens with a short summary: problem, your role, team, timeline, tools and the outcome.
  • States who the users are and what they were trying to do.
  • Explains why the problem mattered (to users and to the business).
  • Shows the research you did and what you learned from it, not only the methods' names.
  • Includes at least one insight that changed your direction.
  • Shows how you explored options (sketches, flows, alternatives) before the final UI.
  • Explains the key design decisions and the trade-offs behind them.
  • Shows testing: what you tested, with whom, what broke, and what you changed.
  • Presents final screens with annotations that point at the decisions, not just pretty mock-ups.
  • Ends with outcomes: metrics if real, otherwise qualitative results and what you would measure.
  • Includes a short "what I'd do next / what I learned" reflection.
  • Is honest about scope: concept or self-initiated projects are labelled as such.

C. Visual and interaction quality — 8 points

  • Consistent spacing system (e.g. multiples of 4 or 8) across screens.
  • A clear type scale with limited sizes and weights.
  • Colour contrast passes WCAG AA for text (check with a contrast checker plugin).
  • Components look and behave consistently (buttons, inputs, cards).
  • Empty, loading and error states are designed for at least one key flow.
  • Touch targets on mobile designs are comfortably tappable (around 44×44 px or more).
  • Screens use realistic content (real-length names, prices, Indian formats where relevant).
  • At least one interactive prototype link works without special permissions.

D. Writing — 6 points

  • Short paragraphs and scannable headings; a reviewer can follow the story from headings alone.
  • Uses "I" for your own work and "we" only for genuine team work, with your part stated.
  • No jargon for its own sake ("leveraged synergistic user-centric paradigms").
  • Spelling and grammar checked (run it through a checker, then read it aloud).
  • Numbers are specific and sourced ("5 interviews with first-time investors", not "extensive research").
  • Each case study can be read in under 5 minutes; appendices hold the rest.

E. Figma file hygiene (if you share files) — 6 points

  • Pages are named and ordered (Cover, Research, Flows, Wireframes, UI, Prototype, Archive).
  • Frames and layers are named; no "Frame 1043" in shared views.
  • Components and variants are used for repeated elements.
  • Auto layout is used where content can change length.
  • Colour and text styles (or variables) are defined, not hard-coded values everywhere.
  • Share links are set to "can view" and tested in a logged-out browser.

Common reasons portfolios get passed over

  • Only UI "shots" with no problem, process or reasoning.
  • Every project is a redesign of a famous app with no access to its users or constraints.
  • Process shown as a template (empathise → define → ideate…) with no evidence behind each step.
  • Too many projects of uneven quality; the weakest one lowers the impression of the rest.
  • Case studies that are very long walls of text or, the opposite, images without any explanation.
  • Group bootcamp projects where the candidate's own contribution is unclear.

Six starter project briefs

If you need stronger work, pick one or two briefs, talk to at least five real users, and ship a tested prototype. Local, specific problems make better case studies than global app redesigns.

  1. Clinic appointment booking for a neighbourhood clinic: patients who book for elderly parents, reminders, rescheduling, and the receptionist's side.
  2. Society maintenance and complaints app: residents raising issues, committee tracking, payment reminders. Interview residents and a committee member.
  3. First-time mutual fund investor onboarding: reduce drop-off during KYC and the first SIP set-up. Focus on trust and plain language.
  4. Regional-language grocery ordering for older users: test with people who prefer Hindi or another regional language.
  5. College placement cell dashboard: how students track applications and how coordinators share updates. A good B2B / dashboard project.
  6. Accessibility audit and fix of an existing public website or app flow: document issues against WCAG and redesign two screens.

Want structured feedback on this?

The ISS UI/UX Design program is a live online cohort where mentors critique the projects you build. Talk to an advisor to see whether it fits your goals, or explore the curriculum first.