Overview
A tool built from research, not assumptions
Most portfolio tools start from the same premise: give designers a canvas and let them fill it. Folio started somewhere different — with a question about why so many skilled designers have portfolios that don't reflect their actual work.
The answer, confirmed through research with six UX designers, was structural. The portfolio format assumes designers have finished screens, clean outcome data, and time to write. When designers are doing research, facilitation, or strategic influence work, the outputs rarely fit the format — there are no finished screens, no clean metrics, nothing portfolio-ready. The format fails the work, so designers avoid the format.
Folio is a response to that finding. It's an AI-assisted portfolio creation tool designed around the actual jobs designers need to get done: capturing work while it's fresh, turning raw notes into a case study narrative, knowing which projects to prioritize, and sharing work on their own terms. Every feature traces directly to a validated user need.
Results
From research insight to working product
Folio is a working, end-to-end product: a design journal, AI-assisted portfolio curation, a case study writing environment, a portfolio assembler, and a private viewer portal — each feature grounded in a specific validated user need. The first real user is the designer who built it.
The research didn't just inform what to build — it shaped what to build first, what to defer, and what not to build at all. Three JTBDs remain unaddressed in v1, by design. Prioritization was explicit, not accidental.
Problem to Solve
The format fails the work — and designers know it
Going into research, I expected to find motivation and time as the primary barriers. Every participant confirmed both — but neither was the root cause. What emerged across all six interviews was a pattern I hadn't anticipated: the portfolio format itself was structurally incompatible with the kind of work most designers do.
The format assumes a designer has:
- Visual deliverables — finished screens, polished mockups, or process artifacts to show
- Measurable outcomes — clean before-and-after data or business results to cite
- A standard project arc — one that fits neatly into Brief → Research → Design → Ship
Most designers doing their most significant work — research strategy, facilitation, design systems influence, stakeholder alignment — have none of these in portfolio-ready form. The avoidance isn't a motivation problem. It's a rational response to a structural mismatch.
The reframe that changed everything: portfolio avoidance isn't laziness, and better templates won't fix it. The format itself is broken for the work most designers do. Folio needed to be designed for what designers actually have — not what the format assumes they do.
What the format assumes
- Finished screens — polished mockups or visual deliverables ready to show
- Measurable outcomes — before-and-after data, conversion lifts, or business results to cite
- A standard project arc — Brief → Research → Design → Ship, with clear handoffs
- Solo authorship — one designer's contribution, cleanly separable from the team's
What designers actually have
- Research artifacts and facilitation notes — evidence of influence that produced no screens
- Ambiguous or NDA-constrained outcomes — real impact that can't be cited by name or metric
- Ongoing, multi-phase, or exploratory work — no clean ending, no ship moment, no tidy arc
- Collaborative decisions — meaningful contributions that were never individually attributed
Approach
Double diamond process — evolved for AI collaboration
The process followed the double diamond, but one thing made it different from a typical design project: research didn't get left behind in discovery. Every interview insight — assumption logs, JTBD frameworks, design principles — was embedded in the codebase as structured data. That meant it stayed searchable and alive throughout design and build, grounding AI collaboration in the actual research rather than general-purpose prompting.
By embedding validated research directly into the codebase, the AI had shared grounding throughout the entire design and build process — not a document in a separate folder, but queryable context at every stage. That meant:
- Workflow design was grounded in real user mental models, not assumptions — every design decision traceable to a participant quote or validated JTBD
- AI interaction design — the Socratic dialogue tone, pacing, and output — was tuned to actual target users (designers) and actual audience values (hiring managers), not generic best practices
- Collaborative brainstorming was productive because the AI and I were reasoning from the same validated foundation, not correcting hallucinated user behavior mid-conversation
Before designing anything, I needed to understand what was actually broken — not what I assumed was broken. I interviewed six UX designers across different career stages — early-career, mid-career in-house, agency, and senior — with the goal of understanding where their current approach fell apart and why. I tracked seven core assumptions and documented each with a hypothesis, evidence, and revised status.
- Portfolio avoidance is rational, not motivational. Every participant described avoidance as a logical response to structural mismatch — the format asks for things most designers simply don't have from their best work.
- The capture habit breaks under friction. All 6 had tried journaling continuously; all 6 had stopped. Any flow that required a context switch from actual work eventually failed.
- The most impactful work leaves no portfolio-ready artifacts. Research, facilitation, strategic influence — the contributions participants were proudest of — produce nothing the standard format can accommodate.
- NDA ambiguity causes over-caution. Participants assumed they could show far less than they likely could. The default response to uncertainty was to show nothing.
The signal across all six participants reframed the entire project: the format is the problem, not the designer.
Artifacts:
Assumption Validation Log
- A1. Designers avoid portfolios because the effort-to-result ratio feels too high.
Validated — Confirmed across all 6 participants, but the root cause was more specific: the format can't represent the kind of work most designers do today. Avoidance is a rational response to structural mismatch, not a motivation problem. - A2. Journaling small moments regularly is more sustainable than big writing sessions.
Validated, with nuance — All 6 participants want to capture continuously; all 6 have tried and abandoned the habit. Zero-friction capture survives real working conditions. Any flow that requires a context switch fails. - A3. HR managers prefer structured narratives over scroll-through visual showcases.
Partially validated — Creators strongly want narrative-first case studies (confirmed). Whether HR managers share that preference is not yet evidenced — no viewer research has been conducted. - A4. AI-generated suggestions lower blank-page anxiety without removing the designer's voice.
Conditionally supported — All 6 participants described blank-page anxiety and asked for structured guidance. Whether AI delivers this without overriding voice is still untested in the product. - A5. Viewer-side access control is a meaningful differentiator vs. public Behance or Notion.
Lightly supported, reframing needed — Creators want to control who they share with (confirmed). The more acute need is navigating what they can show at all — not just who can see it. - A6. The portfolio format itself is a structural barrier — not avoidance, not a skill gap.
Unvalidated — Research suggests this strongly, but the right product response and how much visual representation remains necessary is still an open design question. - A7. Most designers show nothing from their best work not because it's prohibited, but because NDA ambiguity makes them overly cautious.
Unvalidated — Strongly suggested by all 6 participants, but not yet validated through intervention.
Research Insight Synthesis
6 participants · early-career, mid-career in-house, agency, senior
- Avoidance is rational, not motivational. Every participant described avoiding their portfolio at some point — but not because of laziness or lack of caring. The format asks for things most designers simply don't have from their most valuable work. Avoidance is the logical response.
- The capture habit breaks under friction. All 6 participants wanted to journal their work continuously. All 6 had tried and stopped. The pattern was consistent: any capture flow that required a deliberate context switch from the work itself eventually failed. Zero friction isn't a nice-to-have — it's the only version that survives real working conditions.
- The most impactful work leaves no portfolio-ready artifacts. Research, facilitation, strategic influence, and stakeholder alignment — the contributions most participants were proudest of — produce no finished screens, no clean metrics, and nothing the standard format can accommodate. The format structurally excludes the work that matters most.
- Blank-page anxiety is universal. All 6 participants named starting from scratch as a primary blocker. Not knowing where to begin — not lacking things to say — was the consistent barrier. Structure and prompting matter more than content assistance.
- NDA ambiguity causes over-caution. Participants assumed they could share far less than they likely could. The default response to uncertainty was to show nothing. Clearer guidance on what NDAs actually prohibit could unlock a significant amount of showable work.
- Portfolio work carries real emotional weight. Many designers arrive at their portfolio at a difficult moment — after a layoff, while quietly unhappy, or after being passed over. The emotional context of portfolio work is not incidental. It shapes what support the tool needs to provide and what it must never do.
With the structural mismatch identified, I used the Jobs to Be Done framework to translate research into a precise design target — keeping focus on what designers are actually trying to accomplish, not on features or UI patterns. JTBD forces precision: it's harder to build something that doesn't map to a real situation anyone faces.
- 11 creator jobs identified from 6 interviews, each mapped to a Folio feature and prioritized by urgency
- 6 design principles defined as constraints — including the emotional weight of portfolio work and the non-negotiable distinction between Journal (capture without judgment) and Workshop (craft with guidance)
- 3 JTBDs intentionally deferred from v1: NDA guidance, a "good enough to send" signal, and early-career discovery support
Prioritization was made explicit: every build decision throughout phases 3 and 4 was traceable back to a specific job and the people who named it.
Artifacts:
JTBD-to-Feature Matrix
| Job to Be Done | Folio Feature | How It Addresses the Need |
|---|---|---|
| Capture while it's fresh | Journal | Quick note capture without structure or commitment — a sentence is always enough |
| Turn notes into a story | Workshop | Socratic dialogue transforms raw journal notes into shaped case study prose — in the designer's voice |
| Know what to work on | Curator | AI-scored portfolio analysis surfaces the strongest projects and explains the reasoning |
| Align my story to the role | Curator | Resume parsing + per-project alignment scoring against target role criteria |
| Share on my terms | Access / Viewer | Password-protected private links, revocable at any time — no public indexing, no SEO |
| Show work that left no artifacts | Workshop | Designed to support text-only, research-heavy, and non-visual case studies — not as a workaround, but as a first-class use case |
| Write without outcome data | Workshop | Coaching approach surfaces what's genuinely there — process, insight, influence — without fabricating metrics |
| Capture before I forget | Journal | End-of-project capture flow designed for the moment immediately after completion, when memory is freshest |
| Three JTBDs intentionally deferred from v1: NDA guidance for what designers can legally share, a "good enough to send" signal, and discovery support for early-career designers. Prioritization was explicit — these jobs will be addressed in subsequent phases. | ||
The design phase was deliberately hybrid: high-fidelity mockups for large-scale layout decisions and complex interaction patterns, design-in-code for iteration and refinement. The two modes were sequenced for what each does best — you learn things in a real browser that you can't learn in Figma, especially with a tool that has many states, loading conditions, and edge cases.
- AI interaction designed as a first-class UX problem. The tone of each prompt (coaching, not critique), when Claude speaks vs. stays quiet, and the clear boundary of AI authority (Claude recommends; the designer decides) were all specified before code was written.
- Embedded research grounded every AI collaboration. Because interview insights, JTBD frameworks, and design principles were structured data in the codebase, they were searchable context for AI prompting — not a document in a separate folder. Research that stays in the system actually influences decisions.
- Annotated mockups for navigation, panel behaviors, and multi-step flows — validating interaction logic before committing to implementation and producing artifacts that could be reviewed and revised quickly.
- Living design system reference page built and maintained throughout — documenting every token, component, and usage rule as decisions were made, not after the fact.
Artifacts:
Annotated Journal Dashboard Mockup
High-fidelity layout with design intent annotations.
Menu Item Interaction States
Visual design of default, hover, and selected states — including drag gripper on hover.
Design System Reference Page
A living style guide built and maintained throughout the project — covering color tokens, typography scale, spacing, all button variants, form fields, and component usage rules.
The product is built and in active use — by me. Every feature has been tested not as a prototype, but in the actual act of creating a real portfolio. The feedback loop is unusually tight: when something doesn't work the way a designer needs it to, I know immediately, because I am that designer.
- Surfaces what traditional usability studies miss — the prompt that asks too much when you're distracted, the multi-step flow that feels like friction at 10pm, the design that looks right in a mockup but doesn't hold up over weeks of real use
- Continuous validation, not punctuated — feedback is ongoing rather than tied to a study or milestone
- Not a substitute for research — Folio was built on research. This is a different kind of evidence that runs alongside it.
Artifacts:
Journal
The capture environment — project list, update feed, AI-assisted description dialogue, and resume analysis.
Curator
Portfolio analysis view — project scoring, tier badges, and alignment results against a target role.
Workshop
Case study writing environment — throughline, three story arc sections, AI-assisted drafting, and a story review panel with gap identification and resolution.
Solution
Six features, each traceable to a validated user need
Folio is an end-to-end portfolio creation tool — sequenced to match how a designer's relationship with their work actually unfolds, not how the portfolio format assumes it does.
Journal
Low-friction capture — a sentence is always enough. A Socratic dialogue helps translate rough notes into a project description in the designer's own voice, without it feeling like a form.
Profile
Resume upload and parsing, target roles, design process preferences. Profile feeds Curator directly — so every analysis is grounded in where the designer is actually trying to go.
Curator
AI-scored portfolio analysis. Each project gets a tier (Portfolio Anchor, Strong Addition, Tell Your Story), a rationale, and a skill coverage map aligned to the parsed resume.
Workshop
Case study writing built around a storytelling framework, not a template. A throughline, three story arc sections, AI-assisted drafting, and a story review that surfaces structural gaps.
Builder
Portfolio assembly: select projects, sequence them, publish. The viewer experience is deliberately minimal — Folio's value is in what it helps create, not in how it displays it.
Access
Password-protected viewer links, revocable at any time. No public indexing. Share intentionally, with exactly the people meant to see it.
This case study was written and assembled using Folio.
The research that shaped the product also shaped this narrative. The tool built to solve the blank-page problem was used to write about solving it. I am, in fact, the exact designer this tool was built for — and that's not a coincidence.
Takeaways
Research first, then build
The question behind Folio — is the format the problem, not the designer? — only emerged because the research came before the solution. Every significant design decision in this project traces back to reframing the problem with that question.
- Problem reframing through open research — I expected to find motivation and time as the barriers. The research surfaced structure. Asking open questions before forming hypotheses is what made that reframe possible — and it changed every design decision that followed.
- JTBD as a strategic discipline — the value of Jobs-to-be-Done isn't a list of jobs; it's the decisions the framework forces. Deferring three JTBDs from v1 was deliberate prioritization, not oversight. A backlog of explicitly reasoned deferrals is evidence of strategy. A feature list with nothing deferred is a red flag.
- AI interaction design — the tone of a prompt, the moment a suggestion appears, the boundary between what Claude decides and what the designer decides — these aren't implementation details. They are the product experience. Treating AI interactions with the same rigor as layout and flow was one of the most consequential design decisions in Folio.
- Sustained self-use as validation — being your own first user with real content and high standards is the most demanding form of testing. It's not a substitute for research, but it surfaces something prototypes can't: what it actually feels like to use a tool repeatedly, under real conditions, when the stakes are real.
Designers aren't avoiding their portfolios because they lack discipline. They're avoiding a format that was never built for the work they actually do. Folio started with that insight — and was built to prove it.