When I read “Usability Inspection Methods”, I realized the importance of knowing how the user would describe the task. Only if the instruction and feedback should be in the user’s vocabulary, users can pick the correct actions. I remembered last time I did usability test of Carle on my volunteer, the task was indeed really easy (because I found it easy when I did it on my own) but she just did not understand. After the test, I showed her what I really meant for my task and then she rephrased my task instruction in a different way.
Besides, I connected it to my Assignment 4 “GitHub project”. During the lecture, Professor also mentioned that GitHub was some unfriendly to new users and learning curve was demanding. This means if I use cognitive walkthrough method on a new GitHub user for usability test, it probably leads to unsatisfied usability testing result. Because cognitive walkthrough is based on a theory of learning by exploration, new user probably takes long time to finish a task with incorrect result. Another point, I know that unless a user will use GitHub very often, it is very likely that user will forget how to use it quickly
This week I read “Chapter 36: Case Study: One-or-More Button” from “Tog on Interface”. I really agree with one of the sentence that “face your own denials and rationalization” and “get honest with yourself”, even if it probably takes a long time. From my own experience, when I was responsible for Front-end development of a website, sometime I could feel that there was something weird in my design, but I just did not know where it was, pretended everything was fine and let it go.
This time, I really need to ask a favor of peer design review. “To infuse fresh ideas and explode false assumptions that may have crept into your design.” And from this week’s paper prototyping class, I also learned the same thing when classmates from the other group came to test our prototype. There should be so many things we needed to modify, even if we though it could not be much better previously.
Besides, after reading this paper, I also read a post “Radio Buttons: Select One by Default or Leave All Unselected?” from Nielson Norman Group website. I never thought that such a little ration button should have a lot of implications and function. This post is really informative and full of examples.
1. If you decide to design your ration button with “Select one button by default”, you’d better also decide on which one is the default button based on organization’ goal and users’ typical behavior. Because “the default ratio selection can assist the person, and sway a person in the direction in which the organization wants him to go”.
(Picture from the post)
(Picture from the post)
2. Also default selection has its own disadvantage that it might be confusing and unexpected, and cause people to feel OUT OF CONTROL.(Why do you force me to choose on something I dislike!!)
This week I read “Why good design comes from bad design“, a very good article full of practical suggestions.
At the beginning, I was confused by its title until I realized that it taught us to make a list of our drafts and embrace our awful original versions. It is not uncommon that when people design something, they usually have high expectation and want to make their first draft as perfect as possible, even if they do not have a clear idea of the prototype.
Successful designer will not spend too much time just thinking about the best one, instead they document all their bad ideas which reveals problems early, and then help the designer focus on the essential qualities and make continuous improvement. This method is not only useful for producing progressing products continuously for each software development life cycle, but also make the designer’s idea more convincible and recognizable as designer can explain pros and cons of each discarded ideas.
I think this methodology is really familiar to most people when they make a decision on their preference. “Although currently I am not sure what I really want, I definitely know what I really do not want. When I exclude those less-preferred choices, the left will probably be my most preferred one”.
When I was reading the “Don’t make me think”, I was quite interested in one of three facts it mentioned about how people read webpages. Particularly, its accompanied picture reminds me of how human eye reads a website. To make numerous information in a right visual hierarchy, UI designers are supposed to understand how human eyes process web content — “F Pattern“.
According to a research conducted by Nielsen Norman Group on eye tracking visualization, the dominant reading pattern for human eyes looks like an F.
It is consistent with the reading materials that “People scan rather than read”. And this also explains the fact that when people can not find the info they want “at the glance”, they feel frustrated and then have to waste much time to read in lines. So it is important to make the webpage self-content, obvious and self-explanatory.
After seeing those awful website, I made a little summary.
1) Do not cramming too much info in a long page. In fact, people are not willing to scroll for more information and just skip those hidden ones. And to make the web more accessible like for the mobile users, it is wise to build the web with built-in responsive design.
2) Lack of main point. Just like writing paper, every page should has one main point. If you do have a lot of information to display, do have an intuition navigation which is critical for user to find what they are looking for.
3) Colors are important. Not too many and have right color combinations.
（Besides, I found endless “rules” online talking about how to make an exceptional web page. 🙂