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 realized that I made a blunder today. I was talking with one of the members of the leadership team for UA. It was brought up that it would have been nice if we had been testing the Web site or planned to do some tests before launch. Now granted I was surprised that they would wait this entire time to bring up a concern like this rather than present it towards the beginning of the project. Nonetheless, I was at fault for not keeping everyone in the loop that IWSS makes usability testing a part of the regimen for Web design. Testing had been going on since the beginning. Maybe it would have made the process easier on everyone if they knew that the recommendations made by myself and IWSS were not coming from text book knowledge, but rather data collected from user experience and past experience dealing with Web sites. I took for granted that it would be a part of the process.
On a side note, it does show how people view usability testing not as a normal part of the procedure, but as a bonus “just in case” type of thing. Go figure.
Needless to say, it was a red-faced moment for me. D’oh!
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.
Carrol makes a good pitch for the usability rationale tool. Used correctly with the proper scenarios, this pro and con type report will relay the progress made within the scenario, displaying what has been overcome, and what has become a problem as a result of the solution. It think it is in this exact use that the usability rationale tool is useful. I wonder though what the clients would think of when they took a look at it. Perhaps seeing two plus points and only one minus under an item would give them the impression that this is a strangely organized pro and con list. More negatives than positives do not make something a poor solution and vice versa.
Really, the strength of the tool is planning for future development. Looking at this report, readers can identify the next problems they need to tackle and evaluate if the solution offered is really worth the trade-offs.
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.
- 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