Data-Driven Design

Triangulation Core Principle

Use when: any analytics finding needs validation before acting on it.

All methods have limitations and blind spots. Analytics shows what is happening but not why. Usability testing reveals why but with small samples. Surveys capture attitudes but are self-reported. Support calls reflect the loudest problems, not the most common. Triangulation means using multiple methods to study the same phenomenon — when analytics, usability testing, and support data all point to the same issue, you can act with confidence. When they diverge, the discrepancy itself is the insight. Start with analytics to identify the problem area, then triangulate with qualitative methods to understand causes before designing solutions.

HEART Framework Framework

Use this to define user-centered metrics for any product or feature.

Google's HEART framework organizes metrics into five categories: Happiness: Satisfaction, perceived ease of use (NPS, SUS, CSAT surveys). Engagement: Frequency and depth of interaction (sessions per week, features used, time in app). Adoption: New users successfully onboarding (signup-to-first-action rate, feature adoption). Retention: Users returning over time (Day 1/7/30 retention, churn rate). Task effectiveness & efficiency: How well and how quickly users complete specific flows (completion rate, time-on-task, error rate, productivity). Don't track all five for every feature — pick 1-2 that match your current question.

HEART Metric Source Mapping Reference

Use this to decide which measurement method will produce the HEART metrics you need.

Different methods produce different HEART metrics. Happiness comes only from surveys (satisfaction rating, ease-of-use, perceived usability, questionnaire scores). Engagement comes primarily from analytics (frequency of return, average time spent, sessions per user, feature usage, conversion rate). Adoption & Retention come from analytics (new accounts, returning users, churn rate, renewal rate, repeat purchases). Task effectiveness & efficiency come from quantitative usability testing (success rate, time on task, error counts, productivity) and from analytics (completion rate, time on page). Surveys capture the subjective side of any category — combine them with behavioral methods for a complete picture.

Event Taxonomy Design Core Method

Use when: setting up analytics for a new product or feature.

An event taxonomy is a structured naming system for everything you track. Without one, analytics becomes a mess of inconsistently named events that no one trusts. Structure: Object + Action naming. "Button Clicked" is useless. "Checkout_Payment_Submit" tells you what, where, and when. Maintain a tracking spreadsheet: event name, trigger condition, properties captured, who requested it, and why. Review quarterly — remove events no one looks at, add events for new questions.

Event Metadata Model Technique

Use when: structuring in-page event tracking for comparison and filtering.

Structure event data with three metadata fields: Category (page or content type — "Blog," "Product," "Help"), Action (interaction type — "Scroll," "Button Click," "Form Submit"), Label (specific element — "Related Links," "Add to Comparison," "Contact Us Form"). This structure lets you filter and compare events across dimensions: filter by Category to see all Blog interactions, filter by Action to compare all scroll events across page types, filter by Label to track a specific element's usage across the site. Plan naming conventions carefully and maintain them — inconsistent metadata makes event data useless.

Heatmap Analysis Technique

Use when: understanding how users interact with a specific page layout.

Heatmaps are "heat" visualizations overlaid on a screen showing where users interacted — clicks, scrolling depth, hovering, taps, and gestures. Click heatmaps reveal which elements attract attention and which are ignored. Scroll heatmaps show how far down users actually get — critical for knowing if important content is seen. Hover heatmaps show mouse movement patterns (loosely correlated with visual attention on desktop). Key practices: always review heatmaps after releasing new layouts, look for attempted interactions (users clicking non-clickable elements — a signal of unmet expectations), and compare heatmaps across device types. Heatmaps tell you where users interact, not why — triangulate with usability testing to understand the behavior.

Metric Interpretation Framework Reference

Use when: reading analytics reports — to avoid misinterpreting common metrics.

Pageviews vs. unique pageviews: Pageviews count every view including repeated visits in the same session. Unique pageviews count one view per session. When pageviews are drastically higher than unique pageviews for a page, it suggests pogo-sticking — users leaving and returning repeatedly, indicating navigation or information architecture problems. Entrances are sessions where a page was the first viewed. Exits are sessions where it was the last. A high exit rate on a checkout confirmation page is expected; a high exit rate on a product page is a problem. Bounce rate is the percentage of sessions with only one page interaction. Interpretation depends entirely on context: 60% is normal for blogs and landing pages, 40% for ecommerce, and exceptionally low rates (under 5%) are almost always tracking errors. Always consider the source of traffic, the volume, and the type of page before reacting to a bounce rate.

Time-on-Page Inference Technique

Use when: interpreting time-based metrics in web analytics.

Most web analytics tools calculate time on page by subtracting the current page load time from the next page load time. This means the last page in a session has no measured time — the user might have spent 20 minutes reading it or abandoned after 5 seconds. Application analytics tools often measure exact session end times, but web analytics cannot. Consequences: average time-on-page metrics are systematically underestimated because exit pages show as zero, and long reading times can be indistinguishable from users who left a tab open. Combine time-on-page with scroll depth and event data for a more accurate picture of engagement.

Internal Search Log Analysis Technique

Use when: understanding what users are looking for and whether your navigation supports them.

Internal site search data reveals user needs in their own words. For content strategy: the most common search terms tell you what users value — prioritize that content and use their terminology. For navigation and layout: frequently searched terms that should be easy to find without searching indicate navigation or labeling problems. For feature prioritization: compare segments of users who search vs. those who browse — do searchers stay longer or convert more often? Typical search usage: 30-70% for ecommerce, support, and government sites; lower for news, banking, and transactional sites. High search rates can mean users rely on search as primary navigation — which may indicate poor information architecture rather than a well-designed search experience.

Funnel Analysis Core Method

Use when: understanding where users drop off in a multi-step flow.

A funnel shows the percentage of users who complete each step in a sequence: landing page → signup form → email verification → first project → active use. The drop-off between each step reveals where the experience breaks. A 60% drop-off between "signup form" and "email verification" suggests the email process is the problem, not the form itself. Funnels are most useful when segmented — compare funnels by traffic source, device type, user segment, or date range to identify which users are dropping off and when.

Goal Architecture Framework

Use when: defining what to measure for non-linear user paths.

Not every user flow is a funnel. For non-linear paths, define goals (success events) at two levels. Macro-conversions: transaction completions — purchasing, registering, downloading. Micro-conversions split into two types: process milestones are steps toward a macro-conversion (adding to cart, starting checkout); secondary actions are desirable behaviors that indicate future macro-conversions (adding to favorites, writing a comment, playing a video, clicking an external partner link, starting a live chat). Three goal types by business model:

• Revenue — orders, quotes, upgrades.
• Acquisition — accounts created, trials started, contact forms completed, newsletter subscriptions.
• Engagement — feature usage, specific pages visited, content interactions. Assign relative goal values — either through stakeholder prioritization or by estimating monetary value (e.g., email subscription value = total revenue from subscribers ÷ number of subscribers).

Page Value Analysis Technique

Use when: prioritizing which pages to improve based on their contribution to goals.

Page value is the average value of a page based on which pages were visited in sessions that led to goal completions. High page value indicates that visitors to this page frequently complete valuable goals. Low page value indicates the page is not often viewed by users who convert. This lets you prioritize by value rather than just traffic volume — a page with moderate traffic but high page value is more important to optimize than a high-traffic page that doesn't contribute to conversions. Combine with qualitative research to understand why certain pages contribute to conversions.

A/B Test Design Core Method

Use when: choosing between two design alternatives with a measurable outcome.

1. Hypothesis: "Changing the CTA from 'Sign Up' to 'Start Free Trial' will increase signup conversion by 10% because it reduces perceived commitment." Always state what you're changing, what you expect to happen, and why. 2. Primary metric: One metric that determines the winner. Don't track 20 metrics and pick the one that looks best — that's p-hacking. 3. Sample size: Calculate before running. Too few users = unreliable results. Use an online calculator (Evan Miller's is standard). Most tests need 1,000-10,000 users per variant for meaningful results. 4. Duration: Run for at least 1-2 full business cycles (typically 2-4 weeks) to account for day-of-week and time-of-day variation. 5. Decision: Did the variant beat control with statistical significance (p < 0.05)? If yes, ship it. If no, keep the control.

Multivariate Testing Advanced Technique

Use when: you need to test combinations of page elements to determine which specific elements contribute to conversion lifts.

Unlike A/B testing (which compares whole-page variants), multivariate testing compares combinations of individual elements — heading A with image 1 vs. heading B with image 2 vs. heading A with image 2, and so on. This reveals which specific elements drive the lift, not just which overall page performs better. The tradeoff: multivariate testing requires significantly more traffic because each combination needs its own sample. Use A/B testing for major design changes and multivariate testing for fine-tuning within a proven design.

Iterative A/B Testing Plan Technique

Use when: optimizing a page or flow through sequential experiments rather than a single test.

Rather than testing one variant and stopping, plan a sequence: test version A vs. B, then take the winner and test it against a new variant C, then the winner against D. Each iteration builds on validated improvements. This approach is more reliable than testing many variants simultaneously (which increases false positive risk) and produces compounding gains. Document each phase's hypothesis, result, and learning to build an institutional knowledge base of what works in your context.

Cohort Analysis Core Method

Use when: understanding how user behavior changes over time or across groups.

A cohort is a group of users defined by a shared characteristic — usually their signup date. Cohort analysis tracks how each group behaves over time. January signups: 40% returned in week 2, 25% in week 4. February signups (after onboarding redesign): 55% returned in week 2, 38% in week 4. This comparison shows whether your changes improved retention for new users without being confused by the behavior of older users. Retention curves flatten where users become habitual — the goal is to raise the curve and flatten it earlier.

Analytics Segmentation Core Method

Use when: aggregate data obscures meaningful differences between user types.

A segment is a filter that excludes data not relevant to your question. Analytics data aggregates all activity — segmenting reveals hidden patterns. Segments can be based on: traffic source (referring URLs, campaigns, keywords, social channels), technical info (device, screen size, browser), activity performed (landing page, pages viewed, events triggered, conversions), user history (new vs. returning, visit count, days since last visit), and session characteristics (pages per session, time of visit, location). Behavior can differ greatly between segments — a high bounce rate might be entirely driven by mobile users from paid ads, while organic desktop users convert well. Segmenting reveals where to focus improvement efforts.

Persona Validation via Analytics Technique

Use when: you have personas and want to test whether they reflect real behavior patterns.

Create analytics segments based on each persona's unique behavioral traits — devices used, pages visited, features used, visit frequency. Then ask two questions: (1) Does the volume of visitors in that segment match your expectations? If you estimated 30% of users are "power users" but the segment shows 5%, either the persona definition is wrong or the behavioral proxy is wrong. (2) Do visitor outcomes (conversion rate, retention) for that segment match your persona's described goals? If your "comparison shopper" persona should browse many products but rarely buy immediately, the segment should confirm that pattern. Analytics segments can validate, refine, or invalidate personas with real behavioral data.

Path Analysis Core Method

Use when: understanding how users navigate between pages, features, or actions.

Path analysis shows the distribution of all pages or events users visit as their next step from any given point. Three types of paths to analyze:

• Exploratory tracking — see which pages users visit after a specific page, revealing unexpected navigation patterns and dead ends.
• Linear workflow progress — track steps through a defined process (onboarding, checkout).
• Multi-session engagement — track how behavior evolves across return visits. For conversion optimization, segment by users who converted and examine their time lag (days between first visit and conversion) and path length (number of interactions before converting). If most converters take 14 days and 3+ visits, a one-session conversion flow is unrealistic — design for the return visit instead.

Recency-Frequency Analysis Technique

Use when: understanding retention patterns and identifying opportunities to increase return visits.

Recency: number of days since each user's last session — reveals patterns in return visit timing. If most users return within 7 days, align system touchpoints (emails, notifications) to that natural rhythm. Frequency: number of visits per user within a time period — reveals engagement depth. Look for correlations between first-visit feature usage and likelihood of returning. Identify which features or content types predict retention, then prioritize making those features more discoverable during first visits.

Quantitative Usability Methods Cluster Core Method

Use when: you need measurable usability data to complement qualitative observations, benchmark performance, or track improvements over time.

Quantitative usability goes beyond "did users struggle?" to "how much did they struggle, and is that improving?" Key methods: System Usability Scale (SUS) is a 10-item questionnaire producing a score from 0–100. Scores above 68 are above average; above 80 is good; above 90 is exceptional. Administer it immediately after a task session. Time-on-task measures efficiency — how long does a representative task take? Track geometric means (not averages) because task times are skewed. Compare against benchmarks or prior versions. Task success rate is the percentage of users who complete a task without critical errors. Binary (pass/fail) or graded (complete, partial, fail). Error rates count the number and severity of errors per task. Distinguish slips (mechanical mistakes) from errors (conceptual misunderstandings) — they have different design implications. Post-task questionnaires like the Single Ease Question (SEQ: "How easy was this task?" on a 7-point scale) capture subjective difficulty immediately after each task, giving you per-task satisfaction data alongside performance metrics.

Standardized Questionnaire Instruments Reference

Use this to select the right pre-made questionnaire for your benchmarking context.

Beyond SUS and SEQ, several standardized instruments serve specific purposes. SUPR-Q measures usability, appearance, and trust for websites — useful when you need a holistic website quality score, not just usability. UMUX-Lite is a two-item alternative to SUS — faster to administer and strongly correlated with SUS scores, useful when you can't afford 10 questions. NASA-TLX measures subjective workload across six dimensions (mental demand, physical demand, temporal demand, performance, effort, frustration) — essential for complex or safety-critical domains where task difficulty matters more than satisfaction. NPS measures likelihood to recommend on a 0–10 scale — popular with executives but tells you nothing about why. CSAT measures satisfaction with a specific interaction — more actionable than NPS because it's tied to a moment. Choose based on what you need to know: task difficulty (SEQ), overall usability (SUS/UMUX-Lite), website quality (SUPR-Q), workload (NASA-TLX), or loyalty trending (NPS).

Post-Task vs Post-Test Survey Design Technique

Use when: designing the survey component of a quantitative usability study.

Surveys within usability testing come in two forms. Post-task surveys are administered immediately after each task — typically a single question like SEQ asking how easy the task was. These capture per-task subjective data that pairs with performance metrics (time on task, success rate) for that same task. Post-test surveys are administered after the entire session — typically a multi-question instrument like SUS that captures overall product perception. Always use post-task for per-task difficulty data and post-test for holistic assessment. When distributing surveys outside of usability testing — via email, embedded intercepts, or popups — aim for 100+ respondents. Within usability testing, 40 respondents is usually sufficient for statistical significance on rating scale comparisons.

Practical vs. Statistical Significance Technique

Use when: interpreting A/B test results or quantitative usability data and deciding whether a difference is meaningful enough to act on.

A statistically significant result means the difference is unlikely due to chance. A practically significant result means the difference is large enough to matter. These are not the same thing. A test with 500,000 users might find that version B has a 0.02% higher click rate with p<0.01 — statistically significant but practically meaningless. Conversely, a test with 50 users might show a 15% task completion improvement with p=0.08 — statistically borderline but practically important. For UX decisions: always consider effect size alongside p-values. A 2-second reduction in task time matters more than whether the p-value crosses 0.05. Set your minimum detectable effect before running the test — decide how big a difference would change your design decision, then calculate the sample size needed to detect that difference reliably.

RAS: Recommendation-Adoption Score Technique

Use when: tracking whether research findings actually influence product decisions, or when you need to demonstrate research team impact.

Most research teams track output (studies completed, reports delivered) rather than impact (recommendations acted upon). The Recommendation-Adoption Score (RAS) measures what matters: what percentage of research recommendations were adopted by the product team? Track each study's key recommendations, follow up after 30/60/90 days to see which were implemented, and calculate the ratio. A low RAS signals a disconnect between research and product — either the research isn't actionable, the findings aren't communicated effectively, or the product team doesn't value research input. A healthy RAS is above 60%. Below 40% means your research practice needs structural changes, not more studies.

Eyetracking Evidence as Design Input Technique

Use when: optimizing content layout, headline placement, or visual hierarchy based on how users actually scan pages.

Decades of eyetracking research reveal consistent scanning patterns that should inform layout decisions. F-pattern: On text-heavy pages, users scan the first few lines horizontally, then scan down the left side — content placed in the right column of long pages gets less attention. Layer-cake pattern: On well-structured pages with clear headings, users scan the headings (the "cake layers") and read the content beneath headings that interest them — making heading quality critical. Spotted pattern: Users scan for specific visual features (numbers, links, bold text, images) and skip everything else — useful for search results and data-rich pages. Commitment pattern: Users read content thoroughly from top to bottom — this only occurs when motivation is high (health information, financial decisions, legal text). Designers don't need to run eyetracking studies — but they should use these established patterns to predict where attention will fall and place critical content accordingly.

UX Benchmarking Process (Seven Steps) Core Method

Use when: establishing a measurement practice to track UX quality over time and demonstrate design impact.

The process has three setup steps and four recurring steps. Setup (once): (1) Choose what to measure — identify the product, its top tasks, and select 5-8 UX metrics considering what UX changes will impact, what your team and stakeholders value, and what connects to business KPIs. (2) Choose how to measure — select from analytics (cheap, fast, uncontrolled), quantitative usability testing (controlled, expensive, 40+ participants), and surveys (self-reported, 40-100+ respondents). Ideally combine a behavioral method with a survey method. (3) Collect the first measurement — this baseline gives you a starting point. Even without prior data, compare against competitors, industry benchmarks, or stakeholder-determined goals. Recurring: (4) Redesign the product. (5) Collect another measurement — wait for users to adapt after a major redesign before measuring. (6) Interpret findings — watch for confounding variables, calculate statistical significance, make comparisons. (7) Calculate ROI (optional) — connect UX metrics to business KPIs. Repeat steps 4-7 after each major iteration, quarterly, or annually.

Four Comparison Types Technique

Use when: you need context for your UX metrics — a number alone is meaningless without something to compare it to.

Benchmarking requires meaningful comparisons. Previous version: Compare the current design against the prior version — the most common approach and the core of longitudinal benchmarking. Competitor: Conduct the same study on a competitor's product to see how you compare — requires quantitative usability testing or surveys since you can't access competitor analytics. Industry benchmark: Compare against published industry averages from sources like MeasuringU, ACM Digital Library, or NN/g reports. Stakeholder-determined goal: Compare against a target agreed upon with stakeholders — useful for setting concrete expectations and tracking progress toward them. Use at least two comparison types for maximum persuasive power.

Goals Pyramid Framework

Use when: you need to connect your UX metrics to the organization's broader objectives — essential for choosing metrics that stakeholders care about.

Four levels, top to bottom:

• Long-term vision — what are we doing here?
• Organization goals — what is success for our company?
• Product goals — what is success for this product?
• Metrics — what will we measure? Work top-down: each level constrains the next, ensuring your metrics connect to strategy rather than measuring what's convenient. For example, an e-commerce site's vision might be to be the most trusted marketplace; organization goal is increasing customer lifetime value; product goal is making repeat purchasing effortless; metrics become repeat purchase rate, time-to-reorder, and ease-of-use rating for the reorder flow.

Benchmarking Philosophies Framework

Use when: deciding your overall approach to metrics measurement — holistic monitoring vs. focused tracking.

Two contrasting approaches: Holistic/Lifecycle Model: systematic monitoring of outcomes at each stage of the user lifecycle — Discovery (new users, sources, channels, onboarding), Usage (task completion, task efficiency), Operations (delivery efficiency, support efficiency), and Retention (repeat users, frequency, duration). This approach catches problems across the entire experience and works well for mature teams with resources for comprehensive measurement. North Star Model: identify one metric that indicates whether your product is providing value to users. Facebook uses daily active users. Airbnb uses nights booked. Dropbox uses files downloaded. The North Star metric should be measurable, controllable by the product team, and clearly connected to user value. This approach provides focus but risks blind spots in areas the single metric doesn't capture. Most teams benefit from a hybrid — a North Star metric for strategic alignment, supplemented by holistic lifecycle monitoring to catch what the North Star misses.

KPI-to-Metric Mapping Process Core Method

Use when: selecting metrics for a benchmarking program — ensures you measure things that connect to real outcomes.

Three levels, top-down:

• (1) Describe success outcomes — what will the world look like if our product is working well? "More people use our product." "Users complete their tasks efficiently.".
• (2) Identify contributing user actions — what specific behaviors signal the outcome has occurred? "People download the app who haven't installed it before." "Users complete the checkout flow without errors.".
• (3) Select metrics to track — which numbers accurately detect changes in those user actions? App store page visits, daily downloads, checkout completion rate, error counts. Articulating the first two levels ensures you (a) only select metrics connected to real-world outcomes you want to achieve, and (b) broaden your view of what data could measure success — avoiding the trap of measuring only what's convenient.

Benchmarking Method Comparison Reference

Use when: deciding which quantitative method to use for your benchmarking program.

Three primary methods compared on data collection, context, cost, and difficulty. Quantitative usability testing: observed data, task-based context, medium cost, medium collection difficulty, medium analysis difficulty. Best for controlled measurements of specific tasks, and the only reliable method for comparing against competitors. Minimum 40 participants. Surveys: reported data, natural or task-based context, low cost, low collection difficulty, high analysis difficulty. Best for capturing user perceptions and attitudes. Minimum 40 within usability testing, 100+ for online distribution. Analytics: observed data, natural context, low cost, low collection difficulty, high analysis difficulty. Best for tracking real-world behavior at scale. Collect 2-4 weeks of data per measurement period. Analytics is uncontrolled — confounding variables (competitor sales, seasonality, global events) can influence results and must be acknowledged in reporting.

Data Storytelling Framework Core Method

Use when: presenting analytics findings or benchmarking results to stakeholders.

Effective data communication combines narrative and visualization. The narrative follows five story elements:

• Setting — the time and place the data originates from (which product, which time period, which users).
• Characters — connect the data to real people to give stakeholders a reason to care (users, customers, specific personas).
• Plot — describe causes and effects, what happened before and after, to create curiosity.
• Conflict — highlight the challenge, surprise, or discrepancy that demands action (a counter-intuitive finding, a gap between expectation and reality).
• Resolution — recommend a next step for investigation or implementation. Example: "Many potential customers visit the pricing page [Setting], indicating serious interest [Characters]. Yet compared to other pages, this page is less likely to lead to conversions [Conflict]. With 5M+ annual visitors, even small conversion increases make a significant impact [Plot]. We should experiment with adjusting this page [Resolution].".

Data Visualization Principles Technique

Use when: creating charts, graphs, or dashboards to present analytics findings.

Visualize numbers as symbolic shapes using easily recognized visual attributes — shapes, colors, size, and position. Key principles: Show just enough context to explain the data — strip away gridlines, legends, and decoration that don't serve the question. Emphasize the main takeaway with color, callouts, and titles — the title should state the insight, not describe the chart ("Login rates increased 25% after redesign" not "Login rates over time"). Eliminate unnecessary comparisons — if you're showing desktop and tablet separately but the story is "logins increased overall," combine them. Tables lack focus and emphasis; dashboards don't answer specific questions. Build each visualization to answer exactly one question and make that answer immediately visible.

UX ROI Calculation (Three Steps) Core Method

Use when: you need to demonstrate the business value of a design improvement to secure funding, justify UX investment, or prioritize projects.

Step 1 — Choose a KPI. Ask what your organization cares about. Common KPIs include profit, cost savings, customer lifetime value, employee productivity, support ticket volume, and customer satisfaction. Study your stakeholders the way you'd study users — find out what resonates. The same UX improvement might be pitched as time savings to one stakeholder and cost reduction to another. Step 2 — Convert the UX metric into the KPI. Find the conversion ratio. Reduced support tickets × cost per ticket = cost savings. Increased completion rate × number of users × average sale value = revenue gain. You'll need assumptions: number of people impacted, frequency of use, transfer rates (e.g., percentage of leads that become paying customers), financial data (average sale value, hourly wage), and unit conversions (seconds to hours). Reach out to analytics, HR, finance, or marketing teams for these numbers. Step 3 — Report responsibly. Always state your assumptions explicitly, acknowledge that these are estimates, project returns over 2-5 years (design improvements are cumulative), and subtract project costs.

Predictive ROI Technique

Use when: pitching a redesign project before the work is done — estimating the potential return to secure funding.

Predictive ROI uses your baseline measurement plus a reasonable estimate of improvement to project future gains. The estimate should be informed by your understanding of users and the product, how much room for improvement exists (a terrible design has more upside than a good one), and any related data sources (industry benchmarks, past redesign results). NN/g's longitudinal data across dozens of organizations suggests an average improvement score of 75% for redesigns, with an interquartile range of 13% to 157%. Use the lower bound for conservative estimates and the median for realistic ones. After the redesign ships, replace the prediction with actual measured data.

ROI Reporting Template Template

Use when: presenting ROI findings to stakeholders — this framing sets expectations correctly.

Follow this structure: "We observed a [percent increase/decrease] in [UX metric]. Assuming [list each assumption], this improvement could potentially translate to an estimated [amount increase/decrease] in [KPI]. Since the design project cost approximately [project cost], our estimated return over [timeframe] is [projected return]." The word "potentially" matters. The word "estimated" matters. Never present ROI as a guarantee — present it as a directional indicator of value.

Correlation-Based ROI (UX-Revenue Chain) Advanced Technique

Use when: your UX metrics don't directly translate to revenue — common in enterprise products where the link between ease of use and business outcomes is indirect.

When UX metrics can't be directly converted to dollars, look for chains of correlations. The UX-Revenue Chain model hypothesizes that UX factors (usability, product quality, customer support) drive overall satisfaction, which drives loyalty (retention, referrals), which drives revenue. Build the chain by starting with qualitative data to identify which experience factors matter most to your users, then collect large-scale survey data to test correlations between those factors and business metrics. Breaking the analysis into multiple steps reduces noise — ease-of-use ratings don't directly predict referrals, but they predict satisfaction, which predicts loyalty, which predicts referrals. Even if you don't succeed in proving the correlation, the pursuit forces you to understand stakeholder priorities and business models more deeply.

Improvement Score Formula Calculation

Use when: computing the relative magnitude of a design change's impact on any metric.

The formula depends on whether the metric is "good" (higher = better) or "bad" (lower = better). Good metrics (conversion rate, satisfaction, success rate): improvement = (after ÷ before) – 1. If conversion went from 2% to 5%, the improvement score is 5/2 – 1 = 150%. Bad metrics (time on task, error rate, support tickets): improvement = (before ÷ after) – 1. If time on task went from 3 minutes to 2 minutes, the improvement score is 3/2 – 1 = 50%. This formula standardizes improvements across different metric types, allowing you to compare the relative impact of projects that measured different things.