UI/UX Designer Portfolio Tips for Beginners 2026

# Case study template — the structure that works
# for beginner UI/UX portfolios.

## 1. Title & one-line summary
"A redesign of a college portal to reduce
assignment-tracking confusion for first-year students."

## 2. Role & scope
- Role: Solo designer (research, IA, UI, testing)
- Duration: 3 weeks, part-time
- Tools: Figma, Maze, Google Forms

## 3. The problem (1 paragraph)
Students in years 1–2 struggle to track assignment
deadlines across 4 different screens and miss
submissions. I wanted to reduce missed submissions
by making deadlines visible from a single screen.

## 4. Research (short, specific)
- 6 interviews with first-year students
- 12 survey responses
- 3 usability tests on the current portal
Key insight: deadlines were technically present but
not "visible" — hidden behind a menu most students
never opened.

## 5. Design decisions (with trade-offs)
- Moved deadlines to the dashboard
- Replaced 4 nested menus with a single visible list
- Trade-off: some information density lost on mobile;
  solved with a compact card layout

## 6. Final design (screens + rationale)
Each screen has a one-line reason next to it.

## 7. Validation (what you tested)
- 3 usability tests on the prototype
- Task completion time halved on the "find a deadline" task

## 8. Reflection (what you'd do next)
- Would test with 3rd/4th year students
- Would add push notifications (out of scope here)

# What this proves to a hiring manager:
# - You can frame a real problem
# - You did real research, not just assumptions
# - You can defend design decisions with trade-offs
# - You can close the loop with testing
# - You can reflect honestly

# That is the portfolio. The screens are the evidence,
# not the point.

// Figma design tokens — the pattern that makes a
// design system credible in a portfolio.

// Tokens are just named values. Show them clearly
// in your case study so hiring managers know you
// think in systems.

{
  "color": {
    "primary": {
      "500": "#0B6E75",
      "700": "#0A5A61"
    },
    "neutral": {
      "100": "#F1F4F3",
      "500": "#8A9398",
      "900": "#1E2A36"
    },
    "danger": {
      "500": "#D94848"
    }
  },
  "space": {
    "xs": "4px",
    "sm": "8px",
    "md": "16px",
    "lg": "24px",
    "xl": "32px"
  },
  "radius": {
    "sm": "4px",
    "md": "8px",
    "full": "999px"
  },
  "font": {
    "family": "Inter",
    "size": {
      "body": "16px",
      "h2": "24px",
      "h1": "32px"
    }
  }
}

// What this proves in a portfolio case study:
// - You think in reusable patterns, not one-off screens
// - You can name and document your decisions
// - Your design system is a system, not a grid of components
// - A developer could implement this
//
// For a "design system" case study, always include:
// - The token values (like above)
// - One component with variants
// - A brief explanation of when to use which variant
// - Screenshot of the component in use in the product

# Accessibility checklist — the section hiring managers
# now actively scan for in UI/UX portfolios.

# Put a short version of this in your case study as
# "Accessibility considerations".

## Contrast
[ ] Text meets WCAG AA (4.5:1 for body, 3:1 for large)
[ ] Non-text UI (icons, borders) meets 3:1
[ ] States (hover, focus, error) are visible, not
    only colour-based

## Keyboard
[ ] Tab order follows reading order
[ ] Focus ring is visible on every interactive element
[ ] All interactive elements reachable by keyboard
[ ] Modals trap focus and return it on close

## Screen reader
[ ] Every image has alt text (decorative images marked alt="")
[ ] Form fields have labels (visible, not just placeholder)
[ ] Errors are announced (aria-live or aria-describedby)
[ ] Headings follow a logical h1 → h2 → h3 order

## Motion
[ ] Animations respect prefers-reduced-motion
[ ] Nothing flashes more than 3 times per second
[ ] Scroll is not hijacked

## Content
[ ] No emoji-only labels for screen reader users
[ ] Link text is meaningful ("View assignment details",
    not "Click here")

# What this proves in a portfolio:
# - You know accessibility is design, not an add-on
# - You can talk about it concretely, not vaguely
# - You check real standards (WCAG), not vibes
# - You can defend your design decisions to a mixed team

# For many junior roles, showing this checklist with
# a few concrete decisions is enough to stand out.