Designing the perfect user experience

Google are changing their Search Algorithms to promote websites with great User Experience. A welcome move. But is Google’s definition of a great user experience really what your customers need?

In this post, I explain the definitions Google uses to describe what they perceive as good user experience, which important metrics Google are ignoring and how we design and build the perfect user experience.

Google recently announced that they are introducing a new ranking algorithm. When it comes into effect later in 2021, Google Page Experience will include its Core Web Vitals to determine ranking scores.

Core Web Vitals will undoubtedly influence website owners to improve user experiences on the web, just as Google’s promotion of mobile-friendly sites led to improved experiences on smaller screens. 

This means that the user experience of your web pages will have a direct impact on their ranking on Search Engine Results Pages and therefore the number of people visiting your website.  Although Google will still optimise Search Results weighted for good quality content, where competing web pages have similar content, user experience becomes much more important.

So, what are the signal measures Google say make the web more delightful, frictionless and engaging for users?

In other words, loading speed.  With this metric, Google concentrates on how quickly the largest content element in the viewport becomes visible.  Slow loading times can be caused by slow server response times, render-blocking CSS and JavaScript and large image elements used in a page header.

Users want to quickly ascertain that they are in the right place and the page is useful. Slow user times cause frustration and abandonment. Google will penalise Largest Contentful Paint times slower than 2.5 seconds.

To decrease loading times, we can use content delivery networks, defer non-critical CSS and JavaScript and optimise and lazy-load images.

AKA the interactivity of page elements. The First Input Delay (FID) metric times the difference between the first time a user interacts with a page (such as clicking on a button or selecting a dropdown) and when the browser is able to respond. This time may be impacted if the browser is busy. For example, if the browser is parsing and executing large JavaScript files, it may be unresponsive when a user tries to interact with it.

This first impression of a web page’s speed and responsiveness can make the difference between delighting a user and frustrating them to the point of never wanting to come back. Google says that pages should have a FID of less than 100 milliseconds.

This metric is all about Visual Stability. Have you ever been reading content or trying to click a button when the page moves unexpectedly? This happens when the user interface changes and loads in other elements such as images, adverts, or notifications.

Techniques to avoid this include reserving space for dynamic content that may appear at a later stage. By adding width and height attributes on images and video before they load and thinking about where banner notifications may appear can help to stop layout shift from happening.

Google says - “to provide a good user experience, pages should maintain a CLS of less than 0.1”; and they have a layout-instability API to help us calculate this number.

To see all these metrics at a glance when browsing, we can add the Web Vitals Chrome Extension. Developers can use Lighthouse in their build chain and Google have made Core Web Vitals an integral part of Developer Tools.

You can also find the metrics as part of Core Web Vitals report in the Search Console and as part of the Chrome User Experience report in Page Speed Insights.

There’s no doubting that optimising for these metrics will improve the experience of someone visiting your webpage.  But it’s not the whole story.  

People have more fundamental needs, and in my book, satisfying these needs through a well-thought out pragmatic solution leads to a great user experience.  Your website can target the Core Web Vitals but if you don’t listen to your customers, how will you unlock opportunities to give them what they want? 

Working at an experience design agency, I’ve seen first-hand what a difference optimising websites for the end-user makes.  It begins by simply observing people using your service. You only need to look at our case studies to get a flavour of what I mean. Solve your users' problems, and you make something valuable to them.

So, what else is missing?

There are some crucial stats that Google could be measuring - accessibility metrics.

As much as we should care about how a page looks, we should also care about how a page is interpreted by Assistive Technologies (AT), such as screen readers. All users should be able to interact with and communicate page content and the user experience should be optimised for everybody.

Accessibility metrics would track the time that pages take to become useful when accessed by AT. Something missing at the moment from the Core Web Vitals. (Although this has been raised as a feature request with the Lighthouse team - one to keep an eye on).

The knock-on effect of creating accessible services is that an inclusive approach benefits everyone. Let me explain.

Inclusive Design is a methodology that enables and draws on the full range of human diversity. Most importantly, this means including and learning from people with a range of perspectives.

Designing inclusively doesn’t mean making one thing for all people. You’re designing a diversity of ways for everyone to participate.

If we use our own abilities and biases, we end up with products designed for people of a specific gender, age, language ability, tech literacy, and physical ability. We may unintentionally limit the number of people that can use our services.

Accessibility can be permanent, temporary and/or situational:

• Permanent is those people who have a disability such as loss of limb, sight, hearing or speech.
• Temporary is when a person has short-term injury or context affects the way they interact for a short time. For example, someone wearing a cast on their hand, or is trying to read on a reflective screen in bright light.
• Situational is when people move through different environments. For example, if you’re a new parent that has to complete tasks one-handed.

The consequence of designing websites in a way that they are accessible to everyone - is that everyone benefits.  And that means you too! For example, changing a page to be more understandable and readable for dyslexic people will also reduce the cognitive load for non-dyslexics.  Great when you’ve already had a busy day making decisions or on back-to-back video calls.

If you compare the web industry to other disciplines such as engineering or architecture, it’s still in its infancy. The tools that we use have only 30(ish) years of development and refinement. We’re constantly evolving the tools that we use to create the web.

Over the years, we have moved towards a standardised approach for building and architecting web pages. Standards and best practices exist to improve the way the World Wide Web is made.  The Web Content Accessibility Guidelines (WCAG) are part of a series of web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), the main international standards organization for the Internet.

WCAG 2.1 is the latest recommendation update to include users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices.  WCAG 2.1 is an ISO standard and accessibility is written into law in many countries.

For me, the perfect web page is one that adheres to these standards so that it’s accessible and usable by everyone who interacts with it. As I’ve mentioned, there are clear benefits to designing inclusively, but if you choose not to, you may be excluding people unfairly.

In the UK, any public sector organisations may be breaking the law if they do not make their services accessible. And, private sector organisations can also be held liable for making their online services accessible under the Equality Act 2010. This protects all individuals from unfair treatment and promotes a fair and more equal society. Site owners are required to make ‘reasonable adjustments’ to make their sites accessible to people with disabilities.

When we build Government services, we are assessed that the service works with assistive technologies and meets WCAG 2.1 level AA. We also take the best practices from our public sector work we do and apply it to private and third sector clients.

Here’s how we do it:

We ensure that we include people with disabilities in our research. So we understand how people use websites differently and the problems they may face. This insight helps us learn what impact our design decisions will have.

Having an appreciation of how different people use the web can help us build better experiences. You can build empathy by engaging with people and content online. I love empathy prompts. Each prompt helps you understand what it’s like to have a particular condition. For example, one reads:

Screen readers and mobile phone accessibility features provide information regarding the device’s operating system, applications, and text content in a speech output form.

When accessing web content, the screen reader indicates aloud the structural information on a web page such as headings, column and row headers in tables, list items, links, form controls, and more that enable users to navigate the page, complete and submit forms, and access information in an effective manner.

Try it out. You can use VoiceOver on Mac and iOS devices and TalkBack on Android. You can get software for Windows called NVDA.

If you tried using the screen reader whilst closing your eyes, you may have an appreciation of what it’s like trying to navigate your device without sight.  If you didn’t, here’s a video clip:  https://youtu.be/OUDV1gqs9GA?t=317

When we design a page for screen readers and other text-to-speech tools, we need to ensure that it’s perceivable, understandable, operable and robust. It’s important that interaction is consistent and predictable, and that we use descriptive titles, headings and labels.

If we think about a web page with images, what are those images communicating to us? If it’s relevant information and not conveyed somewhere else on the page, then the image’s meaning can be communicated by providing alternative text that a screen-reader can interpret.

Sometimes, when web pages aren’t built with accessibility in mind, users that navigate with the keyboard can get stuck in certain areas or are unable to access some content. Try using the tab key to navigate through a few websites to get a feel for this.

To make sure this doesn’t happen we can use semantic HTML elements, and where we are creating custom elements with JavaScript, ensuring that we use ARIA roles. By coding a website properly we ensure that users can easily navigate, find content, and determine where they are.

We may think about whether there is a meaningful sequence when navigating around the page. Which may make sense to follow the visual hierarchy. Pages may start with a visually hidden Skip to main content button to help keyboard users navigate past menu bars quickly. (The button becomes visible when it has focus).  Check out the BBC or Government websites and tap the tab key to see this in action.

This is a short description of just a few of the techniques we might use for building web pages to be accessible for blind users. There are a whole host of other techniques we must use to include people who have a spectrum of different abilities.

Because our designers and developers work collaboratively together  with inclusive design in mind, we create accessible web pages for everyone’s benefit. And by testing our work with users with disabilities, we have an effective way of identifying issues that adversely affect people that following the accessibility guidelines can’t always catch.

I really welcome Google’s focus on User Experience. Core Web Vitals are going to have a positive impact on people’s experience of using the Web.

Making things work for all people, in turn, makes things work better for everybody. There’s no such thing as the perfect design but by designing for everyone we can go a long way to making things better. 

cxpartners can help. As well as building accessible and performant websites, we offer accessibility audits that capture issues on your website which we report back to you in a prioritised action plan.  And we always advocate testing with real users for a more thorough approach.

Get in touch with us at hello@cxpartners.co.uk to find out more.