Product Designer

I treat a design system as a product with its own users, the designers and engineers who consume it. Before adding a new component, I check whether an existing pattern can solve the problem with a small variant instead. Each component ships with clear usage guidelines, accessibility notes, and both Figma and code implementations so the two never drift apart. I run a fortnightly office hours session where any designer or engineer can bring a gap they have found in the system, and I keep a backlog of proposed additions reviewed monthly rather than added ad hoc. When a component changes, I audit every screen that uses it before shipping the update, because a silent break in a shared component has a much wider blast radius than a one-off screen bug. I also track adoption: if a new pattern sits unused after a quarter, I ask whether it solved a real problem or just felt like good practice at the time.

I start by writing a small number of specific tasks tied to the flow I am testing, usually three to five, phrased as goals rather than instructions so I do not lead the participant. I recruit five to eight users who match the target profile rather than convenience-sampling colleagues, because internal testers already know too much about the product. During the session I ask participants to think aloud and I resist the urge to explain or defend the design when they struggle. I take notes on where hesitation happens, not just where people fail outright, since hesitation often points to the same underlying confusion at a smaller scale. Afterward I group findings into patterns across sessions rather than treating each comment as an individual bug, and I separate severity from frequency: a rare issue that blocks a core task outranks a common issue that costs a few seconds. I bring the clip of the most telling moment into the readout, because a short video changes a stakeholder conversation faster than a slide of findings.

I bring both into the process before I have a solution, not after. With the product manager I want shared clarity on the problem and the success metric before I open Figma, so we are not negotiating scope after the design already exists. With engineering I share early, rough explorations rather than a polished mockup, because a rough version invites real feedback on feasibility while a polished one invites silent nodding. I ask engineers directly what would be expensive to build, and I treat that as design input rather than a constraint to fight against. During implementation I stay involved through a lightweight design QA pass on staging, checking spacing, states, and edge cases like empty and error states that often get deprioritised under deadline pressure. When priorities conflict, I try to reframe the conversation around the user problem everyone agreed on at the start, which usually resets the discussion away from personal preference and back toward evidence.

AI shows up at several points in my process now. Early on, I use it to generate quick variations on a layout idea so I have more starting points to react to before committing to a direction, which is faster than sketching six versions by hand. For research, I use it to help summarise open-ended survey responses or interview notes into themes, though I always spot-check the summary against the raw transcripts because it occasionally smooths over a contradiction that matters. For copywriting inside interfaces, I use it to draft microcopy options for buttons, empty states, and error messages, then edit for tone and brevity myself. Where I do not use it is the actual judgment calls: what the design should communicate, which trade-off matters most for this specific user, and how a flow should feel. Those decisions need context about the product and the user that the tool does not have, so I treat AI as a way to get to a first draft faster, not as a substitute for the thinking that comes after.

I presented a checkout redesign to a review with our head of design and two senior product designers, and the feedback was much harder than I expected: several people felt the new flow added a step for a problem that did not need solving. My first reaction was to explain my reasoning, but I stopped myself and asked instead what specific evidence would change their minds, since defending the work in the room was not going to resolve anything. We agreed on a small unmoderated test with eight users comparing the old and new flows on completion time and reported confusion. The test showed my version was actually faster but scored worse on confidence, people were not sure the order had gone through. I used that finding to keep the structural change but add a clearer confirmation state, which addressed the actual concern under the criticism rather than the criticism as stated. The revised version shipped and checkout confusion tickets dropped by about 18% the following month.

Leadership wanted to simplify our pricing page by removing the feature comparison table, based on a belief that it overwhelmed visitors. I ran five moderated sessions before the change shipped and found the opposite: users in the consideration stage relied on that table specifically to justify the purchase to themselves or a manager, and removing it made them less confident, not more. Rather than simply reporting that the data disagreed, I brought clips of two sessions where participants explicitly scrolled back to the table after reading the plan names, plus a summary of what they said they needed it for. I proposed a middle path: keep the table but move it below the fold and add a condensed three-row summary above it for people who wanted the short version. Leadership agreed to test both versions live. The condensed-plus-full-table version outperformed the simplified page on conversion, and it became the version we kept.

I designed a notification centre with real-time updates and smooth entrance animations for each new item, which looked great in the prototype. Engineering flagged that the real-time layer we had would introduce noticeable lag under load, and that the animation approach I had chosen was expensive to implement consistently across our web and native codebases within the sprint we had. Instead of pushing to keep the original version, I asked what was achievable without the animation-heavy approach and what a slightly delayed but reliable update pattern would look like. We landed on a polling-based update every few seconds with a simpler fade-in, which was less dramatic but shipped on time and never glitched. I learned to bring engineering into a design earlier, at the concept stage rather than the polished-mockup stage, so trade-offs like this surface before I am emotionally attached to a specific execution. The simplified version still tested well with users, who cared more about reliability than about animation polish.

I usually start a portfolio walkthrough with the problem as the team understood it going in, including the constraint that made it hard, not just the polished final screens. For a recent project, a multi-step signup flow with a 40% drop-off rate, I explain how we first confirmed where users were actually leaving using session recordings and funnel data, rather than assuming based on the flow's length. I walk through two or three early directions, including one I dropped and why, since showing a wrong turn demonstrates real reasoning rather than a designer who got it right on the first try. I show the usability testing round that changed the direction of the final design, then the shipped version, then the outcome: drop-off fell from 40% to 27% over the following month. I close with what I would do differently, which is usually the most telling part of the walkthrough because it shows whether a candidate is still learning from their own work.

My default is to use what already exists and to treat a new component as something that needs to earn its place, not the other way around. Before proposing something new, I check whether the problem can be solved with an existing component plus a variant, a different arrangement, or a content change, since most apparent gaps turn out to be a layout problem rather than a missing component. If a genuine gap exists, I look at whether it is likely to recur across the product or is truly one-off; a one-off case usually gets a local solution rather than a new system component, because adding rarely-used components to a shared library adds maintenance cost for everyone. When I do propose a new component, I bring it to the design system team or a working session rather than shipping it silently in one feature, since an unreviewed addition tends to fragment the system within a few months as other designers copy it without understanding why it was made.

I define the target metric and how I will measure it before the design ships, not after, because retrofitting a measurement plan tends to produce a metric that flatters whatever happened. For a recent onboarding redesign aimed at activation rate, I agreed with the data team on the exact activation event, the comparison window, and which user segment counted before we launched. Where possible I ship behind an A/B test rather than a full rollout, since a before-and-after comparison alone cannot separate the design change from seasonality or an unrelated marketing push that happened the same week. I also watch a secondary metric that would catch an unintended cost, for an onboarding change that might be time-to-complete, in case a redesign that lifts activation also makes the flow slower for everyone who gets through it. After the test window closes I look at the result alongside qualitative feedback from support tickets or session recordings, since a metric can move for a reason unrelated to what I assumed.