Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
190
Usability Study issues
posted

We've just upgraded from Indigo Lite to Indigo Studio and we're very happy with the added functionality. We've made our prototypes and are ready to create usability studies. But I'm having trouble to set up a useful study. For example let's use this study of a simple design: 

indigodesigned.com/.../

The idea is to use the start button to begin, choose a emoticon, enter some text and hit send. These steps are also defined in one Task in the study. With this study I run into the following issues:

1. For the study I don't care what type of emoticon the user selects, but the flow of the study only lets me choose 1 emoticon and disables the others. Of course I could say in the task description: 'You are very happy about this product', to guide the user to select a certain emoticon. But what I would like is to edit the task flow so it detects a group of elements is clicked instead of a certain element in that group.

2. For the study I care if the user first would like to enter text and then chooses the emoticon or vise versa. But unfortunately the task flow only dictates the flow I choose. Of course I could analyse the click map to see what the user clicks first. But because all elements are disabled in the flow except the one the 'need' to click it could lead to users stop using the study. What I would like is if I can set up the study so users can interact with the elements in a more free-flow form. For example I could record certain steps for a task, group a few steps in that task and give it an indication that 'it doesn't matter in what order the user follows these steps'. Or perhaps the user may skip steps because some fields are optional to fill-out.

3. Since there isn't a Material Design/Android pack (yet) in Indigo Studio I've used a screenpart library. In specific this one: indigodesigned.com/community made by reiss.cashmore. As you can see in the study I've used a material designed textfield. Unfortunately the participants of the study cannot enter a random text in the textfield, but are limited to what I have defined when I recorded the steps. In this case if the user enters 'ok' they can continue. Is this a bug? Because the base element for this screenpart to enter text is an 'input box' and should not care what the user enters in the field (like a normal textfield).

I hope you can comment on these issues so I can set up an usability study that is useful for us and does not frustrate the user.

Parents
  • 2475
    Verified Answer
    Offline posted

    Here’s a slightly longer explanation for why we expect steps for conducting usability studies, and you can let us know whether it clarifies our intentions.

    The current usability studies, as designed, align better with closed tasks as opposed to open-ended tasks.

    • Closed tasks are helpful in the unmoderated setting, especially when we are trying to aggregate a pattern of usage.
    • Open ended tasks work well in a moderated setting, where we can engage with the participant to gain more information. The prototype serves as a research instrument, giving the participants or moderators something tangible to discuss.

    More importantly, closed tasks significantly reduce the burden of prototyping, focusing on the obvious flows first. As part of the study, we are testing the assumption whether users and designers agree about what’s obvious. Furthermore, we don't have to spend the time designing all the combinations to answer the question about usability. In the time required to create one complex prototype, we would like our users to create 3 simpler alternatives :D

    See the image showing a simple flow to buy an iPhone 7.

    Buy an iPhone

    It looks simple, but you can only imagine the amount of time one will need to spend to design all the flows, without revealing more information about usability. For this example:

    • Open ended task: Buy an iPhone 7 from the Apple.com website.
    • Closed task: Assume you are Verizon customer. Go ahead and buy a Black iPhone 7 with 128 GB of storage?

    As you can tell, there is always a trade-off between speed of prototyping (and iterating), and flexibility in using the prototype. And the usability tasks are a representation of this trade-off. It’s better to leave all the logic complexities for the actual development.

    You briefly talk about this yourself, but in this particular instance the task ends up sounding a bit artificial. You said, "You are very happy about this product...". Although it sounds a bit artificial, from a usability point of view, it will answer whether it was obvious to the user what to do. I admit that for this specific example it feels more natural to let users select any of the feedback options. We will look into this.

Reply Children