I should give a little disclaimer here as I am making a post on the end of Making Use. I have not discussed all that could be discussed in the book. As scenarios were a new thing to me, I needed to accept a lot of what Carroll was saying and interpret the ways he used scenarios in his examples. For example, I have not talked about the model in chapter 11 for the task-artifact cycle. I think that this is a great model to reference. I would feel strange about breaking down for a small blog what Carroll uses an entire chapter to describe. But I wanted to not this here for my future reference in case I decide to look at some scenario-based design for a thesis or another future project. This figure should not be modeled, but looked at in a more theoretical light according to Carroll, and I agree. The figure demonstrates how a project would ideally unfold using scenarios and claims, but we all know that we do not live in an ideal world. Clients, other designers, our own inhibitions, and technology related problems will require us to visit scenarios again and again. Trade-offs will occur and scenarios might not necessarily be resolved.
Carroll cautions the scenario manager to not fall prey to the requests for glitz and external noise that will stray from the scenario and the proven data. After reading this, I found myself a little discouraged. To be able to ignore the external noise and requests for “more ______”, I would have to be in a position where I could refuse. It depends where the designer’s management lies. Carroll sound like when he was developing the MiTTS projects, he was working for the IBM research center. It was likely a project controlled by the IBM research center, and not a client. How would Carroll have reacted if her had been designing software for an external client and despite scenario data that pointed in a specific direction, the client insisted on a different solution that problematizes the scenario? Would the scenario be abandoned? Changed to something that deviates from the core goal of the project?
The environent Carroll suggests is one where everyone already buys into the idea of scenario based design. In this way we end with the same problem as I came to in Information Architecture. Unless you have spent time reading the book and not only understand, but have been receptive and believe in the value of scenarios, the client will not neceaasrily buy into the practice. Scenarios are a lot more accessible than aspects presented in Information Architecture, in that if the design team prefers scenarios, they can make use of them as a way of understanding the overall goals, subtleties, and pre-empt and problems that might occur if not otherwise examined.
How do I feel about scenario based design? I think it is a great way to disseminate data and to keep a handle on the overall task at hand. Scenarios serve as a constant set of check point where when revisited can show if a project has remained on task and relevant to project goals. I believe that most people will not take issue working with scenarios, but would have liked to hear how Carroll recommends selling scenario-based design to colleagues and clients.
Hopefully that wasn’t too much of a rant. This book has changed the way I will approach design. Going back to one of my first posts, it encourages to examine the why and not just accommodate a request.
I was surprised at the number of categories that Carroll adopted for his book. In reflecting on the way scenarios have been presented for the UA web site, I would lean towards participatory scenarios. As a refresher, participatory scenarios occur from allowing users into the process. Their observations and interactions with the site give rise to exact scenarios to be fulfilled. This is not to say that a person merely saying, “I want this,” is creating a scenario. I think I have a good example.
The other day a colleague approached me and told me that an issue with the current site is that if alumni want to register for events, they have to go deep within the navigation to find the right links and forms. (I suppose this could also fall into an example of reuse scenarios. Carroll did mention that scenario categories tend to overlap.) She asked where the user would go on the new site to register for events. We did a mock situation where I supposed that the users would go to the “Get Involved” link in the main navigation, then to “Alumni events,” and then select the appropriate and register from there. This seemed logical to me. Of course my focus in this process is to keep pages clean and systematic in their organization. Nonetheless, my colleague still felt that the events registration link would be found.
So, we have a scenario. How did we solve this problem? I was not keen on reorganizing this navigation. IWSS has been conducting usability testing on the site and this issue has not come up. (Then again, perhaps they haven’t asked someone to try to register for an event. I’ll have to check into this.) Because we seem to have a layout that works and is logical, I did not want to mix that up. Plus, my colleague was looking for something more on the top side of things.
We identified that we have additional resources on how we can drive users towards event registration. On the main page are six on page boxes, as well as a main flash banner that can contain up to six rotating images, each with a small amount of text. By plugging specific events into these areas, based on when they would be most effective, we created a front page presence for event registration, without upsetting the overall navigation.
I do not consider this scenario closed. Once we launch the site I plan on keeping close tabs on whether alumni are able to find the registration page within the navigation. If it is not working for them, I do not want to rely on the band aid of using the banner and front page to direct them. I will make sure it is in the place where they will look.
In keeping with the spirit of the chapter, after finding out what the users are doing to get to the proper page, if they can get there at all, I should be able to make a claim on what they are doing instead and why they are doing that. If there is consistency, perhaps my claim will point me towards a better solution.
When reading about the various evaluative models which Carroll suggests using as a lens to streamline usability costs and time expended, I found myself trying to guess which evaluation model Carroll recommended in the end. He used the examples of the Smalltalk training program and the MiTTS program to apply the models to their usability rationales.
In viewing the minimalist model, I immediately thought that one of the negatives to the rationale immediately trumped the use of the system. Carroll tells us that users may not have the information or skill required to complete the tasks. This is of course to be applied to the scenarios where users are working on a realistic task. On top of that, Carroll sites that there may be too many kinds of task settings to support. In reading further on in the book, I see that Carroll did end up adopting the minimalist model for the MiTTS program.
The strength of the minimalist model lies in its ability to allow users to integrate prior knowledge into their current learning experience. The minimalist approach facilitates realistic, relevant tasks. My concern with the model, that users not having the knowledge to navigate the program in such a manner, or the multitude of settings being a problem was not unfounded, but relatively misplaced. Carroll is not advocating for a “best” model. Just as in usability rationale where the strengths and weaknesses of a scenario solution are listed out, some concerns may be relevant and worth overlooking for the overall good of the project since all problems cannot always be solved. IN this way, using different models for different rationales makes sense. Carroll realized that the designers navigating MiTTS were highly likely to have the knowledge to complete the tasks. As a result, the minimalist approach would minimize mundane tasks and maximize their potential for learning through the module.
A similar balance must be created between intrinsic and payoff evaluation. Where payoff evaluation focuses on the performance of features and produces data that is difficult to link to exact elements, intrinsic evaluation produces a number of observations about the features without a way to apply the information. However, when combined the two evaluative methods can produce a picture with a wider scope. As Carroll mentions on page 198, Early intrinsic testing will keep the design goals in perspective for designers, while shifting them later towards a payoff evaluation will allow the product of the goals to be tested. In this way, we can have a credit-blame relationship in the evaluation. With this relationship, we return to our scenario type roots, where we can identify a problem and propose a solution to that problem.
One idea that Carrol mentions briefly, but that seems extremely important to scenario use is revisiting the established scenarios. Too often it seems that once a scenario is used to identify a problem and its appropriate solution has been used, it is retired. In reality, the newly created solution should be tested against the created scenario as if it doesn’t address the concerns. Does it still fulfill the scenario? Or does it just make a bad situation better. Carrol even acknowledges that it is not always possible to solve a problem entirely as there are many competing factors in design. He illustrates this in his library information system scenario, and again in his multimedia design interface example. However, even given this, scenarios should be reevaluated periodically so that the solution created is still the most applicable and not compromised by other variables in the design process. After all, when change or creation is the overall goal, variables will never be constant.
Carrol makes the argument that using scenarios identify problems more effectively than merely stating the problem or proposing a solution to the problem. I think of it this way as an example. One of the features that was requested on the UA web site was to have a page within the site where media relations stories could compile allowing for the Alumni, Donors, and Friends web site to be a one-stop shop for news. So originally, we went about trying to find a way to get the stories from media relations to feed directly onto a page. It turns out that the problem is one of accessing content. Users wanted to be able to have all of the links in one location. It didn’t necessarily matter if the content was a part of the official page. As a result, we could place a link in the navigation page that led directly to the content on the media relations page without duplicating the already updating system that media relations had in place.
Scenarios are helpful because they do not tell the problem, they show it. A scenario being presented allows the designer, who has learned the design problem solving solutions to apply those to the problem presented. This way, it is not the client trying to solve the problem with their limited knowledge.
I suppose on the whole that is what scenario-based design provides–problem clarity.
This was an engaging chapter and really made me think about computer-based design and all types of design for that matter in a new light. Let me list the six properties of design problems out as John M. Carroll has them on page 22.
Incomplete description of the problem to be addressed
Lack of guidance on possible design moves
The design goal or solution state cannot be known in advance
Trade-offs among many interdependent elements
Reliance on a diversity of knowledge and skills
Wide-ranging impacts on human activity
What I like about this list is that at first glance, most of them don’t seem to be negative points and the rest seem to be facts of life. But the first point is especially surprising. How often is a design rendered (no matter what the format) without clearly exploring the problem fully. Carroll’s analogy of the house shows how piecemealing problems is not a good way to an effective design. If you look at the house in terms of foundation, supports, and a roof, a bigger picture is present. But even these can be broken down further into water, cement, iron, wood, nails, shingles, more wood, etc. The result is that you might address the problem of users being able to search a database remotely, but since the problem is “solved” little attention is paid to the placement of the search, the construction of the database, or the navigation leading you to the search bar.
Carroll had another good example when talking about Dreyfuss and his approach to design. When looking to design a new typewriter, he spent a lot of time beforehand watching the people using the typewriters work. One of the things he discovered was that gue to the traditionally glossy black coating, the typewriters were reflecting a glare into the eyes of the workers from the overhead lights which would cause headaches. This touches a little on point six. The coating on a typewriter would have been put on it for aesthetic purposes. It did not serve any other purpose. But while it made for a better-looking typewriter, it did not make for a better tool.
Dreyfuss really is a good example of a good route to design. He began by discovering the problem. Perhaps problem can be a confusing word, maybe to say Dreyfuss always discovered the “Why” he should design and gained a thorough knowledge of the product from the point of view of the person who would be using it.
Yet often, designers who are not provided with a clear description of the problem that their design is going to address assume free creative reign over the planning of the project. I think that in a lot of ways, designer has come to be almost synonymous with artist. In fact, when dealing with IWSS to work on the Web site, I have frequently said, “I know you guys are the designers and do this every day, so you know better than me.” Thinking about this, it is really untrue.
They do not know better than me. I do not necessarily know better than them, but I do have a better understanding of my project than they do. Are they to be blamed for taking control of the project? Of course not. All too often we expect designers to be master planners as well as artists. In reality, they probably are busy focusing on the design itself and do not have the needed time to go out and search for the real problems. They rely on the clients initiating the project to discover, identify, and be on the constant look out for problems that will occur as the design trade-offs are happening.
One of the hard points to accept was that reliance on diversity and skills can be a bad thing…especially when we are always told otherwise. However, Carroll equates this to too many people in the kitchen. Good ideas will spawn from mass collaboration, but rather than being fully developed, they can be swallowed up in the constantly emerging good ideas. It seems like it is best to collaborate in moderation.
So really, these artists of today shouldn’t have a vision for the project until they know why they even have a project to do. Then again, perhaps the clients should be aware of the problems that are supposed to be addressed with a new design before they bring their project to the desgners.
Carroll concludes the chapter by telling us that the examples of the projects he used employ situations or scenarios that sought to remedy certain problems, but this is not scenario based design at its best. He promises that true scenario-based design can happen on purpose and not as a side product of discussion. Perhaps proper use of scenario based design can avoid these six frequent flaws in the design process.
- Crossing the Digital Divide
- Mouse pad rhetoric
- Sarah Palin rhetoric
- Chapter 9 Postmodernism, Indie Media, and Popular Culture
- Convergence Culture
- Digitizing Race and the Matrix
- Modules in video games
- Weather channel
- Figure/ground, framing, and grids
- Grids, layers, hierarchy, transparency, modularity, patterns
- Readings on disability
- Rhetoric of Walls