Humayun Rashid
Designer and founder in NYC
About
I’ve spent over a decade designing and building products across B2B SaaS and eCommerce. Most recently, I was on the early design team at Sublime Security, the fastest-growing cybersecurity email startup in the US. I led design on crucial launches like quarantine digests and tailored phishing simulations. Before that, I founded and led Nessa Lab, a studio where I advised founders and designed digital products for early-stage startups.
I care about what never makes it onto the screen: the onboarding flow nobody notices, the empty state that quietly loses the user, the setting that should’ve been the default all along. Getting those subtle details right starts with talking to users first, understanding where they get stuck before assuming you know the fix. That’s where the real work happens, and where most teams give up.
Great design is deciding what to leave out.
Case studies
Pack Platform
Turning a development agency’s custom commerce builds into a scalable, merchant-friendly SaaS platform.
Company: Pack | Role: Design Director | Team: Nessa | Year: 2023
The problem: Pack’s custom agency work had to become a product that hundreds of merchants could use without relying on developers or technical expertise.
The approach: Customer interviews before screens, then build less, but build it right.
The work: I led design across five workflows: the dashboard, developer setup, the site customizer, merchandising, and the design system.
The result: Happier customers, and an exclusive partnership with Shopify.
From bespoke builds to a real product
Pack started as an agency, building fully custom headless commerce sites for brands like Cuts and Vuori. That work was good because it was custom: a small team hand-building one storefront at a time, solving each brand’s problems directly.
After closing their seed round, Pack needed to evolve their product. The same team, the same expertise, but now serving hundreds of merchants instead of a handful of clients. That’s a harder design problem than it sounds like. Custom work assumes a developer is always one message away. A product has to let merchants and their non-technical teams run their storefront on their own.
As design director, I led the design of this transition with a small team, working directly with Pack’s product and engineering team, including CEO Cory Cummings, to define what “productized” actually meant for the business.
The first screen a developer sees: a checklist to connect GitHub, sync products, migrate blogs, set redirects, and customize.
Creating an account, and the email that invites a teammate.
Interviews before screens
I started with customer interviews, not screens. My team and I talked to merchants who’d tried other headless platforms, to learn where they actually got stuck rather than where we assumed they would. Three patterns emerged:
Onboarding was complex and took too long.
Merchandising tools felt bolted onto the commerce infrastructure instead of built for it.
There was no intuitive site customizer experience for headless builds.
That research drove one of the harder calls I made on the project: build less, but build it right. Instead of chasing feature parity with every competitor, I pushed us to prioritize the handful of workflows that would decide whether someone succeeded in their first week on the platform. Everything else could wait.
From there, I set the rhythm for a small, fast-moving design team: sketches into clickable prototypes, testing rough ideas with Pack’s team before committing engineering time, then refining based on what we learned.
The navigation system, light and dark, with the organization switcher and sync notifications.
One unified place to understand the business
Store owners needed one place to understand how their storefront was actually performing: revenue, traffic, conversion, site speed. Instead of a wall of charts, I organized the dashboard around what a merchant would actually want to check on a given day. A sidebar carries across multiple storefronts, so managing more than one store never feels like starting from scratch.
Drag to move from the wireframe to the final dashboard: revenue, customers, and usage, a conversion funnel, and prompts for next steps.
Opinion-free setup, built for developers
Modern headless builds mean wrangling a pile of apps just to get started. We stripped the setup down so developers could plug into Git with their own API keys and start building without an opinionated workflow forced on them, with real visibility into deploys and status instead of a black box.
A store owner’s profile: name, email, image, and password.
Members grouped by role (admin, store owner, developer), with seats, status, and per-person access.
Developer settings: a connected Git repository, API keys, and the storefront starter variables, each one copyable.
Deploys: auto-deploy on every change, with a history that shows what published and what failed.
Clockwise from top left: a store owner’s profile, members grouped by role, deploys with their history, and developer settings with Git and API keys.
Merchant-friendly editing, not an abstraction of it
I designed an intuitive site customizer experience around two core tenets: easy navigability and modularity. The customizer has a sidebar that slides out over a live preview of the actual storefront, so a marketer edits the real page, not an abstraction of it. Every component, from banners and product carousels to video modules and rich text, was built to the same global system, so swapping one out never breaks the page around it.
The goal was letting a marketer launch a new landing page or run an A/B test without pulling in a developer. That’s the actual measure of whether a customizer works.
A product page in the customizer: its template and sections on the left, the live storefront on the right.
Adding a section from the library, split into global sections (the same everywhere) and linked ones.
Jumping between pages and articles from the top bar, without leaving the editor.
The media manager: search and filter the library, or drop a file in to upload.
Review what changed, then publish now or schedule it for later.
Bundles in a few clicks, not a spreadsheet
Headless builds have a reputation for clunky merchandising, mostly because commerce infrastructure and merchandising tools at the time tended to get designed separately and bolted together after the fact. We redesigned this so merchants could build product bundles and collections through intelligent, attribute-based grouping instead of manual, one-by-one setup. It’s a small change with a large effect: what used to take a spreadsheet and a developer now takes a few clicks.
Product groups: subgroups on the left, the products inside a group in the middle, and a visual list of groups on the right.
The product catalog, synced from Shopify, with status and quick actions on every row.
One system, built to grow with the product
We designed the system from the ground up, evolving it from Pack’s existing product. It included a custom iconography library, a refreshed color palette, bold lifestyle photography, and a new set of UI components, each considered for its own use case, flexibility, and reuse across the platform. The goal was one cohesive kit that could extend to every touchpoint as the product kept growing.
The kit: type scale, form and navigation components, tags and toasts, shadows, and the color ramp.
Happy customers, and Shopify as a partner
The redesign was a clear success. Platform satisfaction, usability, and customer retention all improved, and merchants could build and launch on their own without a developer in the loop. Pack also formed an exclusive partnership with Shopify, becoming one of its recommended headless framework partners for Hydrogen storefronts.
The new Pack platform gives brands and agencies powerful front‑end tools to communicate with customers more easily. We’re incredibly proud of Nessa’s design work. Collaborating with their team allowed us to simplify the headless build process into a cutting edge software product designed for brand operators and developers.
Link: https://www.humrashid.com/#work/pack
Inveterate
Taking a loyalty and membership platform from zero to one for eCommerce brands.
Company: Inveterate | Role: Design Director | Team: Nessa | Year: 2022
The problem: Replace points programs with a premium membership model, for merchants who want to build relationships with their customers.
The approach: Map every place the platform has to bend, then build one system that flexes both ways.
The work: Four pieces: the brand system, data and analytics, a menu of benefits, and the program builder.
The result: Adopted by notable CPG brands, and later acquired by Onward.
Loyalty, rebuilt for a different kind of shopper
Most loyalty programs are still built around points that customers rarely redeem and brands rarely benefit from. Inveterate’s founder, Dylan Whitman, wanted to replace that model entirely with a premium membership program, closer to Amazon Prime, built specifically for independent eCommerce brands.
The platform had to work for two very different audiences at once: self-serve merchants who wanted to launch a program in a few clicks, and larger enterprise brands who needed a white-glove build with full control over pricing, benefits, and branding. Same product, two very different comfort levels with software.
As design director, I led design on the platform end to end, working directly with Inveterate’s founder and product team to take the idea from a raw concept to something merchants could actually run their business on.
The brand and the product together: a bold wordmark over the platform on a laptop and a tablet.
One system, built to flex two ways
I started by mapping out every place the platform needed to bend: a merchant setting up their first program in an afternoon, and an enterprise brand customizing every touchpoint of theirs.
That split shaped almost every decision that followed, from the design system down to how a single benefit gets configured.
Setup starts with a few questions: monthly order volume, average order value, and whether the merchant works with an agency.
The welcome screen: a short video, a scheduled onboarding call, and a checklist to set up the company.
The kit: a dark palette with violet accents, form fields and controls, and the type scale.
A product with more brand personality than B2B usually allows
Most B2B platforms play it safe. Inveterate wanted the opposite: a bold, irreverent identity that felt more like a consumer brand than backend software.
We started from their existing brand system and built out the design language, logo, color system, and UI kit to carry that same attitude through the whole product, so the merchant experience stayed cohesive and consistent.
One picture of the whole membership program
Merchants needed one place to understand their program: who signed up, how much they’ve spent, what’s selling, where churn is happening. None of it was useful scattered across spreadsheets.
I designed a unified dashboard that pulls the membership lifecycle into a few clear views, with data tools built into the platform behind it, from year-to-date sales down to which products were selling today. A decision that used to take a spreadsheet takes a glance.
Drag to move from the wireframe to the final dashboard: subscribers, monthly revenue, lifetime value, and the leaderboard of top categories.
A single customer: their subscription and spend, with a credit history underneath.
Active customers in a filterable table, with status, spend, and dates on every row.
Account tools for one customer: adjust credits, edit a birthday or join date, cancel a subscription, or anonymize the account.
A flexible menu of shopper perks
The value of a membership program comes down to what’s actually inside it. We designed a library of benefits: exclusive drops, tiered discounts, expedited shipping, referrals, and store credit, each built as a modular, tiered add-on so merchants could shape a program around their own customers instead of a fixed template.
Credits as modular benefits: store credit, birthday, anniversary, referrals, and credits for reviews, each switched on or off.
Configuring a benefit in the builder, next to the content blocks for the program’s landing page.
Launch a program in weeks, not months
At the center of the platform is the builder: the tool merchants actually use to stand up a program. I designed it for real flexibility and modularity: every piece (tiered pricing, benefit activation, a custom landing page) is a component that can be configured on its own. That let a brand either launch fast through self-service or work hand-in-hand with Inveterate’s team for a fully white-glove build.
The landing page builder: sections on the left, and a live preview on desktop and mobile.
Zero to one, and a category of its own
The platform shipped with a full set of benefits merchants could switch on out of the box and integrations with the tools brands already used, so self-serve and enterprise brands alike had a real program to launch on day one. It went on to power loyalty and membership programs for notable CPG brands like Fly By Jing, Bylt, Cuts, and more. Inveterate was later acquired by Onward, which folded it into a wider platform built to grow customer lifetime value.
It’s rare to find a design partner who can take a raw idea with a very specific and unique vision, yet turn out a beautiful user experience that can support both our self service and enterprise customers. Every element provided by the Nessa team was purpose-driven towards providing a frictionless experience for our users, but more importantly, a scalable one.
Link: https://www.humrashid.com/#work/inveterate
PPVP
Designing an exclusive investment app for accredited investors.
Company: PPVP | Role: Design Director | Team: Nessa | Year: 2023
The problem: PPVP wanted to open its exclusive fund to more investors, but access ran on Excel files and emailed expressions of interest, so it needed an exclusive mobile investing app.
The approach: Talk to as many investors as possible, then work backwards from what they care about.
The work: I designed five pieces: invite-only onboarding, the feed, deal discovery, a UI kit, and the admin tools.
The result: Strong investor traction, with active deal flow every week.
Institutional deal flow, opened up to individual investors
Parri Passu Venture Partners backs early-stage eCommerce and SaaS founders, and wanted to open its fund to a growing list of investors outside of it, giving them direct access to the kind of exclusive deal flow usually reserved for firms like Sequoia, Sierra, and Upfront. Until then, interest came in through Excel files and emails, with no way to scale it. The plan was a members-only mobile app, invite-only from the first screen, built specifically for accredited investors.
The hard part wasn’t any single screen. It was the tone. Every part of the app, from the sign-up flow to how a deal gets published, had to feel as selective and considered as the fund itself. A generic fintech UI would have undercut the entire pitch.
As design director, I led design on the platform end to end: the investor-facing app, the design system underneath it, and the internal admin tools the PPVP team uses to actually run it.
The first three screens an investor meets: a welcome, a request to join the waitlist, and a place to enter an invite code.
Start with the investors
I started by talking to as many investors as possible. My team and I asked how they look at deal flow, how they decide which startups to back, and what they expect from a great investment opportunity, to understand their intent and where the current process fell short for them.
From there, I worked backwards: the onboarding flow, the overall experience, and the process of investing itself, all shaped around what investors actually cared about. The design system came later, once the needs were clear, to carry a quiet, editorial tone through every screen.
The design system, built once the research was done: a type scale, buttons and form fields, and a palette of soft pastels with a deep indigo and a near-black.
Access that has to be earned before it’s granted
We made sign-up invite-only by design, gated behind a 6-digit code and FaceID, with a direct LinkedIn import so a profile could be verified without a pile of manual fields. Anyone without a code could still request access, but the default path was always: you’re here because someone vouched for you.
Once inside, I added a short set of guided onboarding questions about an investor’s past experience with venture deals before they ever saw an opportunity. That context mattered more than any single UI decision: it’s what let the feed personalize itself from day one instead of showing every investor the same generic list.
The path in: request access, answer a few questions about past experience, turn on notifications, then land on the home screen.
One feed, the right information at the right time
I gave the home screen one job: surface the right thing at the right moment without turning into a wall of charts. A portfolio summary sits at the top, followed by a single curated feed mixing new deals, company updates, and notes from the PPVP team, ordered by what actually needs an investor’s attention rather than by section.
I kept navigation deliberately simple, so access never felt like work. Home pulled new deals and the latest company news into a single view, while Explore opened up exclusive deals available only to PPVP members.
The Portfolio tab: the total, and the deals an investor is in, each with its amount and status.
The same feed on a phone, with company news alongside deals.
Explore active deals without losing the thread
I split discovery and portfolio tracking into two tabs instead of one crowded view: Explore for new deals available to members, and Portfolio for tracking what an investor already has money in. Opening a deal from either one leads to the same detail view (terms, pitch deck, memos), so requesting an allocation is a couple of taps, not a phone call.
The home feed in motion: the portfolio total, a new deal, and news from PPVP, in one stream.
A component system built to outlast launch
PPVP’s team was always going to keep adding features after launch, so I built the interface kit as a real system, not a one-off screen library: form fields, buttons, cards, and interaction patterns that could be recombined without a designer in the room every time.
The same deal template, reused across mobile and desktop, is a small example of the bigger idea: one component, built once, holding up everywhere it’s needed.
The component sheet: toggles, settings rows, buttons, invite and allocation controls, and a FAQ, all from the same kit.
Everything the PPVP team needs to run the platform
Behind the investor app, we built an admin panel that’s part CMS, part user-privilege system. The PPVP team publishes new deals, edits terms and closing dates, manages investor profiles and invitations, and pushes updates straight to the feed, all through simple forms, so getting a deal live never waits on an engineer.
Building a filter by status, who invited them, or how much they have invested.
The investor table: status, who invited each person, and when they joined, with bulk actions for selected rows.
Real traction with real investors
The app took off with investors. Active deal flow now runs through it every week, with investors coming back to review new opportunities, request allocations, and follow the companies they back. The invite-only feel held up past the first screen, in how people actually used the app and not just in how it looked on the way in.
A company in the admin: its deals, the founder asks, and the investor updates, each with its own create button.
Nessa has done an incredible job from a design standpoint, providing us with unique and innovative designs that are rooted in research, not just aesthetics. We’ve also enjoyed working with their team; they feel like a true partner.
Link: https://www.humrashid.com/#work/ppvp
Ideas
My portfolio is a piece of software
2026-10-28
I designed and built this site with Claude Code. Here’s how.
My portfolio isn’t a normal website. It’s a piece of software, and I built it with Claude Code for two reasons. I wanted to go down the rabbit hole on a tool I’d only scratched the surface of, and I wanted to see how far a semi-technical designer could take it alone. A few weekends later, here’s what I built, why I built it this way, how I set it up, and what I think it means for designers.
Why I built it myself
For most of my career, I didn’t need a personal portfolio. I ran my own studio, Nessa Lab, and the studio’s site was where the work lived. Moving into product design changed that. It’s a different body of work, and it needed a home of its own.
I could have handed it to a developer friend or customized an off-the-shelf template. I didn’t want either. I wanted full creative control to design something wholly my own. I’d been designing with AI at work, and a portfolio was the perfect excuse to go deeper: low stakes, and a real product at the end.
Credit where it’s due: my former design colleague Patrick Morgan [wrote up how he rebuilt his portfolio with Claude Code](https://itspatmorgan.com/writing/how-i-rebuilt-my-portfolio-with-claude-code/), and it’s what finally pushed me to get started. Read it, and subscribe to his newsletter while you’re there. This is my take, with a different setup and a different goal.
A portfolio that behaves like software
I design software for a living. Workflows, interaction patterns, data-heavy dashboards. Underneath all of it is one job: organizing information so people can act on it.
So why not design my portfolio the same way?
Too many designer portfolios run on the same template: a hero, a grid of case studies, an About page. They show the work but say nothing about how the designer thinks or what their style is. I wanted mine to make the argument before anyone opened a case study. That meant treating it like a real product, with its own navigation rail, interaction patterns, and a dashboard pulling in outside data I care about, like my GitHub commits and my Strava running log.
(If you check that running log right now, go easy on me. It’s been a quiet two weeks since the Chicago Marathon.)
That’s also why I used a coding agent instead of a site builder. Site builders give you pages. I wanted software. Frontier models are finally good enough to make that realistic for one designer, so I took Claude Opus 5.5 for a spin to see how far it would go.
Scope hard, then let it grow
The fastest way to stall an AI build is to give it no edges. Claude Code will happily build anything you describe, so the constraints have to come from you.
Before opening it, I wrote a one-page scope: the app shell and navigation, the homepage dashboard, a reusable case study template, and an About page. No CMS, no contact page. Everything else went on a “for later” list.
That list is where the extras live, and some of them have already shipped. Scoping didn’t kill those ideas. It gave them a stable foundation to land on.
My personal rule of thumb: if your scope doesn’t fit on one page, you’re not ready to build v1.
The stack, and why
Every tool earned its spot by doing one job.
1. [Astro](https://astro.build) v7 renders every page. The site is mostly content with a few interactive pieces, and Astro ships plain HTML by default, loading JavaScript only where it’s needed. Next.js would have worked, but it’s built for full apps, and I’d have been carrying complexity I didn’t need.
2. [Tailwind CSS](https://tailwindcss.com) v4 handles styling. I could change layout right where I was building instead of jumping between files. The catch: out of the box, every Tailwind site looks like every other Tailwind site. I swapped the default tokens for my own on day one.
3. [shadcn/ui](https://ui.shadcn.com) gave me the scaffold for buttons, cards, and other UI components. It’s code copied into your project that you own outright, not a package you install. I’ll say it plainly: if your site looks like stock shadcn, people can tell. I kept the structure and rebuilt the look.
4. [GitHub](https://github.com) and [Vercel](https://vercel.com) handle the rest. GitHub holds the code and every past version of it. Vercel builds and hosts the site. More on why Vercel below.
How the tools connect
Claude Code writes the code, GitHub stores it, and Vercel turns it into the live site. Astro, Tailwind, and shadcn/ui work side by side inside the codebase, which is why they share a box.
How I worked with Claude Code
I started from an empty repo. Nothing to inherit, nothing to work around.
Before any code, I wrote a detailed Markdown file with everything Claude needed: design direction, fonts, the one-page scope, and the case study content I already had from my studio work. Claude Code reads that file every session. The more specific it is, the less Claude guesses, and the less you repeat yourself when a session runs out of memory.
The visual direction started where it always does for me, as a moodboard in Figma.
From there the workflow was a loop: build one section, review it, call out what’s off, refine, move on. Don’t try to one-shot a portfolio unless you enjoy AI slop. Treat Claude like a fast collaborator who needs clear direction, not a vending machine.
One template, no CMS
Every case study runs on the same component. A new case study is new content, not a new layout. Once the template worked, adding work became a writing task, not a design task.
I also skipped a CMS entirely. I edit content through Claude Code and push it to GitHub like any other change. No admin panel, no extra login. The trade-off is real: you have to be comfortable in a code repo. For a one-person site, that’s an easy call. For a team with non-technical editors, I’d make a different one.
Why Vercel: a site that’s live, not frozen
GitHub Pages only serves static files. What you push is what every visitor sees, frozen until the next push. That’s fine for a brochure. I wasn’t building one.
Vercel supports serverless functions, small pieces of backend code that run on demand. They let the site call an outside API and pull data in without me running a server. Today that powers two things:
1. My Strava running log, pulled from my account so new runs show up on the homepage dashboard on their own
2. My GitHub commits, so the dashboard shows what I’ve actually been building
A fun little easter egg. I wanted the homepage to show two things I care about outside of work: running, and getting more comfortable around code. Every panel is live, and hovering any day tells you what happened, including the 2026 Chicago Marathon.
The weather panel didn’t even need one. It reads a free public forecast straight from the browser.
Neither is a big feature. That’s the point. Once the plumbing exists, the next data source is a small task, not a platform migration.
Two extras came with the move:
Preview links: every branch gets its own URL, so I can check a change before it’s merged to main and goes live
Built-in analytics: I can see whether anyone’s actually visiting
What actually got faster
AI made the building fast, but it didn’t make the deciding fast.
Scaffolding a section, wiring a layout, a first pass at styling: faster than I’ve ever done it. Knowing whether that first pass was right took as long as it always has. Sometimes longer: there were more options on the table, and the agent kept needing small visual corrections.
The skill this sharpened wasn’t technical, and it wasn’t prompting. It’s the one you use in a good crit: spotting the thing that’s almost right and isn’t, before it ships.
What this means for designers
For most of design history the line was clear. Designers design, engineers build, and every so often the two meet in a Sergio Leone-style standoff over scope. The designer hands off a Figma file and waits.
That line is gone. Not because designers are becoming engineers, though some of us partly are, but because one person can now carry an idea from sketch to shipped product without losing fidelity in the handoff.
When building gets cheap, judgment becomes the scarce value. The question shifts from can you build it? to should this exist, and why? That’s a designer’s question. It always was.
You don’t need to become a design engineer. But if you design software for a living, you should be able to ship something real on your own. A few years ago, a portfolio with live data, reusable components, and its own deploy pipeline meant hiring a developer. For me, it took a few weekends, some curiosity, and a clear scope.
Pick the thing you’ve been meaning to build, and go build it.
Link: https://www.humrashid.com/#ideas/my-portfolio-is-a-piece-of-software
Race day is just another long run
2026-10-05
What training for marathons has taught me about being a designer.
I’m running the Chicago Marathon this Sunday, my third. Somewhere between the long runs and the sea of Figma files, I noticed I talk about both the same way. Neither rewards a single burst of effort. Both come down to showing up and putting in the reps.
Nobody nails it the first try
The first mile of a new training block feels awful, and so does my first draft of anything. When I learned type, the concepts took a while to hold. When I built my first design system in Figma, same story. Colors, tokens, systems thinking: none of it clicked until I had gotten it wrong a few dozen times. I didn’t get a stronger stride from one great run. I got it from the hundredth ordinary one.
I’ve had creative outbursts and days when everything just clicked, but they never guaranteed anything. Repetition did. The tools keep changing, like my shoe rotation. Claude Code has transformed my design process again, but the routine of showing up and getting a little better every day hasn’t.
There’s always a race on the calendar
Reps need somewhere to point. A 20-week training block works backward from race day, the same way I work backward from a feature launch. The date turns a habit into a plan, and the constraint forces better decisions.
Some days I just don’t have it. The system does the work: a component library, protected blocks on the calendar, jam sessions with the team, a long walk with my dog to think a problem through. Process is what shows up when motivation doesn’t.
Everyone hits the wall
Marathons hurt like hell. Around mile 20 the body shuts down and the mind screams to stop. Design has its own wall: the team review where nothing lands, the flow I’ve redrawn a dozen times, the Figma file named Project_files.final.FINAL.V3.
The way through is the same in both. Make the next step small. Run to the next light pole. Fix the one screen. Refine, iterate, throw out the bad ideas, start again. It wears me down either way, physically on the road and cognitively at the desk, so I take it one step at a time.
The work is done before race day
After four or five months of weekly mileage, strength work and dialing in nutrition, the outcome stops being a leap and race day is just another long run. A good design review is built the same way, well before the kick-off meeting. I frame the problem, prototype, talk to users, throw out what doesn’t work, and repeat until the solution is so obvious I wonder why I didn’t see it sooner.
Love the boring miles
Both only work if I love the thankless parts. Managing Figma files. Naming and organizing the countless layers. Updating the design system. Waking up early to run before work. Doing post-run mobility. If I don’t love doing that while no one is watching, I won’t enjoy any of it, especially on race day.
Nobody cheers for the Tuesday morning run, but that’s where the marathon gets decided.
Link: https://www.humrashid.com/#ideas/race-day-is-just-another-long-run
The interface is becoming ephemeral
2026-09-24
The screen you use may soon be built for you, on demand. What does that mean for designers?
The other day I asked Claude for a marathon training guide to organize my training block so I could simulate race-day scenarios. I never asked for an interface. It gave me one anyway: a clean, working HTML page, laid out month by month around exactly what I needed.
I could have asked for a tracker styled like a 1990s Tamagotchi, and it would have built it in a few hours. It would be wholly unique to me, and nobody else would ever use it. A few years ago, that sentence would have been absurd.
Here’s my prediction: the interface is becoming ephemeral and amorphous at the same time. Ephemeral, because it gets generated for a moment and then disappears. Amorphous, because it takes whatever shape the person and the device need.
We used to be what we made
For a long time, a product designer’s identity was rooted in output. We designed interfaces, made them beautiful, and solved real problems for real people. Every era of computing handed us a new canvas: the terminal in the 80s, the early web in the 90s, operating systems and a maturing internet in the 2000s, then social media, when interfaces started to feel connected.
The canvas changed, but the job stayed the same: design for the screen.
Then the screens multiplied
When the iPhone launched in 2007, we had one new paradigm to learn. Now there are smartwatches, TVs, tablets, car dashboards, and pendants with always-on AI (RIP Humane). Input has spread out too: we talk, tap, glance, gesture, and hand routine tasks to agents.
Designing a fixed interface for a fixed screen stops scaling in that world.
Now the models draw the UI
I’ve been using Claude Opus 5.5, which can produce a vintage Winamp player skin or a full B2B SaaS shell in minutes. That used to take weeks of iteration and polish. The execution layer of design has become cheap, and it will only get cheaper.
What changes is who decides what the interface looks like. It’s no longer a designer shipping one version to everyone. It’s a model shaping something around one person’s intent and context, in near real time.
That’s exciting, because it lets everyday people think like designers and solve their own problems. It’s also a little uneasy, because it’s our craft being democratized.
The real interface is the context layer
Here’s the part I keep coming back to. If the interface is generated on demand, something has to know what to generate. Your phone, watch, TV, and pendant all need to share one understanding of you, whether it comes from a local model on device or a frontier model that holds your full context.
I think that context layer is becoming the core interface. Buttons and form fields don’t vanish, but they become one possible output among many instead of the product. Interaction is going more sensory too: audio, video, ambient context. The visible UI shrinks, and the real work happens in the layer you never see.
What we might lose
I don’t want to be naive about this. Standardization gave us learnability, accessibility, shared mental models, and, most importantly, trust. If every interface is bespoke, how do two people collaborate in different UIs? How do you spot a fake when nothing looks familiar?
Operating systems show the tension. Apple keeps pulling macOS and iOS toward one shared design language in Liquid Glass, while generated interfaces pull the other way, toward the individual. My bet is that both survive: a stable layer of familiar patterns for anything that touches trust, like payments, permissions, and security, and a fluid layer for everything else.
Please, not another chat box
One trend I’m confident about is that a chat box with a little diamond logo is not the future of AI design. Everyone is doing it, which is exactly why it’s lazy.
There’s no killer use case yet. Every standard bearer is guessing: maybe audio, maybe chat, maybe something else. Voice isn’t the problem. The problem is copying one modality everywhere and calling it an AI strategy. My bet is that whatever wins looks vastly different, and I’d be surprised if it’s a text field.
So what is a designer now?
Honestly, I don’t know exactly what the job becomes.
If our identity was built on the output we produced, and interfaces are now generated per person, per moment, per device, then something about what we do has to change.
But I do know what stays: judgment. It has never been more important to have a point of view and a vision for a product. Years of failures, iterations, and hard-won experience shape what the output should look like. Execution is cheap now, but the intent, judgment, and strategy behind why we design something at all matter more than ever.
The interface may be ephemeral. The judgment behind it isn’t.
It’s going to be chaotic, and that’s the fun part
I think the future of design will look weirder than we expect and show up everywhere. It will be chaotic magic.
It’s the most exciting moment in a long time to be a designer, because AI gives everyone a chance to build their own answer to how software should work. The field is wide open. Go forth and build.
Link: https://www.humrashid.com/#ideas/the-interface-is-becoming-ephemeral
Process
From an ambiguous problem to a tested direction.
Bring every stakeholder along (Frame): Every product I’ve shipped had a narrative, and every person touching it needed to hear the same one. I retell it until engineering, sales, and leadership are solving the same problem.
Talk to users as early and as often as possible (Map & sketch): I’ve never regretted a user conversation. I’ve regretted plenty of assumptions. This is the one step I don’t skip, no matter how confident the room feels.
Simple is hard (Decide): Cutting a feature takes more conviction than adding one, and the constraints behind it (time, headcount, scope) never hold still for long. What survives isn’t just what mattered on day one. It’s what still holds up.
Prototype from day one (Prototype): Specs go stale the moment they’re written. I’ve built this way for a decade: a rough, clickable version in week one beats a polished document in month three, every time.
Show, don’t tell (Validate): Ten years of shipping taught me decks convince nobody. A working prototype argues my case better than I ever could, so I build the real thing first and explain it second.
Stay through the build (Handoff): A handed-off flow is the start of the work, not the end. I stay close through the build, answer the questions a spec can’t, and check what ships against the measure we set on day one.
Apps
rendr: Polished backgrounds for any image to share across social. https://www.humrashid.com/apps/rendr
Atrium: A curated library of books, articles and sites worth your time. https://www.humrashid.com/apps/atrium