According to Hartson & Pyla there are several ways for doing usability evaluation/inspections and each comes with its pros & cons. Some requires only a small group of potential real-world users (RITE, Rapid Iterative Testting and Evaluation; Quasi-Empirical UX Evaluation), some can be conducted with only the developer and UX practitioners (Heuristic Evaluations). Here are some of my questions and remarks:
1) User Experience can’t be inspected but issues in UX design can be inspected. This is like the core idea of UX testing which renders the notion of “as long as it’s an intuitive design it’s a good design.” But what is “intuitive”? Something intuitive to one may not be another one. The context of the product may be intuitive for the Subject Matter Expert but the way it’s made for use may not make sense to the SME at all. (Just like what Cooper mentioned in his Metal Models chapter, things designed by an engineer may be too close to the Implementation Model of the product that it might not be easy to use for other users.) This question is like the ever-lasting question for every design. And that’s why I think it’s important to identify the demographics of “target audience” during the design and evaluation phase.
2) Yet, it’s almost universal to have certain “heuristics” for designing software related product, just like what Nielsen’s Ten Usability Heuristics. Be it from empirical data or just from field experience, most of the heuristics works for different kinds of product. However I believe heuristics evolve over time, i.e. in this information overload age we prefer simple design or plain color scheme, but in 1995 you won’t say DOS (two colors, very simple interface) is easier to use than Windows 95. It will be interesting to do a UX heuristics comparison every one decade.
3) On a personal note, once I did a “think-aloud” UX testing for a friend’s learning game research by playing with his game prototype. It’s really an interesting and useful experience. It’s like what The UX Book said, I was being “schizophrenic” (dual personality) exploring the functionalities while saying out loud about what I get from my previous action and what I am going to do for my next action. In a way I was trained as a UX tester of my own for my personal projects (whether it’s just writing an article with Word or developing a program).
4) The idea of evaluating “emotional impact” caught my attention. Most of the time we want a software or website act just like our body “No news is good news”; “Not feeling something is a good thing”. But conveying positive emotion is like going beyond just being “okay”. This is fun. This is beautiful. It looks elegant. Computer games, contrary to websites or application, it’s more important to be entertaining/horrifying/saddening/engaging than being user-friendly because as Hartson & Pyla mentioned in Chapter 2. It will be good to find balances or trade-off between emotionally-satisfying and user friendly across different kinds of software.
5) The inspection methods are quick and dirty. The pros are they are inexpensive; they are fast to do so they can provide iterative modifications. The con is they will give errors, whether they are “false negatives” or “false positives”. Yes we know the idea number for testers is 3 to 5. But how does this number come up? Good we have Nielson’s figure, from a benefits to costs analysis, to answer my question:
(copyright: “How to Conduct a Heuristic Evaluation“, by Jakob Nielsen)
I enjoy reading Cooper’s writing style. He uses many good examples to elaborate on one idea. Anyway, Cooper described Implementation Models are how things work, Mental Models are how we perceive/use things. Represented Model is how something is designed as a “bridge” between these two models. And it’s better the Represented Model is closer to Mental Models. Questions arose to me:
1) As Cooper mentioned, we can use mechanical examples in Repented Models, even it’s different from how a product really mechanically work, to facilitate the Mental Model. But what if the mechanical example doesn’t make sense to a certain demographics or generation of users? Like in many softwares, you look for a floppy disk icon to save the project. But for those who never get to use floppy disks, do they experience difficulties or confusions the first time they see this icon? And how about the idea of “recycle bin” or “virtual CDR drive”? Will they become so obsolete that using them as mechanical “metaphor” actually becomes a minus for providing information-age representation?
2) And, will what is information-age enhanced interactions someday or soon become the mechanical-age design for us? Be it the examples mentioned (Photoshop, calendar, drag-dropping file) or other digitally- designed, I think we are inevitably facing the evolution (as mentioned in point 2 of the last section) and challenges of designing with and for new heuristics over the change of time.