How we do usability testing with sensitive personal data

How many times a day do you figuratively throw your phone across the room or shake your computer’s monitor in outrage when a website forgets who you are or does something ‘stupid’? I bet it’s more than you think. For every good service that you use, there are 10 poor ones. What is the difference in how they are built? Why are projects consistently failing to deliver both value and an enjoyable experience?

For me, the same preconception exists in software as in many other places: more must mean better. Designing a tool that tries to do everything for everyone will often have the opposite effect, creating a frustrating experience that will drive people away from it.

How do we avoid this problem?

User Driven Development (UDD) is a simple software design principle. Embedding its principles into your process and culture can lead to extremely positive results but is often overlooked in favour of those which are more easily measurable.

The core of the idea is to provide the users of a system the opportunity to influence its development from the beginning of its life cycle. By usability testing the product after each release, it’s possible to understand and formulate what the most valuable features are right now and feed that directly into the decision making.

I’ll explain how we helped maintain this focus on one of our bigger projects with a bit of technical magic.

The problem

Over the last year we’ve been developing an online customer services portal called MyTVH for Thames Valley Housing. They manage housing for thousands of residents across the South East of England including homeowners, shared owners, key workers and students. Each of whom have lots of sensitive information about their tenancies.

Within the first few months of starting usability testing we quickly exhausted the pool of invested users, as we were usability testing every couple of weeks. We only had real data to test with, so we had to have test with users who were MyTVH subscribers, otherwise we risked showing private data to the wrong people, nobody wants their neighbour to see their financial standings.

The solution was to generate faked sets of data that looked realistic: both to the user, and to us as developers who understand the system. For example, the test data couldn’t include records of repairs made for residents who own their homes, and thus cannot request repairs through MyTVH.

From a technical standpoint there appeared to be no solution, short of building a complete mirror of the external systems, which was much too complex to be an option. With this in mind, we were really struggling to keep UDD at the centre of our process.

The solution

MyTVH has two parts. The application (which you see on the web) and an unseen component, the middleware, that allows the application to get access to your data from TVHA’s back-end systems.

I mention the middleware because we realised that it could help us achieve this goal quite quickly.

We created a feature nicknamed “Fakify” that generates realistic but random data for each of the following entities:

The realism of the data was an important factor. Using Lorem Ipsum would reduce the believability and confidence in the testing sessions, lowering the insight we could otherwise gain from authentic interactions.

Once we had this fake data we saved it by using the same mechanism that is normally used to make the middleware faster – its cache.

Normally, when the middleware receives a request for some data, it searches its cache to see if it has already been asked for it before. If so, it returns the data from the cache, as it’s much quicker to do that than to make a request to the back-end.

The Fakify feature that we built inserts the realistic but random data into the cache, so that when a fake user logs in to the application they only get test data back. Warming the cache in this way meant that we needed very little extra logic in the middleware, helping us to keep it clean, simple and maintainable.

Now that Fakify is working, we’ve been able to do regular usability testing during and between sprints. This often gives us valuable insights to focus on in planning meetings, helping us to make sure that MyTVH is as simple and easy to use for as many people as possible.