Things to Do to Get Better at User Testing

User testing is an exercise wherein the design and usability of a product are tested with users. In this process, participants are asked to complete a task in the best ways possible using the product. The whole session is observed in detail to understand if users are facing any difficulty while using the product. Things that are adding to their satisfaction and the ones that are ruining experiences are taken note of. The insights from these sessions are then used as a fuel for effective design iterations and improvements.

A couple of months back we got the opportunity of improving the user experience of one of the critical screens of a product. The bounce rate of this particular screen was quite high, and it was a big concern for the business as this particular screen was the chief entry point of the platform.

Before we could make any design changes, we needed to learn why so many users were leaving this screen and not staying for long. This called for conducting comprehensive user testing.

Given below are the top three things we learned in the process of preparing and running these user tests.

1. Discrete Inclusion of Target Features in Test Scenarios

When planning to run user tests, it is essential to pinpoint the exact features on the screen which require testing. This is to prevent the sessions from getting side-tracked from the target. For these features to be tested, the participants should be using them.

In our case, the screen that was being tested was a listing page. One of the features we wanted to test was the ‘filter’ function. The filter function allows us to narrow down the list of products on the screen based on specific parameters.

For example: On a website that delivers flowers, filter parameters could be the price range, type of flower, delivery location, and so on.

So, instead of asking the participants to find a product of their preference, we listed certain characteristics of the product they should look for. This nudged the participants for using the filter functionality. While doing this, we were careful of the terms used in writing the scenario to make it not sound like direct instructions for using the functionality.

For Example: In the flower delivery website the scenario could be something like:

“Your sister’s birthday is next week. You want to send a bouquet of Orchids to Nagpur where she has recently moved.

2. Construct User Scenarios Using the Actual Data Available on the Product

This is specifically applicable when testing live products. While constructing the scenario, check the product listing to verify that the combination of filter parameters returns some results.

For example: In the scenario – “You want to send a bouquet of Orchids to Nagpur where she has recently moved”, see that there are at least a handful of orchid bouquets listed which can be delivered to Nagpur available on the platform.

We learned this one the hard way. For writing our scenario, we looked through the filter function and selected a few of the parameters and inserted them into our scenario.

Our first participant read the scenario and started looking at the filter parameters and selecting them. On applying the filter, to our surprise, there were no results returned. There were no products listed on the platform which matched the combination of characteristics we had listed in our user scenario. This meant that we couldn’t proceed any further in the session. We had to make changes to our user scenario on the fly which completely disturbed the participant’s flow and negatively impacted the outcome of the session.

3. Use a Template to Record Observations

The user testing sessions are very dynamic, the observer must be very alert and note down quite a lot of things that the participant is doing. To make things easier and faster, it helps to keep an observation template ready. It should list down in detail all the features which are being interacted. In our instance, we listed down all the filter parameters so that the observer could just put a tick mark and write their observation against each of them. It is best to use the observation template in addition to screen recording or session recording.

These observation sheets can also be easily incorporated into the report which will be presented to the product owners and development team.

As a Final Note

The above-mentioned points are helpful in optimally using the time available for conducting sessions. Having specific test scenarios increases the chances of getting significant insights around the targeted features. Reducing the amount of writing required for noting down an observation, frees up time to observe the user. They aim at improving the user experience of participating in and conducting user testing thus making the whole activity more fruitful.

What is UX Writing?

UX writing is a speciality within content strategy which emphasizes on the use of language in a way which helps and guides users to achieve their goal. This might sound like some fancy definition pulled off the internet, but what does it actually mean?

Before UX writing, let us begin with the type of writing we do for digital products.

  • Information
  • Feedback – error, success messages
  • Help and instruction.
  • Call to action

And there could be more.

These are everyday things we come across while designing or developing any software application. What’s the ‘UX Writing’ in these?

Let’s see an example of Information – empty state message.

There does not seem to be any problem with the way this message is written. There were indeed no records found in the database to show on this screen.

So, what’s missing here?

Let’s refer back to what UX writing is. It says –

“Use of language in a way which helps and guides users to achieve their goal”

When we extract the keyword HELP and GUIDE we can deduce that the message should be simple and easy for the user to quickly understand and it should tell them what to do next.

This brings us to the guideline for UX Writing: Clear, Concise, Useful.

1. Clear: Jargon freestyle which includes context

We often describe the problem in actual technical terms which can sometimes be incomprehensible or even intimidating for users. We need to demystify the problems and put them in a way which is relatable for them.

No records found. ——->No job applications have been created yet.

Here the record is a very generic term. It gives no context about what this screen is about. Using job application adds a context and it is a term that users can understand.

2. Concise: Efficient and easy to scan

By now we know that on the web, users scan the text instead of reading it word by word. So, making text shorter and scannable is better. Each work used should serve a purpose.

No job applications have been created yet.  ——-> No job applications created.

The words have, been, and yet can be removed without changing the meaning.

3. Useful: Help user to take next action

The messages should not only convey precise information but also guide the user to take the next step to achieve their goal.

No job applications created. ——-> No job applications created. Click on Find Job to start.

Now we are guiding the user to take the next step.

Bringing it all together with Brand Voice

To take product messaging to the next level, the product voice of your product needs to be defined. It can range anywhere from serious and professional to casual, even whimsical. The tone and language need to be in sync with the brand image.

The brand voice will help in deciding the balance between:

Clear – Concise – Language – Tone.

Why Angular 2

Early this year, I began on a self-righteous (but approved, of course 😉 ) journey to make things right for my project — to break all shackles and limitations that the team faces in working with older technologies, methodologies and guidelines. When I started off, my aim was to make as minimal-but-essential changes to the system as possible, keeping in mind that my project is a live one, having at least 100 MegaBytes of code, with around 16 developers contributed to this application — in batches, of course — in the past 8 years, each having their own signature style of coding. Needless to say, there were more than a few tasks for research in this journey of mine.

One such, important analysis was to decide what UI methodology should the team adopt going forward. This blog post will focus on the analyses and decision-making process that made it happen and finally helped me decide on Angular 2.

Continue reading Why Angular 2