This set of 22 notes really answers just one question:How to use data to clearly explain both "how good the UX is" and "whether it delivers business value". Broken down into four main threads —
- Choose the right metrics: Don't be fooled by Vanity Metrics that "only go up and never down"; look at ratios, time trends, and user segment breakdowns; understand the respective properties of conversion rate, success rate/completion rate, and time on page/page views.
- Division of labor between two quantitative methods: Analytics tools tell you "what users did", while quantitative usability testing tells you "whether users can succeed"; one covers breadth and the other covers depth, and they must be used together.
- Calculate UX ROI to show to leadership: Convert UX metrics into monetary value (or other KPIs) in four steps, but don't chase false precision — ROI is an estimate, not a financial statement.
- Statistical rigor: Statistical significance ≠ practical usefulness; means must be paired with confidence intervals, and even when data is not statistically significant, you can still make decisions using probability plus qualitative insights.
One core principle that runs through the entire piece:A good metric must be actionable — when it moves, you should know exactly what to do; if it moves and you do nothing in response, it is a vanity metric and you should ignore it.
1. Choose the right metrics: First recognize "vanity metrics", then replace them with "actionable metrics"
Covers: Vanity Metrics (what vanity metrics are) + Vanity Metrics: Add Context. The two articles overlap heavily, so they are explained together here.
Vanity Metrics = Numbers that look pretty and make you "feel good", but whose fluctuations cannot be linked to any action and provide no guidance for decision-making. Typical traits: the number only ever goes up and never down(cumulative download curves naturally rise over time),isolated with no context(a bare total count with no supporting information). NNGroup's McDonald's analogy: the sign by the door says "billions served", a huge number that tells you nothing about whether customers are satisfied or will come back.
| This is a vanity metric (don't only look at it) | Replace it with this to make it actionable | Why |
|---|---|---|
| Total downloads / total users / total page views / total shares | Ratios/proportions: average uses per user, new active users per download | Totals only go up, so they cannot show whether the experience has changed |
| Total video plays | Weekly play count (with a time frame day/week/month) | Only trends can tell whether a change or campaign worked |
| Single total conversion count | Per-user conversion rate, per-visit conversion rate (broken down by user segment/visit) | You see "what proportion of people completed the goal", not an absolute number |
| Total Monthly Active Users (MAU) | DAU/MAU Stickiness Ratio | A DAU/MAU of 10% means 1 out of every 10 monthly active users comes every day; it measures retention stickiness |
| Looking at unique visits / total visits separately | Compare the two (to judge whether users are bouncing back and forth between pages) | You only get context by comparing two related metrics |
Four methods to "add context"(to rescue vanity numbers): ① Convert to ratios/proportions; ② Apply a time frame(daily data catches anomalies but is prone to false alarms; annual data is stable but too slow — find the middle ground); ③ Segment by user/visit, using Cohort Analysis(e.g., did people who registered in the same week complete a certain action later, compared to the same cohort from the previous week); ④ Compare one metric against another related metric.
Two criteria for selecting effective metrics:Balance stability and sensitivity(stable under normal conditions, responsive when the design changes);Traceable to specific design decisions(if a change comes from seasonality or unexpected events rather than design, the metric is not suitable for evaluating design).
Core principle: An ideal metric "stays completely still most of the time, and only moves when something real changes in the system (a redesign or an outage)", rather than moving from random noise.Whether a change can drive you to act is the only litmus test. Counterexample: Celebrating that "10,000 people downloaded the app", only to find 8,000 of them never opened it again — that 10,000 is pure vanity.
2. The full conversion rate family: Conversion / Macro·Micro / Success vs Completion
Covers: What Is a Conversion Rate + Macro vs Micro Conversions + Success Rate vs Completion Rate. All three articles discuss "whether users achieved their goals", so they are combined into one map here.
Conversion Rate = One of the most important metrics in analytics, measuring whether a product successfully guides users to complete expected behaviors (purchase, form submission, sign-up). A higher conversion rate generally means more successful design, but it must be placed in context and a comparison framework to be meaningful.
Don't read conversion rates in isolation — it is affected by many external factors, and not all changes are due to UX:
| External confounding factors | Impact | What to do |
|---|---|---|
| Price changes / promotional discounts | Conversion rate rises, unrelated to UX | Exclude or list separately as a variable when interpreting |
| Seasonality (Black Friday, Double 11) | Holiday purchase intent is naturally higher | Compare to similar time periods; don't compare across seasons |
| Ad placement / marketing campaigns | Traffic composition changes, causing conversion rate fluctuations | Account for marketing variables in analysis |
Three rules for correct interpretation:Compare against historical trends(don't look at single points),exclude external factors, and combine with other metrics(retention rate, time on page) for a holistic view.
Macro vs Micro Conversions
| Macro Conversion | Micro Conversion | |
|---|---|---|
| What it is | Behaviors that directly correspond to core business goals | Small step behaviors along the path to macro conversion, with higher frequency |
| Examples | Complete purchase / register an account / submit a form / complete event sign-up / file taxes on a government website | Add to cart, start checkout, visit form page, subscribe to emails, download app |
| Measurement | Conversion rate (key success/failure metric) | Fine-grained tracking of user progress, locating drop-off points |
Micro conversions are further divided into two types:Process Milestones — Key steps on the path to macro conversion (select flight → fill in payment), defined via user journey maps, analytics data, and walking through the flow yourself;Secondary Actions — Do not directly lead to conversion but build trust and loyalty, and can predict future conversions(subscribe to emails, watch videos, share content).
Key judgment: mandatory actions vs optional actions. For things users must do (e.g., requesting leave on an employee intranet) → conversion rate does not apply; look at ease of use and error rate instead. For things users choose to do (e.g., whether to sign up for an event) → conversion rate is the right measure. Non-commercial/intranet and other non-monetized platforms can also use the Macro/Micro framework, though macro conversions are harder to define.
Success Rate vs Completion Rate — the easiest pair to confuse
| Completion Rate | Success Rate | |
|---|---|---|
| When to use | When user intent is clear and steps are fixed and linear (e-commerce checkout, registration) | When user intent is unclear and paths are diverse (finding a specific article, possible via navigation/search/tags) |
| How to measure | Analytics tools(Google Analytics) — but cannot measure users' original intent for visiting | Usability testing — Give participants a clear task, so you know definitively whether they succeeded |
| What to look at | Of the people who started the flow, how many reached the final step | Of the people given the task, how many achieved the goal,looking only at the outcome, not the path |
Core principle:Whether intent is clear determines whether you use analytics tools or usability testing. For fixed flows, use completion rate (automatically calculated by analytics tools); for flexible paths, use success rate (judged manually in usability testing).
"More" is not always better: How to interpret time spent / page views
Covers: How to Interpret User Time Spent and Page Views.
More clicks, more pages, longer time on site —whether this is good or bad depends on task type. NNGroup's Greek travel website example: the same behavior of "browsing many pages and staying a long time" is immersive enjoyment (positive)when planning an itinerary, but getting lost and frustrated (negative)when you only want to check a cruise departure time and can't find it — the analytics data looks almost identical, but the experience is completely different.
| Task type | User expectation | More time/clicks = | Optimization direction |
|---|---|---|---|
| Productive tasks (e.g., checking departure time) | Complete quickly and efficiently | Bad signal(stuck) | Shorter is better; reduce clicks and navigation |
| Engaging tasks (e.g., planning a trip) | Willing to browse slowly | Good signal(engaged) | Provide more explorable content |
Core principle: Analytics data tells you "what users did", but can never tell you "why"; you must pair it with usability testing to distinguish between "enjoyment" and "frustration". This leads directly to the next section.
3. Two quantitative methods: Analytics covers breadth, quantitative usability testing covers depth
Covers: Analytics vs Quantitative Usability Testing.
| Analytics | Quantitative Usability Testing | |
|---|---|---|
| What question it answers | What users did(which page they stopped on, what they clicked, how far they scrolled) | Whether users can successfully complete tasks, how high the efficiency is |
| Environment | Real natural environment, automatic real-time collection | Controlled environment, given tasks, manual observation |
| Data scale | Thousands to millions of records, used to observe overall trends | Small sample size,typically around 40 people |
| Cost | Low daily operating cost after the system is set up | Recruitment / scheduling / compensation,high cost, time-consuming |
| Strengths | Large-scale behavioral patterns, long-term trends | Specific usability issues + underlying reasons / thought processes |
| Weaknesses | Lack of context(knowing what happened but not why), complex upfront setup (event tracking / instrumentation) | Small sample size, difficult to generalize to the full user base |
Core principle: the two complement each other— analytics tools cover breadth (finding overall trends and where problems lie), usability testing drills into depth (explaining why and how to fix them). NNGroup repeatedly emphasizes that they are the "perfect pair." PM implementation: If analytics finds a large number of exits on the shopping cart page → don't rush to change it; first run usability testing to clarify whether it is a cluttered interface, slow loading, or something else, otherwise any changes will be blind changes.
IV. UX ROI: Converting Design Value into Money (or Other KPIs) to Show Leadership
Covers: Calculating ROI (principles version) + Calculating ROI in 4 Steps (numbers version) + How to Measure ROI (metric system version) + Three Myths (misconceptions version) + Don't Overthink (simplified version). These five articles on the same topic are combined into "principles → four steps → metric library → three myths → simplification."
Why calculate ROI: UX teams often lack early involvement and sufficient resources/funding because leadership does not support them. Calculating ROI = using financial language to prove that "design is not only good for users, but also brings great value to the business," in exchange for resources and cultural change.
Four-step ROI calculation method (Four Steps)
| Step | What to do | Health insurance website case |
|---|---|---|
| 1 Collect UX metrics | Take one quantifiable UX metric from benchmark testing (sources: surveys/NPS, analytics data, quantitative usability testing, customer service data) | Number of customer service tickets for the registration flow |
| 2 Select a KPI | Select one key performance indicator that the entire company cares about(profit / cost / CLV / employee productivity) | Cost savings (reducing customer service demand) |
| 3 Convert UX metrics → KPI | Like unit conversion, find the conversion ratio | Tickets 23,000 → 1,100,reduced by 21,900 tickets × $6 per ticket |
| 4 Report responsibly | State that this is an estimate, not a financial report, clarify data sources, state project costs, and extending the timeline to 2–5 years makes it more persuasive | See the complete script below |
Complete case numbers (all retained):
- Monthly savings = 21,900 × $6 = $131,400
- Annual savings = $131,400 × 12 = $1,576,800
- Project cost = $75,000
- Report script: "Registration-related customer service tickets decreased by 21,900. Assuming a cost of $6 per ticket, the estimated monthly savings are $131,400 and annual savings are $1,576,800; the project cost is $75,000,with a return of approximately $4,655,400 over three years. "
Standard ROI formula = (Gain − Cost) / Cost. In UX, gain = increased revenue / cost savings / efficiency improvement; cost = design + development + research + testing investment. Example: Conversion rate goes from 2% to 3% (monthly revenue increase of $10,000), project cost $5,000 → calculate ROI.
UX ROI metric library (menu provided by How to Measure ROI, select by dimension)
| Dimension | Metric | Definition / formula |
|---|---|---|
| Business layer | Conversion Rate | The proportion of visits that complete the target behavior |
| Retention Rate | The proportion of customers who continue to use the product over a period of time | |
| Customer Lifetime Value (CLV) | = Average purchase value × purchase frequency × length of customer lifecycle | |
| Sales growth / new revenue | New revenue brought by UX improvements | |
| Behavior layer | Bounce Rate | The proportion of users who enter a page and leave directly without taking any action |
| Task Completion Rate | = Number of users who successfully complete the task / Number of users who start the task | |
| Average Task Time | The average time taken to complete a specific task | |
| Dwell Time | The time users spend on the page | |
| Feedback layer | Net Promoter Score (NPS) | = % Promoters − % Detractors, a loyalty metric |
| Customer Satisfaction (CSAT) | Satisfaction with a specific product/interaction measured via survey | |
| Support Request Volume | Number of customer service requests (decrease = cost savings) |
Five steps to apply: Select appropriate metrics (if the goal is revenue increase → look at conversion rate/new revenue; if the goal is satisfaction → look at NPS/retention) → collect baseline data → calculate changes after improvement → quantify business gains → calculate ROI.
Three Myths + Don't Overthink
| Myth | Truth |
|---|---|
| ① ROI is all about money | ROI can be non-monetary goals— a government agency for oceanic and atmospheric research cares about "resource coverage / public perception quality" rather than profit; leadership may care more about retention rate / usage rate / brand influence |
| ② ROI must be completely accurate | ROI is an estimate, not a prediction. Calculating "saving $400,000 per year" does not mean there will actually be an extra $400,000 in the account at year-end (external variables, saved time may not all be used for production); the key is to estimate the potential value |
| ③ ROI must cover every detail | Complexity matches need.Design system case: The UX lead: The UX lead only calculated the repeated development time for one video plugin × the number of times it was repeated over the past few years,and in less than an hour convinced leadership to build a design system — they did not calculate all components and average hourly wages, because it was unnecessary |
Simplification tips (Don't Overthink): First clarify the goal (save time? improve efficiency? prove business value?) → adjust for the audience (bosses look at "how much money is saved," technical teams look at "how to implement it") → only do necessary calculations (focus on 1–2 core data points) → if data is missing, use reasonable assumptions/estimates(leadership cares about trends, not decimal points) → expand gradually from simple to complex. Tidy room analogy: spend one day organizing, and save 20 minutes every time you look for something over the next year, which pays back quickly.
Core principle: In organizations with high UX maturity,UX metrics themselves may be KPIs(such as "reduce task time"), in which case ROI conversion may not be necessary at all — don't calculate just for the sake of calculating. Counterexample: For the sake of "rigor," calculating every UI component and every variable into ROI takes weeks, by which time the boss has already checked out — overanalysis equals no analysis.
V. Statistical Rigor: Significance, Confidence Intervals, and How to Make Decisions Under Uncertainty
Covers: Practical vs Statistical Significance + Why Confidence Intervals Matter + Handling Insignificance in UX Data. These three articles form a logical chain: first understand significance → then understand confidence intervals → finally learn what to do when data is not significant.
Statistical Significance vs Practical Significance
- Statistical Significance = mathematics tells you "this difference is 95% not due to chance." But it only says a difference exists, not whether it is useful.
- Practical Significance = whether this difference is worth caring about for users/business.
- Classic example: Design A task completion time 72 seconds vs Design B 75 seconds, the 3-second difference is statistically significant, but users cannot feel it at all,so it is not worth spending money to change. Conversely: a small sample finds A is 30 seconds faster than B but it is statistically "not significant"; this 30 seconds may already be very important to the experience and worth taking seriously.
How to balance: ① First look at the actual impact of the difference on users/business; ② focus on effect size rather than only staring at p-values(with large samples, tiny differences easily become significant but meaningless; with small samples, non-significant results may still be worth taking seriously); ③ combine with qualitative research ("why the difference matters"); ④ always use user and business goals as the yardstick.
Analogy: Statistical significance is "finding a needle," practical significance is asking "can this needle knit a sweater."
Confidence Intervals — Don't Treat the Mean as a Certain Value
Samples only estimate the population.Confidence interval = the range within which the true value is very likely to fall. Example: The measured average completion time is 4.3 minutes, but you should report "we are 95% confident that the true mean is between 3.6–4.9 minutes."
What determines the width of the interval:
- Sample size: more samples → narrower interval, more accurate; fewer samples → wider interval.
- Data consistency: large differences between individual data points (1 minute vs 10 minutes) → wider interval; more consistency → narrower interval.
- Confidence level: commonly 95%; if you want higher confidence (99%) → the interval becomes wider.
How to use: ① If the goal is "complete checkout within 5 minutes" and you see the upper bound of the interval is 4.9 minutes → you can safely say "basically achieved"; ② When reporting,provide the mean together with the interval(only saying 4.3 minutes appears overly precise); ③ In A/B testing,look at the degree of overlap between the two groups' intervals — heavy overlap = the difference is likely small; almost no overlap = the difference is very likely real.
How to Make Decisions When Data Is Not Significant (Handling Insignificance)
Statisticians often say "don't make decisions without significance" — but"not making a decision" is itself a decision(equivalent to continuing to use the old design, which may miss growth opportunities). And collecting more data has costs:
- Opportunity cost / time cost: Continuing to use the old design while waiting for data may cause ongoing losses; running prolonged A/B tests also crowds out opportunities to test other ideas.
- Do the math: If the cost of collecting more data is $200,000, but the expected improvement only brings $100,000 in additional revenue —it is not worth it.
Two ways out:
- Probability-based decision-making: The mean is still the maximum likelihood estimate. Even if Design A only has a 60% probability of being better (40% risk), you can still choose A based on this — because extreme scenarios like "A's true value is at its lowest point + B's true value is at its highest point" are very rare.
- Rely on qualitative insights: When quantitative data is insufficient, rely on user testing / heuristic evaluation / UX professional judgment.Strong qualitative information should take priority over weak quantitative data.
Integrated decision framework: Quantitatively significant → prioritize statistics; quantitatively not significant → turn to qualitative data; qualitative data is also unclear → fall back to the maximum likelihood option, but clearly recognize the risks.
VI. Benchmarking: Using a "Yardstick" to Prove Whether a Redesign Is Actually Worth It
Covers: Benchmark Usability Testing (how to do it) + The Benefits of Benchmarking (why it is worth it).
Benchmarking = using quantitative data and summative evaluation to measure a product's performance against a certain standard, and track the effect of improvements. Frequency is usually once a year or after major iterations; you can compare against your own history, or against competitors/industry averages. Compared to "you need to weigh yourself first before losing weight" — without a baseline, you cannot tell whether a redesign had an effect.
How to do it (key numbers): ① Set goals (measure time? errors? satisfaction?) → ② recruit at least ~20 people(more than daily small-scale tests, so the data is representative) → ③ Record the current state as the Baseline → ④ After the redesign, test again with the same method and compare old and new.
Why it is worth it(three major benefits):
- Measure progress: Look back at whether changes met the goals.
- Demonstrate impact: Quantify and prove value to stakeholders (example: completion time for a certain task reduced by 60%).
- Quantify business value: Linking metrics to revenue/cost is most persuasive. NNGroup case: an internal application reduced a key task from 10 minutes to 4 minutes(saving 6 minutes), for the company's 1,000 employees × average hourly wage of $50 → estimated huge labor cost savings → secured funding for subsequent projects.
Core principle: Benchmarking is the data source for ROI calculation (Step 1 of the four-step method comes from benchmarking). Without a baseline, all claims of "improved by X%" are empty talk.
VII. Supporting Research Methods: Sampling / Confounding Variables / Triangulation / Statistical Personas / Long Tail
This section wraps up five methodology articles that "support the quality of quantitative research." They are not directly metrics, but they determine whether your metrics are credible.
7.1 Convenience vs Probability Sampling
| Convenience Sampling | Probability Sampling | |
|---|---|---|
| How participants are selected | Recruit people who are easy to reach (non-random) | Random; every member of the population has a chance of being selected |
| Bias / Generalizability | High bias, difficult to generalize | Low bias, generalizable to the overall population |
| Cost | Low cost, fast | High cost, time-consuming and complex |
| Best suited for | Rapid iteration, discovering usability problems, early exploratory research | Large-scale studies, high-stakes decisions, situations requiring population inference or group comparisons |
Two types of probability sampling:Simple random sampling(every person has equal probability),Stratified sampling(first divide into groups such as novices/experts, then randomly select from each group to ensure representation of every category).Sample size thresholds (key numbers): at least 40 participants for quantitative testing,at least 40 people, at least 100 respondents for survey research at least 100 people. Probability sampling is only possible when you can obtain a complete list of users (CRM customers, enterprise employees, project participants); for anonymous e-commerce visitors, potential new users, or churned users for whom no list is available, you can only use convenience sampling.
Core principle: In UX research,convenience sampling is the most commonly used method— because most studies aim only to discover usability problems and do not require statistical inference. Upgrade to probability sampling only when you "need to generalize to the whole population, when stakes are high (healthcare/banking/automotive), or when you need to compare between groups." Note:Setting screening criteria ≠ random sampling; do not test with colleagues (their feedback is biased).
7.2 Confounding Variables
A confounding variable = an unmeasured hidden variable that affects both the independent variable and the dependent variable at the same time; it contaminates results and threatens internal validity. Classic example: testing Design A in the morning and Design B in the afternoon → "time of day / learning effect / post-lunch fatigue / hunger" all become confounding variables.
| Common confounding variables | Solutions |
|---|---|
| Age (affects satisfaction, task completion time, success rate, reading ability) | Recruit a representative age sample + use random assignment |
| Seasonality (Q4 vs Q1) | Compare data collected during similar time periods |
| COVID-19 pandemic | Exclude date ranges when the pandemic was most severe |
| Market competition (competitor major promotions / new product launches) | Avoid conducting research during major market upheavals |
| Existing product experience / prior opinions | Recruit participants with different experience levels or screen out those with extreme positive or negative sentiment |
Best practices to avoid confounding: Prioritize within-subjects design + randomized order; for between-subjects designs,randomly assign participants to groups; identify and control known confounding variables; keep the testing environment consistent; if control is truly difficult, switch to qualitative research.
7.3 Triangulation
Triangulation = examining the same problem using multiple data sources or multiple methods to improve credibility (the concept originates from geometry). It takes two forms:Multi-method(using quantitative + qualitative + expert review to examine the same activity),Multi-metric(looking at satisfaction + time on page + revenue together).
Practical examples: If satisfaction drops → check visit duration and revenue to corroborate; if subscription form success rate is low → use interviews to understand barriers; if interviews reveal common themes → have another researcher independently analyze and verify.When to use it:The higher the stakes of the decision, the more you need triangulation(full-site redesigns require thorough triangulation; minor UI changes do not).
Core principle: The key is not "how much time we can spend on research," but "how much risk of failure we can tolerate." Market feedback after product launch will ultimately become a data source, but making changes at that point is more expensive and difficult.
7.4 Statistically-Generated Personas
Personas are fundamentally a qualitative tool(used to map intrinsic motivations and pain points), but statistics can be added to improve generalizability. Process: ① Lay a qualitative foundation(conduct interviews with 5–30 people to identify common themes) → ② design a survey based on the themes → ③ collect at least 100 responses, ideally 500+ samples → ④ use clustering methods such as Latent Class Analysis (which excels at handling categorical survey data and missing data).
Limitations / counterexamples: Purely statistical approaches may produce conclusions that are "obvious and lack insight" (e.g., users' primary device is iPhone, they self-identify as early adopters, they love Tesla and Apple) — the data holds true but provides no design guidance.Always base personas on qualitative understanding; statistics are only a supplement; if you lack statistical expertise, collaborate with a data scientist. For details see NNGroup Personas (Essence / Three Types / Scope Hierarchy / Creation / Comparison with JTBD-Prototypes-Segmentation / Application / Maintenance / 5 Major Failures).
7.5 Long-Tail Data
Sales and behavioral data often follow a power-law distribution: a small number of hits/high-frequency behaviors sit at the head, while a large volume of low-frequency items form the "long tail" at the back. Chris Anderson proposed the long tail theory; Amazon and Netflix profit by eliminating physical inventory to meet niche demand.Four long-tail scenarios where UX can deliver value: ① Revenue from niche content on e-commerce/social media (enable users to find content through strong search + recommendations + information architecture); ② SEO long-tail keywords (low competition, precise traffic, low cost; mine them by analyzing internal search logs); ③ Website latency (most requests are fast, but extremely slow long-tail requests cause user and revenue loss; collaborate with engineering to optimize them); ④ Machine learning (large datasets including rare samples are needed to reduce error rates; design recommendation systems to help collect data + build trust without frequent interruptions).
Relationship with the Pareto (80/20) principle: The 80/20 rule = focus on the 20% that drives 80% of results (short-term resource optimization / fast decisions); the long tail = optimize the cumulative value of many low-impact points (long-term value). The two appear to conflict but are actually complementary.
Sourced from NNGroup Topics / Analytics & Metrics (22 articles). Related:NNGroup Quantitative Research (A/B Testing · Sample Size · Confidence Intervals · UX Metrics · Conversion Analysis · Benchmarking · Learning Curves), NNGroup Qualitative Research and Research Methods Toolkit (Method Landscape / Interviews / Empathy Maps / Sample Size / Task Design / Moderation / Expert Evaluation / Workshops / Ethics), NNGroup Personas (Essence / Three Types / Scope Hierarchy / Creation / Comparison with JTBD-Prototypes-Segmentation / Application / Maintenance / 5 Major Failures), Google UX Certificate / UX Research and Empathy - Define. Images and original files are retained in sources.
Sources and Related Materials
- NNGroup Quantitative Research (A/B Testing · Sample Size · Confidence Intervals · UX Metrics · Conversion Analysis · Benchmarking · Learning Curves)
- NNGroup Qualitative Research and Research Methods Toolkit (Method Landscape / Interviews / Empathy Maps / Sample Size / Task Design / Moderation / Expert Evaluation / Workshops / Ethics)
- Google UX Certificate / UX Research and Empathy - Define