Selling automation to MSPs is a specific rhetorical problem: the buyer is the person whose team the software is about to change. The pages had to lead with capacity rather than replacement.
See it live at neels.ai.
]]>Launch pages are a deadline discipline more than a design one. The work is having a system good enough that a new page can be up in days without every launch becoming a fresh argument about typography.
See it live at www.sarvam.ai.
]]>Medical device marketing runs on a narrow rail — you have to be compelling to clinicians and investors while staying accurate about what the device does and doesn’t claim. The restraint is the design.
See it live at www.neuro-sonic.com.
]]>Designing for an arts foundation means getting out of the way. The work on the site is the point, and the job of everything around it is to frame without commenting — which is much harder to do well than it is to describe.
See it live at anantfoundation.art.
]]>There’s a nice recursion in designing the brand for a product that designs presentations: everything we made was implicitly a demonstration of the standard the output should meet. It kept us honest.
See it live at presentations.ai.
]]>The phrase doing the most work in that sentence is human oversight. Enterprise buyers evaluating agent platforms are asking one question underneath all the others — what happens when it goes wrong — and the design had to answer it early rather than bury it.
See it live at sycamore.so.
]]>As a designer who spent four and a half years at Microsoft working on products like Word and Copilot, I was always on the design side of the handoff. I’d do the research, make the designs in Figma, work with a PM on the spec, and wait for a developer to pick it up. One of the reasons I left my job at Microsoft was that I felt this way of working was going the way of the dinosaur.
Now I’m on the other side of that wall, designing and building things myself with Claude Code, and the view is very different from here.
Something has shifted in how projects start. I’ve had multiple recent clients send me a vibe-coded prototype and ask me to base my designs on it. I haven’t seen a wireframe in months, and I rarely get a brief — instead I get a working thing they prompted into existence. The workflow has literally inverted. Developer time was scarce and it made sense to wait for specs or at least wireframes before any development started, but now the code sometimes comes first and design is the refinement layer.
How long should it take to design a full app? I used to say three months. Now that feels like an eternity. If you approach this with an attitude that’s open to iterative testing and improvement, you can move a lot faster. But there’s a real risk in this speed. AI makes the most boring, obvious solution instant. The card grid. A text input and a button labelled “Get Started“. The layout you’ve seen a thousand times. I think designers should be pushing for the truly great stuff — the interactions that surprise people, the details that make something feel considered. That’s harder to prompt for, and it’s exactly where designers earn their keep.
I’ve started to think of product design less as a job title and more as a lens through which you approach making software. It’s entirely possible that very soon a developer and a designer both spend most of their day instructing an Agentic Coding tool that spits out working code. Figma already has Figma Make, and Lovable has design mode. The tools are converging, but what’s different is what you notice and what you care about. Designers care about how things feel. They tend to be detail-oriented in ways that matter to the person using the product. That doesn’t go away just because both people are using the same tools.
When code becomes cheap, more people want to make more things. The expectations on designers are through the roof right now. Nobody knows how long anything should take anymore. But I think this is actually exciting.
If you’re a designer who wants to try building with Claude Code and Figma, here’s what I’ve found works well.
The single most useful thing for connecting Figma to Claude Code is the Figma MCP server, which lets Claude read a link to your Figma directly — understanding your components, variables, styles, and layout structure. It’s not just looking at a screenshot; it semantically understands your design system.
Use the online hosted MCP server, not the local one. The local version is fiddlier to set up and maintain. The online server just works. Connect it, point Claude Code at a frame in your Figma file, and ask it to build what it sees.
Set up your text styles. Get your color tokens defined. This is the foundation, and it’s the part that benefits the most from getting right early because you will be able to speak the same language as the code. If your Figma variables are called things like primary-500 or surface-default, the AI will understand what you mean much more reliably than if they’re called Blue 3 or New Color Style 47. You’re essentially making your design system predictable and machine-readable, which is exactly what the AI needs. Tailwind’s naming convention for variables seems to work best at the moment.
Set up your primary and secondary buttons in code first. Figure out their hover and active states. Get a feel for how components are handled. Componentize any other repeated blocks.
Once your components and tokens are set up in code, try to one-shot a page. This doesn’t always work, but it’s magical when it does. The context window tends to run out on longer pages — you’ll likely get a starting point, but the context window runs out lower down and sometimes the first section will be perfect but the footer will be nothing like what you asked for. You can fix thing section by section or component by component. If you’re patient, it’s possible to get very high fidelity prototypes that are automatically set up to be interactive. The kind of thing that would have taken days to build by hand in Figma.
I was really hoping to be able to fire off an agent and let it run in the background while I do other things. And to be fair, you can. But in practice, for anything more complicated than a single page I’ve found it’s worth reviewing the plan that Claude Code generates before it starts executing. Even if you’re not very technical and don’t fully understand every line of the plan, you can catch things — wrong assumptions, missing requirements, an approach that’s going to lead somewhere you don’t want. This saves a lot of iteration cycles (and tokens).
You can also add a line to your Claude Code preferences that tells it to ask you clarifying questions before it starts working. This is a small thing that makes a big difference. It turns the interaction from “hope it does the right thing” to “have a quick conversation and then let it go.” Designers already know how to give feedback and direction — this is the same skill, applied to a different collaborator.
The traditional design-to-developer handoff with its redlines, its spec documents, (who remembers Zeplin exports?) — is fading. Not because it wasn’t useful, but because the gap it was bridging is getting narrower. When a designer can build a working prototype directly from their Figma file, and a developer can read that Figma file through MCP, the handoff becomes less of an event and more of a continuous conversation.
The parts of the handoff that always mattered most were never the pixel specs anyway. It was the conversations. Why did we choose this pattern? What happens on the edge cases? How should this feel? Those questions don’t go away with AI in the middle. If anything, they get more important, because the AI will happily build the wrong thing with perfect precision if nobody asks the right questions. If you’re a designer who can articulate what “good” looks like, describe interaction patterns clearly, and push back when something feels off — you’re more valuable now than you were two years ago, not less.
]]>Here’s what I’ve learned about what works.
Before I even click on a project, your portfolio site itself tells me a lot. It tells me whether you understand responsive design, visual hierarchy, and interactive experiences. It tells me if you care about the details.
Use Framer or build something in code. At the very least, use a nice Framer template. There are so many good options out there now for getting a polished, interactive portfolio up that a bare Notion page feels lazy. I know that’s a strong opinion — and I’ll soften it by saying that having any portfolio at all is much better than having none. Start wherever works for you. But if you’re applying for product design or UX roles, your website should feel like something you designed, not something you typed into.
The platform you choose is a signal. A Framer or Webflow site says you understand interactive, responsive experiences. A custom-coded site says even more. A Squarespace template with nice content is perfectly fine. A Notion page with a dozen links says you didn’t prioritise this, and that tells me something too.
I don’t want to read three paragraphs of context before I know what you actually made. Show me the outcome first. What shipped? What did it look like? What changed because of your work? Once I’m hooked on the result, I’ll happily read about how you got there.
The classic problem-process-solution case study structure isn’t dead, but it’s gotten stale when everyone follows it mechanically. If you’re going to walk me through your process, make it worth my time — show me the interesting decisions, the moments where you changed direction, the constraints that shaped the outcome. Skip the part where you explain what a user persona is.
This might be my most contrarian take: I would rather see a side project you’re genuinely excited about than boring production work. If your day job has you tweaking form fields in an enterprise dashboard, that’s fine — that’s real work and it matters. But it’s not going to make me stop scrolling.
Side projects show me that you care about design beyond your 9-to-5. They show initiative, curiosity, and taste. A weird little app you built over a weekend, a typeface you’re working on, a data visualisation of something you find interesting — these things tell me more about who you are as a designer than a case study about optimising a checkout flow.
This doesn’t mean production work has no place in your portfolio. If you shipped something at scale and can talk about the impact, absolutely include it. But don’t pad your portfolio with work you’re not excited about just because it happened at a recognisable company.
Since a big part of the work we do at the studio involves landing pages and marketing sites, I care about visual storytelling. But more generally, what I’m really looking for is: do you understand hierarchy well enough to know what to point my attention towards? And do you know how to achieve that visually?
This applies to your case studies too. A wall of text with a few screenshots at the bottom doesn’t cut it. Use images, annotations, before-and-after comparisons, and clear visual structure to walk me through the story. If your case study itself has poor hierarchy, I’m going to wonder about the hierarchy in your actual designs.
A lot of designers at larger companies can’t show their best work. This is a real problem, but it’s not unsolvable.
Show the process. You can talk about the problem space, your approach, the research methods, and the decisions you made without revealing proprietary screens. Anonymise the details responsibly — change the company name, abstract the specifics, but keep the substance.
When the project launches and becomes publicly available, it’s usually no longer bound by NDA. If it shipped, show screenshots of the shipped UI. Password-protected NDA-bound projects are generally considered acceptable across the industry, but check the exact terms of your NDA before assuming.
And if you truly can’t show anything from work — that’s what side projects are for.
This is new advice, and I think it matters. If you’re using AI tools in your workflow — whether that’s generating UI concepts, prototyping with vibe coding tools, using LLMs for research synthesis, or building with Claude Code and Figma MCP — show it. Demonstrate that you know how to leverage these tools smartly. It’s a skill, and it’s one that’s increasingly valuable.
I’m not saying dedicate a case study to “I used ChatGPT.” I’m saying that if AI was part of how you worked through a problem, don’t hide it. The designers who’ll do well in the next few years aren’t the ones who avoid AI — they’re the ones who use it thoughtfully and know when it’s helping and when it’s getting in the way.
I read it. I want to know who you are, what drives you, and whether I’d enjoy working with you. Recruiters are curious about your personality — your side projects, your hobbies, something you do for yourself or your community could be what speaks the most about you as a person.
Don’t overthink it. A few sentences about who you are, a photo, and links to find you elsewhere. But don’t skip it.
If you’re putting together a portfolio right now, here’s what I’d focus on:
The best portfolios I’ve seen don’t just document work — they demonstrate how someone thinks. That’s what I’m hiring for, and it’s what your portfolio should show.
]]>They were my contribution to visual design at SPC, and they’re built from assets already in the brand system rather than anything invented for the occasion — the monogram, the type, the illustration and image treatments were all there. The work was choosing among them and deciding what a bookmark, specifically, should do.
A bookmark is an unusual object to design. It is tall and narrow, it is seen edge-on more often than face-on, and it spends most of its life inside a book with only an inch showing. So the top of the card carries the identity and the bottom carries the call — “What are you curious about?”, “Want to invent the future?” — and the long middle can be given over entirely to image.
