So we design and ship a shiny new feature. How do we know if it’s working? How do we measure and track its impact? There is no shortage in UX metrics, but what if we wanted to establish a simple, repeatable, meaningful UX metric — specifically for our features? Well, let’s see how to do just that.

I first heard about the TARS framework from Adrian H. Raudschl’s wonderful article on “How To Measure Impact of Features”. Here, Adrian highlighted how his team tracks and decides which features to focus on — and then maps them against each other in a 2×2 quadrants matrix.

It turned out to be a very useful framework to visualize the impact of UX work through the lens of business metrics.

Let’s see how it works.

1. Target Audience (%)

We start by quantifying the target audience by exploring what percentage of a product’s users have the specific problem that a feature aims to solve. We can study existing or similar features that try to solve similar problems, and how many users engage with them.

Target audience isn’t the same as feature usage though. As Adrian noted, if we know that an existing Export Button feature is used by 5% of all users, it doesn’t mean that the target audience is 5%. More users might have the problem that the export feature is trying to solve, but they can’t find it.

Question we ask: “What percentage of all our product’s users have that specific problem that a new feature aims to solve?”

2. A = Adoption (%)

Next, we measure how well we are “acquiring” our target audience. For that, we track how many users actually engage successfully with that feature over a specific period of time.

We don’t focus on CTRs or session duration there, but rather if users meaningfully engage with it. For example, if anything signals that they found it valuable, such as sharing the export URL, the number of exported files, or the usage of filters and settings.

High feature adoption (>60%) suggests that the problem was impactful. Low adoption (<20%) might imply that the problem has simple workarounds that people have relied upon. Changing habits takes time, too, and so low adoption in the beginning is expected.

Sometimes, low feature adoption has nothing to do with the feature itself, but rather where it sits in the UI. Users might never discover it if it’s hidden or if it has a confusing label. It must be obvious enough for people to stumble upon it.

Low adoption doesn’t always equal failure. If a problem only affects 10% of users, hitting 50–75% adoption within that specific niche means the feature is a success.

Question we ask: “What percentage of active target users actually use the feature to solve that problem?”

3. Retention (%)

Next, we study whether a feature is actually used repeatedly. We measure the frequency of use, or specifically, how many users who engaged with the feature actually keep using it over time. Typically, it’s a strong signal for meaningful impact.

If a feature has >50% retention rate (avg.), we can be quite confident that it has a high strategic importance. A 25–35% retention rate signals medium strategic significance, and retention of 10–20% is then low strategic importance.

Question we ask: “Of all the users who meaningfully adopted a feature, how many came back to use it again?”

4. Satisfaction Score (CES)

Finally, we measure the level of satisfaction that users have with that feature that we’ve shipped. We don’t ask everyone — we ask only “retained” users. It helps us spot hidden troubles that might not be reflected in the retention score.

Once users actually used a feature multiple times, we ask them how easy it was to solve a problem after they used that feature — between “much more difficult” and “much easier than expected”. We know how we want to score.

Using TARS For Feature Strategy

Once we start measuring with TARS, we can calculate an S÷T score — the percentage of Satisfied Users ÷ Target Users. It gives us a sense of how well a feature is performing for our intended target audience. Once we do that for every feature, we can map all features across 4 quadrants in a 2×2 matrix.

Overperforming features are worth paying attention to: they have low retention but high satisfaction. It might simply be features that users don’t have to use frequently, but when they do, it’s extremely effective.

Liability features have high retention but low satisfaction, so perhaps we need to work on them to improve them. And then we can also identify core features and project features — and have a conversation with designers, PMs, and engineers on what we should work on next.

Conversion Rate Is Not a UX Metric

TARS doesn’t cover conversion rate, and for a good reason. As Fabian Lenz noted, conversion is often considered to be the ultimate indicator of success — yet in practice it’s always very difficult to present a clear connection between smaller design initiatives and big conversion goals.

The truth is that almost everybody on the team is working towards better conversion. An uptick might be connected to many different initiatives — from sales and marketing to web performance boost to seasonal effects to UX initiatives.

UX can, of course, improve conversion, but it’s not really a UX metric. Often, people simply can’t choose the product they are using. And often a desired business outcome comes out of necessity and struggle, rather than trust and appreciation.

High Conversion Despite Bad UX

As Fabian writes, high conversion rate can happen despite poor UX, because:

• Strong brand power pulls people in,
• Aggressive but effective urgency tactics,
• Prices are extremely attractive,
• Marketing performs brilliantly,
• Historical customer loyalty,
• Users simply have no alternative.

Low Conversion Despite Great UX

At the same time, a low conversion rate can occur despite great UX, because:

• Offers aren’t relevant to the audience,
• Users don’t trust the brand,
• Poor business model or high risk of failure,
• Marketing doesn’t reach the right audience,
• External factors (price, timing, competition).

An improved conversion is the positive outcome of UX initiatives. But good UX work typically improves task completion, reduces time on task, minimizes errors, and avoids decision paralysis. And there are plenty of actionable design metrics we could use to track UX and drive sustainable success.

Wrapping Up

Product metrics alone don’t always provide an accurate view of how well a product performs. Sales might perform well, but users might be extremely inefficient and frustrated. Yet the churn is low because users can’t choose the tool they are using.

We need UX metrics to understand and improve user experience. What I love most about TARS is that it’s a neat way to connect customers’ usage and customers’ experience with relevant product metrics. Personally, I would extend TARS with UX-focused metrics and KPIs as well — depending on the needs of the project.

Huge thanks to Adrian H. Raudaschl for putting it together. And if you are interested in metrics, I highly recommend you follow him for practical and useful guides all around just that!

Meet “How To Measure UX And Design Impact”

You can find more details on UX Strategy in 🪴 Measure UX & Design Impact (8h), a practical guide for designers and UX leads to measure and show your UX impact on business. Use the code 🎟 IMPACT to save 20% off today. Jump to the details.

Useful Resources

Further Reading

(yk)

The post How To Measure The Impact Of Features appeared first on The NOKIA Blog.

There’s no single way to measure website performance. That said, the Core Web Vitals metrics that Google uses as a ranking factor are a great starting point, as they cover different aspects of visitor experience:

• Largest Contentful Paint (LCP): Measures the initial page load time.
• Cumulative Layout Shift (CLS): Measures if content is stable after rendering.
• Interaction to Next Paint (INP): Measures how quickly the page responds to user input.

There are also many other web performance metrics that you can use to track technical aspects, like page weight or server response time. While these often don’t matter directly to the end user, they provide you with insight into what’s slowing down your pages.

You can also use the User Timing API to track page load milestones that are important on your website specifically.

Synthetic And Real User Data

There are two different types of web performance data:

• Synthetic tests are run in a controlled test environment.
• Real user data is collected from actual website visitors.

Synthetic monitoring can provide super-detailed reports to help you identify page speed issues. You can configure exactly how you want to collect the data, picking a specific network speed, device size, or test location.

Get a hands-on feel for synthetic monitoring by using the free DebugBear website speed test to check on your website.

That said, your synthetic test settings might not match what’s typical for your real visitors, and you can’t script all of the possible ways that people might interact with your website.

That’s why you also need real user monitoring (RUM). Instead of looking at one experience, you see different load times and how specific visitor segments are impacted. You can review specific page views to identify what caused poor performance for a particular visitor.

At the same time, real user data isn’t quite as detailed as synthetic test reports, due to web API limitations and performance concerns.

DebugBear offers both synthetic monitoring and real user monitoring:

• To set up synthetic tests, you just need to enter a website URL, and
• To collect real user metrics, you need to install an analytics snippet on your website.

Three Steps To A Fast Website

Collecting data helps you throughout the lifecycle of your web performance optimizations. You can follow this three-step process:

1. Identify: Collect data across your website and identify slow visitor experiences.
2. Diagnose: Dive deep into technical analysis to find optimizations.
3. Monitor: Check that optimizations are working and get alerted to performance regressions.

Let’s take a look at each step in detail.

Step 1: Identify Slow Visitor Experiences

What’s prompting you to look into website performance issues in the first place? You likely already have some specific issues in mind, whether that’s from customer reports or because of poor scores in the Core Web Vitals section of Google Search Console.

Real user data is the best place to check for slow pages. It tells you whether the technical issues on your site actually result in poor user experience. It’s easy to collect across your whole website (while synthetic tests need to be set up for each URL). And, you can often get a view count along with the performance metrics. A moderately slow page that gets two visitors a month isn’t as important as a moderately fast page that gets thousands of visits a day.

The Web Vitals dashboard in DebugBear’s RUM product checks your site’s performance health and surfaces the most-visited pages and URLs where many visitors have a poor experience.

You can also run a website scan to get a list of URLs from your sitemap and then check each of these pages against real user data from Google’s Chrome User Experience Report (CrUX). However, this will only work for pages that meet a minimum traffic threshold to be included in the CrUX dataset.

The scan result highlights pages with poor web vitals scores where you might want to investigate further.

If no real-user data is available, then there is a scanning tool called Unlighthouse, which is based on Google’s Lighthouse tool. It runs synthetic tests for each page, allowing you to filter through the results in order to identify pages that need to be optimized.

Step 2: Diagnose Web Performance Issues

Once you’ve identified slow pages on your website, you need to look at what’s actually happening on your page that is causing delays.

Debugging Page Load Time

If there are issues with page load time metrics — like the Largest Contentful Paint (LCP) — synthetic test results can provide a detailed analysis. You can also run page speed experiments to try out and measure the impact of certain optimizations.

Real user data can still be important when debugging page speed, as load time depends on many user- and device-specific factors. For example, depending on the size of the user’s device, the page element that’s responsible for the LCP can vary. RUM data can provide a breakdown of possible influencing factors, like CSS selectors and image URLs, across all visitors, helping you zero in on what exactly needs to be fixed.

Debugging Slow Interactions

RUM data is also generally needed to properly diagnose issues related to the Interaction to Next Paint (INP) metric. Specifically, real user data can provide insight into what causes slow interactions, which helps you answer questions like:

• What page elements are responsible?
• Is time spent processing already-active background tasks or handling the interaction itself?
• What scripts contribute the most to overall CPU processing time?

You can view this data at a high level to identify trends, as well as review specific page views to see what impacted a specific visitor experience.

Step 3: Monitor Performance & Respond To Regressions

Continuous monitoring of your website performance lets you track whether the performance is improving after making a change, and alerts you when scores decline.

How you respond to performance regressions depends on whether you’re looking at lab-based synthetic tests or real user analytics.

Synthetic Data

Test settings for synthetic tests are standardized between runs. While infrastructure changes, like browser upgrades, occasionally cause changes, performance is more generally determined by resources loaded by the website and the code it runs.

When a metric changes, DebugBear lets you view a before-and-after comparison between the two test results. For example, the next screenshot displays a regression in the First Contentful Paint (FCP) metric. The comparison reveals that new images were added to the page, competing for bandwidth with other page resources.

From the report, it’s clear that a CSS file that previously took 255 milliseconds to load now takes 915 milliseconds. Since stylesheets are required to render page content, this means the page now loads more slowly, giving you better insight into what needs optimization.

Real User Data

When you see a change in real user metrics, there can be two causes:

1. A shift in visitor characteristics or behavior, or
2. A technical change on your website.

Launching an ad campaign, for example, often increases redirects, reduces cache hits, and shifts visitor demographics. When you see a regression in RUM data, the first step is to find out if the change was on your website or in your visitor’s browser. Check for view count changes in ad campaigns, referrer domains, or network speed to get a clearer picture.

If those visits have different performance compared to your typical visitors, then that suggests the repression is not due to a change on your website. However, you may still need to make changes on your website to better serve these visitor cohorts and deliver a good experience for them.

To identify the cause of a technical change, take a look at component breakdown metrics, such as LCP subparts. This helps you narrow down the cause of a regression, whether it is due to changes in server response time, new render-blocking resources, or the LCP image.

You can also check for shifts in page view properties, like different LCP element selectors or specific scripts that cause poor performance.

Conclusion

One-off page speed tests are a great starting point for optimizing performance. However, a monitoring tool like DebugBear can form the basis for a more comprehensive web performance strategy that helps you stay fast for the long term.

Get a free DebugBear trial on our website!

(gg, yk)

The post Effectively Monitoring Web Performance appeared first on The NOKIA Blog.

WordPress is fairly performant out of the box. However, that changes when we add a theme, plugins, content, and media files to the mix. Web hosting is also a factor. Your site can slow down before you know it. Even worse, diagnosing these issues isn’t always easy.

That’s why building your website with performance in mind is the best option. Picking the right tools and techniques brings better results.

With that in mind, let’s review the ingredients of a performant WordPress website. We’ll share some tips for pleasing users and Google’s Core Vitals.

Choose the Right Web Host for Your Project

Great website performance starts with a great web host. After all, no amount of optimization can make up for a slow web server. It will inevitably weigh down your page loads.

Every website has different needs, so we can’t tell you the perfect option. However, there are a few factors to consider, including:

• Available server resources: Choose a hosting plan that includes enough memory, storage, and CPU cores to run your website efficiently. The more complicated your site is (e-commerce, membership, etc.), the more resources you’ll need.
• Server-level caching: There are plenty of effective plugins available to cache your website. However, caching works best at the server level. A host that offers page and/or object caching will provide a performance boost.
• Content Delivery Network (CDN): You can use a CDN to achieve blazing-fast performance for users around the world. It sits between your site’s server and visitors, serving files from various geographic locations. Users are connected to the closest server, reducing latency. Some hosts provide a CDN as a standard or optional feature. Bonus: CDNs also improve your site’s security and can reduce bot traffic.

At a minimum, you’ll want to choose a hosting plan that has more than enough server resources. Features like caching and a CDN are optional, but helpful for powering busy websites.

Take a Minimal Approach to Themes and Plugins

There is no shortage of WordPress themes and plugins on the market. But quality matters, and not every product adheres to best practices. The wrong ones could lead to an instant performance hit.

Despite the myth, the number of plugins you use isn’t always the culprit. You might see better performance by running 20 well-made plugins in place of 10 bloated ones. The key is to install only what you need.

It’s also worth experimenting to see how different plugins impact your site’s performance. You could install a plugin like Query Monitor to see the number of scripts, styles, and API calls a plugin adds. Your web browser’s console is another good option for reviewing what’s happening behind the scenes. Check for errors and network bottlenecks.

Themes can be just as impactful. We recommend choosing a starter theme or framework that lets you start small and add on as needed. Themes that trade old-school JavaScript libraries (like jQuery) for more modern options will also load faster.

Block themes are also worth trying. They rely on core WordPress features, rather than heavy PHP templates.

Not sure about a plugin or theme’s impact on performance? Test them on a staging environment or local WordPress installation.

Limit Calls To Third-Party Scripts and APIs

Connecting WordPress to third-party services adds all sorts of useful features. Common examples include Google Analytics, remotely hosted fonts and scripts, and embedded media. That’s only scratching the surface of what’s possible.

Such convenience comes with a price, however. Each call to a third-party service impacts your website’s performance. The more calls you make, the more potential for bottlenecks.

The volume of calls to outside resources is only one part of the equation. All it takes is a singular issue with a service to delay a page load. It could be a slow analytics server that gets in the way. Even worse, a remote script that fails to load could break your site’s functionality or prevent it from rendering.

Once again, it pays to use only what you need. Features like social media feeds and other outside widgets may do more harm than good. Think about what matters most to your site and act accordingly.

Sometimes, a remotely-hosted resource is a necessity. But there are often alternatives you can host locally. For instance, Google Fonts can be stored on your web server, as can various analytics suites.

There are benefits to using third-party services, but choose wisely.

Use the Latest Image Compression Techniques

Design features such as sliders, photo galleries, and hero areas often include large images sized for HD or even 4K screens. They can easily slow down your site if they’re not efficiently optimized.

Legacy image formats like JPEG are often to blame. Their compression techniques make it tough to achieve a balance between image quality and file size. They also struggle with complex image compositions.

Thankfully, we don’t have to settle for old-school image formats. Newer formats, such as WebP and AVIF, are widely supported by browsers and offer better compression. They’re also great at maintaining image quality.

Oh, and we can’t forget about SVG. These vector images are often tiny in file size but can be scaled without losing detail. They’re great for use with icons and logos.

How much space can you save? Test your site with Google PageSpeed Insights, and it will provide a savings estimate for detected images. You might be surprised at the difference these modern formats can make.

Create a WordPress Performance Strategy

Building a performant WordPress website doesn’t happen by sheer luck. It requires a mix of planning and testing.

The planning stage is all about identifying the best tools for the job. It starts with your web host, as a fast server is a must-have. From there, choose a lightweight theme and plugins that avoid bloat.

Testing provides an opportunity to improve on your work. Use your favorite tool to analyze page speed and take note of any suggestions. Make the necessary changes and retest until you’re satisfied with the results.

You’ll also want to make sure your site’s assets load efficiently. Defer items that aren’t needed right away, and preload above-the-fold fonts and scripts.

With a little work, it’s more than possible to achieve top-notch performance with WordPress. We hope the tips above will help you create the perfect strategy!

Read more articles by Eric Karkovack

The post Tips for Building a Performant WordPress Website appeared first on The NOKIA Blog.