Loading stats…
Reading the work
Six ways of looking at the work above. Two are drawn from the real project list below; the rest are illustrative, not measured data.
Illustrative figure, not a measured audit result.
Skill areas by frequency
Project × tag matrix
Showing all projects. Click a tag above to filter to projects that carry it.
FAQ
Grouped by theme, click a question to expand. Where an answer references a specific project, its name links to that case study.
These answers are first drafts written with Claude from the case studies and my notes. I am editing them.
How do you usually start a new project?
I start with what already exists: the tickets people have raised, the spreadsheets they email each other, the previous tool, or the client's proof of concept. Those show the real requirements. Before I design any screens, I write down the objective, what the project will not cover, and how we will judge whether it worked. If nobody has set success criteria, I write them and put them in the project document. I also send a first wireframe early, before I fully understand the domain, because corrections on a wireframe teach me the domain faster than reading about it.
Walk me through how you go from an ambiguous brief to a finished design.
First I write the frame: objective, non-goals and success criteria, in a few lines. Then I find the people who understand both the domain and the engineering, and I keep two lists of questions for them, one about the domain and one about the users. I produce wireframes quickly and send them out for correction. To decide between options, I test them rather than debate them: real users go through written scenarios on dummy data and think aloud, and I watch for where they get confused. I ship the version that meets the need with the resources available, and I document what was left out and why, so the next phase can pick it up. The D.E. Shaw overview shows this process across four business units.
How do you decide when a design is done versus when it needs another round?
A design is done when it meets the criteria set at the start and the user tests stop finding new problems at the same step. It needs another round when a test finds a problem nobody expected. In the date picker, that was the switch between day, month and year views. In Nirnay, it was that nobody ever chose the risky business option. Resources also matter. If the cheaper version passes the test, it ships, and the better version is documented for the next phase.
What's the throughline across your work, given how different your projects look on the surface?
Each project involves a dense body of information that someone has to act on: a team's compensation, a 40-year dataset, a lifetime of financial decisions, the documents of a legal case, a margin calculation. In each case the work is to show the relevant data at the point where the decision is made, without simplifying it into something inaccurate, and to keep a record of what happened. The projects look different because the data is different. The approach is the same.
How do you balance usability with visual craft when they pull in different directions?
Usability comes first. Visual craft decides whether people want to keep using the tool. In enterprise tools the screens are dense on purpose, and the craft goes into hierarchy, alignment and what is one click away, not into whitespace. When the two conflict, I fix usability first and then polish. The test of the Evolution Data Story gave the feedback "very nice to look at, but the interaction could be more polished". That is the order I would expect to fix things in.
What's a design opinion you hold that not everyone agrees with?
A chat window is the wrong interface for most AI products. It suggests the product can answer anything, so every refusal looks like a failure. I have designed against it twice: a research assistant at D.E. Shaw that returned lines of inquiry with sources instead of a single answer, and Mercury Ask, where the client's brief said the tool must not look like a chatbot. The more capable the model, the more the interface needs to show its sources and its limits. A second, smaller opinion: for expert users, a dense screen is easier to use than a simple one that hides the data in another tab.
What did two years of independent work actually teach you?
I left my full-time role after three years to take a deliberate two-year break from that structure, not to step away from design. After three years the work had settled into a rhythm I knew well, and I wanted to grow faster than that rhythm allowed. I wanted to leave the system long enough to actually observe it from outside, and figure out how to realign myself as a designer for a world that's changing faster than most teams are built to handle. What follows is what that break actually taught me, and it's still growing: I'll keep adding to this as I learn more.
I'm looking for what comes next to solve the exact problem that sent me out here in the first place: a place where I can grow as fast as the market is moving, which is why I'm aiming at either startups or a leading tech company rather than another large, slow-moving team.
Free-Range Exploration & Learnings (2024–2026, ongoing)
Last updated: September 2026. Editable directly in this page's HTML as new entries are added.
Seven things two years of independent work actually taught me.
1. Never say no, always ask why.
Bill Hader has a line about comedy that applies just as well to design: "When people tell you what doesn't work, they're usually right. When they tell you how to fix it, they're usually wrong." The same holds in UX. Feedback about a problem is almost always worth taking seriously. Feedback about the solution rarely is, at least not literally. Listen hard to the "what's wrong," and stay skeptical of the "here's how to fix it."
See it in practice: designing with the community rather than for it, on the Nirnay project.
2. Never accept responsibility without the power to make decisions.
There's a line from an IBM training manual, 1979: "A computer can never be held accountable, therefore a computer must never make a management decision." I'd apply the same logic to designers, but pointed the other way: never accept accountability for a design decision without the actual power to make it well-informed, through user testing, through data, through repeated iteration until something fails. There's no conventional correctness in design. There are guidelines and heuristics, but the real answer is always testing, repeatedly, until failure tells you something true.
See it in practice: the iteration story behind the date-picker project.
3. Work doesn't happen in front of a laptop screen.
Work happens in the mind, while you're living your life. What happens in front of a screen is just the outcome of decisions already made elsewhere. Screen time was never the same thing as productivity.
4. Design is a cycle, not a straight line.
Frameworks are guidelines, not the process itself. Ideation comes from thinking outside whatever box the framework implies, and real insight can arrive at any point in the process, not just where a framework says it should. Frameworks are a way of explaining what happened after the fact, not a map for what will happen next.
5. It's a good time to be a designer with a god complex.
Things that used to be out of reach, the power to deploy, to research every corner of a problem, to explore every scenario, are now available at your fingertips. If you're someone with curiosity that never quite gets satisfied and a drive to do things that used to be impractical, AI closes the gap between ambition and execution. Identify the gaps and pitfalls in your own approach honestly, then let AI fill them in.
See it in practice: the resource library app, built end-to-end in public.
6. The expiration date on design and user behavior is shorter than ever.
You're not designing a finished product anymore. You're designing something that can keep evolving and scaling. Swiggy added a porter service. Zomato added District. The product that stands still is the one that expires.
7. The interface is getting cheaper. Judgment is not.
I spent part of this break taking on UI design projects with smaller startups and brands, the kind of work that used to be a full craft in itself. Working with AI tools alongside that work showed me where the craft is moving. Lovable, Claude and tools like them are getting better by the day at producing the interface itself, so the screens are no longer the scarce part. The scarce part is knowing which screens to build, for whom, and why: vision and strategy that align with business goals, and business goals that align with a realistic read of the market. I still care about the pixels, and I still do them well. I just want to direct the work as much as execute it, with AI as my toolset rather than my competition. It all comes down to data, over and over again.
What I bring beyond execution is understanding users qualitatively, staying close to social trends, and keeping a genuine read on the pulse of how people actually behave, the kind of judgment AI can't yet replicate and that becomes more valuable, not less, the more AI absorbs the execution layer. That's what I want to bring to a team. And I want to bring it somewhere with real resources behind it, the kind that are only really available at organizations genuinely operating at the frontier of technology right now, not on the sidelines of it.
What's it actually like to work with you day to day?
I keep a running list, and anything not finished rolls over to the next day. I send work early and unfinished, because a correction on a sketch is cheap and a correction on a build is not. I document a lot, including what was deferred and why. When I am in flow I go quiet and I tend to overwork. In meetings, I am usually the person who says what the minimum version would be.
How do you handle feedback you disagree with?
I test it. Most disagreements are two guesses about what users will do, and a scenario walked through by three real users settles the question faster than a meeting. If the evidence goes against me, I change the design and say so. If it supports me, I show it once and let it make the argument. If the client still decides the other way, it is their product. I document the trade-off and ship it.
What do you do outside of design that shapes how you work?
I make things by hand: cyanotype prints, clay, stitching and embroidery. Materials do not behave the way pixels do, and working with them has made me more patient with the parts of a project that cannot be changed. I also produce workshops on a farm, which is mostly logistics: artists, attendees, space, food and payments. And I run a household app with my flatmates. The Free-Range page lists all of this.
Why did you go independent after your full-time role, and what have you learned from it?
I went independent to learn faster than a large team allowed, and to look at the industry from outside for a while. Three things I learned. Interfaces are getting cheaper to produce and judgment is not. Scope is a design decision. And rigour has to come from me when there is no manager to require it. The full account is in the essay above.
What's different about designing for a freelance client versus an enterprise team?
In an enterprise, the users are a small, known group. There is no quantitative data, so validation means think-aloud sessions with the real users. The stakes are high and the approval chains are long. You are one designer working with developers who often know the domain better than you. In freelance work, most of that is reversed. You inherit research and proofs of concept that other people ran. The timeline is days rather than months. You are the entire design function, and nobody sets success criteria unless you do. The design-history site had a launch date and three goals. The personality assessment came with interviews someone else had conducted. In both cases I had to write the frame before I could start.
Are you looking to go back full-time, and what are you looking for?
Yes, from September 2026. I am looking for a team working at the front of the technology, with the resources that come with that, where a designer is expected to direct work as well as produce it. That means senior or lead product design, or design strategy with AI tools used for execution. Funded AI companies, large technology firms, remote-friendly teams anywhere, and studios with a strong culture. I want to avoid large, slow teams where the pace is set for me.
What kind of problems or teams are you best suited for right now?
What can you do that most product designers at your level can't?
What are you actively getting better at?
Design engineering. This site, a household app and a native app in progress are all built with Claude Code, along with Framer components and Figma's MCP, so that the things I design also run. I am also getting better at measurement. Most of my enterprise work was validated qualitatively, and I now set up the numbers before a project starts instead of looking for them afterwards.