Role Day2Day

"At [Company], our team was about to enter a new surface [e.g. mobile onboarding] but there was no agreed direction on what success looked like. The PM had a rough goal ('improve activation') but no framing for what the experience should feel like or prioritise.

I volunteered to anchor the vision work. Over two weeks I did three things: I interviewed six users about their first-week experience to understand the actual failure modes. I did a competitive teardown of five onboarding flows not to copy, but to map the design decision space. And I ran a half-day workshop with engineering, PM, and customer success to surface what they thought the product needed to be.

I synthesised that into a four-page vision doc not wireframes, a framing doc. It defined the user mental model we were designing for, three principles for the experience, and two explicit non-goals. The artifact let the PM write a proper discovery brief. Engineering stopped a tangential sprint they'd been about to start because the vision made the priority clear.

Six months later the activation metric improved 18%. What I can say is that every design decision during that period traced back to the principles we'd set. That's what I mean when I say vision work is upstream leverage."

"Our design reviews had become rubber-stamp sessions designs came in finished, got nodded through, and the same quality issues kept recurring in prod. I wanted to change the culture but had no authority over the process.

I started small: I asked if I could facilitate one critique a month alongside the standard review. I restructured it two works-in-progress only, 30 minutes each, everyone writes one question before speaking. No 'I would have done it this way.' After three sessions, other designers started asking to be on the calendar invite.

After two months, the design manager adopted my format as the team standard. Design QA issues in our sprint retros dropped about 30% over the following quarter. More importantly, designers started sharing work earlier the culture shifted from defensive to collaborative.

The lever wasn't authority. It was making the new approach obviously better, and making it easy to adopt without feeling like the old way was being criticised."

"When I joined, we had four product teams each maintaining their own component library. Some overlap, a lot of drift. A simple button had seven variants across codebases.

I started with an audit inventorying every UI pattern across all four products in a single Figma file. Not to judge, just to see. That audit became the most-commented file in the company's history because it showed teams visually how much duplication they were maintaining.

I proposed a federated model: a core system I'd own, with a contribution process any team could use. I ran monthly office hours for contribution questions. I wrote a decision record for every deprecated component so teams understood the rationale, not just the mandate.

Within a year all four teams were on the core token system. Design-to-dev handoff time for standard components dropped from several days of back-and-forth to same-day. The audit habit became a quarterly ritual the team now runs without me."

"We were preparing to build a collaboration feature the assumption was that users wanted to share work with teammates inside the product. I ran six user interviews as discovery.

What I found surprised everyone: users weren't blocked on sharing inside the product. They were blocked on sharing outside it with clients and stakeholders who'd never have accounts. The 'collaboration' problem was actually a 'presentation and handoff' problem we'd completely mislabelled.

I wrote a two-page reframe brief not a design spec, a strategic reframe. I showed it to the PM and then to the product VP in back-to-back sessions. Led with the user quotes, then the implications, then what I thought the actual opportunity was.

The team paused the original sprint. We ran two weeks of focused discovery on external sharing. That eventually became a core product surface one of the higher-engagement features in the next release cycle.

The research didn't improve a feature. It stopped us from building the wrong thing."

"I was pulled onto a project mid-stream a redesign of our core settings experience that had been running three months with no clear outcome. Three PMs had opinions. Eng had started building a new navigation model. Design had produced two entirely different directions. Nobody agreed on what 'done' looked like.

My first week I didn't design anything. I interviewed every stakeholder five PMs, two eng leads, the design manager, and three support reps who handled settings-related tickets. I made a simple 2x2: what we agree on vs. disagree on, and what's in scope vs. out of scope. That map alone surfaced three blocking assumptions.

I ran a 90-minute working session to ratify scope and a single success metric. I facilitated I didn't present. By the end, we had a one-page brief everyone had co-authored.

The project shipped four weeks later. It would have taken two more months of circling without the scoping work. Settings-related support tickets dropped 40% in the first quarter post-launch."

"Our three mid-level designers were working in silos each doing strong individual work but not benefiting from each other or from institutional knowledge I'd accumulated. I was repeatedly answering the same craft questions in Slack.

I started a weekly 'design office hours' 45 minutes, open invite, no agenda. Anyone could bring work at any stage, even rough sketches. I facilitated but treated my role as questioner, not critic. Within a month all three mids were attending consistently.

The qualitative shift was visible fast mids referencing each other's solutions in their own work. The quantitative signal came in our quarterly review: one mid's work was flagged by the CPO as a quality step-up. In my 1:1 with her, she specifically credited office hours as where she'd developed the framing for that project.

I've since handed facilitation to a senior who wanted to grow leadership skills. It's still running six months later."

"Our PM wanted to ship a feature with significantly reduced UX scope basically a form with no guidance or recovery path to hit a sprint deadline. My concern wasn't aesthetic: our research showed 40% abandonment at error states in similar flows, and this design would produce more.

I didn't raise it in the planning meeting. I asked for 20 minutes with the PM beforehand. I came with three things: the abandonment data from our last similar flow, a mockup of the minimal viable version I thought we could actually ship, and an eng estimate that it would add two days, not two weeks.

The PM pushed back initially. I said: 'I'm not asking for the full design. I'm asking for the error states and one recovery path. Here's the user data that justifies the two days.' They agreed to the minimal version.

We shipped. Abandonment on that flow was 18% versus the 40% baseline. The PM cited it in the next retro as a decision they were glad we'd made.

My takeaway: advocacy works best when you come with a pre-scoped alternative, not just a critique."

"Early at [Company], design was brought in after the PRD was written basically handed a spec and asked to make it look good. I started showing up to PM planning sessions uninvited but useful: I'd bring a one-page opportunity map showing what users were struggling with, framed around the same business goal the PM was planning for.

After doing that three times, the PM started scheduling me into earliest discovery sessions. That shifted our dynamic from 'design executes PM's spec' to 'design and PM co-own the problem definition.'

On the engineering side, I made a practice of pairing with a senior eng early on every project not to negotiate constraints, but to understand what was technically interesting to them. Twice that led to them proposing approaches that were actually better user experiences than what I'd designed, because they knew the system in ways I didn't.

The concrete outcome: our design-to-dev cycle shortened because designs were shaped around real constraints. We had fewer 'can't build that' conversations in review because we'd had them in discovery."