Methods for Evaluation
The last several weeks we have been learning about evaluation methods for a product. Having these methods is an important skill set because it enables us to make judgment calls even when there are no users to test on. The first method I learned was the Cognitive Walkthrough. It is used for evaluating the learnability of a product based on a theory of problem-solving in unfamiliar situations. To do a cognitive walkthrough, I first have to have a prototype, even if it’s just sketches. In this case, I used the Chase mobile banking app I redesigned last quarter. Then I had to identify the user and also assume it’s their first time using the system. From there, the primary goals and each step through the product that supports the user’s main objectives need to be identified. I got a screen shot of each step in the walkthrough.
Next I paired each flow or sequence with the following questions.
- Will the user try to achieve the right effect? Will the user understand the intent?
- Will the user notice that the correct action is available? Is it visible?
- Will the user associate the right action with the effect that user is trying to achieve?
- If the correct action is performed, will the user see that progress is being made towards their goal? Is there feedback?
Celine did the cognitive walkthrough on this app as well.
The second method I learned is called Heuristic evaluation. During Heuristic Evaluation is a method used to identify usability problems in user interface designs. It is used by comparing the screens to a list of “best practices” also known as heuristics to determine the usability problems. This method is best done with 3-5 people, so I sought help from my cohort. David, Misty, and Celinè all took parts in helping me identify major issues found within the app.
We paired each screen individually with the following ten questions.
1. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time
2. Match between system and the real world
The system should speak the users language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real- world conventions, making information appear in a natural and logical order
3. User control and freedom
Users often choose system functions by mistake and will need a clearly marked emergency exit to leave the unwanted state without having to go through an extended dialogue. Support undo and redo
4. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow software/hardware platform conventions.
5. Error prevention
Even better than good error messages is a careful design that prevents a problem from occurring in the first place
6. Recognition rather than recall
Make objects, actions and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
7. Flexibility and efficiency of use
Accelerators unseen by the novice user may often speed up the interaction for the expert user to such an extent that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
8. Aesthetic and minimalist design
Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility
9. Help users recognize, diagnose and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution
10. Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large
All critiques from both methods were recorded in a shared Google document. I took all of the feed back, including my own, using the methods and found that there are three major themes of issues within the UI (user interface) of the mobile app.
The most common comment across the board was to check the size of the touch points and to consider making them larger because there is the space to. After doing research, I found according to IOS standards, 44px by 44px is the minimum size. So when I compared that to the touch points on my screens, they passed the minimum size test. After going through the benefits or potential drawbacks, I decided to focus on the minor adjustments that would take a longer time wasn’t worth it immediately.
These things included making the title bar 44pt instead of 82 px or adding a status bar. I also think adjusting the current title bar to be smaller would make it harder to read or understand.
However, there were other elements that had a much larger impact and lower time commitment such as the correct standard keyboard for entering amounts and alert consistency to match IOS standards.
The second common theme was there is a lack of user control or freedom. The nature of the UI design currently is to enter the user in a step by step process to prevent confusion or information overload. However, a downfall of that approach is it takes away a user’s freedom and control. So for the next phase, I will be taking more time to draw out and talk out with my cohort what controls enhance a user’s ability to learn or use the product. In many ways, I feel as if there is a bell curve where too much user freedom could drastically decrease the learnability and usability of a product.
The final category is help, documentation, and error prevention. There are simple fixes that I believe could greatly enhance the learnability of the app. These include adding a blinking cursor, or an indication on where to click to take a photo for checks.
Other examples of simple fixes that need to be made are to change the spending alert screen. It currently looks like with the slider adjustments can be made to their budget when the intent is to alert them their of spending in a category for that month.
During the redesign of the app, I also decided to take out the entire “help” section because it seemed unnecessary. However, coming in from a first time user perspective, help screens would be extremely helpful, especially the first time around. After the user does the tasks several times, the help screens will no longer be needed. So I will explore building out “tips” or a “first-time walk through” and what those elements might look like integrated. This is a much longer time investment but could increase the learnability of the product drastically.
Moving forward I will be fixing the most important aspects of each category and working down the list as time permits. More and more, what I’m learning about is there is no such thing as a perfect app or product. I’m confident that if I put the most beautifully designed apps up against the heuristic or cognitive walkthrough, I would find an array of issues. I’m also certain, the designers working for those companies have a long list of changes they are planning on making. So with that, the most important lessons I can learn is not how to make something perfect but how to discern what is most important now. There will always be a thousand things I “should” work on but understanding what’s essential to the product and customer right now is invaluable. I think as a designer who is used to being on the production side, I find myself getting lost in the details. Some that matter and others that don’t. So for the rest of the quarter, I will be focusing on thinking through what’s most essential first in both this class but also all areas of my life.
I read this book over winter break, and it gave me an excellent perspective on what it means to be an essentialist as well.