This week's reading reflection is going to be a little different. I have been just reading the articles and summarizing them, but at the request of my teacher, I will try to reflect more on them. So here it goes.
This chapter of Cooper goes very in-depth on modeling users through the use of personas and goals. The chapter goes into a lot of detail about what a persona is, as well as the many different types of personas, which I will not get into now. A persona (Cooper, 2007) is a way to represent complex phenomena with a useful abstraction. They “provide us with a precise way of thinking and communicating about how users behave, how they think, what they wish to accomplish, and why” (Cooper, 2007). Personas are formed based off the users motivations and goals, not something like demographics, communication channels, etc. This makes a bunch of sense. If I want to understand how somebody works, I want to know how they feel, why they are doing it, not what race are they, or how they get their information.
Cooper also states personas need to be based off DATA, not stereotypes. Data is key he says, rightly so; without it one cannot form a persona that is free of stereotypes (although provisional personas can sometimes get mixed up with stereotypes even if it’s not the designers intention).
We got into a little argument in class last week about the creation of personas. Half the class wanted to be general, and the other half (professor) wanted to be more specific. After reading Cooper’s chapter, I realize we need to be more specific, but cover a broader range of people using multiple personas. Cooper says we need to accommodate a variety of users and the way to do that is to design for specific types of individuals with specific needs. I would say getting a specific group of users to like your product rather than having everyone thinking your product is okay, or bad, is the what designers should strive for. A product cannot meet the needs of every users, that’s why personas are a great way to get a feel of potential users.
Cooper states that personas are represented as an individual person, yet they represent a group. Confused? So was I. An example of this would be: I am wanting to buy a car. I want it to be fast, good looking, and have high mileage. This represents me as a persona. Yet, there are other people out there who are just like me. This is the group part.
Cooper then goes on to talk about how to actually determine personas using a seven step process, which is too long to go over for this post.
Now that Cooper has talked about research, collecting data, and everything that goes along with that, how does on translate into a design? Well, Cooper states it is a 4 step process: developing scenarios, defining requirements, defining the interaction framework, and then filling the framework with increasing amounts of detail. So that’s it….. Just messing, I wish.
The first important thing Cooper talks about are scenarios, or narratives. They are the “story” which the product is designed around. Cooper talks about John Carroll and his scenario-based design, which focuses on describing how users accomplish tasks. He then rips it apart stating they focus too much on tasks and not enough on motivation, as well as the actor is too abstract. This goes back to the previous chapter where he states motivation and behaviors are the way to go.
I like how he then integrates the idea of personas into persona-based scenarios. It makes sense to combine these two. The definition he provides states, “persona-based scenarios are concise narrative descriptions of one or more personas using a product to achieve specific goals” (Cooper, 2007). He then goes over the three types of scenarios, which build off one another (context, key path, and validation).
Like the next article, which I actually read before these chapter, Cooper delineates a difference between use cases and persona-based scenarios. I’ve explained them more in the next article, so look there for further explanation.
Lastly, he goes into the step by step process of creating a requirements definition, which is long and will not be detailed here. I feel that is it a good process, but as Cooper said it is an iterative process, meaning it can continue for a long time (hopefully not).
Whoops, forgot to mention an extremely important point. Figure out what the product does before thinking about how it works, behaves, or looks. This is a huge deal. If you don’t do this, you may be caught in a never-ending cycle of design.
This book chapter was great. It solidified what we talked about in class last week about personas, data collection, and various other things. I liked to the first thing emphasized in this chapter was do fix problems EARLY, in the design and requirements phase. It is 100x more expensive to change something after the product is completed, as compared to the early phases. I guess I knew this already, but it was nice to hear someone else agree with me.
The chapter then goes into why do we need requirements and where do we get them from. Where do we get them from? The user/client? We, as developers/UI engineers, choose them? Well they say that both are true. Shouldn’t the client have the requirements? Who knows, they probably don’t even know what they want at this point. In the end, the authors say requirements are formed from gathering data, analyzing it, and interpreting activities established from a sound understanding of users’ needs. This definition really brings it all together, even though it is putting more work on the UI designer/engineer. Oh well, a job is a job.
The author also does a good job of explaining personas more. Also, they discuss the various requirements relative to the users’ environment. There are four main ones, listed but not defined, they go over; physical environment, social environment, organizational environment, and technical environment. It never occurred to me, consciously, people need to design for different environments. What if your designing something for a client where they can barely see due to safety requirements? What would you have to do? Make everything brighter I would assume.
Lastly, I wanted to highlight essential use cases, which are combination of scenarios and traditional use cases (in regards to data analysis, interpretation, and presentation). I had never heard of these. I knew scenarios involved descriptions of tasks (stories), and use cases deal more with system-user interaction. I liked how there is something in the middle, and that thing is an essential use case. Essential use cases “represent abstractions from scenarios [...] and try to avoid the assumptions of a traditional use case.”