UI UX Design Career Options for Students in Ghaziabad

# figma_project_structure.md — the file structure behind a professional Figma project

## Pages

1. **Cover** — project name, date, author, one-line summary
2. **Context** — the problem being solved, user, goals
3. **Research** — interview insights, competitive analysis, personas
4. **Flows** — user journeys and information architecture
5. **Wireframes** — low-fidelity screens (grayscale)
6. **Components** — the design system (buttons, inputs, cards, etc.)
7. **High-fidelity screens** — final UI screens
8. **Prototype** — clickable interactive flows
9. **Handoff** — specs, states, and edge cases for developers

## Component naming

- `Button/Primary/Default`
- `Button/Primary/Hover`
- `Button/Secondary/Default`
- `Input/Text/Default`
- `Input/Text/Error`
- `Card/Product/Compact`
- `Modal/Confirmation`

## Why this structure matters:

- **Recruiters scan portfolios in seconds.** A clear structure communicates professionalism.
- **Developers can find specs quickly.** Better collaboration.
- **Design changes propagate.** Components + variants make iteration fast.
- **The case study becomes easy to write.** Each page maps to a section of the story.

## What separates a good Figma file from an average one:

- Real component variants (not duplicated frames).
- Auto-layout used everywhere (no manually positioned buttons).
- Consistent spacing scale (4, 8, 12, 16, 24, 32, 48, 64).
- Accessibility: contrast ratios, focus states, labeled inputs.
- Clear naming — no "Frame 1234" or "Rectangle 57".

# case_study_outline.md — the structure of a portfolio case study
# The kind of case study that actually gets students interviews.

## 1. Overview (30 seconds to read)
- Product name
- Role and timeline
- One-sentence summary of the problem
- One-sentence summary of the solution

## 2. The Problem
- Who has this problem? (target user)
- What is the current pain?
- Why does it matter to the business?

## 3. Research
- 3–5 user interviews or surveys
- Key insight that reframed the problem
- Competitive analysis highlights

## 4. Design Process
- User flows
- Wireframes (low fidelity)
- 2–3 iterations with rationale

## 5. Final Design
- Screens with annotations
- Key design decisions and trade-offs

## 6. Prototype and Testing
- Clickable prototype link
- 2–3 user testing insights
- What was changed as a result

## 7. Outcomes and Reflection
- What worked, what didn't
- What would you do differently

## Why this structure works:
- Recruiters can scan it in under a minute.
- Interviewers can dig into reasoning.
- It shows process, not just output.
- It demonstrates self-awareness and communication.

## What students often get wrong:
- Only showing final screens.
- Skipping research entirely.
- No mention of trade-offs or constraints.
- Too much decoration, too little reasoning.

// design_tokens.json — the foundation of a real design system
// Tokens keep colors, spacing, and typography consistent across screens.

{
  "color": {
    "primary": { "value": "#ff5126" },
    "primary-hover": { "value": "#e3441c" },
    "surface": { "value": "#ffffff" },
    "surface-muted": { "value": "#f4f7fa" },
    "text-primary": { "value": "#1e2a36" },
    "text-muted": { "value": "#5b6b72" },
    "border": { "value": "#dce4e2" },
    "success": { "value": "#16851d" },
    "warning": { "value": "#e8a317" },
    "error": { "value": "#d63426" }
  },
  "spacing": {
    "xs": { "value": "4px" },
    "sm": { "value": "8px" },
    "md": { "value": "12px" },
    "lg": { "value": "16px" },
    "xl": { "value": "24px" },
    "2xl": { "value": "32px" },
    "3xl": { "value": "48px" },
    "4xl": { "value": "64px" }
  },
  "typography": {
    "font-family-sans": { "value": "Inter, sans-serif" },
    "font-family-mono": { "value": "IBM Plex Mono, monospace" },
    "size-body": { "value": "16px" },
    "size-h1": { "value": "40px" },
    "size-h2": { "value": "28px" },
    "size-h3": { "value": "20px" },
    "line-height-body": { "value": "1.6" }
  },
  "radius": {
    "sm": { "value": "6px" },
    "md": { "value": "12px" },
    "lg": { "value": "20px" }
  }
}

// Why tokens matter:
// - Every screen uses the same scale, so nothing feels off.
// - Designers can change one value and update everything.
// - Developers can map tokens directly to CSS variables.
// - Accessibility contrast is easier to reason about.

// What interviewers look for:
// - Do you have a system, or do you free-hand every screen?
// - Can you scale your design without duplication?
// - Do you think about implementation?