Archive for the 'ethnography' Category

Grounding Abstract Methods in Design Needs

Two articles, once again from Todd Walker, highlight how research (or research-driven techniques) needs to be (re)-grounded in the needs of design.

The first, Design Meets Research from AIGA,  has a useful survey of leading testing techniques and provides some pros and cons about each of them.  In the middle of the piece is a paragraph that summarizes the key problem most designers have with research:

There is a group of brand consultants and cultural anthropologists alike that believe now that it is not the actual research itself that is the problem. It is rather about how research is often misused, what type of design concepts and stimulus are tested, and how data is analyzed that is most often at fault. When used correctly, research shouldn’t stifle creativity but rather offer designers stronger inspiration and focus.

They remind designers that there’s a critical interpretation phase that comes between research and design.  No one would disagree with that statement, but where it gets tricky is how people define interpretation and who participates in it.  In more than one work environment, interpretation meant a summary of major findings, was conducted by the strategy group or account lead, and somehow straight-lined to design recommendations.  (”Only 49% of respondents viewed element x favorably -> Replace element x or remove it.”)

The article hits some other high points:  know what you’re testing for; remember that testing is ultimately about better understanding a customer (heightening designer empathy with the audience) and not about having customers do design; ethnographic activities are still the best things for designers to do no matter what; research is an art not a science; interpretation is a joint activity between design and research.

The other article, Personas and the Role of Design Documentation has similar themes, but is more focused on personas.   Specifically, it focuses on the way in which most people go through personas as a deliverable that needs to be done, not as a tool with a purpose and communication goal.  Key point for the writer:

Personas are not documents, and they are not the result of a step-by-step method that automagically pops out convenient facsimiles of your users. Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

The best part of the article is a distillation of lessons from Alan Cooper’s ‘origin of personas’ story (mythic in its grandeur, but true):

1. Cooper based his persona on a real person he’d actually met, talked with, and observed.
This was essential. He didn’t read about “Kathy” from a market survey, or from a persona document that a previous designer (or a separate “researcher” on a team) had written. He worked from primary experience, rather than re-using a some kind of user description from a different project.

2. Cooper didn’t start with a “method”—or especially not a “methodology”!
His approach was an intuitive act of design. It wasn’t a scientific gathering of requirements and coolly transposing them into a grid of capabilities. It came from the passionate need of a designer to really understand the user—putting on the skin of another person.

3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play.
Cooper was telling himself a story, and embodying that story as he told it. The persona was in the designer, not on paper. If Cooper created a document, it would’ve been a description of the persona, not the persona itself. Most of us, however, tend to think of the document—the paper or slide with the smiling picture and smattering of personal detail—as the persona, as if creating the document is the whole point.

4. Cooper was doing this in his “spare time,” away from the system, away from the cubicle.
His slow computer was serendipitous—it unwittingly gave him the excuse to wander, breathe and ruminate. Hardly the model of corporate efficiency. Getting away from the office and the computer screen were essential to arriving at his design insights. Yet, how often do you see design methods that tell you to get away from the office, walk around outside and talk to yourself?

5. His persona gained clarity by focusing on a particular person—”Kathy”.
I wonder how much more effective our personas would be if we started with a single, actual person as the model, and were rigorous about adding other characteristics—sticking only to things we’d really observed from our users. Starting with a composite, it’s too easy to cherry-pick bits and pieces from them to make a Frankenstein Persona that better fits our preconceptions.

There are, of course, challenges embodied in these lessons.  Grounding a persona in one person could lead to endless ratholes about which one person, and number wonks will immediately jump all over the “method”/”methodology” point.  But the key point is that personas are ways of creating empathy with the user, of getting us (our team and clients and other stakeholders) out of our own heads and into someone else’s, of creating conversations with potential customers and users.

Is the XO hate just sloppy design thinking?

holeinwall.jpgI’m blogging about the XO because it feels like most interactive professionals are rushing to judgement (positive and negative) and missing an opportunity to dig into a rich design case study.

When I say “most interactive professionals”, I’m referring to the voices I’ve come across on blogs, twitter, and some searches. It’s not a scientific sample, by any means. However, the rush to harsh judgement, and the lack of any real in-depth looks, makes me suspicious. In our daily work, we spend hours and hours watching users look at slightly varying shades of color, or small pixel level adjustments to improve the performance of a page by .5%. We spend hours and hours speculating about what features the next OSX release might have, and then many more hours evaluating them. But, for the XO, it seems like we have it all worked out in 20 minutes or from the press coverage.

I wish there were people out there who were explicitly evaluating the XO against: 1) the educational approach driving the project; and 2) research addressing how kids approach computers for the first time.
The first point refers to constructivism, an educational theory which can be summarized crudely (to the point of coarse vulgarity) as kids grow cognitively by doing things rather than simply being taught. There’s too much to cover in a blog post, but even Papert’s summary is better than nothing:

The word constructionism is a mnemonic for two aspects of the theory of science education… From constructivist theories of psychology we take a view of learning as a reconstruction rather than as a transmission of knowledge. Then we extend the idea of manipulative materials to the idea that learning is most effective when part of an activity the learner experiences as [the construction of] a meaningful product. [italics mine]

The constructivist point of an XO, and there are other points (such as providing digital textbooks via the internet), is to get kids building and making things with a computer. I haven’t dug deep into the literature, but there are some places that look at the tools underlying this approach and how well they work: Life-Long Kindergarten, the Maine Laptop Initiative, and the robotics-in-school wave sparked by LEGO’s Mindstorms. Experiments like this are, by nature, hard to conduct. The lab is usually restricted to a single classroom, maybe a school district, or, at best, one state. I would love to hear designers and others talk about this.

(Interesting) sidenote: an individual’s early experience with computers seems to be a strong factor in whether people are inclined to like or put the hate on XO. As a kid, I took an 8th grade programming course on a TRS-80 and it created a lifelong fascination with math, science, generative design, computation, digital creativity. When I was eight or nine, I played with a lunar lander program (your craft is falling to earth and you can use direct or rotational thrust to land safely). It was a painfully slow computer (a phone handset was placed in large rubber holders to talk to the mainframe at CMU), but I spent an entire afternoon plugging numbers in, waiting three minutes for a response, recording the results, and backing into the rules driving the game (to say I was backing into the math would be an exaggeration, it wasn’t as formal as that). I was, in effect, “reverse engineering” and learning a complex system.

Slightly younger friends of mine had Commodore 64s with Turtle Art (the epitome of a constructivist software app, shown below) as kids. They also seem to be predisposed to liking the XO. For all of us, there is a sense that these constructivist moments were as valuable in forming our clearly fabulous minds and inspiring us to learn as any formal schooling we had.
turtleart.jpg

Understanding, and actually looking at, the constructivist underpinnings and implementation of the XO seems to be missing from most design discussions of the tool.

The second point, how kids approach computers especially when they are largely undirected, is another area where I think western designers are missing an opportunity (or being sloppy). We’re all very well versed in how comparatively affluent consumers approach websites and other interactive experiences. We also have an idea of how supervised kids approach the web, but do we know anything about how kids learn them for the first time and alone? When we “laugh our asses” off at the operating system, what is it based on? How do we know that the OS is inappropriate?

Again, I don’t personally have a lot of data points, but one project that is repeatedly referenced is the Hole in the Wall, a program where unattended computers are made available to kids in India. From PBS:

From the slums of New Delhi to the coastal roads of Banda, hundreds of poor kids in India go online every day at free, outdoor computer kiosks installed in slums and rural villages to read news headlines, befriend cartoon figures, draw with digital paintbrushes and explore the possibilities of cyberspace.

There are no manuals, no adults to guide the kids, and it’s a Windows machine (originally an English version). The kids (who appear to skew older than the OLPC target by three years), teach it to themselves and each other.

hole2.jpgThere are a lot of design challenges against new assumptions in the XO, so the question for me is: why aren’t designers trying to learn from the XO or at least do a more informed critique of its design?

Seeing People Better, with Practice

mccrackenpost.jpg

Inspired by the insightful photography of Gus Powell, Grant McCracken has a post close to the spirit of people who carry cameras everywhere looking for Thoughtless or Everyday acts of design. There is much to be learned by looking around and recording, thinking about we looked at and chose to record and, most important, learning to look deeper into what hapens around us:

[Gus Powell’s photography] demonstrates how much anthropological work there is to be done, and that it is open to anyone prepared to engage in simple acts of observation. Clearly Powell is extravagantly talented as a photographer but some of the power of his work comes I think from a willingness to notice what the rest of us let slip by. That is to say, there is a Pepysian project here that invites the participation not only of the likes of a Pepys or a Powell, but anyone prepared to pick up a camera or a pen. Lunch hour anthropology is open to everyone. And I particularly love the constraint Powell puts in place. After his inspiration Frank O’Hara, he asks, “what can I see in an hour?” A constraint of this kind prevents us from being overwhelmed by everything that needs noticing “out there.” A little act of discipline makes the project manageable and this in turns makes the project possible.

Thoughtless Acts photostream on Flickr.  The picture above is from my iPhone on the F train:  he was doing multiple shapes with his origami, using some cool metallic purple tweesers for the more delicate folds and tucks.