Measurement Strategy

It is possible to collect a great deal of information and still be unsure what to do.

Before choosing reports or configuring tools, we ask what the organization needs to understand. Perhaps people abandon an application. Perhaps customers use a new feature but still ask for help. Perhaps a website attracts interest that never becomes a useful conversation.

Each situation calls for a different investigation. A dashboard may help reveal a pattern; it cannot decide on its own which pattern deserves attention or why it matters.

We work with the client to connect a purpose to a question. What would we need to learn to decide whether to simplify the application, change the explanation, improve the offer, or investigate a different problem entirely?

That gives measurement a job within the design process.

Human and business outcomes belong in the same conversation. So do the conditions required to deliver them.

For the person using an experience, success might mean finding an answer, understanding a choice, completing a task, or feeling confident about what happens next. For the organization, it might involve suitable inquiries, revenue, repeat use, or fewer preventable service failures. For the people delivering the work, it might mean receiving complete information or spending less time resolving avoidable confusion.

These outcomes can support each other. They can also reveal tensions.

A shorter form could be easier to complete while leaving staff without essential information. A longer visit could reflect interest or difficulty. Fewer support requests could mean an improvement—or that people cannot find help.

We examine these possibilities before deciding what a rising or falling number should mean. The objective is not to make every measure move in a preferred direction. It is to understand whether the experience is becoming better in the ways that matter.

“Make the portal more useful” is a reasonable ambition. It needs more definition before it can guide evaluation.

Useful for whom? During which task? What is difficult now? What would change if the problem were resolved?

We might examine whether someone can submit the right documents, whether they understand their submission's status, and whether the receiving team can act without repeatedly asking for corrections. Some of that evidence may come from system records. Some may come from conversations, observation, or a review of support issues.

No single measure has to stand in for the entire experience. A small, purposeful set can give us different views while keeping the work manageable.

We also distinguish an outcome from a proxy. Opening a guide tells us it was opened. It does not establish that someone understood it. A proxy can still be useful, provided we remember what it does—and does not—show.

A measure should be understandable to the people expected to use it. We document the important definitions rather than leaving them inside someone's memory or a tool's default settings.

Depending on the question, that can include:

• The action or condition being measured, including when it counts as complete.
• The people, accounts, sessions, or cases included and excluded.
• The time period and, for a rate, the population used as its denominator.
• The source of the information, its limitations, and who maintains it.
• The baseline or comparison that gives the result context.
• Who reviews the finding and what decision it may inform.

An attempted submission is different from a successfully received one. One person making several attempts is different from several people completing the task. Comparing different definitions can make a report look precise while leaving the conclusion uncertain.

Targets need the same care. They should reflect a reasoned ambition and the circumstances of the work—not an impressive number borrowed from an unrelated business. A target is a way to focus effort, not a promise that design can guarantee the outcome.

Once the questions are clear, we identify the tracking, records, feedback, or research needed to investigate them. Analytics configuration, integrations, and technical validation may involve the client's team or specialist collaborators.

We check whether important actions are recorded as intended. Duplicate events, missing steps, internal traffic, changes in consent settings, and differences between systems can affect the account we see. Missing information should remain visible as a limitation; it should not quietly become a zero.

A baseline also needs context. The period it covers, the version of the experience, the audience, and significant business conditions may affect its usefulness. When definitions or collection methods change, we retain that history so later comparisons do not suggest continuity that is not there.

The strategy should be proportionate. We do not need to monitor every interaction simply because a platform allows it. We consider what information is necessary, how sensitive it is, who should have access, and how long it remains useful. Privacy and appropriate consent practices belong in the design of measurement, not as an afterthought to a tool installation.

When we shape a measurement plan for a document-upload portal, we begin with the people on both sides of the submission. What does the customer need to understand before an appointment, and what does the receiving team need in order to prepare?

The business wants more people to finish this step. Customers want to know which documents are needed and whether they have done enough. Staff need usable information in time to prepare.

Counting uploads alone could obscure the problem. A customer may upload the same file repeatedly because the confirmation is unclear. Another may submit an unreadable image. Someone else may leave to find a document and return later without difficulty.

A useful measurement plan could therefore distinguish successful submission from attempts, examine correction requests, and look at whether people understand the next step. It could also separate time spent actively completing the task from time spent waiting for something outside the portal.

Suppose a revised instruction appears to coincide with fewer corrections. That is a finding to investigate, not automatic proof of cause. The customer mix, staff practices, or document requirements may have changed too.

The value of the plan is that it makes those questions discussable. We help the team decide whether to keep improving the instructions, adjust the workflow, investigate a technical issue, or gather more evidence.

Evidence does not arrive with the design answer attached.

We bring together the available information, the client's knowledge, and the context of the experience. Quantitative patterns can help identify where to investigate. Qualitative accounts can reveal difficulties or meanings that a count cannot describe on its own. Neither should be treated as automatically representative of everyone.

When a controlled experiment is appropriate, its question, evaluation approach, and conditions need to be planned. When activity is limited or an experiment is impractical, other forms of investigation may be more useful. A before-and-after comparison can inform the conversation without establishing that the design change caused every difference.

We also look for consequences beyond the primary measure. An increase in completed actions is not sufficient justification for concealed information, unwanted commitments, or a worse experience afterward.

Design decisions are informed hypotheses. People provide the evidence.

Measurement becomes useful when there is a practical path from evidence to a decision.

We agree how findings will be reviewed, who needs to contribute, and what deserves follow-up. Some questions call for ongoing monitoring; others need a focused review after a change or enough meaningful activity. The cadence should suit the question and the organization's ability to respond.

A useful report explains what was observed, what it may mean, what remains uncertain, and what we propose doing next. That may be a small content adjustment, further research, a larger redesign, or a decision to stop pursuing an idea that no longer makes sense.

Those records become part of Product Intelligence: knowledge built with the client that remains available when the next question arrives.

Within Design Thinking, Discover and Define help establish what we need to understand. Explore helps us consider how a proposed direction could be evaluated. Design / Develop / Market bring the work and its measurement into use. Learn and Advance carry the findings into a new round of Discover.

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

Conversion Rate Optimization applies that evidence to meaningful actions and the experiences surrounding them. Design Research, Service Blueprinting, content, and technical work contribute other views. Measurement Strategy gives those views a shared purpose without making them interchangeable.

It is usually established within a broader engagement. It can also be a focused starting point when an organization has information but lacks a useful foundation for deciding what it means.

If you are collecting data but still asking whether your website, product, or service is helping people and the business, bring us that question. We can work out what is worth learning—and how the answer should shape what happens next.

Contact Us