The following notes are in response to testing completed on Dr. Pullman’s to-do list (https://www.gpullman.com/8122/todo2.html) and the ensuing discussion around what was good, bad, and strange about how the application functioned, its usability, and what the user experience of using this application might look like. I have attempted to maintain the nature of my field notes to reflect my experience with the different testing methods sampled in class, showcasing some of the advantages and disadvantages that will be reflected on later in this post, along with a mockup of a potential alternative to the application provided to us in class.
5 Second Test Notes
The app seemed to be designed as a schedule organizer. Giving a prompt to add tasks with the ability to sort them. However, there aren’t any organizing features.
Using and Brainstorming Session
To do list is rudimentary, can add tasks, delete them, or mark them as completed, but the option to sort doesn’t do anything, nor are there any additional bites of information that indicate when/where/how something needs to be completed.
The enter key doesn’t add the entry that you’re typing out, making the interface feel even more clunky than it appears.
Revision on sorting comment* – once a task is completed and the button is pressed, it sorts based on completed/not completed. This helps get things out of the way once they’re done, but still lacks other sorting principles that might be valuables. I.e. being able to sort by time it needs to be completed, date to be completed, date added, type of task, etc.
Looking back, I noticed that because there was a lack of ability to add additional information regarding time/date, one of my criticisms, I ended up putting down tasks for today only that I still needed to complete but that didn’t have a specific time they needed to be completed by.
Heuristic Inventory Form and Personas
Heuristics
Visibility – Yes, if link is broken, site responds to users saying page doesn’t exist or incorrect web address is inputted.
Use Familiar, real-world language – Yes, the to do list is simplistic in language it uses to prompt users and is therefore easier to use.
Users should be in control – No, users have some control over adding, deleting, and marking as completed/incomplete, but there isn’t anything that allows users to save their to-do list for later reflection. No ability to undo deletion of a task and no real sorting options beyond complete/incomplete.
Follow Industry Standards – Yes, can save web page as a pdf as you can with any other web page.
Don’t let users make mistakes – No, users can delete a task and can’t recover it. Need to type it out again.
Recognition over recall – Yes, simplistic design makes it easy to recognize how a user should be using the app.
Flexible designs – N/A, no real shortcuts or specialized knowledge that allows experienced users to quickly navigate interface.
Minimalist Design – Yes, avoid overly complex design.
No error should be fatal – Yes, you can delete tasks you didn’t mean to, but you can just input them again. Can’t delete more than one item at a time.
Provide help – No, app relies on recognition to guide users, doesn’t have additional documentation. Was tempted to say N/A, since it’s just a to do list.
Personas
Low, medium, high frequency
Low, medium, high skilled
Demographic data related to race, ethnicity, gender
Do they use lists?
Paper or digital lists?
Reflection
This reflection will hopefully provide some context on each of the above sections, and offer some of the insights gleaned from their completion at each stage of the class. While the methods of testing differed, a constant was that field notes helped to provide an in-the-moment way of documenting the impression that the application left on me, and how my perception of the app changed with each method of testing. The 5 second test, the extended brainstorming session, and the heuristic were especially valuable in communicating the level of information that each type of testing could give and why testing with each of these methods can yield vital insights into the value of your creation/application/service.
5 Second Test
The 5 second test was interesting and of all the methods, the only one I was unfamiliar with. I recall in my past run-ins with user experience testing that it was important to document first impressions, and this test does just that without tainting the user’s response with the ability to test any further than that very first impression. In reflecting on my brief notes, it’s obvious to me that while this was successful in documenting first impressions, the class discussion that followed and peoples’ varied answers to what the app was for, and the amount of information they deducted about the app, showed that even among twelve participants a 5 seconds test results in multiple different answers. So, while useful, this doesn’t seem like it should be the preferred testing format under most circumstances, even if it should be utilized if possible.
Brainstorm Session
The brainstorming sessions yielded much more results and gained much more agreement among the class than the 5 second test did. Key issues of the app were brought to light, and enabled us to discuss things like the enter key not doing what we usually expect it to, issues with sorting items added to the list, user errors that caused frustration, the challenges posed by deleting items with no undo button, or how the simplicity of the app resulted in a desire for more features. This consensus among participants demonstrated that while the 5 second test was valuable in capturing a variety of first impressions, it’s in these longer tests that you can determine the genuine issues and challenges you will have as the developer moving forward. However, that doesn’t mean that this consensus is even then accurately portrayed through something like survey data – rather the interview/discussion portion of this assessment of the app was extremely important in coming to an understanding amongst participants.
Heuristics
The survey data did demonstrate, however, the importance of simplicity in how you manage your testing as much as, if not more than maintaining simple language and design in the application itself. Things like industry standards, fatal errors, and communicating system status were foreign concepts for some of the participants showing that a novice user might not be able to respond to questions about these terms specifically – or if you give them examples they might just say that the app either does or doesn’t satisfy the design principle given in that example. For example, the system status communicated by the website that a page doesn’t exist at the given link is much different than a web service telling users that the server is down. These two examples of system status help users understand what’s being discussed, but they have widely different implications for how users actually interact with the app. In the case of the To-do List, there is no server attached to it, instead the only status to report is if the list is functioning or not. Some may argue that communicating things like completed v.s. Incomplete tasks could be another example which is something the list did do. So, if we are to use heuristics as an effective tool for user experience research moving forward, the language used in the questions is extremely important for getting accurate results, especially if no interviews/extended discussion will be conducted afterward.
Personas
Personas were an interesting part of our discussion following heuristics. While it can be detrimental to put your potential users into a box, if you have limited access to test with those types of users it makes it possible to go through testing with a couple of assumptions in place that may allow you to see how some users will use your app/service. This is most useful if you’re limited to inhouse testing, caused by various limitations including but not limited to user experience research budget, limited access to actual users, attempting to test very early iterations of what will become the end product, lack of other adequately sized departments in the case of larger organizations, etc. Any of these limitations or any more that appear in the lead up to user testing may indicate that you will need to brainstorm some user personas and test using them rather than your actual users.
To Do List Mock Up
