How I Work

Every project starts with the problem, not the solution. Before anything else, I work to build a shared picture of the user needs, problem statement, and business context — with the PM and lead engineer when I have them, or with Teammate when I’m working independently.

Part of that picture is the product that already exists. A new feature almost never lands on a blank canvas. It lands inside flows people already use, and understanding how it relates to them is its own piece of discovery. Where does this feature actually belong? What existing screens should point to it, and what would make those entry points feel obvious rather than bolted on? Designing a feature in isolation and then looking for somewhere to put it is how products accumulate orphaned screens nobody can find.

When I designed the new seat maps feature at TripIt, this was half the work. Seat maps was an expansion of the existing seat tracker, so its home was clear. The entry points were the real design problem. We updated the pre-flight alerts to surface it, and made the seat number itself a tappable way in, since someone looking at their seat is exactly the person who wants to see the map. The Seat Maps case study goes deeper on this.

The goal isn’t a document. It’s a problem statement the whole team has genuinely bought into, so that when decisions get made under pressure later, everyone is working from the same frame. Discovery done well makes every subsequent stage faster. Discovery skipped makes every subsequent stage a renegotiation.

In a compressed timeline, this is the piece I never drop. I’ll compress everything else before I’ll let the team start building against an unvalidated problem.

Before strategy gets locked, I prototype. Intentionally rough, often stripped of branding, built to surface constraints and narrow scope. The tools change (currently Figma Make and Cursor), but the purpose doesn’t: a rough prototype that breaks is more valuable than a polished deck that doesn’t get tested.

This phase is particularly useful when scope boundaries aren’t clear. The Disruption Hub case study shows this in practice. Rapid prototypes surfaced feasibility gaps in the brief before they reached engineering and quietly became someone else’s problem.

When time is short, this stage compresses into something more targeted: one or two concepts instead of five, tested against the riskiest assumption rather than the full surface area.

Once scope is defined, I move into Figma for design explorations. Iteration happens fast and often. I review work in progress with the PM and lead engineer multiple times a week to catch misalignments early, while there’s still room to adjust — not at review, when the cost of changing course is already high.

Teammate is especially active here. Alternative directions and the reasoning behind them are among the highest-value documentation in any project. The paths not taken are as important to preserve as the one that was.

At TripIt, design review happened at two layers: within the immediate agile team, and a weekly full-team review open to any PM or engineer across the organization. In practice, that room was regularly full of people with no formal obligation to be there.

That didn’t happen by mandate. It happened because putting user needs at the center of every conversation gives people outside of design a reason to care — and over time, they showed up for it.

Design review works when it’s not a presentation. It works when it’s a conversation the whole team is already invested in because they’ve been part of the thinking.

Spec work is collaborative by nature. I work closely with the lead engineer to document not just screens but logic: loading states, error states, validation rules, edge cases, accessibility requirements, motion behavior. I use Cursor to help define and simulate interaction logic — the prototype is often the spec.

The work isn’t done when the file is handed over. Logic questions surface during build. Outlier cases appear that didn’t make it into specs. I stay available.

Every shipped feature should be measured and iterated on. What that looks like in practice depends on the tools and access available — I’ve worked in environments where formal analytics were limited, and learned to build feedback loops from whatever signal existed: support cadences, engagement reports, unmoderated research.

The important thing is closing the loop, even informally. Without it, the next project starts from assumption instead of evidence.