Why UX Strategy Decks Fail Without A Field Map

A UX strategy deck shared in a leadership meeting almost always lands the same way. The first reaction is appreciation for the framing. The second reaction is agreement with the principles. The third reaction, two months later when nothing has happened, is quiet bewilderment that a strategy everyone agreed with produced no measurable change in the product. The deck did not fail because it was wrong. The deck failed because there was no map under it.

A strategy describes how to move from where the team is to where the team intends to be. Without a description of where the team is, the destination is the entire artefact, and the team has no instruction set for the journey. The deck reads as a destination poster the team can post on a wall and admire. The walls accumulate posters. The product does not change.

What a UX strategy deck normally contains

A typical UX strategy deck is built around four sections. A vision statement describing the experience the team intends to deliver. A set of principles that govern decisions made in service of the vision. A list of bets, each describing a hypothesis the team is willing to test. A sequence of initiatives flowing from the bets, with rough quarters attached. The deck closes with success metrics and a request for resources.

Each of these sections is well-formed in isolation. The vision is articulate. The principles are sensible. The bets are bold but plausible. The initiatives are scoped at the right altitude. The metrics are measurable. The request for resources is reasonable. The deck looks complete because every section a strategy deck should have is present.

What is missing is the underlying terrain. The deck assumes the reader, including the team that will execute the strategy, knows how the product actually behaves in users’ hands today. Most of the time, the team does not know. The team knows how the product is supposed to behave, which is the version described in the documentation, the marketing site, the onboarding flow, and the leadership offsite. The team knows much less about how the product behaves in the third hour of a busy user’s day, three months into their subscription, with a half-configured workspace and a habit they invented to route around a product gap nobody has noticed.

The strategy proposes to move the product from where it is to where it should be. The team cannot execute the move because the team does not know where it is.

What a field map adds that a strategy cannot

A field map is the description of where the product is. It is built from artefacts the team can collect in the field. Recordings of real user sessions. Threaded support tickets that show the same misunderstanding surfacing across many users. Observation sessions where the team watches users in their own contexts, with their own data, doing the work the product is supposed to support. Synthesis sessions where the team converts the raw observations into a readable artefact that captures the actual flows, the actual decisions, the actual confusions, the actual workarounds.

A field map produced this way takes longer than a strategy deck. A small team can build a field map for one major product flow in a fortnight. A full-product field map takes two to three months of dedicated work and benefits from a professional researcher running it. The cost is real, and the cost is the main reason most teams skip the map.

The teams that do produce a field map find that the strategy that emerges from the map is different from the strategy they would have written without it. The vision is usually less ambitious in the abstract and more specific in the concrete. The principles are sharper, because the principles are tested against real situations the team has observed. The bets are smaller, because the team has noticed how much friction exists at the level the bets would have to operate. The initiatives are more concrete, because the team can name the specific surface each initiative touches.

The deck that comes out of a field map is shorter, less impressive, and substantially more useful.

Why teams skip the map even when they know they should not

The map is skipped, almost always, for the same set of reasons. The map costs months. The strategy deck costs weeks. The leadership offsite is in three weeks. The team has to bring something to the offsite. The choice between a strategy without a map and no strategy at all looks, in the moment, like an obvious choice. The strategy without the map gets written, presented, and approved. The team returns to the office with an approved strategy and no idea how to execute it.

The pattern is structural. The leadership cycle wants strategic outputs faster than the discovery work the strategy requires. The discovery work, if done properly, would slip the cycle by a quarter. The team that protects the discovery work earns the right to write a real strategy, and is also the team that has to push back against a leadership rhythm that does not want to wait. The team that does not protect the discovery work writes a strategy that has no foundation, and ends up rewriting it the next cycle when the strategy fails to produce results.

A useful tactic is to disconnect the deck from the offsite. The team commits to producing the field map on its own schedule, presents the map to leadership when the map is ready, and writes the strategy from the map after the map has been presented. The strategy is presented in a separate session, on a separate cadence, with the field map as the explicit prerequisite. The leadership rhythm has to flex to accommodate this, and the team has to make the case for the flex.

Most leadership teams will allow the flex if the team makes the case clearly and presents the cost of not flexing, which is the cost of every strategy deck the team has produced in the last two years that nobody can point to as having produced results. The historical record is usually persuasive, because the historical record is usually grim.

The wrinkle about who can read the map

A field map is only useful if the team that needs to act on it can read it. A map written in the language of professional UX research, with rigorous notation and dense synthesis, will sit in a research repository and not be read. A map written for the team’s actual operating context, in the team’s vocabulary, with the right level of detail for the decisions the team needs to make, will be read constantly.

The trade-off between rigour and readability is real, and the team that prioritises rigour over readability ends up with a beautiful map nobody uses. A useful map is shorter than the team thought it would be, structured like a story rather than a database, and supplemented by an appendix with the underlying evidence for anyone who wants to verify a claim. The structure matches the way the team will actually use the map, which is to look up specific situations as those situations come up in product decisions.

A team that has never produced a map of this kind will usually overshoot rigour on the first attempt. The second attempt corrects. The third attempt is right. Building this practice takes a year of sustained investment, and it is one of the most reliable predictors of which UX teams produce strategy that compounds over time.

The teams that build this practice end up writing fewer strategy decks, with less drama, and shipping more strategic work. The teams that do not, write strategy decks every six months, on a treadmill, and wonder why nothing seems to move.

A strategy without a field map is a sentence without a verb. The team agrees with it and cannot move.