Conducting usability tests or the experience of stuffed cones



    A small collection of tips and conclusions about usability testing.

    Everything that you read below is based on personal experience and observations, therefore it does not claim to be the ultimate truth. I'd like to believe that this will make it easier for someone and the number of cones full.




    Testing friends and colleagues


    Of the advantages, the first lines of the charts take time, money and effort to search for respondents.

    And now about the cons and pitfalls.

    Acquaintances


    Acquaintances can be so good that, in attempts to preserve your self-esteem, the test results will completely fail.

    It will be inconvenient for them to say that such a rare garbage is heaped up in the prototype, which you can understand only if you have two higher technical educations and ten years of experience in designing aircraft control systems.

    By the way, not only acquaintances can suffer from the fear of offending, sometimes unfamiliar tested users suffer from this disease.

    The moment they find out that here and now there is a developer of a product that they mercilessly criticized just five minutes ago. The degree of criticism drops sharply and everything is not so bad. In general, the benefits of such testing are rapidly declining.

    Another pitfall from acquaintances: here you sit all so smart, testing here, you know. And a friend also wants to not face the dirt, so to speak. In this situation, there may be several options: he will be afraid to make a mistake, to pretend “But I didn’t really want to” or to be clever, “I haven’t seen such a thing”. Any option for the purity of the experiment is useless.

    Colleagues


    With good colleagues, the situation may be the same as the situation with good friends.

    Colleagues whom you pulled “literally for five minutes”, tearing, perhaps, from important work, will be inattentive and will try to get rid of you quickly.

    What to do


    when time is running out and still need to be tested?

    “Good” ask not to be shy and criticize all the shortcomings, since any criticism in this matter is only for the good.

    Shy ones, warn that you are testing not his abilities, but the results of your work. If something didn’t work, then it’s not him who is fool, and you didn’t take it into account.

    And it is advisable for the user not to say that he is sitting in the same room as the developer. Well, just in case.



    Male and female audiences


    According to my observations, the female mind is more flexible and it is easier for him to fantasize or imagine something, men are more specific and they are not up to your syu-syu mu-syu.

    Therefore, if there is still not a complete prototype on hand and somewhere you need to show imagination and, suppose, imagine a pop-up window on a click - take the women.

    Men are better suited for a more complete version of the prototype with all the pop-up and pop-up windows.



    Setting tasks close to the user


    About the fact that for testing gaining "their" target audience has already been said before me. I will say a little about the tasks.

    They should be close to the user. In this case, he is more interested in the testing process, and his interest affects the test results.

    Conclusion


    No need to ask a childless man, twenty years old, to look for bedtime stories for children of primary school age.

    No need to ask a mother with many children to look for wheels for a bike, unless she is a biker in her free time from motherhood.

    I’ll add here a little more about the tasks and the audience: if you need to check the work of a small functional, in principle, almost anyone will do. If you need to check scenarios, then your own audience is better.



    Testing five


    “To identify the key problems on the site, it will be enough for you to test five users” (c) Jacob Nielsen.

    I can not vouch for the accuracy of the quote, but the essence is clear.
    Once upon a time, three was enough for me to understand in what places I messed up and illuminate dark spots.

    For a more detailed debriefing, more people are needed, and at the initial stage a small amount is enough.



    The presence of more than one interviewer in testing


    In such cases, everything is individual and depends on both the tested and production needs.

    On the one hand, it’s very useful for the developer to observe how people use the product, so to speak, in combat conditions.

    On the other hand, it is difficult for some users to concentrate on a task when 2 or more pairs of eyes look closely at it.

    And on the third hand, if you don’t agree in advance on the method of conducting the interview (who asks questions and who observes), you can simultaneously flood the user with questions, under the avalanche of which he will be lost and generally forget why he is here.



    Too talkative user


    It also happens. He likes your product, he is megaloyal. He gushes a bunch of ideas, sometimes very good, how to make the product even cooler.

    Only, in the process of telling about the product, he can remember the cousin of the folder lines, whom he expertly helped to understand the site well on and on and on. People love to talk about themselves.

    At such moments, you need to gently and unobtrusively return him to the truth of life, namely to tests. Only gently and accurately so as not to offend.

    for instance


    we can say: All this is very interesting, but, unfortunately, we are very limited in time. Let's get back to the test now, and if there is time, I will gladly listen to your story.



    Questions on the forehead


    “You did not click on this button! You did NOT SEE her !!! ”and her eyes are so big, big, and there’s a running line:“ Well, users, well, dumb! ”

    At that moment, when you are so obviously angry about the stupidity of the user, this same user is locked in himself and everything, he is in the house.

    Conclusions why he did not press this ill-fated button, zero.

    Finely? Lost in the middle of the text and the blinking banner, or is its purpose not clear?

    When you need to solve a problem regarding the operation of an element, but it is not solved the first time, ask him to solve the problem again, in any way convenient for him . If again by, you can ask to try again, maybe even again until he sees this ill-fated button (if he sees), but here it already smells of failure.

    And calmly, without nerves. In no way hinting that your 3-year-old son completed this task the first time yesterday.

    That's actually all I wanted to tell. Fruitful work for everyone!

    Also popular now: