Week 5: My first car

This week’s reading: Morville and Rosenfeld, Chapters 10 and 11

This week’s reading was more of a challenge than that of preceding weeks. Morville and Rosenfeld’s writing is perfectly clear; the problem is that I lack a frame of reference to instantiate into the general ideas they discuss. When our authors talked about issues of organization and navigation, I understood using my experience as a website user, but I’ve never architected a large website or intranet, nor participated in an architecture project run by someone else. As we move from product to process, therefore, I feel like an Amish teenager reading a Chevy owner’s manual: I just don’t have a way to situate the information and transmute it into knowledge.

The best way for the Amish teenager to address his confusion is to get inside a Chevy, and the best way for me to address mine would be to design a website, perhaps collaboratively. A first-person account of the decisions that went into building a hypothetical website might make a compelling term paper. The objective would be to produce a design that could be confidently handed off to the coders, along with some exploration of how I would review and administer the coders’ work. To elaborate on the research phase, I could identify relevant sites to benchmark my own project against, and I could even conduct some simulated user testing with the help of volunteers. The strategy phase would include some interesting visuals as I constructed metaphors, wireframes, and other tools for conceptualizing and rendering the information I wanted to present. This idea doesn’t match the usual notion of a “research paper,” but in a broader sense, a hands-on project like this would foster the clear understanding that is the purpose of research. I’ll be emailing Dr. Simon about the acceptability of this topic.

Consistent with this blog’s focus on empirical user-centrism, the most interesting part of the reading to me was the section on users and how they can be deployed in the research and strategy phases of site building. I was unfamiliar with the technique of card sorting, a thought-provoking means of recruiting users to help build taxonomies. I imagine that an information architect up to his or her neck in data, content, and bureaucracy might easily lose perspective on what categories belong together – or might simply have a different perspective than the future users of the project, who may be professionals in an industry that the architect is only now exploring. Card sorting could remedy that lack of perspective. However, I tend to agree with the authors that such studies should not be taken too far. Elaborate “affinity models” based on a few data points hide significant statistical uncertainty; what is more, users do not always know what they want and their responses may exhibit systematic bias of various kinds. In the authors’ Weather.com example, I would expect that card sorters would be moderately unlikely to group “gardening” with “stargazing” (p. 281), even though both tasks fall into the category of “reasons people care about the weather.” In the final wireframe in Figure 11-10 (p. 285), a wide number of disparate ideas are unified under the “How Will the Weather Affect Your...?” banner. It’s a solid model, but it seems likely to me that this was a top-down decision springing from the architects’ creativity and content research, not a bottom-up decision based on card groupings.

Gratifying in the reading was the discussion on before-and-after benchmarking, which bears some resemblance to my Week 3 idea of setting up two different web designs and testing user efficiency separately in each. This method is deeply empirical, making use of the scientific method to generate information that is independent of the intuition of either users or architects. The importance of intuition and creativity is not to be understated, but in the end, we would like to have a way to know whether we did our jobs right!