A mobile-first portfolio platform designed for architects — built around how architecture is reviewed, not just displayed. Because a finished rendering is only half the story.
Architects are assessed by their portfolios from the moment they graduate until the moment they retire. A job application, a competition submission, a new client pitch — all of them start with "can you send me your portfolio?" Yet the tools architects use to build these portfolios are either generic (Behance, Cargo) or so expensive and complex that only large studios can use them properly (Dezeen, proprietary client extranets).
The result: most architects have a PDF they send by email, updated once a year, that tells you nothing about how they think — only what the finished building looks like.
I am the user. I have an architecture degree. I've applied for jobs with a portfolio. I've reviewed student portfolios as a guest critic. This created an unusual research situation: I had deep domain knowledge, but also strong preconceptions about what a "good" architecture portfolio should look like — preconceptions that not all architects share and that hiring managers actively pushed back on. This project became as much about managing my own research biases as it was about designing the product.
I deliberately recruited two groups: architects building portfolios, and the people reviewing them. I was worried about designing something that satisfied my own aesthetic sensibilities — the kind of minimalist, process-heavy portfolio I personally value — rather than what actually gets architects hired.
Before writing my interview script, I wrote down every assumption I was bringing into the project. Eight of them. Then I designed questions specifically to challenge each one. For example, I assumed that showing design process was more important than showing finished results. Hiring managers told me something more nuanced: process matters, but only after the first 30 seconds, which are always about images. That changed the entire information hierarchy of the app.
"I see 200 portfolios a year. I decide in the first page whether I want to keep reading. The story comes later — but it only gets to come later if the first image makes me want to see the second."
Architects were frustrated with existing tools for consistent reasons: Behance was for graphic designers, not architects. The image compression was wrong for the scale of architectural renders. The project structure didn't match how architecture is presented — by building phase, programme type, or scale, not by date.
Crucially: architects working on collaborative projects had no way to properly credit their contribution vs. their firm's. Everything looked like solo work or firm work — the nuance in between didn't exist.
Hiring managers did look at process — but their definition of process was narrower than I expected: sketches, physical models, early-stage drawings. Not the full BIM documentation chain I'd assumed they cared about. They wanted to see thinking, not documentation.
They also wanted to filter quickly by specialism. A firm focused on residential housing doesn't want to scroll through 15 large-scale civic projects. Context-switching between portfolio types wasted their time.
| Feature | Behance | Cargo Collective | Folio (designed) |
|---|---|---|---|
| Architecture-native structure | Generic project pages | Generic project pages | Phase/programme/scale taxonomies |
| Image quality | Compressed, social-feed format | Better, but ratio-constrained | Lossless, ratio-free, full bleed |
| Process documentation | Unstructured body text | Unstructured body text | Structured layers: concept → built |
| Collaboration credit | None | None | Contribution % and role per person |
| Audience modes | One public view | One public view | Tailored view per viewer type |
| Mobile-first | Partial | Desktop-first | Designed mobile-first |
Graduated from Escola Superior Artística do Porto six months ago. Has been applying to studios in Lisbon and Porto. Sends a PDF portfolio as email attachment. Gets few responses and doesn't know if it's the portfolio, the experience gap, or the market.
Leaving a mid-sized architecture firm after 11 years to go freelance. Has a rich body of work but most of it is under the firm's branding, not his own. Needs to build a personal portfolio that clearly establishes his individual contribution and specialism (sustainable residential).
Architects at every career stage need a way to present their work that reflects how architecture is actually evaluated — by thinking, contribution, and context — not just by the visual quality of the final render.
Studios and direct clients evaluate portfolios completely differently. A studio hiring manager wants to see process sketches, drawings, and evidence of technical rigour. A direct client wants to see finished spaces they can imagine living in. The same portfolio, presented identically to both, fails at least one of them. Nobody had solved this.
I nearly didn't include the "client view" concept because I personally find client-facing portfolio work aesthetically less interesting than technical documentation. A hiring manager participant — unprompted — described exactly this problem in her third interview. I had to actively override my bias to include it. The research was right; my taste was irrelevant.
Three concepts drove the ideation phase, each emerging from a specific research finding:
Each project has multiple depths: a cover image for the 30-second scan, a short narrative for the 3-minute read, and full process documentation for the deep-dive. Viewers access more as they're interested — they're not forced through a linear PDF.
A single portfolio URL can show different content to different viewers. The architect decides: studio mode (process-heavy, technical) vs. client mode (image-first, spatial narrative). The underlying content is the same; the ordering and emphasis changes.
Collaborative projects are tagged with the architect's specific contribution: concept design, technical detailing, site management, visualisation. Hiring managers said this was more useful than a project credit — it told them exactly what they were hiring.
I designed the project taxonomy from professional practice: Project type (residential, commercial, civic, landscape), Scale (interior · building · urban), Phase shown (concept, schematic, developed, construction, built), Programme (single-use, mixed-use, adaptive reuse). These categories match how architecture offices actually organise their work — not how design portfolio tools typically think about "projects." Behance's equivalent is "category" with a free-text field. That's not how architects think.
Miguel's problem — projects he can't fully show due to client confidentiality — led to a specific feature: a "protected view" that requires the viewer to enter an email before seeing sensitive content, creating a lightweight access log. Not a perfect legal solution, but a practical tool for sharing work that's too commercially sensitive for a fully public portfolio.
The wireframe process started with the viewer experience, not the editor. I wanted to nail how the portfolio felt to receive before designing how it was built. This was counterintuitive — most portfolio tools design the editor first — but it matched the research insight that the first impression is decisive.
I specified that Folio would support architectural drawing formats natively: DWG thumbnails, large-format PDF plans (A0/A1) with zoom and panning, and section/elevation drawings displayed at consistent scales. Generic portfolio tools display everything as a square image. An architectural elevation is not a square. This single decision — treating architectural drawing formats as a first-class content type — separated Folio from every competitor.
I tested architects and reviewers in separate sessions. This was deliberate: I didn't want architects to perform for an audience, and I didn't want reviewers to be influenced by hearing architects talk about their process.
Architects couldn't find the audience mode toggle during setup. They kept looking in settings. Fix: made audience mode a primary choice in the "share" flow — you choose the mode before you copy the link, not as a hidden setting.
Architects wanted 12 contribution types. Reviewers understood 3: "designed it," "worked on it," "managed it." Fix: simplified to three primary tags with optional detail for architects who want to elaborate. The viewer sees the summary; architects see the nuance.
The timeline view of process layers (concept → schematic → developed → built) wasn't intuitively navigable for hiring managers without architecture backgrounds. Fix: replaced the timeline with a simple tab bar: "Concept," "Development," "Built." Less precise, but actually usable.
Architects checked the insights page compulsively. But the most useful metric — how long someone spent on each project — wasn't visible at a glance. Fix: redesigned to lead with per-project time, not total view count.
Reviewers balked at entering their email for every protected project. Fix: added a session cookie — enter email once, access all protected content in that session.
"I've been a hiring manager for twelve years. This is the first portfolio tool that seems to understand that what I need is different from what an architecture student needs."
I am the most dangerous kind of user researcher for this project: I know the domain deeply, I have strong opinions, and I'm designing something I personally want. Writing down my assumptions before research started was the single most valuable methodological decision I made. It let me notice when research was challenging my assumptions — and act on it rather than dismissing it.
Folio serves architects building portfolios and reviewers consuming them. These groups have genuinely different needs that sometimes conflict. The audience mode feature resolved the conflict by giving architects control over which need to serve — rather than designing for one group at the expense of the other.
My architecture background was most valuable in the taxonomy design — knowing how projects are actually categorised and evaluated in professional practice. But it was a liability in the process layer design, where I over-engineered the nomenclature. Domain expertise is an asset with known failure modes.
The contribution tag redesign — from 12 types to 3 — was the hardest decision in the project. I thought the nuance mattered. Research showed it didn't matter at the point of use. Cutting something you believe in because evidence says it doesn't work is a specific UX skill, and I got to practice it here.
Back to start
← Neighborhood Explorer App