Website UX/UI Testing Parameters Part II

In this post, I will discuss compatibility, performance and security testing as important parameters of UX website testing.

In the previous post, I covered the first group of website testing parameters. In this post, I will discuss compatibility, performance and security testing.

website testing

  • Check how your website is rendered through different browsers and if the website functionality is maintained. You surely do not need to cover all existing browsers, however, the website should be compatible with the essential browsers and browser versions. In case you have visitor statistics from the past, you will know which browsers your visitors use (this may differ e.g. depending on the business you are in). Otherwise, you can use available statistics, such as by W3 (https://www.w3counter.com/globalstats.php). By the way, instead of installing all of the browsers, you can just turn to one of browser testing tools (Browser Sandbox, Ghostlab, etc.)
  • Device compatibility at a higher level means mobile-friendly layout and functionality. At a more granular level, it means compatibility with most often used devices, in particular with their screen sizes and resolutions.
  • Statistics on operating systems (device platforms) can also be found in your previous web analytics reports, or, in the absence of those, on the Web (here you can also refer to W3 website).
  • The last point on compatibility refers to the most common OS, browser and device combinations. Also here you can use professional testing tools without having to buy hundreds of devices.
  • Load testing examines how a site would perform at peak loads (extremely high user activity), stress testing may stretch the site beyond its limits or well beyond an expected peak load.
  • Take preventive measures in order for a website crash not to happen  (use a reliable hosting company, cautiously make code changes)  or to restore your website quickly in case it does crash (making a backup, of course).
  • Website speed greatly influences not only user experience but also how your website is ranked in the search engines. For determining the site speed you can again turn to Google Search Console, but there are a lot of other tools out there.
  • Login security guarantees that only logged in users can view certain areas of your site, but also that each user may only use their unique user name and password.
  • Form validation means that only valid information can be entered. It is essential that your website’s code cannot be manipulated through form fields.
  • Internal website files should not be available to external viewers unless you want some of them to be accessible (such as .pdf files for download). Also, be careful about any transactions involving file uploads to prevent visitors from uploading executable files.
  • SSL enables secure file transfer between a server and a client and is an crucial feature of any up-to-date website. Using SSL causes that the links in the browser appear as https://. In case SSL is not present, website visitors will get a warning from most browsers.
  • This is by no means a full list of measures to protect your website from hack attacks, so check logs of important transactions and error messages to identify any security breach attempts. Abnormal user behavior can sometimes be identified through your web analytics data.

Using the framework shown above, you will be able to test most important UX/UI parameters of your website before or just after it goes live.tes

Share this post

Website UX/UI Testing Parameters Part I

UX/UI testing is an essential step in website development. You should plan for testing early in the process and decide what will be tested in addition to the tools you will use. Remember that you cannot test everything, so prioritization should also take place.

This post is largely based on a Udemy UX and Web Design Masters course and provides a basic framework for website testing.

This table structures testing parameters into several categories. Below I will explain the first three groups of criteria. My next post will cover the rest of the parameters.

website testing

 

  • Links to and from pages on the site should point to a correct destination. This includes mailto: and social media links. While you will not be able to control all of the incoming links (links coming from other domains), bear in mind that changing your URLs without a redirect will cause them to become invalid. Pay special attention to internal links, that is cross-linking between the site’s pages.
  • Things to check on the forms are default form values, required data format, entry validation and storing entered information.
  • Apart from including a privacy statement, test what happens if cookies are actually rejected, blocked or deleted by users. Also check that all information is encrypted and that cookies are not stored longer than required.
  • CSS styles render the design of the page, such as fonts, colors, etc. HTML is the “carcass” of the page, while JavaScript is used for interactivity features. There are various code validators, for example https://validator.w3.org/.
  • The capability to be indexed by search engines is an aspect less related to the UI/UX of the page, however, it directly affects if and how your website appears in Google Search results. A popular tool to use is Google Search Console. This tool additionally checks the site usability on mobile devices.
  • Database connections include correct execution of database queries, reliable data storage and retrieval and correct updating of stored information in case of any changes.
  • Navigation clarity means that users should be able to find what they need on the site using the navigation. Furthermore, the navigation should stand out from the rest of content and its elements should be labeled clearly.
  • Ideally, the content of the website should match what visitors are looking for but in any case it should be understandable and actionable.
  • Distraction in the desired user journeys, such as pop-ups or multiple CTAs should be avoided.
  • Calls-to-action express the purpose of your website or, in other words, what you want users to do. In my post on CTAs I covered how they should be formulated and designed.
  • The main benchmark of your website’s usability is the ability of users to complete their tasks and their satisfaction with the results and the process.
  • Beside the correct rendering of fonts and colors, it is important that the overall readability and visibility of the content are not impacted (an example of bad usability is using light font colors over white background). In addition, consider emotional aspects of the website colors and how they match your brand.
  • Proper handling of errors means that they are recognized and assigned to the correct category. For example, an HTTP 404 error message is generated when users try to reach a non-existent page. Other examples of errors can be form submission errors or incorrect content display.
  • Error handling also includes displaying appropriate and understandable error messages to the user. In parallel, errors should be logged into the system for review. However, make sure not to include any security-sensitive information into the displayed error messages, e.g. user names.
  • It goes without saying that all known errors should be promptly fixed.

In the next part, I will go through testing parameters for compatibility, performance and security.

Share this post

The Why, How, and What of Onsite UX/UI User Surveys

Onsite user surveys are a cost-efficient way to gather not only quantitative but also qualitative information useful for business decisions.  There are two basic types of onsite surveys: website-related (UX/UI surveys) and offering-related (about the actual product or service promoted through your website). In this post, I will concentrate on the first type of questionnaires and give some guidance on how successfully set up, run and evaluate them.

Why

As with other projects, we always start with a Why – question. Without formulating a clear purpose, you will not be able to derive much useful information from the survey. Do not start with a general question such as “Do users find the website easy to use?”- but concentrate on particular UI components (e.g. top navigation, product finder or product descriptions). You may also run a survey to gather more insight into the data from analytics, e.g. high bounce rate on a particular page or repeated shopping cart abandonment by users. Another possibility is to follow up on a particular user journey (registration, form submission).

When & Where

When and Where to place the user survey will depend on its purpose. Say, if you are testing a new color scheme of the site you could place a survey on most pages, but if you are interested why users do not manage to submit forms, you will display a questionnaire only on Submission Failed page.

Besides placing the survey on relevant pages, you may additionally target a random sample of users, i.e. 10% of visitors, or show the questionnaire after a certain time on site/to returning users. Sometimes it is also possible to display a survey on an event, such as a button click or multiple mouse-overs a page element. If the software you use allows gathering user data, consider targeting certain user groups (e.g. users coming from a particular device or from a certain country).

When displaying the survey, decide how long the delay should be. If a user first needs to read the contents of the page, the delay may be up to a minute. In any case, loading the questionnaire simultaneously with the page may confuse users, so several seconds delay will still be appropriate (it will also exclude users who are in the “explore mode”, i.e. just clicking through the pages).

How

Speaking about How the survey will be set up, it can be a pop-up, a slide-out panel or a Feedback button (during user journey or placed in the header of the page). In any case, you will need to include a recognizable Close button to avoid irritating users who do not wish to participate. You may, however, display the survey again at a later point/during the next visit or allow the visitor to choose, by implementing a Maybe Later button.

What

When deciding What to include in the survey, consider the number and the type of questions you want to ask.  Generally true: the shorter the survey – the higher the submission rate. If you want to ask questions on different areas of the website, break them into two or three smaller surveys and display upon user interaction.

As for the type of questions asked, open fields and ratings will probably give you the most insights into how users perceive your site. If possible, avoid asking many yes/no or very broad questions, such as: “What do you think of our new site?”

Users may also be reluctant to provide personal details, so reduce personal questions to a minimum. In other words, every question should fulfill the purpose of the survey or be removed.

Monitoring

Once the user survey is live, continue monitoring and adjusting it, whilst carefully recording all changes made in the process. Some adjustments can be: broaden the display rules if too few visitors view the forms, reformulate a question that seems to cause misunderstanding, exclude some user group from targeting.

Reporting

Last but not least: results processing. You may report daily, weekly or monthly, depending on the traffic volume and stakeholder requirements. The reports you produce should have the same format in order to compare results over time. Questions with open fields are the most useful, but also the most time-consuming to evaluate. You can group responses into categories and later re-formulate the question as a multiple-choice, still leaving one variant as open field.

With UX/UI surveys, you are likely to get some irrelevant responses, such as comments about the product or customer service queries. Make sure to have a process to deal with such responses in place.

As a short conclusion, here are some do’s and don’t’s of onsite UX/UI surveys.

The Why, How, and What of Onsite UX/UI User Surveys

Share this post