After this lecture I read the Nielsen Norman Group article on creating task scenarios for usability testing. I found it interesting how they used the term activity rather than tasks, which links in with the lecture content on making sure the user feels comfortable to use the product like they would normally, and knows that they are not being tested, but rather the product. I feel the use of this term puts also pressure off the user, as they do not feel like they need to perform. Another tip I took away from the article is to avoid telling the user what they need to do, such as not directly using the names of certain sections of the app. I believe this is useful, as in real life application, when a user first opens a product they will not have any knowledge of the intricacies of the app, such as the names of navigation items, but only know what they are using the product to achieve.
For the group task this week, we built the smart pot wireframe into an interactive prototype. We chose the objective to be identifying and diagnosing any signs of infection in the plant. Firstly we went through various ideas for the words we will present the objective to the user in. I found the Hemingway app extremely useful for this part of the task, and fixing up the sample text within the app helped me develop some understanding of the concise writing style required for understandable and accessible web based content. For example using the simplest form of a word possible and reducing sentences to as few words as possible while retaining an easily understandable meaning. (Removing filler words and passive voice, which also adds unneeded words.) The tasks we arrived at after this was:
“You suspect your plant may be sick, use the Plant Co. app to diagnose the plant’s sickness.”
“You have a magnolia plant in a Plant Co. pot. Use the app to find out how to care for it.”
Our wireframe worked quite well overall. But users stated that they did not know certain items were scrollable because they could not see any part of the further elements hidden outside of the screen. In my product I will then ensure all scrollable items are discoverable, and the user can find anything they might need which is not immediately displayed on the screen.
I found this class useful not only for learning what a usability testing is, but also to gain the experience of setting up, conducting and being part of one. Initially I found it difficult being the user, due to having to explain my reasoning for doing each action, as it requires you to slow down and articulate a process which often comes by instinct (when a product is well designed), but eventually it became more natural as I tested more prototypes around the class.