Design Iterations in a Portfolio: How to Show Them

Show two or three meaningful iterations per case study. For each one, give the evidence that prompted the change, a before-and-after view, and the result. Hiring managers read iterations as proof of how you think, so a short, well-explained sequence beats a long gallery of screens with no context.

This guide covers what counts as an iteration, how many to include, a repeatable format for each one, and what to do when the work is confidential or never shipped. It also covers how to gather the proof before you sit down to write, which is where most designers get stuck on a blank page.

Alloquy

alloquy.app

Show the Evidence Behind Your Work

Turn project files, notes, and other real deliverables into a shareable portfolio that gives context to the work behind your design iterations.

See a live portfolio

Key Takeaways

An iteration is a documented change: what prompted it, what you changed, and what happened next. A new version of a screen with no reasoning is just a screenshot.
Choose representative iterations, not every version. Two or three explained changes tell the story better than ten polished screens.
Include at least one rejected direction and the version just before the final design, so reviewers can see real decision-making.
Label every outcome honestly (shipped, tested, proposed, estimated, or confidential). A precise limitation is more credible than a claim nobody can check.
Collect your artifacts (sketches, test notes, decks, spreadsheets) while you work, so each iteration can point to real evidence.

What hiring managers mean by design iterations
How many iterations to show
A repeatable format for each iteration
Where iterations sit inside a case study
Collect the evidence while you work
When the work is confidential or never shipped
Mistakes that make iterations unconvincing
Examples across career stages
Our perspective on proving iterations
Put your iterations in an interactive portfolio
FAQ
Sources

What hiring managers mean by design iterations

Showing iterations means showing process, not only the final interface. Nielsen Norman Group says hiring managers want to see the research and early work behind the polished result: early sketches, research documentation, the changes from one iteration to the next, how research shaped the design, and concepts you did not pursue.

The UX Design Institute goes further. It calls the process and iterations section the most important part of a case study, because it shows how you make decisions and respond to setbacks. Constraints, compromises and dead ends help a reviewer understand how you handle adversity.

A plain definition helps here. An iteration is one loop of this cycle:

You make something (a sketch, wireframe or prototype).
You put it in front of evidence (a user test, stakeholder feedback, analytics, an engineering constraint).
You change it because of what you learned.

If step 2 is missing, you have a revision, not an iteration. Reviewers can tell the difference quickly.

How many iterations to show

You cannot include every document from every round. The UX Design Institute advises choosing representative examples that give a hiring manager an idea of how the project progressed.

A practical rule for most case studies:

Two or three explained iterations. Pick the changes that moved the project most.
One rejected direction. Show an idea you abandoned and why. Designer Lucas Rappart argues that portfolios that look 100% polished raise a flag, because real product work involves rejected concepts and ugly first drafts. He suggests one rejected direction per project, plus the iteration just before the final.
The final design, last. It should read as the result of the earlier decisions, not as a separate gallery.

Coursera recommends three to five in-depth case studies in a UX portfolio, each including iterations such as sketches, wireframes, and low- and high-fidelity prototypes. That means a full portfolio might hold roughly nine to fifteen documented iterations in total. Each one needs to earn its place.

Two terms worth defining: a wireframe is a simple layout sketch of a screen without visual styling, and a prototype is a clickable or interactive mock-up. Low-fidelity versions are rough and fast. High-fidelity versions look close to the finished product.

A repeatable format for each iteration

The UK Department for Education publishes a template for documenting iterations in its design history. It is built for government service teams, but it works well in a portfolio. Adapt it into five short blocks:

Background. One or two sentences of context. What was this screen or flow for?
What prompted the change. Give specific evidence. The template’s own example is a count such as four out of six users struggling with a task, which is far stronger than “users found it confusing.”
What changed. Show before and after, as screenshots or a short description.
What happened when you tested it. Share the result, even if it was mixed.
Next steps. Say what you would do or did do next.

Keep each block to a few lines. The visuals carry most of the weight.

A worked example (hypothetical)

This is an illustration of the format, not a real project. Imagine a designer working on a meal-planning app’s signup flow.

Background: The signup flow asked for dietary preferences on five separate screens.
Prompt: In a round of moderated tests with six participants, four abandoned the flow on the third preference screen and said they expected to set preferences later.
Change: Version 2 cut the flow to one screen of required choices, with the rest moved into a skippable checklist after signup.
Test result: In the next round, five of six participants finished signup. Two did not notice the checklist.
Next step: Version 3 added a reminder card on the home screen.

Three short iterations, each tied to evidence. A reviewer learns how the designer weighs feedback, without reading a single paragraph of theory.

Where iterations sit inside a case study

Most published structures place iterations in the middle, between research and the final solution. The sources differ in names but agree on the order.

Source	Section where iterations live	Surrounding sections
UX Design Institute	Process and iterations	Introduction, problem, users, final design solution, results and takeaways
Interaction Design Foundation	Prototyping and iteration	Hook, research, sketches and wireframing, outcomes and lessons learned
Nielsen Norman Group	How you came to the solution, plus challenges and concepts not pursued	Problem, your role, how the solution solved the problem, user and business impact, what you learned
OpenTable Design	Iterations on the design work	User problem, business goals, research, sketching, final shipped work, impact and metrics

The Interaction Design Foundation also suggests a balance of roughly 60% to 80% text and 20% to 40% media in each section. For an iterations section, many designers will want to lean toward the visual end of that range, since before-and-after images do the explaining. Treat the benchmark as a guide, not a rule.

OpenTable Design frames the whole portfolio as a balance of showing and telling: images of sketches, concepts and screen iterations, paired with a description of why they led to each decision.

For a deeper look at structure, see our portfolio case study guide for designers and the six-block case study template that leads with outcome.

Collect the evidence while you work

The hardest part of documenting iterations is usually not writing. It is finding the proof months later. The Interaction Design Foundation recommends showing works in progress, including sketches, photos or videos of user testing sessions, photos of notes and feedback, sticky notes or whiteboards, and early wireframes, spread throughout the case study.

A simple capture habit:

Save every sketch and whiteboard photo in one folder per project, with a date.
Keep raw test notes, even messy ones. A spreadsheet of task results can become your “four out of six” line later.
Export slide decks from design reviews. They often hold your original reasoning in your own words.
Keep stakeholder comments and written feedback, with names removed where needed.
Note the version label (v1, v2, v3) on each file so the sequence is easy to rebuild.

If you are rehearsing how to talk through these sessions, a user research interview script can help you plan a timed run-through of your questions and your explanation of what the findings changed.

If you are starting from scattered files

Many designers reach the portfolio stage with a messy drive: a capstone paper, a Figma export, a client report, a handful of screenshots. Writer’s block is common at this point, because nothing is organized and the first sentence feels impossible.

Start from the artifacts, not from a blank page. Open the folder, sort files by date, and ask of each one: what did this show me, and what did I change after seeing it? The answers become your iteration notes.

This is the same idea behind Alloquy. You connect or upload project docs, Google Drive files, slide decks or notes, and the platform organizes them into a master achievement profile. Google Drive access is strictly read-only, and your original files are never edited or altered.

When the work is confidential or never shipped

Not every project has a launch, a metric or permission to share. Nikki Kipple of The Crit offers a practical way to stay honest: label each outcome as shipped, tested, proposed, estimated, or confidential. She also explains that a precise limitation is more credible than an unverifiable claim.

Student and concept work

Define the real constraints you worked under (time, audience, technology), and end with what you would validate before a release. A capstone with two documented rounds of peer testing and a clear “what I would test next” can be stronger than a vague claim of impact.

Confidential or NDA work

An NDA (non-disclosure agreement) is a contract that limits what you can share about a client or employer. The Crit’s advice is to review the agreement and get written approval for anything you publish. Then focus on your role, the kind of problem, non-sensitive constraints, your decision logic, and a sanitized reflection. Coursera notes that some work may need to be password-protected because of NDAs.

Never invent numbers to fill a gap. If you do not have a metric, say what you do have: test observations, stakeholder feedback, or the decision you made and why.

Mistakes that make iterations unconvincing

Only polished screens. Reviewers at design schools and studios look for what Vizcom calls the “messy middle”: rough sketches, failed prototypes and abandoned directions. They weigh your reasoning above technical execution.
Versions without reasons. Three screens in a row with no explanation of what changed is a gallery, not a process.
Vague evidence. “Feedback showed users were confused” says little. State how many people, doing what task, struggled where.
Hiding the dead ends. A rejected concept, explained briefly, shows judgment.
Too many iterations. If every minor tweak gets a section, the important decisions disappear. Pick the changes that mattered.
No outcome. Each iteration should end with what happened, even if it was “better, but not solved.”

Examples across career stages

The format stays the same at every stage. The artifacts differ.

College student or recent grad. Your sources are a capstone paper, a studio critique deck and two rounds of classmate testing. Show the v1 sketch, the critique comment that changed your direction, and the v2 result. Label the project as concept work.

Career changer. A teacher moving into learning experience design might use a lesson redesign, student feedback forms and a before-and-after worksheet. The iteration story is the same: here is what I observed, here is what I changed, here is what improved.

Professional returning after a break. Pull older design review decks, exported prototypes and project notes. Rebuild two iterations from the files you still have, and add a short reflection on what you would do differently with today’s tools.

Experienced designer. Years of work can bury your best examples. Choose the project where a research finding forced a real change of direction, and show the rejected concept next to the shipped one. If the details are confidential, follow the sanitized approach above.

Portfolio iteration evidence across four career stages

For more on how recruiters read these examples, see design case study examples recruiters can verify and UX portfolio examples hiring managers trust.

Our perspective on proving iterations

Iterations are a claim about how you think, and claims are easier to believe when a reviewer can inspect the evidence behind them. A before-and-after image is helpful. The test notes, the critique deck and the spreadsheet behind it are better.

That is why we built Alloquy as a proof-of-work companion. You build a master achievement profile once from your real artifacts, such as slide decks, capstone papers, spreadsheets, client reports and project docs. Resume bullets are generated strictly from those linked documents, not from generic AI claims, and Google Drive access is read-only, so your originals stay untouched.

Alongside the resume, a shareable interactive portfolio includes an AI assistant that answers recruiter questions using only the evidence you have provided. It complements LinkedIn and your PDF resume. It does not replace them, and it does not replace you. The human candidate still explains the judgment calls in the interview.

We would encourage every designer to document iterations as they happen. The habit costs minutes per project and saves hours when a job search begins.

Alloquy Team

Put your iterations in an interactive portfolio

A static PDF can hold a few screenshots. An interactive portfolio can hold the full trail: the sketch, the test notes, the deck and the final design, with an assistant that answers a recruiter’s follow-up questions at any hour from your verified material.

You can start with a free Alloquy profile, link your project files, and generate a master resume and tailored versions for specific job descriptions in seconds. To compare plans and limits, see Alloquy pricing. Alloquy cannot promise interviews or offers, but it helps you present real work clearly.

If you want to show process as video, our guide to a video case study portfolio covers that format.

FAQ

How many design iterations should I include in a case study?

Two or three explained iterations is a solid target, plus one rejected direction. The UX Design Institute advises choosing representative examples rather than every version. Pick the changes that most affected the final design.

Should I show failed or rejected designs?

Yes, briefly. Reviewers look for the messy middle, and one rejected concept with a clear reason shows judgment. Keep it short and end with what the dead end taught you.

What if I have no metrics for my iterations?

Use the evidence you do have: test observations, critique comments, stakeholder feedback or the decision logic. Label the outcome as tested, proposed or estimated rather than implying a result you cannot show. Honest labeling reads as more credible than a number nobody can verify.

How do I show iterations without breaking an NDA?

Review your agreement and get written approval for what you publish. Then focus on your role, the type of problem, the non-sensitive constraints and your reasoning, and use sanitized visuals. Password-protecting the case study is another common option.

Can I use student projects to show design iterations?

Yes. Capstone and coursework projects work well if you define the real constraints, show at least two rounds of feedback, and say what you would validate before a release. Label the work as concept or academic so the context is clear.