Can you test without knowing the names of your users?

A couple of days ago I saw a short youtube video that got me thinking about an issue I stumble upon almost daily as a tester.

cnbcaljazeera

The video, not even closely related to testing, was posted out of a CNBC program that was itself talking about a documentary made by Al Jazeera on the topic of Abortion Legislature.  In this video the host of the program, Rachel Maddow, shows a cut from the documentary where a legislator is asked a simple but extremely good question by the interviewing reporter.

The topic of the documentary is “very loaded” and so I don’t want to go into it.  But the comment from the CNBC host really drove a point I’ve been trying to get through to other testers, developers and product owners for a long time now.

Why don’t you start by watching the short video (1:48 min) to understand what I am talking about.

Done, good!
Now, let’s focus solely on the sarcastic commentary made by Rachel Maddow: 

“Why would a woman want an abortion?  I’ve never thought about it!”
Says the man who’s doing his best to ban abortions in Ohio…

Regardless of what side of the abortion issue you are in, and there are very valid cases for both sides of this topic, you have to agree with the host.  How can a legislator decide on issues affecting other people without deeply understanding what are the reasons behind their choices or actions?

I am not talking about the reasons that push the legislator, I am sure he also has good ones, but in this case the question is very simple and it is focused on the individuals affected most directly by the decision here, the women wanting to do an abortion.

How can he choose for them without even understanding why do they want to perform the abortion in the first place???

Is this related to testing?

YES, and now let me explain to you why.

When I saw this video I was “virtually transported” to the many times when I found myself “defending” (there is no other word for this) the interests of end-users in front of developers or product managers who had not really thought about the reasons behind our users’ actions and decisions.

I don’t intend to compare the two issues, but in both of them we have people making decisions that directly affect others without really understanding the reasons these people have for behaving the way they do.

I am sure you’ve seen this yourself!

When programmers choose a “development solution” based mostly on technical constraints (what is technically “safer”, or the less complicated way to do something), and this forces the end-users to work harder to do achieve simple actions in the product.

Or when product managers decide on workflows or configurations with only partial information about the real needs of the users and without understanding the ways they work with the product during their day-to-day operations.

I remember a case about a decade ago where we developed a product for Customer Support centers.  The product was pretty impressive and it had some amazing features in it, but it also had many modal messages that got in the way of our end-users, who could not work in the way they needed with multiple customer tickets opened in parallel at the same time.

When will people realize that quality is not only making sure there are no bugs or crashes in the product?

It is not enough to be “customer focused”

bulls-eyeBut back to our video.  I want to say once more that these are cardinally different situations, but still we are talking about the same symptoms:  Someone makes a decision without understanding the reasons, the real needs, of his constituents or his end users.

Why would she / he / the user want to do this???
–  Did we really stop to think about it?
–  Do we understand how is this person thinking?
–  Do we care what he feels? Do we need to care at all?
–  Do we have a good sense of what are the working / living / thinking constraints dictating the needs and actions?

It is NOT ONLY about WHO this person IS, but most importantly about WHY does he/she wants to do what they do!

It is easy to say that you are focused on your users, that all the decisions you make on the product are in order to provide them more features or to make the product more stable.  Many developers and product owners will even explain how they are sacrificing things that are important for the company in order to focus more the user.

But at the same time, we are missing the point altogether!

Did we stop to understand if the user agrees?  Do we know our users enough to make these choices?

Simply put, do we understand how our users FEEL about the features we are providing them?

The fact is that we don’t spend any energies on who are users are (their personal profiles!) and why do they do what they do (their professional reality).

If you want to provide a solution that really fits the user it’s not enough to know the user, you need to empathize with him.

When you empathize with someone you not only know what he does,
you can also share the feeling of why he is doing it.

How do you empathize with your users?

The answer is simple: learn more about them.

Go and meet users.  See how they work and what “other things” they need to do as part of their jobs.

Ask them to walk you through their work while they are using your system.  Get real-life feedback focusing on the WHY they do things, and not only on WHAT they are doing.

You can even dare to ask them what would they do differently in order to make their work better if they could.

The aim is to get enough information to put yourself in their shoes.

If for some reason you cannot go and meet your users in person – and there are many reasons why you will not be able to do this – try to get in touch with them in other ways.  Use Skype or any other virtual meeting system. Even a combination of phone and emails will provide you value.  Anything you do to be closer to your users will be better than doing nothing at all.

If you think that our users will not want to “waste” time on this, you are wrong!  Your users are eager to share with you their thoughts if you are only willing to listen.

Create personal profiles

austin_powersAfter you meet a bunch of users and understand their needs (no need to meet all of them…) create schematic personal user profiles to help you and the rest of your team understand and relate to them better.

These profiles should include professional, personal and background information (if possible add a picture of this user at work with your system).  The profiles should include, for example, a name as well as age, education, professional aspirations, work times, noise conditions, devices they use to work.

They should also include the number of children they have, hobbies, social media they use, etc.  All the things that will help you to relate to them and to make a mental picture of their needs and preferences.

Once you have these profiles you can evaluate your product, its features and workflows based on their “individual” personal profiles, and help all the team to develop and provide a product that will be better suited to your users.

You should not be surprised when quickly enough the whole team relates to these users by name and when you start referring to them as if they were real people everyone knows and works with on a day-to-day basis.

Do you empathize with your users?  Does it help?

If you’ve tried this and succeeded or even failed I will be happy to hear your experience!

, ,

  • Pingback: TestNet network test | Derk-Jan de Grood

  • Pingback: Testing Bits – 1/5/14 – 1/11/14 | Testing Curator Blog

  • Sue-Leigh

    I definitely agree it is important to create user personas to test the user experience and for end to end testing. It is also important to make sure from a quality standpoint that bugs and software failures are not passed off as “that’s not how the customer is going to use the software”, which could happen depending on a team mindset. I think user profiles and personas are also important, since the users are the stakeholders of the product / software.

  • joelmonte

    I totally agree with this, and I think that we as testers need to have enough information in order to defend the “that’s not how the customer is going to use the software” syndrome. Many times the problem is that neither us nor the developers have direct knowledge of this and so it becomes a matter of opinions (and many times we are outnumbered on these opinion fights).

    In any case, as you mention, Personas & Profiles will help us to have a better understanding and a better grip when we need to catalogue and prioritize the issues in our products.

    Thanks,

    -joel

  • Pingback: fortidsertul