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)