The Tools of Analysis — When the Data Still Hasn't Spoken

These are the tools you reach for when the data has piled up but you still don’t know what it means. Observation is an enjoyable, insight-rich process, but the observed data itself tends to be fragmented, local, and subjective. Individual problems get tangled up with collective ones, and a special case can look like a universal pattern. The tools of analysis exist to find structure among these fragments and to read meaning out of them.

The tools introduced here aren’t tied to any particular project phase. Whenever you have data and that data still hasn’t spoken, you can reach for them.

Card Sorting

“Which of the categories we already know does this data belong to?”

This is a method for placing new observations into classification criteria that already exist. For example, if a service already has defined categories like “membership,” “payment,” and “store,” you sort what you found during observation into those categories and build experiential insights from within them. Grouping new observations by screen or by feature, when a list of screens or features already exists, follows the same approach.

Statistically, this is a top-down approach that classifies data against labels that already exist; in machine-learning terms, it corresponds to supervised learning.

Caveat: An existing classification scheme can distort what you observe. Data that doesn’t fit the criteria gets forced in anyway, and new discoveries that fall outside the existing categories are easily ignored. If a lot of data resists classification, you should question the categories themselves.

Affinity Diagram

“Is there structure among this data that hasn’t been discovered yet?”

This is a bottom-up method: you gather observations for which no classification criteria have been set yet, arrange them by similarity, and build insight as you define the resulting clusters. In machine-learning terms, this maps to unsupervised learning — specifically, cluster analysis.

Because it lets you focus on the data itself, free of the project lead’s preconceptions or assumptions, it’s useful when you want to newly define a problem or a need.

Caveat: The boundaries of a cluster depend on the analyst’s judgment. The same data can produce entirely different structures depending on who arranges it, so where possible, it’s best to have multiple people cluster independently and then compare results.

KJ Mapping

“Can the distance and relationships between data points be made visually apparent?”

Named after the Japanese anthropologist Kawakita Jiro, this method is a more granular variant of the affinity diagram: it maps data by adjusting the distance between items according to their affinity to one another.

Affinity diagramming and KJ mapping are often used interchangeably and treated as near-synonyms, but strictly speaking they differ. Diagramming is a broader category than mapping. KJ mapping is a mapping method — one that uses coordinates and distance — that diagrams based on affinity, so it’s best understood as one specific way of executing an affinity diagram.

The word “map” here is worth paying attention to. When a technique calls itself a map, it means the two-dimensional X/Y coordinates carry meaning, and the distance or relative position between data points becomes the crux of the analysis.

Caveat: The core of the process is turning each observation into data and calculating the distance between them to place them accordingly — and the nature and outcome of the resulting clusters depends entirely on how sound that data conversion and calculation are. If the preprocessing is weak, the map itself ends up distorted.

Preprocessing the Data: How to Write a Card

“How do you refine fragmented observations into analyzable units?”

Whether you’re doing card sorting or affinity diagramming, you first need a preprocessing step that refines your observations into data suitable for analysis. In the same vein as data preprocessing in statistics, you need to filter out and tidy up data that’s too much of an outlier, observations that are too vague, and cards that mix multiple pieces of content together.

The recommended approach is to write each card as a descriptive statement with the observed user as the subject. This makes the content easier to grasp when you go on to map it, and it reduces confusion.

Say, for example, you observed a user standing in front of a touchscreen kiosk who hesitates over which button to press while trying to place an order, then walks away. Instead of writing the card as “complex touchscreen kiosk UI,” write it as “I want to order, but I don’t know where to press.” This makes the situation and the user’s emotion unmistakable. It also clarifies which category the card belongs to, and makes it much easier to develop into a cluster that stays in sync with the user’s emotional state.

Caveat: When writing a descriptive card, it should carry the user’s voice, not the observer’s interpretation. “The UI is inconvenient” is the observer’s judgment; “I don’t know where to press” is the user’s experience.

POV (Point of View) Statement

“Can the observation be converted into a single point of view?”

A POV statement is a tool for compressing scattered observations and analysis results into one clear point of view. It takes the following form:

“[User] needs [need/desire], because [insight].”

For example: “An older user using a kiosk alone for the first time needs clear guidance on the opening screen, because they believe that pressing the wrong button can’t be undone.”

What this format forces you to do is pack three elements — the user (who), the need (what), and the insight (why) — into a single sentence. It serves as the bridge that converts a pattern found through analysis into a point of view you can actually design against.

Caveat: If a POV statement is too broad (“the user needs a good experience”), you can’t find direction; if it’s too narrow (“the user needs a blue button”), it already presumes a solution. The insight clause is the crux — whatever follows “because” must be the real reason uncovered through observation, not an assumption.

HMW (How Might We) Question

“Can the problem be reframed as a solvable opportunity?”

HMW is a question in the form “How might we ___?” that reframes an identified problem as a design opportunity. It often starts from a POV statement.

Continuing the kiosk example: “How might we help first-time older users place an order without fearing mistakes?”

The power of an HMW question lies in framing the problem in the language of possibility rather than constraint. Instead of stopping at the diagnosis “the kiosk is hard to use,” the “how might we” frame opens up a concrete direction to explore.

Caveat: Just like a POV statement, an HMW question needs the right scope. “How might we satisfy every user?” is too broad, and “How might we make the text bigger?” already contains its own answer. A good HMW question should be open enough to invite solutions in several directions, while still staying anchored to a specific user and context.

Closing

All of these tools point in the same direction: moving fragmented observations toward structured understanding. Card sorting places data within an existing structure; affinity diagramming discovers new structure from the data itself; POV and HMW convert that structure into language you can design against.

But there’s something worth remembering. The structure of analysis exists to make the user’s voice come through more clearly — not to replace that voice. Get swept up in inspiration and intuition, and the whole process can end up as nothing more than forced rationalization. Only by setting aside preconceptions and predictions and staying focused on the data itself does observation turn into a living structure.

The next post covers the tools of expression — the tools for sharing the understanding of the user gained through analysis with the team, such as personas and empathy maps.