What I designed when I stopped designing pages

Everything started asking me questions

Over the past year the software around me stopped waiting to be operated. People stopped navigating and started asking. Sequences of clicks collapsed into a sentence typed into a box. Agents began doing multi-step work on someone's behalf, which moved the person from operating a tool to briefing it and then checking what came back.

Individually each of those looks like a feature. Together they are the interaction model changing, and that is a design problem before it is anything else.

I spent three to six months paying attention to it across the products I actually use, not just portfolios. Then I noticed I was watching the same thing from the inside at work.

I moved from IC to design manager at HashiCorp in January 2025, five weeks before the IBM acquisition closed, inheriting a six-person team that had lost several senior managers in six months. In among the harder parts of that job, the designers around me were already adopting AI on their own terms, in ways that did not reproduce. One person's setup produced great work and nobody else could get near it.

Handing down a standard would have been the fast move and the wrong one. I started an AI sharing series built from a corpus of what people were actually doing instead. One designer on the team built a QA agent that runs against any Figma file and returns a heuristic evaluation, an accessibility audit, and design-system and design-principle checks. It is in daily use by more than a hundred designers across the business unit.

I did not build that agent. My contribution was creating the conditions and doing the coaching.

I did not read about this shift. It was already on my team's calendar.

Three arrivals, one aim

I had a pile of half-formed ideas about what this means for design and nowhere to put them. Inside a company, ideas at that stage queue behind a roadmap, and rightly so. A designer rarely gets to take a thesis and carry it end to end, through interaction model, content, type, colour, voice, accessibility and delivery, until a stranger can use it. My own portfolio was the one product I fully controlled.

It also needed the work. My case studies lived in two places that did not know about each other: a Framer site, picked originally because it was the fastest way to have something up at all, and five older case studies on GitHub Pages. Two design systems, two URL schemes, two versions of the same projects. Every time someone asked for my portfolio I picked a half and apologised for the other one.

1. Primary

   The person deciding whether to talk to me

   A hiring manager or design lead with minutes, not an afternoon. They need relevance, level, what I personally did, and whether to start a conversation. Everything else is secondary to that.

2. Secondary

   The curious browser

   A peer or a recruiter with no specific brief, moving fast, under no obligation to stay. They should still hit something worth stopping on.

3. Third

   Not a person at all

   An assistant, sent by one of the first two, reading on their behalf. I wrote this one into the brief before a single page existed, which at the time felt slightly ridiculous.

Three arrivals, one aim. Whichever door someone comes through should feel considered rather than tolerated. That sentence did more work than any wireframe I drew.

A mood board, then the interactions, then a brief

The first artifact was a mood board I assembled by hand, collecting references until I could describe how the site should feel rather than what it should contain. Editorial restraint, a lot of quiet, hairline rules, one accent used sparingly.

The second artifact is where the thesis entered the design. Before I drew a page I sketched two interaction patterns: human-readable text published for AI consumption, and an intent-based conversation for people arriving with one question. Both came out of the shift, not out of portfolio convention.

Only then the brief — the promise, the positioning, the decisions the site has to support, what was explicitly out of scope, and the three arrivals above. Alongside it I wrote a gap inventory listing every planned surface and what I honestly did not have yet. Large parts of it read “Critical gap,” “Missing,” “Concept only.” Writing down that I had no approved answer bank and no verified chronology is not a fun morning, and it is exactly why none of it got quietly invented later.

One voice, three materials

The clearest design decision in the whole project is visible in two screenshots. The homepage opens with a sentence. The terminal opens with the same sentence, set in a monospaced grid under an ASCII wordmark. The machine file opens with the same positioning in plain Markdown.

One voice, three materials, because all three read from the same approved content. No surface gets to invent its own version of me. When I change a fact it changes everywhere at once, which is the only way a portfolio with three front ends does not slowly start contradicting itself.

Explore is a context-driven intent pattern

The second arrival wants one answer, not four case studies. The pattern that serves them is context plus intent, and both halves have to be real.

Contextwhat the surface already knows before a word is typed

Which project's page you are on. What lens you have been reading through. Whether you arrived with an explicit scope. On a project page, that project always claims the scope, so a stale session can never answer for the wrong work. Every active scope is visible and removable, because context you cannot see or drop is surveillance rather than assistance.

Intentwhat the question is actually for

Someone reading a case study who asks for the thirty-second summary should get that project's summary. Someone asking the same thing from the homepage should get the portfolio-level answer. Same question, different intent, because the context differs.

Underneath both halves, Explore does not generate. It returns complete answers I wrote and approved, 42 of them, 41 live, one deliberately left in draft. Where no approved answer exists it says so, points at nearby material, and stops.

That is a design decision rather than a technical limitation. A generative portfolio chatbot has one failure mode that matters: it will answer a question about work I have not done, in my voice, to someone deciding whether to hire me.

My visitors arrive braced for invention. Refusing to invent is the most useful thing the surface can do.

AI is still all over this feature. It did the synthesis and it does none of the serving. My case studies, evidence and resume were the raw material; the model helped me draft, cluster and pressure-test candidate answers; I approved every one. Visitors get my data, never a model improvising on top of it.

• It renders inverted

  The conversation always takes the opposite colour scheme from the page it sits on, so you always know which material you are in.

• It talks about me, not as me

  Its questions and follow-ups are third person — “What was Parimal's role?” — while the answers stay in my own words under my own mark, because they are quotes rather than generated replies.

• Every answer has an anatomy

  A direct answer, a provenance line, two contextual follow-ups, and at most one onward pathway chosen for that answer rather than the same links stapled under everything.

• A prompt can never dead-end

  Starter prompts follow the resolved scope and are checked at build time against the approved bank, so a prompt with no answer behind it is a build failure rather than a shipped disappointment.

Designing for a reader that is not a person

If I publish nothing for machines, an assistant asked about me scrapes the rendered page, loses the attribution, flattens “I led this” and “my team shipped this” into one sentence, and fills the gaps with something plausible. The line between what I did directly, what I contributed to, and what my team delivered is the part of my portfolio I am most careful about, and it is the first thing a scrape destroys.

So the site publishes a clean, attributed, explicitly bounded version of itself for that reader, with an instruction I wrote on day one and have never changed.

Shipped with every context package, unchanged since day one

Use only the supplied portfolio evidence. Do not invent experience, responsibilities, research, or outcomes. Distinguish direct evidence, contributed or team results, adjacent experience, genuine gaps, and unknowns.

The site does not connect to any AI service. You copy the context and take it to your own assistant.

Designing for a non-human reader turns out to be ordinary craft. It is the same class of decision as a real print stylesheet or a real keyboard path. Someone will consume this in that mode; they should get the good version rather than the accidental one.

A portfolio you can read in eighty columns

More people work in a text interface than did three years ago, and the reason is that AI tooling now lives there, which has pulled designers, PMs and writers into the terminal for ordinary work.

I am one of them. I spent this entire project in a terminal, so the portfolio can be read there too.

The brief for that surface was narrow. It is a terminal application, not an imitation shell. No fake boot sequence, no guess-the-command puzzle, no login. Work appears immediately. Tabs mirror the site. At a wide enough terminal the index and the selected summary sit side by side, and below that width they go one after the other rather than shrinking into nonsense. Every important state has to survive with no colour at all, because someone will read it that way.

Translating an editorial layout into a monospaced grid is the most enjoyable constraint I have designed against in years.

Technical challenges, and what they taught me

None of what follows is the interesting part of the story, and all of it is the reason the story has an ending. I am a designer who reads code. Every one of these was solved by treating it as a design problem I had created for myself.

1. The cloud had no room for me

   The first host I picked had no capacity for the free instance size, across every availability zone, for two hours, and reported one of its refusals as a permissions error. I moved providers and it came up first try. The configuration for the failed one is still in the repository, correct and unused.

   What it taught meA plan that verifies is not a plan that runs. I now check availability before I check syntax.

2. The command had to be clean

   I wanted one word and a hostname, with no port flag, which meant moving my own administrative access off the port I was reaching the machine through. That is how people lock themselves out. The cutover kept the previous working path open until the next one was proven, at every single step.

   What it taught meThe typing experience of a command is interface design, and it is worth an afternoon of risk to remove one flag.

3. It shipped in black and white

   The deployed terminal rendered in monochrome while the identical build rendered in full colour on my laptop. After I fixed that, it rendered bright magenta where the green should be. By then the output was provably correct; what no measurement could tell me is that the terminal on the other end renders 24-bit colour unreliably. Capping the output at 256 indexed colours fixed it.

   What it taught meVerifying that a system sent the right thing is necessary and not sufficient. A capture proved the server correct while a real person looked at a pink heading.

4. I burned a weekend on one bad instruction

   Early on I tried to process my whole content archive in a single pass. It broke, burned through a great deal of model capacity, and cost me roughly twenty-four hours of a fourteen-day project, with each repair attempt spawning the next one, a snake chasing its own tail.

   What it taught meA long unattended run with no checkpoints is an interface problem, and I had designed that interface badly.

The lesson that transferred

Most of my early frustration was my own imprecision. Naming the outcome I wanted and the constraint it had to respect works; describing a change and hoping does not. Written rules a session reads before it starts are worth more than any amount of correcting it afterwards. That transfers directly to working with people, which was not what I expected going in.