Answer in brief
A strong no-client portfolio is best built around real constraints, with each project's status honestly labeled: training, volunteer, or an unofficial redesign concept.
Why Student Work Alone May Not Be Enough
Nielsen Norman Group warns that a convincing portfolio is harder to put together when all a candidate can show is student work, because such projects often carry invented constraints, users, and personas, which makes them weaker evidence of handling real conditions. NN/g recommends getting at least one real project through an internship, and for student work that is already finished, disclosing the unrealistic elements directly in the case description so the reader understands the limits of what it proves.
Interaction Design Foundation frames a similar practice differently: a "hypothetical project" can be built around analyzing an existing product, or it can be entirely invented — IxDF calls both a good strategy specifically for beginners. This does not fully match NN/g's warning: IxDF separately notes that real projects — volunteer, student, community, or hackathon work — are often more valuable than hypothetical ones, but it does not forbid inventing the product itself. The gap here is not about facts but about emphasis: NN/g's first recommendation is to find a real project and only fall back on realistic constraints with an honest disclaimer when one is not available; IxDF allows a fully invented product too, even though it considers real projects often more valuable. From this, the editorial rule for the three assignments below follows: not "invent a brand from scratch," but "take a real product and a real, verifiable constraint" — this is an editorial decision that rests on NN/g's warning and on IxDF's own preference for real projects over hypothetical ones, not a shared position both sources state outright.
Three Assignments Instead of One Invented Brand
Each of the three assignments is built around a real, verifiable constraint — an existing service, a genuine volunteer request, or another company's product — rather than a fictional brand with invented metrics. Each assignment has its own type of constraint: an existing technical platform and navigation in the first, a time budget and no pay in the second, another company's already-established visual system in the third. The evaluation criterion also changes from assignment to assignment and is never just whether the final image looks good.
The rule shared by all three: the output is not a client testimonial or a sales figure that does not exist, but a verifiable artifact (a mock-up, a prototype, a redesign concept) with an openly stated project status. Three suggested labels for the three assignments: "training project, not a client commission," "volunteer project for [type of organization], unpaid," and "redesign concept: unofficial work on another company's product, not commissioned or approved by the owner." The sources do not weigh such labels against a completed commission in an interview: NN/g calls a training project weak evidence of the ability to work under real conditions, and IxDF ranks real projects, including volunteer ones, above hypothetical ones (see above) — meaning a training-project label alone carries less weight than a completed commission. The practical principle from here on is editorial: to avoid creating a false impression of client work, state the status in the case before describing the outcome, rather than leaving it unclear until the interview.
Assignment One: Audit an Existing Service and Justify One Change
Pick a service or interface you use yourself — not an abstract "startup," but a specific app, website, or form with real screens you can open and screenshot. Frame one narrow question: which step in this interface creates the most friction, and why. The constraint here is technical and real: you are working inside existing navigation, a type system, and screen sizes rather than a blank page, and that needs explaining before you propose changes. Nielsen Norman Group recommends capturing the starting state — with screenshots or other records — before any redesign, so there is something concrete to compare the final decision against.
Interaction Design Foundation calls this format — analyzing an existing product and proposing an improvement — a recommended strategy specifically for beginners. Structure the case using the "context and role → process → outcome and reflection" scheme described in a separate methodology article from the same resource: first, what question you asked and why; then, which options you considered and rejected and why; and finally, what you would do differently if you returned to the task now.
Deliverable: A One-Step Prototype and at Least One Rejected Option
The verifiable deliverable for this assignment is not a full service redesign, but a mock-up or prototype of one specific step, a screenshot or record of that step's "before" state, and a short description of at least one option you considered and rejected, with the reason. A one-to-two-week timeframe is not a rule from the sources but an editorial guideline — enough time to walk the "question → options → decision" path without stretching a training exercise over months.
Self-Check: Can the Problem Be Explained Without the Mock-Up
A simple self-check: can a reader of the case retell exactly which problem you were solving without looking at the mock-up. The status for this assignment is "training project, not a client commission"; state it directly in the case description, not in fine print at the bottom of the page — in the same spirit as NN/g's advice to openly disclose the unrealistic elements of training projects.
Assignment Two: A Volunteer Project With a Real, Unpaid Request
The second type of real constraint is not a hypothesis but a live request from an organization that needs design work and has no budget for it. Interaction Design Foundation directly names charities and nonprofits, student and community projects, and hackathons as sources of such non-invented constraints — and separately warns that trading labor for "experience" often turns into exploiting young designers, so it is worth choosing exactly these kinds of ethical options from that list rather than any unpaid job from anyone.
What sets this assignment apart from the first is the amount of feedback involved: a volunteer request has a representative from the organization who can confirm or reject the solution, even without payment. Define the constraint in advance and in writing, as a brief: what needs to be done, by when, and in what format. It is the same skill as working from a brief for a paid commission — the difference is that here you write the brief yourself together with the organization's representative, rather than receiving a finished one from a studio's client.
Deliverable: A Brief, a Solution, and the Organization's Response
The verifiable deliverable is a written brief with the task and deadline, the mock-up or prototype itself, and a short documented response from the organization's representative to the proposed solution — even if it is a rejection of some ideas: what matters is the fact of feedback from a real person, not only your own self-assessment. A timeframe of several weeks is an editorial guideline, not a rule from the source.
Self-Check: Does It Account for This Organization's Own Constraints
The evaluation criterion for the case: does it show that the solution was made with this specific organization's constraints in mind — its audience, its resources for maintaining the mock-up after handover — rather than lifted from a generic template. The project status is "volunteer project for [type of organization], unpaid," naming who it was made for, without inventing a result the organization never confirmed.
Assignment Three: An Unofficial Redesign Concept With an Open Status
The third format is the riskiest, ethically: it involves taking a real product from another company and reworking it visually, and this is where it is easiest to present the result as if it were a commission from that company. None of the reviewed sources states an outright ban on this — this is an editorial methodology position, resting on NN/g's advice to openly disclose the unrealistic elements of training projects in the description: the editorial team extends the same principle to work on someone else's product — the status has to be visible immediately, not something the hiring side has to guess at.
From an editorial-transparency standpoint, this kind of case cannot be presented as a company commission: the product or interface is treated as an object of independent analysis, and the very first sentence needs to state plainly that the work is unofficial and was not commissioned or approved by its owner. But an honest label alone does not settle the legal question. Under Article 1270 of the Russian Civil Code, translating or otherwise adapting a protected work, as well as making a work available to the public, are counted among the uses covered by the exclusive right. These are rules of Russian law: outside Russia, the copyright and trademark protection regime can differ, and it is worth checking separately. Whether this applies to a specific interface, logo, or individual elements, and whether a lawful exception exists, depends on the object and the circumstances. Trademark rights are governed separately and are not fully addressed in this article. So this material does not grant a universal license to publish someone else's logo or its redesign; the practical minimum is not to create a false impression of a commission or approval, and to separately check the rights to the elements used before publishing.
Deliverable: A Redesign Concept With an Open Status Label
The verifiable deliverable is the redesign concept itself (a mock-up, prototype, or system) and an explanation in the opening paragraph of the description: what exactly was reworked, that this is unofficial work, and that the company did not commission or approve it. Mentioning the company in the description should be kept separate from using its logo or other mark: whether that use is lawful depends on the specific context and the rights to that object, and this article does not substitute for a legal review.
Self-Check: Does the Text Hint at the Company's Consent
A pre-publication self-check: reread the case description and flag every spot where a casual reader might think the company knows about or approved this work — then rewrite those spots plainly. The same principle applies to the logo separately from the interface: the right to show a logo made for a real commission in a portfolio and the right to show a rework of someone else's already-existing logo are two different things with different legal consequences, and it is worth sorting out that difference before publishing, not after a question in an interview.
How to Build a Case That Shows Your Thinking, Not Just a Picture
For all three cases, it helps to keep the same set of questions — context, your role, process, alternatives, outcome, and reflection — without forcing different projects into an identical visual template. Interaction Design Foundation describes a basic "beginning — process — conclusion" sequence, in a separate methodology article from the same resource: first, the context of the task and your role; then, the path to the solution and the alternatives; and at the end, the outcome and reflection on what you would do differently. The final mock-up, in this logic, shows the outcome of the process, but the case's own format can be adapted to the material.
A similar emphasis appears in an Interaction Design Foundation video roundup featuring several design leaders and hiring managers, among whom the page names, by title, Smashing Magazine's Creative Lead Vitaly Friedman and Netflix's product design lead Nival Sheikh; the video's transcript is not readable on the page, so this article does not attribute specific individual words to them. IxDF's summarized takeaway from the roundup is to show your thinking in the portfolio and be specific rather than vague. The comparison with a polished final image is stated directly in other methodology articles from the same resource — the one describing case structure and the one listing common portfolio mistakes. The practical takeaway for a case: write not only "what you ended up with" but which options you rejected and why — this part of a case's structure deserves attention in any format, not only in a training one.
How to Label a Project's Status Without Passing It Off as Paid Work
The three statuses used above exist mainly for transparency: a case's reader immediately understands where a training project was, where volunteer work was, and where an independent redesign concept was. Nielsen Norman Group recommends doing exactly this with already-finished training projects — plainly disclosing their unrealistic elements in the description, so the hiring side does not get the impression that the author simply cannot tell the difference from a real project. The editorial recommendation is to disclose the status in the very first sentence of the case description, so the visual presentation does not create the impression of a real commission before the caveat appears.
The wording should be just as specific as the case itself: not "a training project," but "training project, not a client commission, done to practice a specific interface solution"; not "helped an organization," but "volunteer project for a local nonprofit initiative, unpaid, timeframe of several weeks"; not "brand redesign," but "redesign concept for [company]: the author's own initiative, not commissioned and not approved by the owner." These exact phrasings are an editorial suggestion, not a quote from a source: none of the reviewed materials supplies ready-made language for this kind of labeling, though NN/g does state the need to disclose a training project's fictional elements.
What to Remove From a Portfolio That's Already Built
If several training projects are already sitting in a portfolio, there is a separate set of checks for them. Interaction Design Foundation lists common mistakes that devalue even strong work: time spent on secondary details like a personal logo instead of the cases themselves; no curation, when everything goes into the portfolio instead of a curated selection of the best work; using a ready-made template without adapting it to the content; weak documentation of the decision-making process; and ordinary technical flaws like broken responsive layout, accessibility issues, or typos in the case text.
Nielsen Norman Group and Interaction Design Foundation agree on a related piece of advice, useful even while a project is still underway rather than only when cleaning up a finished portfolio: document the process as you go, before the details are forgotten. IxDF frames this as a separate principle — document as much as possible and include drafts, sketches, photos, and voice notes in the case; NN/g separately recommends keeping any working artifacts for future cases. That said, cases do not benefit from lengthy prose: hiring managers skim a portfolio quickly rather than reading it start to finish. For assignments built on a real constraint, documenting along the way also works as evidence: a draft shows that the solution was not the single obvious option from the very start.
How to Describe Training Projects on a Résumé, Separately From the Portfolio
A résumé and a portfolio solve different problems. Nielsen Norman Group recommends not creating separate résumé sections for individual projects at all: a completed training program or course should be described there in two or three sentences, in the language of skills — what topics were studied, what tools were learned — while the projects themselves, with all their details, alternatives, and status, belong in a portfolio adapted for a non-academic reader, not in an internal program report.
This rule also applies to the three assignments in this article: on a résumé, a general line about the program completed or independent practice and the key skills involved — not a separate entry for a specific case involving a service, a logo, or an organization. The full version — with research, alternatives, project status, and reflection — stays in the portfolio; a hiring side that wants the details will open it themselves.
Practical checklist
- The project status is stated in the first sentence of each case description, not tucked away at the end of the text.
- The constraint is stated concretely: a service's existing navigation and layout, a volunteer project's time budget, or someone else's visual system — not abstract freedom.
- The case text includes a paragraph about at least one rejected option and the reason it was rejected.
- The service or product's starting state is captured with a screenshot or other record before the finished solution appears in the case.
- No case includes a client testimonial, a sales figure, or a mention of a business relationship with a company that never existed.
- If a case is a redesign concept of someone else's product or logo, the status is stated honestly in the first sentence, and the wording never hints that the company commissioned or approved it; the legal risk of publishing a rework of someone else's mark is not removed by a single disclaimer.
- On the résumé, the training program and courses are described in two or three sentences in the language of skills; there is no separate section for a specific project — the details stay in the portfolio.
Questions and answers
Can I show a redesign concept of a real company's logo in my portfolio without its knowledge?
There is no clear "yes" here. Article 1270 of the Russian Civil Code counts adapting a protected work and making a work available to the public among the uses covered by the exclusive right. So publishing a specific redesign may require the rights holder's permission or reliance on an applicable lawful exception — it depends on exactly what was reworked and whether the relevant element is protected. Separate trademark rights are not analyzed here. These are rules of Russian law: in other countries, copyright and trademark protection rules can differ, and they are worth checking separately. Either way, you cannot present the work as if the company commissioned or approved it when it did not.
How many cases do I need to send a portfolio to a first job application?
The sources give different but close ranges: Nielsen Norman Group recommends choosing 3–5 projects for detailed cases and stresses that the number itself matters less than the variety of skills shown; Interaction Design Foundation suggests a range of roughly three to six cases. There is no data on a number that guarantees an interview invitation — not from the editorial team, and not from the reviewed sources.
Should a résumé mention that a project was unpaid or academic?
Per Nielsen Norman Group's advice, it is not worth creating separate résumé sections for individual projects at all: courses and the training program can be described there in two or three sentences in the language of skills, while the projects themselves — with status, details, and reflection — belong in the portfolio. The status — "training," "volunteer," "redesign concept" — is stated there, not on the résumé.
What if the only available volunteer project is not in the specialty I want to work in going forward?
Interaction Design Foundation recommends choosing methods and case types that match the target role and combining different formats in one portfolio rather than relying on a single project. If the volunteer project is off-profile, the editorial suggestion is to use it only when it shows methods useful for the target role, and to strengthen the portfolio's profile with the first or third assignment, which are easier to pick closer to the desired specialization.
Is it better to do one detailed case or three short ones?
The sources favor curation over volume: NN/g notes that cases do not benefit from lengthy prose because they get skimmed anyway, and recommends focusing on one or two projects instead of spreading effort thin when time is short. The three assignments in this article cover three different types of constraints and are meant to build different skills, not to spread effort thin; if time is genuinely short, it makes more sense to finish one or two assignments than to start all three superficially.