Week 1 Reading Notes and Reflections

This blog post is a make-up blog post for the reading of first week on the book design of everyday things: Donald A. Norman. I was so inspired by this book that I started looking for usability issues in everyday object like my shower knob and elevator. It broadens the knowledge of Human Computer Interaction to interaction design of all man made objects. The principles for design computer software interfaces in fact are not so different than the interface of a microwave, kitchen stove, or elevator. In fact computer interface has drawn inspiration from buttons, knobs, and switches, which are industrial age inventions. The usability principles remain the same even though things have gone digital for the last decade. On the other hand, we can also see that computers are made to be small in size and portable. Take my car for an example, it has a computer built inside for the radio, CD, bluetooth and navigation system. But we perceive as we are interacting with the car not a computer. So I think there is a no boundary as in how far this knowledge can go. It only matters where I want to use it.

The area I’m particular interested in is the interaction design of games. Games are differentiated from animated movies because of the involvement of interaction. But people don’t seem to notice the importance of that. There are already many well-defined genre of games. Each offers its own pre-defined interaction experience. But people including the players or the developers don’t really take this seriously, because at the end of the day “it’s just a game”. That’s why we see some game companies hire interns to do interface design and leave the more code heavy work to engineers, and art heavy work to artists. It’s almost as identical as the situation with software industry years ago, when big software companies were doing the same thing.

As was shown in my example of Dead Space, good interaction design can indeed transcend the game. And I sincerely hope that I will be able to use the knowledge learned from this class to accomplish that in my future career in the field of game development.



Week 12 Reading Notes and Reflections – This is a battle between UX and STAT

This is week’s reading is ridiculous. Not only it’s trashing statistics to an unbearable extent, but it also justifies its wrong doing in a shameless manner. One quota from the book says it all – “Because product design is not research but engineering, we are not concerned with getting at scientific “truth”; our is more practical and less business. Our evaluation drives our engineering judgement, which is also based on hunches and intuition that are, in turn, based on skill and experience.”. It’s this kind of attitude that leads to the design that kills people.

List of sins against statistics:

1. “It may help to include standard deviation values, for example, to indicate something about the rough level of confidence you should have in data.”

Standard deviation and level of confidence are very different things. Level of confidence is to show how confident you’re that the real value (population mean) falls into an interval called confidence interval (E.g. we’re 95% confident that the average time it takes for the user to print out a report in the system is between 2 to 5 mins). Our confidence is in our method not in our data.

2. “Sometime it can mean that you should try to run a few more participants. ”

The number of participants should be decided according to your expectation towards the data (for example if you want your margin of error to be 0.3% then you need roughly a thousand people to participate). You can’t fix your result by getting more participants.

3. What are the UX goals based on?

The book talks nothing about how they actually set the UX goals. It may well be that the goals are set too high or even unrealistic in some cases. How can you tell?

4. “The quantitative data analysis for informal summative evaluation does not include inferential statistical analysis.”

So you have the data, why not do inferential statistical analysis on it? In fact, there is program for doing that. It can be done in minutes. And it costs nothing.

5. Why is this the only way to identify UX problems?

Statistical analysis can show association too. See, in statistics we have both quantitative and categorical data. Say there is question on the survey “what do you think is the best way to get to XXXX screen” and there is 4 answers. That data is categorical not quantitative. We can definitely run test with it to see if there is an association between this and the average time spent doing a task. On the other hand it makes sense, since the book tells us not to do statistical analysis, so I guess qualitative analysis is the only way.

I’m not disagreeing with the ability of qualitative data analysis. I think it’s great in finding UX issues. It’s just that the book is unfair in the way it describes power of statistics. If I want to make a very high-cost decision, I want to know the probability that I will be right. I can’t just put my trust into honesty of the participants and the ability of the evaluators to interpret the data.

There are questions that qualitative analysis can never give answers to. One I can think of is “Pepsi and Coke, which one is better?”. You can never convince me with your conclusion drawn by qualitative research. Exploring the goals and emotions behind each brand won’t tell you anything!!!


Week 11 Reading Notes and Reflections – “run screaming back home”

OMG. This week’s reading is killing me. The book goes into so much details in the parts related to participants. Examples like “calling your participant in advance to remind them of their appointment”, “have some granola bar and / or fruit available in case hunger becomes an issue”, “keep blank questionaries in the control room”, “bring this evaluation session work package to each evaluation”, “greet and welcome each participant and than him or her for helping”, “hand out leaflets in shopping malls and parking lots”, “proceed your testing with a positive attitude” are plenty. There are several paragraphs discussing the matter of the appropriate number of participants. I think the book basically tells me nothing. I like the “three to five users are enough to find 80% of your UX problems” rule. It at least narrows the options to 3 of them that I can adjust accordingly without having to think about it too much.

I think no one has to read all these excruciating details in order to know what to do. I’m gonna share with you some examples of rigorous empirical evaluation done by people on youtube. I think they are pretty good, despite the fact that they most likely haven’t read the two chapters in the book and they most likely are not UX practitioners. My point is that it just takes so little to prove that a product really really suck. But sometimes the company who produced this product just won’t listen to it.

Benchmark tasks example: Windows 8 – Even a 12-year old can’t do it

(A good example to count the number of grunting)

Free use example: How Real People Will Use Windows 8

Post task interview example: Windows 8 Vs. Mac OS X

Think loud example: Mum meets Windows 8

This one is just for the interesting comment: Systems Administrator Reacts to Windows 8

Yes, I said it. Windows 8 sucks. In this case, Microsoft has one foot in the new touch screen device era but the other foot in the desk top PC era. It’s not hard to conclude that this is a terrible idea. JUST PICK ONE AND DISCARD THE OTHER!!!

On the other hand Apple has done a way better job than Microsoft.

Free use example: Using Mac OS X for the First Time

The funniest of all in this week’s reading is “scheduling breaks between tasks where participants can … run screaming back home”. And this is my reaction to this week’s reading and windows 8. It’s halloween, so what the heck!

See you next week,


Week 10 Reading Notes and Reflections

So this week’s reading in UX book spends a whole chapter discussion prototyping. The reason of having prototyping as an essential method in product design according to the book is that a prototype gives you something to evaluate before you have to commit resources (time, energy, investment, etc) to build the real thing. There are four factors concerning prototyping: breadth, depth, fidelity, and level of interactivity. Different values of these four factors bring diversity to the types of prototyping. To determine how far you want to go in each factor, you must consider both the stage of progress and the design perspective. The author seems to be a strong advocate of paper prototyping. The book describes in length and detail how this method is use and the guidelines one must follow for it to be effective. Then it analyzes the pros and cons of paper prototyping. Finally, the book talks about the transition between prototype and product.

The reading has convinced me that prototyping is effective in discovering major issue from early stage. And I was also made to believe that paper prototyping has advantages over wireframe. Top of them all the advantages, the potential of paper prototyping is almost unlimited (if you don’t mind it’s only two dimensional). If combined with physical prototyping, it can cover 3 dimensional design as well. I just hope that we get a chance to do a prototyping exercise in this course. That will sure bring a lot of fun. However, on the other hand, the prototyping method described here in the UX shares lots of similarity to defining the interaction framework in Cooper’s book. Sketching and storyboarding are basically Cooper’s way of saying paper prototyping. Although UX book describes this book in much more details than cooper and offers a much broad concepts of prototyping, this method doesn’t not build on the foundation of personas, scenarios, and requirements. I think that’s probably the reason why it’s destined to fail and need multiple iteration to get right. If we do as Cooper says, build prototype on personas, scenarios and requirements, I think we can guarantee that we’re on the right track.

BTW, the links to additional readings on BB aren’t working…

It says “The specified resource was not found, or you do not have permission to access it.”


Week 9 Reading Notes and Reflections

Last we read about Requirement Definition. Now it’s time to move on to the next step – Framework and Refinement. Since these two design processes are inherently connected to each other in many aspects. I think the best way to represent them is to talk about them together.

There is one quote from Cooper that best explains the different purposes doing the two – “Requirements Definition answers the broad questions about what a product is and what it should do, and Framework Definition answers questions about how a product behaves and how it is structured to meet user goals.”. However the difference in their purpose, these two design processes both stay at a high level -meaning in these two processes, we only concern ourselves with the overall structure of the user interface rather than burry ourselves in too much details. Framework Definition is in fact when the transition of requirement elements translates translates into fuller designs in a step-by-step interaction. The reason this process is intentionally stretched to a long repeating process according to Cooper is “it’s always easier to discard work and try another approach when you don’t have a lot of effort invested.”. Interaction design is a team effort. It’s never easy for people to come to a consensus in early phase. Throwing away ideas in early stage is unavoidable. And we want to eliminate the cost of that as much as possible. And another benefit of doing this is that we can start to get a general feeling of the end product from a much much early phase. This opens the opportunity that many things can run in parallel. For example, the end result from sketching phase may be used in feedback sessions with the users to validate the design. And also in the same sense defining interaction framework, defining the visual design framework, and defining industrial design framework can be conducted concurrently.


Week 8 Reading Notes and Thoughts

This week’s reading talks about how to use data collected from ethnographic interviews to build a set of personas, and from there how to put the personas into stories to provide understanding for the requirements of the design. The readings go into really specific details of what we should watch out for and what we should be concentrated on, so it’s gonna be really helpful for us in doing our future assignments.

My question of how the quality of the work is measured using this research method continues from last week’s reading. Specifically, in constructing personas, how do avoid building a stereotype? The book says as long as we base our work on data collected through various reliable sources, we will be able to avoid stereotype. But the book also indicates that in the process of building personas, inferences, assumptions, even guess must be made from the data. Even though the data itself is completely objective and accurate, which is impossible, interpretation of those data would introduce errors. And I think the reliability relies heavily on the people doing this. Different people doing this may produce very different result. There is no standards to tell whose is better. Therefore, I’m still skeptical about this. I can’t see that people base billion dollar investment  without knowing the risks. We’ll see about this, as we move on to practice doing this ourselves.

Week 7 Reading Notes and Thoughts

2 mins into the reading:

I’m also taking STAT 501. I think my STAT teacher would be really mad, if he saw this. The reading argued that since we can’t put tight controls on people like we do in physical experiment, and since human behaviors are too complex and subject to many variables, it’s better to use qualitative research rather than quantitative research. I think this makes sense. But I think it’s wrongful to say that quantitative research can only answer “how much” and “how many”, but not “how” and “why”. Statistics analysis association between different variables and causation of changes of them, although some associations found through statistical inference may seem absurd in practical sense.

4 mins into the reading

OK. So the author then argues that qualitative research is faster, easier, and less expensive. The example he gave about investigating the need for a video-edit software is kind of interesting. He said he used 4 days to visit 12 people. From a statistical stand point, the sample size of 12 is too small to draw any reliable conclusion. If statistician were asked to do this, I would imagine him to send out questionnaires to 1000 people to get response of 100. So, this way of qualitative research is indeed faster, easier, and less expensive. But A statistician can tell you how accurate his statement is by giving either a confidence level or probability. It seems to me that qualitative research can’t give anything like that. So, how can I make sure that the result of a qualitative research is solid enough to invest tons of money on it?

6 mins into the reading:

Stakeholder interview: So the informations that we can extract from stakeholder interview are preliminary product vision, budget and schedule, technical constraints and opportunities, and business drives, stakeholders’ perceptions of the user. Well, it’s kind of interesting to see things being broken down to this, ’cause from apple’s presentations that I’ve seen, they just tell you just want to invent a revolutionary product, or change the world. I think in fact they must take these things that’s mentioned here into consideration too, or otherwise they won’t have a “new thing” to show the world every once a while. For example, when iPad2 came out, they weren’t ready for introducing the retina display yet, but the competition of other companies was catching up really fast. So they put out iPad2 without the retina display and saved it for iPad3. And it was very successful for them. They could say that at that specific time, there were no company other than Apple that can produce a product that’s this thin, this powerful (dual processor), and this easy to use (iOS).

8 mins into reading:

SMEs are experts of users. Customers are the people who pay but not necessarily the people who use it. For example, for the iPad app for cats, cats are the users but the cat owners are the customers.

10 mins into reading:

Finally, it’s time for user interview and user observation. So, the reason to have both interview and observation of users is that we care about them but we don’t trust them enough to believe whatever they say, and we have to see them behave ourselves.

14 mins into reading

Literature review and product and competitive audits happen in parallel with stakeholder interview and SMEs.

24 mins into reading

I think this part is combining the things that were listed above to use. It’s called Ethnographic interview, or more specifically a method called contextual inquiry.

So identifying candidates starts with persona hypothesis which depends on factors such as demography, roles, behaviors, and the environment.  Then it’s to create a interview plan. Four to six interviews for each factor. Overlap is allowed. Then conducting interviews.

32 mins into reading

Here comes Focus group, Market demographics and market segments, Card sorting task analysis. Loosing focus…

Well, there are so many methods. And it seems to me that their is the significant overlap of the function of them. And some of them work better together, and some of them alone can give good answers. I would prefer the book tells the process linearly, like first, second, third…etc. I wouldn’t mind knowing all the options, I just want to see who they are put to use in a specific case.

Dylan Liu

Thoughts on last week’s presentation 2

The biggest take away from last week’s presentation is that with a little bit push and incentive we can all do great. Every group managed their time much better than last time. And surprisingly, although the time given for each group had been reduced, the presentations were much more informative than last time. It seemed like instead of listing all the key points like we did last time, most groups took the approach to use more examples. This made the presentations much more understandable and manageable to people who had not read the readings for the topics. And it’s also great to see that some group inherited the successes that they had in last time in last week’s presentation. For example, I really love the Deok’s discussion session at the end. It’s like Worst Website Contest happening all over again. If I remember correctly, group doing menu had a menu bar on the right of there slides all the time. I think that’s a cool feature. It seemed to me that the menu is fully functional, and it knows which slides that it’s one and what’s going on on that slide. I would guess that there is code implementation behind it. If anyone knows how this was implemented please leave a comment.

Our presentation was delegated to one person per section in Cooper’s book. The reason that we did it this way was that our schedule only permitted us to do our own part individually and meet before class for a practice run. If we had communicated more often, we would have shown more consistency between different sections. Doctor V’s comment for our presentation was that she expected us to go for breadth instead of depth. I think she’s referring to my part, which was the selection controls. Since there were 14 items covered in Cooper’s book, I figured I could not possibly cover all of them, I chose to dig a little deeper into the ones I’ve chosen. Since most examples are pretty self-evident, I definitely could use less time talking about them.

Personally, I think I’ve grown a lot in presenting because these two opportunities to present a topic of the text book to the rest of the class. I’m looking forward to do more.

Dylan Liu

Thoughts on last week’s presentations

First of all, as the first group presenting our topic, we were the first to go beyond 15 minutes time limit. In fact, we doubled it. It’s a good gesture from Dr.V to allow us to continue afterwards and complete our presentation. But apparently other groups took that as a permission to go way over time. Our biggest problem was that we didn’t have the opportunity to do a rehearsal of the whole thing, so we had no idea how long it would take to complete the whole presentation. And second problem of our approach was that we didn’t cover all the materials given to us, ’cause we couldn’t find a clear structure to include all the information. But there is no excuse for that. Now I think about it, we could’ve at least given the audience a list of things that we didn’t cover and means to find them.

On the other hand we think our presentation did better than other group of not listing all the keywords and concepts on the slides. We followed the thread in Cooper’s chapter 12 Designing Good Behavior. All the things shown on our slides were  processed information instead of directly copied from the text book. I will keep on doing this in the future.

As for other people’s slides, I think some people went too much into making their presentation look cool, instead of making them informative and organized. But at least the prettier ones did a better job of keeping me awake, and interested.

As for the materials that were presented last week, I think I missed a considerable amount of them. And now a week has passed, I can’t remember much. So, I guess I have to do the readings myself to learn them myself.

Week 3 Reading Notes and Thoughts

My thoughts on Cooper Chapter 2 — Implementation Models and Mental Models

Key Words:

Implementation model / system model: the representation of how a machine or program actually works. For machine it’s mechanisms and for program it’s algorithms and models of code.

Mental model / conceptual model: what the user think the machine or program does. Cognitive shortcut for explaining how it works, one that’s powerful enough to cover their interaction with it.

Represented model /  designer’s model: the way designer choose to represent a program’s functioning to the user.

This chapter can be broken into two parts. The first part discusses the definition of the three models and their relationships. And the second part discusses the use of mechanical-age representation in information-age design of represented models.

I think the author is keen to point out that the “distance” between implementation model / system model and mental model / conceptual model isn’t the barrier for user to understand and better use a product. It is the “distance” between mental model and represented model / designer’s model that actually matters. So this means that no matter how far or advanced our science and technology gets, it’s possible for normal people who’s not familiar with the advancement to take advantage of that. So hypothetically, a man traveled forward in time would be easier to adapt to changes in every day life than a man traveled back in time.

The author also talks about that most current software designers don’t really care to bring mental model and represented model together, ‘cause it’s easier for them to stick to the logic that they used in implementation phase than to design a new one specifically for the sake of easy using for the users. I think the reason behind this is that it’s the computer scientists and engineers who are taking the lead in the industry instead of people with knowledge of the design aspect. The computer industry starts with hackers and programmers sharing their latest find in their small circle to the point that everyone else relies on these people to achieve certain functions on their computer. The involvement of design people in developing new softwares hasn’t been stressed until the emergence of the study of human computer interaction. And now people start to realize the important of interaction design factors in developing new softwares, but they are still more comfortable to put more resources on having a completely new feature on their product instead of making their product easy to use.

My thoughts on UX Chapter 13

(This book is considerably hard to read comparing to other materials, so I haven’t spent too much time on it)

My thoughts on Blackboard Reading — How to Conduct a Heuristic Evaluation and Ten Usability Heuristics

Key Words:

Heuristic: involving or serving as an aid to learning, discovery, or problem-solving by experimental and especially trail-and-error methods

This article describes a method called heuristic evaluation that is used to find usability problems in user interface design. It goes into details about the number of evaluators and its effect on finding problems and cost-ratio, the effect of introducing observer/experimenter in the evaluation process, and the set-up of the evaluation process.

What’s interesting to me is the definition of the word “evaluator”. Who would be qualified as evaluator? Are these people professional user experience practitioners or just randomly selected it people? My guess is that these people should at least have some knowledge in HCI in order to relate the actual design to the usability principles/heuristics given to them. And the article also tells us that they may not have the professional knowledge required in the field of the application. And from the section that discusses the association of the number of evaluators and the ratio of benefits to cost, I can see that hiring evaluators are really expensive (between $410 and $900) considering they only work for one or two hours according to information given in previous paragraphs. This brings even more questions, for example why don’t companies hire evaluators for a full time job? How can one become an evaluator? Answers to these questions are nowhere to be found either in the article itself or related topics on the Internet. So I think some explanation of how to select evaluators for best results would be great addition to this article. (I later found information about this on the reading of UX chapter 13. There is no surprise that UX experts are the best candidates for evaluators)

Another thing is that I would really love to see some examples of the comments the evaluators made to a given user interface design with a certain set of usability principles (the heuristics). This would also be helpful in understanding the evaluation process and eliminating misconduct in doing the test.