Professional experience, demo projects, personal projects and experiments call for different presentations. What I learned while organizing my portfolio and how I plan to test whether the distinction works.
My portfolio brings together professional experience, personal projects and experiments. While organizing how to present this material, a question came up that I had not anticipated: how do you show these different fronts side by side without making a prototype look like a client deliverable, or a fictional study look like a real case?
The question matters because whoever reviews a portfolio, whether in a hiring process or in a conversation about a project, usually has little time and reads based on visual cues. If every item has the same format, people tend to assume they are all the same kind of work.
The decision was to indicate the nature of each item and to separate professional experience from the selection of projects and experiments. In practice, each project received a visible category:
| category | what it indicates |
|---|---|
| Professional experience | work at a company, described without internal data or confidential results |
| Demo project | a study with a fictional company, product and brief, created to show a method |
| Side project | an initiative of my own outside my main job |
| Personal project | work done for my own use or learning |
| Product experiment | a prototype to explore an idea, with no commitment to real use |
The featured case, Compasso (in Portuguese), appears as a demo project. The product and the brief are fictional, and this is stated on the page itself, not just in a footnote. The other items appear as side projects, personal projects or product experiments.
This concern is not new in experience design. A Nielsen Norman Group guide on UX portfolios lists, among the elements expected in a case study, the problem definition, the person’s specific role, the process and the constraints encountered. For academic or hypothetical projects, the guide recommends openly acknowledging what was simulated, because transparency tends to be read as professional maturity (NN/g, 5 steps to creating a UX-design portfolio).
The recommendation also applies to marketing portfolios. A well-documented fictional study demonstrates method. The same study presented as a real case, if discovered, undermines trust in everything else.
The most useful lesson from organizing this material was realizing how much information needs to accompany each deliverable for it to be understood correctly. Beyond the category, I try to make four points clear in each project:
That last point is the one most easily lost. A visually polished prototype can suggest that the solution was validated, when in fact no one besides me has used it. I wrote about this concern, specifically for projects built with AI assistance, in Why “knowing how to use AI” says little about the work.
In the current version of the site, this organization is already on the pages. I don’t yet have evidence that recruiters or potential contacts understand the presentation the way I intend. The category may be visible and still be ignored during a quick read.
The next step is a simple usability test. I want to ask a few people to browse the portfolio without any prior explanation and tell me which projects they understand as a demo, a prototype or professional experience.
This doesn’t require a large study. Jakob Nielsen has long argued that small tests, with around five participants, reveal most usability problems, and that it is better to repeat short rounds after each adjustment than to concentrate everything in a single extensive test (NN/g, Why you only need to test with 5 users).
The success criterion is also simple. If the distinction between project types depends on me explaining it separately, the presentation still needs adjustments.
Many websites open with an abstract promise and leave what the company does for later. A study with a fictional product shows what changes when the headline and the button start to inform.
With AI, a content idea can be fully written before anyone decides whether it deserves to exist. Criteria for telling search intent apart from keyword variation, and a reminder that every publication requires maintenance.
The phrase fits very different activities and, on its own, does not explain what someone delivers. How to show the task, your role and the limits of a project built with AI assistance.