Skip to content
Design Academy My progress

Career

Portfolio, interviews and first jobs.

How to turn your projects into a portfolio that shows how you think, prepare for interviews and design challenges, and work with clients. Practical checklists, no shortcuts promised.

An honest starting point

Junior design roles are competitive in many regions, and the number of openings changes with the economy. Nobody can promise a job after any course, including this one. What you can control is the quality of your evidence: two or three case studies that show clear reasoning, a tidy portfolio, and the ability to talk about your decisions calmly.

Widen your search beyond the exact title "UX designer". Many designers start in adjacent roles: UI designer at an agency, design assistant, content or UX writer, research assistant, front-end developer with design duties, or a designer inside a non-tech organisation such as a hospital, university or council. Those roles build real experience and count on your CV.

Choosing portfolio projects

Reviewers spend a few minutes on a portfolio. Two or three strong case studies beat eight thin ones. Choose projects that together show:

  • Problem framing: you found or sharpened a real problem rather than receiving a finished brief.
  • Evidence: you spoke to or observed real people, even only five.
  • Range: for example one responsive website, one mobile app and one data-heavy product.
  • Iteration: at least one project where testing changed your design.
  • Craft: polished, consistent final UI with all important states.

Avoid redesigning famous apps with no access to their users, constraints or data. These "unsolicited redesigns" are common, rarely convincing, and can come across as naive about the real constraints. If you do one, frame it honestly as a learning exercise and focus on a narrow, testable problem.

Good sources of real projects: a local business or charity, a club or society, a tool your current workplace uses (with permission), or the four guided projects in this academy, which ask you to do real research.

Structuring a case study

A case study is a short story about a decision process. Use a structure reviewers can skim:

  1. Summary (top of the page): one sentence on the problem, one on what you did, one on the outcome. Your role, the team, the timeline and the tools.
  2. Context: who the users are, what the business or organisation needed, and the constraints.
  3. Problem: what was going wrong and how you know. Include your problem statement.
  4. Research and insights: what you did, with whom, and the two or three insights that shaped the design. Quote people where you have permission.
  5. Exploration: the options you considered, including the ones you rejected and why.
  6. Design: the final solution, shown with annotated screens that explain decisions.
  7. Testing and iteration: what you tested, what you learned, what you changed.
  8. Outcome and reflection: results you can honestly claim, what you would do next, and what you learned.

The case study outline template turns this into a fill-in document.

Writing concise, honest case studies

  • Lead with the point. Each section starts with its conclusion, then the detail.
  • Use real numbers or none. "Three of five participants could not find the delivery fee" is strong. Invented percentages are dishonest and experienced reviewers notice.
  • Say "I" and "we" accurately. Be specific about what you did yourself in a team project.
  • Annotate images. A screenshot without explanation is decoration. Add a short caption explaining the decision it shows.
  • Cut process theatre. Do not include every artefact. Include the ones that changed a decision.
  • Aim for five to ten minutes of reading. Most reviewers will skim; headings and captions should tell the story on their own.
  • Protect confidentiality. Remove client names, real customer data and anything under a non-disclosure agreement. Ask permission before publishing client work.

Portfolio website structure

A simple structure works best:

  • Home: one sentence about who you are and what you design, then your two or three case studies as large, clearly labelled cards.
  • Case study pages: one per project, using the structure above.
  • About: a short, human paragraph, your background (including previous careers), and what kind of role you want.
  • Contact: email, LinkedIn and a downloadable CV. Make it work without a form.

Practical checks before you share it: it loads quickly on a phone, text is readable, images have alt text, links work, there are no placeholder pages, and it passes your own accessibility audit. A plain site built with a website builder is fine; the content matters far more than the platform.

Resume and professional profile

  • Keep it to one page if you have under ten years of experience.
  • Use a simple single-column layout with real text so applicant tracking systems can read it. Save fancy layouts for your portfolio.
  • Put a link to your portfolio at the top, next to your contact details.
  • Describe impact, not duties: "Redesigned the volunteer sign-up form; completion went from 4 to 9 of 10 test participants" rather than "Responsible for forms".
  • Include relevant earlier careers with the design-relevant parts highlighted: customer insight, writing, training, analysis, coding.
  • Keep your professional profile (for example LinkedIn) consistent with the CV, with a headline that names the role you want.

Presenting your work in interviews

Many design interviews include a portfolio presentation of 30 to 45 minutes for one or two projects. A reliable structure for each project:

  1. Set the scene (2 minutes): the product, the users, your role and the problem.
  2. The key insight (3 minutes): what you learned that changed the direction.
  3. Exploration and decisions (5 to 8 minutes): options, trade-offs and why you chose one.
  4. The solution (5 minutes): walk through the final design as a user would.
  5. Results and reflection (3 minutes): what happened, what you would change.

Rehearse aloud with a timer. Prepare for "What would you do differently?", "How did you handle disagreement?" and "How did you know it worked?". It is fine to say "I don't know, but here is how I would find out".

Whiteboard exercises and design challenges

Live challenges test your process, not your drawing. A typical 45-minute challenge might be "Design a way for patients to reschedule appointments". A dependable approach:

  1. Clarify (5 to 8 minutes): ask who the users are, what the goal is, what constraints exist and how success would be measured. Write your assumptions down where the interviewer can see them.
  2. Frame (5 minutes): pick one primary user and one primary task. Say why.
  3. Explore (10 minutes): sketch two or three different approaches quickly.
  4. Choose and detail (15 minutes): pick one, explain the trade-off, and sketch the key screens including an error or empty state.
  5. Validate (5 minutes): explain how you would test it and what you would measure.

Think aloud throughout. Interviewers want to see how you reason and collaborate. For take-home challenges, respect your own time: agree a time limit, note what you would do with more time, and decline challenges that look like unpaid client work.

Common interview questions to prepare

  • Walk me through a project you are proud of.
  • Tell me about a time research changed your mind.
  • How do you decide what to work on when everything feels important?
  • Tell me about a disagreement with an engineer or product manager and how it ended.
  • How do you make sure your designs are accessible?
  • How do you know whether a design was successful after launch?
  • What feedback have you received that changed how you work?
  • Why this company and this role?

Prepare short stories using situation, task, action and result. Have one example ready for collaboration, one for failure and one for research.

Giving and receiving critique

When receiving: state the goal and what kind of feedback you want ("Is the hierarchy clear?" rather than "Thoughts?"). Listen, write it down, ask clarifying questions, and decide later. You do not have to accept every suggestion, but you should understand it.

When giving: start from the goal, describe what you observe and its likely effect on users, and suggest rather than dictate. "The two buttons look equally important, so people may hesitate at checkout. Could the secondary action be a text link?" is useful. "I don't like it" is not. Use the design critique worksheet to structure sessions.

Freelancing, clients and project scope

Freelance work is a valid path into design, and it teaches client communication fast. The most common problems come from unclear scope.

  • Write a short proposal before starting: the problem, goals, what is included, what is not, deliverables, timeline, number of revision rounds, price and payment terms.
  • Define a revision round: for example, one consolidated set of feedback from the client within five working days.
  • Handle change requests in writing: "Happy to add the booking page. It is outside our current scope; it would add about three days and the following cost. Shall I update the proposal?"
  • Collect feedback in one place and ask clients to describe problems ("customers can't find prices") rather than solutions ("make it blue").
  • Get permission before showing client work in your portfolio, and agree what can be shared.

Pricing and contracts vary by country and are legal matters; use local freelancer associations and professional advice rather than templates copied from elsewhere.

A continuing learning plan

After the core curriculum, pick one specialism from Stage 12 that matches the jobs you want, and keep a light routine:

  • One small practice exercise a week from the practice library.
  • One real conversation with a user, client or designer a month.
  • Read one long-form article or chapter a week from the resource library.
  • Update your practice log and refresh one case study each quarter.
  • Join a community or critique group, online or local, and give feedback as often as you receive it.

Stage 11: Portfolio and career readiness ยท Case study template