The Field Guide — Ashley K. Needham

01

Project Rescue

Use when: a project has stalled, you're not sure why, or you want to diagnose whether a reset is even the right call before pulling the trigger.

"The energy you spend avoiding the hard conversation is borrowed from the project. You'll pay it back eventually — usually at the worst possible time."

The Waypoint

How I assess whether a project needs rescuing — and what to actually do once I know.

Stalled projects rarely die from a single cause. Usually it's a combination: unclear ownership, a decision that never got made, an assumption that nobody questioned out loud, or a team that stopped trusting the process. Before I do anything else, I have to figure out which of those is true — and that means getting everyone in a room and slowing down before speeding up.

1

Drop the blame — hit 'em with gap analysis

Start with a shared map of where the project is vs. where it was supposed to be. No finger-pointing — just a factual gap analysis. Getting everyone to agree on the current state is often the hardest part, and it's the only foundation a real reset can stand on.

2

Run the True / Uncertain exercise

Two columns: what we know to be true, and what we're treating as true but haven't verified. Stalls often hide in that second column — assumptions that slipped into requirements without anyone noticing.

3

Identify the one real blocker

There's usually one decision, dependency, or missing piece that everything else is waiting on. Name it explicitly. Ambiguity about the blocker is often more paralyzing than the blocker itself.

4

Rebuild with small wins first

Don't try to solve the whole project in the reset meeting. Pick one thing the team can ship or decide in the next week. Rinse, then repeat until it's shipped. Momentum is a muscle — you have to use it to rebuild it.

5

Document the new contract

Write down what was decided, who owns what, and when the next check-in is. A reset without documentation just produces a second stall in four weeks.

"The energy you spend avoiding the hard conversation is borrowed from the project. You'll pay it back eventually — usually at the worst possible time."

02

Discovery

Use when: the team is about to build something and hasn't talked to a real user in a while — or when you suspect the roadmap is optimizing for the wrong thing.

"Feature requests are symptoms, not diagnoses. Users tell you what they want. They rarely tell you why — and the why is where the strategy lives."

The Research Setup

How I run a discovery sprint that actually changes what the team builds — not just validates what they already think.

Research fails when it's treated as a step in the process rather than the foundation of it. Most teams research to confirm what they already think. I've learned to structure research so it's genuinely capable of surfacing the uncomfortable truth — and to build the presentation strategy before the first interview so findings land with the people who need to act on them.

1

Define the question, not the answer

Write down the one question that would genuinely change your roadmap if you knew the answer. That's your research question. If you can't name it, you're not ready to start.

2

Three segments minimum

Happy users, recently churned users, and a group that never converted. Each segment tells a different part of the story. Happy users tell you what's working; churned users tell you what failed; non-converts tell you what never connected. And if you have a CX team, they need a seat at this table from day one — they're sitting on a goldmine of real customer sentiment that research should plug into, not duplicate separately from.

3

JTBD framing, not feature lists

Ask people to walk you through the last time they used the product end to end. What were they trying to accomplish? What did they do right before? What did they do after? The story around the product is where the insight lives.

4

Layer in behavioral data

Interviews tell you what users think and feel — behavioral analytics tell you what they actually do. Tools like Fullstory surface friction points, rage clicks, and drop-off patterns you'd never think to ask about in an interview guide. PowerBI and your product analytics layer can reveal patterns at scale. Layer these signals with your qualitative findings before you form conclusions — the intersection is where the real insight lives.

5

Validate qualitative with quantitative

Every major finding needs a number behind it. Not to prove the qualitative wrong — to give leadership something to hold. "83% of churned users said..." is much more actionable than "several users mentioned..."

6

Build the narrative before the deck

Know the story you're telling before you open a slide. Research readouts fail not because the findings are wrong but because they're presented as data instead of implications. Lead with the insight, not the methodology.

"Feature requests are symptoms, not diagnoses. Users tell you what they want. They rarely tell you why — and the why is where the strategy lives."

03

Design Culture

Use when: you want to build a team that shares work early, gets feedback often, and doesn't save everything for the scheduled review.

"Great critique isn't an event — it's the air your team breathes. When designers share rough work without flinching, you know the culture is real."

The Open Studio

How I build a culture where feedback is constant, safe, and woven into how the team works — not saved for the big reveal.

The worst version of critique is a ceremony. Work disappears for two weeks, gets presented to a room full of opinions, and the designer is on the defensive before anyone says a word. I've spent years building the opposite: a team culture where sharing rough work is the norm, not the exception — and where the weekly design review is a working session, not a performance.

These aren't design students. They're experienced practitioners who need an environment that trusts them — and a lead who actively creates the conditions for that trust to exist.

1

Run the calibration

Regular design team calibrations where every designer shares what they're working on — no polish required. The goal isn't critique; it's shared awareness. No one should walk into a weekly review surprised by someone else's work. When the whole team knows what's in progress, feedback becomes contextual and conversations become genuinely useful instead of reactive.

2

Make WIP the norm

Establish explicit team norms around sharing early. Rough work is welcome — a Figma frame with sticky notes and half-formed ideas counts. When the team sees that leadership responds to messiness with curiosity instead of judgment, the culture shifts. Psychological safety isn't declared; it's demonstrated, repeatedly, at the small moments.

3

Peer feedback, not just top-down feedback

Don't build a team where all critique flows through the lead. Designers should be actively seeking each other out throughout the week — a Slack thread, a Figma comment, a quick sync. My job is to calibrate norms and catch what peers miss, not to be the only feedback source in the room. A team that only waits for me isn't a team — it's a queue.

4

Use design reviews as working sessions

Weekly design reviews aren't presentations — and the weekly review should never be the first time the team is hearing about the work. Come with a half-baked idea, an interaction you're stuck on, or a problem that needs more eyes. They're brainstorms, jam sessions, and a place to get unstuck. The review should feel like a studio, not a boardroom.

5

Lead cadence: bi-weekly up the chain

At director level, I expect design leads to bring their team's work to me bi-weekly. This keeps me informed without micromanaging individual contributors. Leads own the synthesis; I provide the strategic lens and cross-team perspective. It also gives leads regular practice advocating for their team's work — one of the most important skills to develop at the senior level.

"Great critique isn't an event — it's the air your team breathes. When designers share rough work without flinching, you know the culture is real."

04

Stakeholder Management

Use when: you have too many stakeholders, too many opinions, and not enough shared direction.

"Alignment isn't a meeting. It's a sequence of smaller agreements that build to a shared direction. The art is knowing which agreement comes first."

The Alignment Map

How I get cross-functional partners pointing in the same direction — and keep them there.

At Asurion I've coordinated up to 43 cross-functional partners on a single project. The mistake most people make in complex stakeholder environments is trying to align everyone simultaneously. Alignment isn't a meeting — it's a sequence of smaller agreements that build to a shared direction. The art is knowing which agreements to get, and in what order.

1

Map Decide / Advise / Execute

For every key decision, identify who decides (1 person), who advises (2–4 people), and who executes (everyone else). Misalignment usually comes from people who should be advising acting like they're deciding. Name the roles explicitly.

2

Do the pre-meeting

Before any large alignment session, meet individually with the 2–3 people whose misalignment would be most disruptive. Surface objections early. The goal is to walk into the room knowing where the tension is — not to eliminate it, but to address it in the right sequence.

3

Anchor to the single source of truth

Every project needs one artifact that everyone refers to when something is disputed. Not a deck, not a doc, not an email thread — one living reference that reflects the current state of decisions. I usually build this in Figma or Notion and share the link aggressively.

4

Document decisions in writing, immediately

After any meeting where a decision is made: write it down, send it to the room within 24 hours, and explicitly ask for objections. Silence is consent. This prevents the "but I thought we decided..." spiral three weeks later.

5

Protect the team from chaos, not from reality

My job as a design leader isn't to shield the team from every stakeholder opinion — it's to filter signal from noise and translate both clearly. A team that doesn't understand the business context can't make good design decisions.

"Alignment isn't a meeting. It's a sequence of smaller agreements that build to a shared direction. The art is knowing which agreement comes first."

05

Team Leadership

Use when: you've just inherited a new team or joined a new organization.

"People don't need you to have all the answers in the first 90 days. They need to know you're paying attention — to the work, and to them."

First 90 Days

How I earn trust, understand context, and set the culture — without burning everything down on day one.

The biggest leadership mistake I see in the first 90 days is optimizing for looking decisive rather than actually being informed. The urgency to demonstrate value leads to changes made before there's enough context to make them well. I've learned that slow is fast in those first months — the understanding you build early compounding into every decision you make after.

1

Days 1–30: Listen with intent

One-on-ones with every team member and key partner. Not just "what do you work on" — "what's working, what's broken, what would you change if you could?" Listen for the things people say carefully, and the things they say quickly. Both are signal.

2

Days 30–60: Understand working styles

How does each person receive feedback? How do they prefer to communicate? What motivates them, and what drains them? I document this — not to put people in boxes, but because great management is personalized, and personalization requires information.

3

Find the quick win, but pick it carefully

Identify one thing that's been broken or frustrating for a while that you can actually fix in the first 60 days. Ship it. This isn't about optics — it's about demonstrating that change is possible, and that you follow through.

4

Days 60–90: Set the norms explicitly

Culture is what you tolerate and what you celebrate. By day 60 I have enough context to name the norms I want to reinforce and the patterns I want to change — and to say so explicitly. Implicit cultural change is slow and lossy. Named change is faster.

"People don't need you to have all the answers in the first 90 days. They need to know you're paying attention — to the work, and to them."

06

Design Advocacy

Use when: you need to convince non-design leadership to invest in, protect, or prioritize design work.

"The strongest argument for design isn't 'users need this' — it's 'here's what it costs us when we don't do it.' Translate user pain into business reality and the conversation changes."

Making the Case

How I advocate for design decisions without losing the room — or the relationship.

Design advocacy fails when it speaks design to people who think in business. Most leadership teams aren't anti-design — they're just operating with a different frame. My job in those conversations isn't to educate them on UX; it's to translate between their frame and mine, finding the overlap where design and business outcomes are the same thing.

1

Lead with the business outcome, not the design decision

"This navigation change will reduce support tickets by an estimated 15%" lands differently than "the current navigation is confusing." Both may be true — only one speaks to what leadership is tracking.

2

Pair narrative with data

A user quote that illustrates a pain point + the retention metric that quantifies it = a case that's both emotionally resonant and analytically credible. Most design advocates use one or the other. The combination is what moves decisions.

3

Name the cost of inaction

Every design decision delayed or deprioritized has a cost — in user trust, in rework cycles, in competitive positioning. Making that cost visible and concrete is often more persuasive than making the case for the design itself.

4

Know when to adapt vs. when to push back

Not every design preference is worth a fight. I pick advocacy moments carefully — for the decisions that will meaningfully affect user outcomes or team trust. Pushing back on everything dilutes the signal. Reserve it for what actually matters.

5

Build the relationship before you need the favor

Design advocacy is easier with cross-functional credibility already in the bank. I invest in relationships with PM, engineering, and finance leaders before I ever need them to go to bat for a design decision. The best advocacy happens before the meeting.

"The strongest argument for design isn't 'users need this' — it's 'here's what it costs us when we don't do it.' Translate user pain into business reality and the conversation changes."

How I actually
do the work.

The Waypoint

The Research Setup

The Open Studio

The Alignment Map

First 90 Days

Making the Case

See these frameworks in action.

How I actually do the work.

The Waypoint

The Research Setup

The Open Studio

The Alignment Map

First 90 Days

Making the Case

See these frameworks in action.

How I actually
do the work.