Nov. 7th reading.

Reading Response

This weeks reading was regarding analysis and reporting your evaluation.

Chapter 16 was rather boring and I don’t think the authors said anything that really stood out.  I suppose the concept of a symptom versus a problem was interesting but the rest of the chapter seemed to read more like, “How do you analyze data? You analyze it.”  I understand it is difficult to describe the process of analysis but I found this rather uninteresting.

Chapter 17 brought up the CIF standard of reporting which is essentially the normal standard of reporting so nothing really new there.  The CIF for qualitative research was basically, “it depends” though.  The chapter also notes you can report individual problems and can include video clips if they are important.  I am not certain who is reading this and are happy they now have permission to use video clips in their report.  It also goes into how you should cater your report to your audience and not use jargon.  You also shouldn’t demean your audience and avoid blaming.

Both this weeks and last weeks seemed to be more of the use your common sense chapters.  I was not really impressed by these as I don’t think they actually gave any really good advice other than common sense.  I think I would search elsewhere for tips on how to create my report.

Oct. 31st Reading not so scary.

Reading Response

Chapter 14 was very broad and its topics could be found in just about any other book discussing research.  It focused on preparing for your research session.  There really isn’t anything there that is special only to UX testing.  I did like the part about compensating your participants with a t-shirt that says, “I survived (some name)’s usability testing.” I think I would like that t-shirt.

Chapter 15 was about how to run the actual testing.  Again, it wasn’t something that was specialized to just UX testing but its always more or less nice to review the steps of how to approach your participant properly. the phrase, “allow some time for co-discovery partners to get to know each other and do a little bonding…” makes me think of taking two puppies and putting them in a box together.  Get to know each other now! The comment about deciding what counts as an error is a good one and should be determined before testing begins.

Overall, these two chapters were an overall look at the actual testing itself, what to do, how to do it, when and to whom you should do it to. As always though, the answer is mostly, “It depends”.  I think that really is the motto of UX testing and design.

Oct. 24th Reading

Reading Response
     The readings this week focus on prototyping and information architecture. The blackboard reading discusses information architecture.  The first thing it describes is navigation and how understand how users navigate websites.  The authors bring up information scent and information foraging which is something we referenced at the beginning of the class.  There are many different approaches and views regarding navigation and not one particular approach can be the best every time.  Like so much in human computer interaction field, the motto for making decisions is once again, “it depends”.
     There is a very nice chart on page 126-127 explaining the various navigation models that I found very helpful. The chapter then goes into explaing how to develop and initial architecture. I am not so certain about the usefulness of the card sorting activity as a method of determining architecture.  It seems like a very large amount of time to waste to have participants group categories.  If the designer already knows the categories and what is in them, surely they have a good idea of what goes where.  I would rather see it more as a double checking the designers work than as the initial construction.  I suspect that often the authors of HCI books think HCI groups have a lot more time and money than they actually do.
There is another useful and simultaneously specific and yet somehow broad checklist about reviewing the architecture of your site on page 144 and 145. This chapter keeps iterating the motto “it depends” in a variety of other roundabout ways.  I wish there was a chapter that actually gave examples and defended the decisions because a lot of what we read is along the lines of “choose what best suits your needs! “or “Not too many and not too few!” Which I would liken to my mother telling me to just swim faster when I was competing. (Rather than telling me how to do so) I would like some definite answers and if there are none, then barrage me with examples and explain why they made those decisions so I can get an understanding of it.
     That being said, I did enjoy the variety of charts and lists in this chapter.  It seemed pretty thorough without being really wordy or getting in too deep for each category. I think if I were going to create a webpage, I would look through this and use the checklists and make note if I covered in some way every topic they mention.

1. How do you choose between the different types and fidelity levels of prototypes?

This is dependent on who you are showing and what you want to learn.  A low fidelity prototype should probably not be shown outside the project team as it will confuse outsiders with its missing parts.  High fidelity prototypes should be made after a majority of the design decisions have been finalized as it will likely be time and money  consuming to create.  Overall, you should know who you are showing the prototype to and what you want to learn.  You don’t have to show them everything if you only want to know a particular part.

2. What are some pitfalls to avoid when prototyping?

Don’t make it too detailed too early.  Also, don’t fall in love with early designs.  They will likely be destroyed or should be destroyed.  Also, don’t worry about how it looks too early on, it will change and the most important thing is the overall functions, not the aesthetical choices.

I found the part about getting out the WD-40 underneath the How to make an effective Paper prototype section amusing.   Also that fact that he mentioned “Scotch” Tape again as well as “Sticky” note pads. (With Post-it in parenthesis)  The UX book is back to being oddly specific in its directions without giving examples which would have been helpful.

I am not certain about the purpose of the decoy buttons.  They seem silly to me. If you’re testing only what you have…then you test what you have.  Otherwise, don’t test.  I don’t see the benefit in letting the user “click” buttons that go nowhere.  It would annoy me and make me wonder what the point of the testing was if there wasn’t something to test.

The chapter ends with a wish list from the authors of what an ideal prototyping software would have.  It almost seems like they essentially have the design requirements already, maybe we will soon be seeing prototyping software from the authors?

Reading Reflection Oct.17.

Reading Response

This was a very long reading and I tried to make my reflection as concise as I could.  With so many concepts to consider, I didn’t want to leave anything major out so I think this going to be a rather long post.

Cooper states there are three parts to the design framework: interaction framework, visual design framework, and industrial framework.  Interaction framework establishes an overall structure for product behavior and for form as it relates to behavior. (136).  Visual design framework is the overall look of the design. Industrial framework deals with the size and shape of the product, buttons, and in general the general physical form and input methods.  You should also check out the capabilities of custom software and how it can be presented or components that are necessary so you understand where they can be presented or hidden.  Then, the design goes into refinement stage.  After that, you begin usability testing and get feedback on the design.  Cooper presents a nice overview of the whole process but does not get into specifics.

The UX Book Chapter seven begins by discussing paradigms.  They recommend that a designer take a paradigm and change it to suit their personal needs for their project.  Next it goes into design perspectives. My personal favorite perspective is the emotional perspective.  I love using something that I love using. (There’s a slogan for a design agency!)  Next, we retouch on user personas.  (again) It is a nice description of how to create a persona. “A sketch is a conversation” (285)  (When listing sketching supplies, why did they feel the need to specifically say Scotch tape? Tape would have sufficed.)

I’d also like to note this book references Wikipedia. The bottom of page 294 shows its used as a reference.  I can’t decide if I like that but I do find it amusing they were brave enough to do so in their textbook.

Chapter 8 goes into mental models and conceptual design.  It begins by noting that all mental models can be viewed through any paradigm that the designer wishes. (I think good data can be gathered by looking at the same data with different paradigms)  The chapter notes that a conceptual design is the only way the designer and user can communicate.  It goes into metaphor which I think ties with the emotional perspective paradigm.  Storyboards are next which I wish they had included with sketching but it makes sense to break them up.  Sketching is about the design, storyboarding is more about scenarios and user experience. I am also uncertain as to why the authors advocate for concept mapping after sketching. To me, they would be likely going on at the same time.

The final chapter discussed design production. I feel like they are breaking down design iteration a little too much.  Sometimes it is better to be concise rather than thorough, especially when you do not have an example to give.  Now, we go onto wireframes. This is like blocking out your design, you put in what you need, where you need it, and it should be here due to this reason.  Later, you go into aesthetics.  I like the idea of using them like a deck of cards to show what the user would see  (rather like storyboarding again) The book also mentions custom style guides, which contain all the design decisions in one document that can be referred to for consistency. The chapter ends by discussing participatory design.

Overall, this week’s reading had a lot of great concepts.  There is so much to remember though that I would have to recommend multiple readings.  Or better yet, putting the concepts into practice in a mock design.  That is usually the best way for me to recognize the concepts.  I also tried to very briefly answer the suggested questions posted earlier.

1.             What are the products of conceptual design? When we are done with conceptual design, what tangibles do we have?

We should have a history of the design through sketches and prototypes and bits of paper with scribbles of words on them.  We should also have a design represented in some way.

2.             Some of the tools that help us come up and communicate the conceptual design are sketches, wireframes, and prototypes.  They have various levels of fidelity: low (sketches); medium (wireframes); or high (prototypes). Although we read about prototypes next week, try to figure out: Why do we use redundant tools at different levels of fidelity? And what does it mean for something to have less or more fidelity?

We can adjust easier, see things clearer. I would venture a guess that fidelity is referring to the level of trust in the design that the designers and creators have.  Each is more time intensive to create, more time involved.  You don’t want to commit to a prototype when you don’t have the first clue what it will even look like.  You start with a sketch, which is easily erased, thrown away and changed. Wireframes are more intensive in time but you can still change them and not lose a lot of time. Prototypes can be expensive.  You don’t want a prototype until you’re ready to present it as a nearly final product

4.             What are some major do’s and don’ts of conceptual design?

Don’t stifle ideation.  Begin as if you can do anything.  Afterwards, figure out what is feasible.

What role do users, user research, and user feedback play in conceptual design?

Their roles should play into everything! Its how the designer and user get on common ground.  You’re trying to match two mental models so that the end product is the best, to avoid these roles is to likely end up with a poor product.

I hope that in class we can go over the question, “What are other useful tools and techniques for creating conceptual design?” I was a bit stumped by this one. Or perhaps just overwhelmed with all the concepts from the reading.

Reading Response Oct. 10th.

Reading Response

It was suggested that we should know the what, how, and why of a few topics covered in the readings.  Here is a brief rundown that I have concluded after reading the chapters.

A persona is a user model that represents a specific. individual human being. A persona is not a stereotype.  Demographic info should be used sparingly when first constructing your personas so it doesn’t influence your persona and change it into a stereotype.  These are useful because you can create a narrative using a persona interacting with your product.  They are a fictional user. How does this persona’s goals change how they use this product?

Use cases focus on low-level user action.  They treat all possible user interactions as equally possible. A use case focuses on the functional requirements of the system and how the user interacts with it and the accompanying response from the product.  Using a person in a use case (or a Goal-Directed scenario) allows the designer to see the behavior associated with the product from the standpoint of a persona.

Scenarios create a specific story to construct and illustrate design problems and/or solutions.  It has a setting, an actor (and/or persona) and the scenario records what the actor would do in a situation.  The scenarios are described in a narrative.  Essentially, a designer needs to know their system well enough to empathize with a persona and view the product through their eyes.

Task Analysis uses questionaires or open-ended interviews to understand how a user currently performs a task. The data from the questionaires or interviews is analyzed and broken down into a concise description identifiying the problems and methods they use to complete a task.

Task analysis can only get you so far.  You can see how the user currently solves problems as well as the problems that currently exist.  This would give you a base of data to answer questions about improving a design or creating a new one.  A use case allows you to see the lowest form of interactions, how does a user complete a task.  This would be helpful for more of a programmer or layout designer but does not help with the experience or interactions with the product. A use case with a persona allows you to see how a particular type of person would solve the problem or task. This could allow you to cater your product to a more specific type of person, or take their needs and wants into account while designing. A scenario could be created at anytime during the design process as it could identify needs or problems of the user, providing information for the designer to work with.

I found the readings ok this time.  Cooper’s reading went deeply into personas but refused to give real examples which is something I was looking for. It also discussed scenarios. The UX Book’s readings focused on different types of models for analyzing data and discussed models that could help influence your design. I liked the photos of their WADD analysis, it was nice to see it in action. The models were rather detailed and had lots of nice examples and even included examples of barriers in the model.  I’m a fan of a graphical representation of the interaction and I would love to make some sketches of one. (It would be fun I think, to try and think of all the different things that would affect each component)  I am still a bit fuzzy on keeping track of all the models. I imagine, like in most things, a mix of models provides the best data.

Reading Response for week 7

Reading Response

The readings this week focused more in on how you approach gathering data about the user experience.

There is a distinction between user and customer.  Cooper notes that often they are the same but a customer is the person who makes the decision to purchase the product.  A user is someone utilizing the product to accomplish a goal.

I also liked the description of the master-apprentice model of learning.  I love learning by teaching others the concept and I think I would love trying to guide a person in teaching me how to use the product while exploring its usability.

I also like the persona hypothesis.  It attempts to answer three questions: 1. What different sorts of people might use this product? 2. How might their needs and behaviors vary? 3. What ranges of behavior and types of environments need to be explored.  Essentially what is the persona of the user for this product? Who is this designed for?

The end of this chapter also notes the three phases of ethnographic interviews.  Early, Middle and Later.  While that seems rather vague, its actually quite helpful to categorize where you are in the interviewing process so you can focus your questions better.  Just another thing to remember when conducting interviews!

A final point that I hope to remember from this chapter is the ethnographic interviews are concerned first and foremost with the “why” of users and “how” they hope to achieve their goal.   The “what” is not as important.

The UX book chapter also agrees with Cooper that the best way to get information about how a user actually uses a product is to go to the user’s work place and observe them.

This chapter also gave theoretical examples which were quite nice.  I like the image of people following flashlight users around taking notes on clipboards.  (I don’t think they were that obtrusive but its possible)  I also like the image of the triumphant voting lady giving an earful of critique to the voting people. (Even if they weren’t interested in her comments)  The ticket kiosk idea was interesting as well, I wonder how much ticket sales would increase here on campus if there was a kiosk at all the major bus stops.

The UX book chapter also notes that you need to know your user, reinforcing Coopers claim as well.  It also has suggestions for preparing for your interviews similar to Cooper and reminds the interview to remain focused on their goals but also establish trust with the user.

Overall, I found Cooper to be a better run down of how to conduct an interview and the UX book was better at giving examples and scenarios.  They should write a book together.

Presentation 2 Response

Reading Response

This week’s presentations were an improvement over last weeks. We were definitely more concise this time! These presentations were more over things that we really take for granted and store as assumptions in our minds.  When you consider what the topics are (Pointing & selecting, Controls, Menus, Dialogs, Errors & Alerts), they seem extremely common sense.  Why it is necessary to break them down into thier design elements is to give us a look into what makes for good and bad design for those elements. (There are tons of variations for the different topics! It makes me feel bad for not noticing all the work someone put into choosing the perfect sound for an alert, or the perfect look for a scroll bar!)

For example, a mouse. It is used to select things by clicking on them so it doesn’t need to be extremely tech savy right? Incorrect! There is a difference in control over your clicking between a mouse with a track ball or a laser and you can preprogram commands/macros to run by clicking various buttons which means you should have more than one button. (If you’re doing more than simple clicking) Our gaming mouse has the traditional left and right click buttons, a scroll wheel that can also click, two buttons on the side that increases or decreases the sensitivity of hte mouse, two on the left side, and two on top. We don’t macro though, we just play better than other people. 😉 (Insert a back in my day we used to click to play games! joke)  But it is so much more complex then just using it to click on things!But you wouldn’t think about a mouse unless you have a real need to make your selecting better than other people’s. Or if your were doing digital painting with a mouse perhaps.

The real motto of all of our presentations was “People don’t think about (insert presentation topic), they just use them.”  So in order to make them better, to design them better, we must force ourselves to think about them and determine the “why'” for all of the design choices about them.

But we did much better this round! Everyone should have a cookie to celebrate! =D

I particularly enjoyed the little error song during the errors and alerts presentation.  I liked it so much I went and listened to it again, then searched for a mac version and found an iphone version instead! It’s kinda cute actually. (It uses app sounds as well so its not just the iphone itself sounds)



First presentations response

Reading Response

The presentations were on a variety of topics.  None of the topics seemed incredibly technical and in fact a majority of the topics seemed almost to echo what we have developed as common sense when it comes to interface design.  Often we get lost in our assumptions in how a user interface will behave and so we must take a step back to look at if the actual rules are being obeyed.  We get a ‘feeling’ of them being off or wrong but mostly we just get frustrated by not being able to achieve our goals and leave.  In the nearly endless choices of the internet, there isn’t time to deal with bad design and so we go elsewhere.

It is nice to break down and look at the various technical aspects of design. I learned or relearned a lot of information about design (for example, the radio buttons and why you can only push one button).   I also kept thinking during the excise presentation about how it relates to exercise. (Too much work to find what I want….*goes and lays down with Cheetos bag*)  I wish they had been able to finish their presentation with that comparison they had lined up.

We uniformly went over our time (excluding the last presenters and the group that didn’t get to present) and I think that we definitely all got caught up in the technicalities of our presentations.  The topics, when we looked at them, were so much more indepth than our initial thoughts and so we wanted to show everything. Plus, we wanted to be good students and good students are thorough, right? well, good students are efficient and this a majority of us were not.  Too much info!

Next week, the goal is efficiency!! The most important information in our given time frame! Go, go, go!!!

Third Reading Response

Reading Response

Our first reading by Cooper was nicely written.  We have now begun to take our concepts of perception and see how the apply to interface design.  Specifically, Cooper illustrates that there are three models or parts to system design.  You have your mental model (What/how you think the process or software should look.) Your implemented model (how the process is actually carried out, the inner workings of the computer or software) And you represented model (What is actually there, the designers chosen representation for the software or systems function). We have how we think it will work, how it actually works, and the method the designer created for you to make it work.  Understandably, the closer you can get the represented model to match the user’s mental model, the easier the users will be able to use the product.

The UX book reading was a nice run down of what a usability inspector does and the different types of inspection techniques they could do. It also introduces the concept of heuristics.  Heuristics  are guidelines about interaction design, they’re only guidelines because there is no real absolutes when it comes to design.  There is always an exception to rules of design. On page 476 there is even an example of what a usability inspector might fill out.  I find it to be a good mesh between qualitative assessment and quantitative reporting.  The inspector makes their decisions on a qualitative basis and then uses a uniform method of reporting the problem to make it easier for others to read the problems and fix them.

I am fond of the fact that usability and testing for heuristics uses qualitative methods.  It makes perfect sense for them to be examine using qualitative methods but it is still delightful when you find qualitative methods out ‘in the wild’ so to speak.

It is interesting as well to note that a really good investigation would use three to five evaluators since they are using a qualitative system. That is the beauty of qualitative methods! No one is technically “wrong”, they just notice different things!    Alternatively you could use one investigator and have multiple clients trying it out but this really depends on what method you are going to use.  People don’t look at things the same way, nor do they operate them in the same manner.  Ask someone to Google something and watch them. Do they type in the exact words you would use to search for it?

I wonder, do usability investigators have to state their bias? Is it assumed they are neutral or must they indicate in their findings things like, “Prefers minimalistic design, Thinks Google Chrome is the best OS, Hates having too many links on a page”?

The final reading was the list of ten usability heuristics.  They seem to be fairly broad without being vague.  They identify areas that problems can easily occur and state what should actually be happening.  For example, one of them is called User Control and Freedom.  Basically, it means that you should be able to go back or end a process easily.  It should have an undo button as well as a redo or forward type system.

Overall, these were interesting readings.  I am finding our usability readings to be very useable!

Second Reading Response

Reading Response

The principles of gestalt were not the first thing that immediately came to my mind when I thought of usability. However, that is exactly where it belongs.  Breaking down your information into components that follows the principles of gestalt allows the user to use the “directions” given by the design. The designer can tell your brain what to look at next without you having to write text instructions, which can take away from aesthetic appeal.  Any interface designer should recognize the principles of gestalt and check that their design takes them into mind.  The delightful thing about the principles of gestalt is that it only takes a simple illustration for the viewer to be able to understand exactly what the principle is discussing.  So it can help the designer to break their design into the visual principles.

Visual attention also helps to focus a designer on what is necessary to direct their viewer. The second reading points out that researchers propose attention selects perceptual objects rather than. Viewers can really only concentrate on one object at a time so a designer cannot create too many focal points. A designer cannot try to draw attention to every item on the page.  If they have a Home page button that flashes, an image of a monkey that says click here for bananas, and a next page button in glittering neon colors the viewer is going to be overwhelmed and not be able to pay attention. Their attention is being drawn in too many places. They also will be annoyed because the aesthetics have to go out the window in order for a designer to try and draw attention to everything at once.  Proper aesthetics encourage only one item to be the focus of a design.  That doesn’t mean a designer cannot draw any attention to other objects but there should only really be one main focus per page.   (Highlander yell, “There can only be ONE!!”) What is the goal of the page? This is what a designer should always keep in mind.  Direct attention to your goals utilizing concepts of visual attention.

Information foraging theory attempts to describe how viewers gather data about what they are viewing. The author, David Trespass, states, “The basis of foraging theory is a cost and benefit assessment of achieving a goal where cost is the amount of resources consumed when performing a chosen activity and the benefit is what is gained from engaging in that activity.” He then goes on to directly discuss how this theory effects interface design by writing, “Poor mark-up reduces our ability to search for content and increases the amount of browsing behaviour that is determined based on the results of fallible image and video analysis technologies.”  If it takes to long to find information, the user will give up.  If the user were a hungry tiger, they would starve because the prey ran so fast and hid so well.  Another article points out that while a viewer wouldn’t starve, viewers are/can be lazy and if a designer wants them to get the information, they have to make certain the viewer has to put forth little effort and be benefited by the effort.

The UX Book reading focused on UX design Guidelines. It started out with an introduction to the overall concept with some of the background, went on to discuss how to use and interpret design guidelines and ended with a description about human memory limitations.  I felt that reading this book last of the other readings helped sort of present a clear picture of what I had read before by retouching on human cognition and giving a background.  I did find one statement to be quite useful even if it’s actually a vague answer.  The authors friend Jim Foley was asked about what was right and wrong in UX design he replied, “The only correct answer to an UX design is: It depends.”  Every instance is new and can really only use past examples as a guideline, not a rule.  I look forward to reading more instances that describe this “it depends” on UX design choices.

So how does this all translate to usability design? We read about design principles that can help shape our designs but can’t really tell us how to design.  They simply tell us how we view things and leave the direction up to the designer.  You can arrange your content in whatever way you like but if you do not follow those concepts and understand human memory, the content is not going to be delivered in an efficient manner.  The user may even not bother trying to get to the information if their needs are ignored.  So, overall, a rather enjoyable set of reading that I look forward to discussing in class.