Start with the work current product-design internships actually ask students to do
Current internship postings give you a better preparation target than a generic learn-Figma checklist. Intuit’s Summer 2027 Product Design internship asks interns to create UI components, wireframes, visual layouts and interactive prototypes, understand customer problems with cross-functional partners, prototype rapidly to test assumptions, gather data, use design systems and take part in design reviews. Its qualifications explicitly ask for an online portfolio that shows both design quality and creative process.
| Current posting | Work the employer names | Evidence you can practice before holding the title | Sources |
|---|---|---|---|
| Intuit — Summer 2027 Product Design Intern | Customer-problem understanding, UI components, wireframes, visual layouts, interactive prototypes, design systems, rapid iteration, feedback and cross-functional work | A case study with a real task, research notes, flow, prototype, usability evidence, revision and rationale | |
| Roblox — Summer 2027 Product Design Intern | Accessible workflows, user and ecosystem understanding, prototypes, competitive analysis, user research, storytelling and refinement from feedback | A narrow workflow where you can explain the user, constraint, alternatives, prototype and what changed after testing |
Roblox’s Summer 2027 Product Design internship similarly names user research, competitive analysis, prototyping, accessible workflows, data-supported solutions, storytelling and refinement through feedback. Those are useful practice targets. They are not evidence that every product-design employer uses the same degree, portfolio, visa or interview rules.
Neither reviewed posting says you must already have completed a prior product-design internship. That does not mean no experience is required across the market. It means a student without the title can build evidence around the work itself and then read each posting for its own hard requirements.
Choose one failed task, not a broad redesign prompt
The easiest first project is usually a workflow you can observe yourself. A student organization has a confusing event-registration flow. A tutoring group loses appointment requests. A lab has an equipment-booking process that new members misunderstand. A small business repeatedly answers the same checkout or scheduling question. Those are better starting points than redesigning a famous app because you can reach the people experiencing the problem.
Write the task in one sentence: who is trying to do what, where do they get stuck, and what would a better outcome look like? Then list the assumptions that could make your idea wrong. Talk with or observe people who actually perform the task before you settle on a screen solution.
A speculative redesign can still be useful practice. Label it as speculative, make clear which evidence came from real users, and do not imply the company requested, approved or shipped the work.
Pick the project route that gives you real feedback, not the fanciest mockup
A campus or community workflow is often the strongest first route because the users are nearby and the current process is visible. A class or research project can work when you actually made interface, workflow or interaction decisions. A hackathon or small shipped tool can work when your design contribution is separable from the code. A speculative product redesign can work when you test a concrete task with real users instead of basing the case only on taste.
| Route | Strong evidence | Weak version to avoid |
|---|---|---|
| Campus, club or community workflow | Observed task failure, user conversations, current-state flow, alternatives, prototype, test and revision | Calling routine club administration product design without a design decision |
| Class or research project | Your exact design ownership, constraints, prototype or interface work, feedback and iteration | Relabeling a group assignment as client work |
| Hackathon or small shipped tool | User problem, your design contribution, scope choice, states, handoff or build, test and post-event fixes | Showing only final screens and a team prize |
| Speculative redesign | Clearly labeled concept, real-user evidence where available, alternatives, prototype test and limits | Pretending the company was a client or claiming unmeasured business impact |
You do not need every project to ship. You do need to label the state accurately. A Figma prototype is a prototype. A concept shown to five people is a usability test, not a production launch. A club workflow adopted by 40 members can support adoption claims if you can verify that use. A predicted conversion lift is not an observed result.
Choose one route you can finish. One complete case with evidence and revisions creates better interview material than four polished homepages with no explanation of the problem or decision.
A two-week design evidence sprint can produce one defensible case study
This is a suggested scope, not an employer requirement. Days 1–2: choose one user and one task, map the current flow and write down the assumptions you need to test. Days 3–4: interview or observe roughly four to six relevant users if you can reach them. Day 5: group the evidence and choose one failure point worth addressing.
Day 6: sketch at least three responses, including a process change or doing nothing. Day 7: choose one flow and define what a successful test would look like. Days 8–9: make wireframes and an interactive prototype with the important loading, empty, error or recovery states that affect the task. Days 10–11: run a usability test with several relevant users and record where they hesitate, fail or take an unexpected path.
Day 12: revise the design based on the evidence. Day 13: document accessibility considerations, edge cases and implementation constraints you can explain. Day 14: publish the case study with the original problem, research, alternatives, selected direction, prototype, test evidence, revision and remaining limitations. If you never shipped the design, say so.
Make the portfolio show the decision trail, not a wall of process artifacts
A reviewer should be able to answer eight questions quickly: Who had the problem? What task were they trying to complete? What evidence did you collect? What constraints mattered? Which alternatives did you consider? Why did you choose this direction? What happened when people tested it? What changed afterward?
Show artifacts only when they support one of those questions. A short current-state flow can explain where the problem occurs. A small research summary can justify the priority. A few alternative sketches can prove you considered more than one answer. The prototype and test notes can show whether the interaction worked. The revision should make clear which evidence changed the design.
Intuit’s current internship asks for an online portfolio that shows design excellence and creative process. That makes the reasoning visible; it does not require turning every class exercise into a twenty-slide case study. Keep the main story scannable and link deeper artifacts only when they add evidence.
Sources[1]
Label the work truthfully, then apply before the portfolio feels finished
Use the real project context: Independent product design project, Student organization design project, the class name, hackathon name or actual job title. Do not call yourself a Product Design Intern if there was no employer and no internship. Do not call a prototype shipped. Keep proposed metrics separate from observed outcomes.
A useful resume structure is: Interviewed or observed [number] [user group] completing [task]; mapped [workflow]; prototyped [scope]; tested with [number] users; revised [specific interaction] after [finding]. Use only the clauses you can support. If the strongest result is qualitative, report it as a finding rather than inventing a percentage.
Start applying once you can explain one complete case without hiding its limits. Current employers vary: Intuit requires an online portfolio and lists design and prototyping skills; Roblox requires relevant design study and names a specific set of design interests and work. Read each posting independently, lead with the case that best matches its work, and keep improving the portfolio while applications are moving.