Danah Boyd is pondering some of the rich, loamy stuff she’s uncovering in her long ethnographic study of young people and social networks.

She’s finding signs that there’s a growing social class/standing divide between Facebook and MySpace among high-school-age kids, and she’s wrestling with precisely what that means.

Thankfully, before waiting until it’s all been strained of all personality and doubt and pinned to wax as an official “paper,” she’s putting her neck out there and sharing some of the ideas she’s struggling with. You know, starting conversations, asking for feedback.

Of course, lots of people don’t get it. The BBC posted a story about it as if it were a University-vetted “study” — and it’s getting slashdotted and everything, which is bringing tons of people to the blog/essay who don’t understand ethnographic methods, or her approach to social sharing.

But, all that aside, it’s a fascinating post in itself.

The “blog essay” itself is on her site at danah.org. And the regular blog post where she explains it and is collecting comments from the public is on her blog at zephoria.org.

It’s especially interesting to read through these comments. Of course, as I said, lots of people seem uncomfortable with qualitative, raw, conversational research-analysis-in-formation. There are also some who, in their snooty disdain for MySpace and what they see there, unwittingly prove Boyd’s point to a degree.

What a lot of commenters bring up is that there are important differences between these two social engines that may cause some of the results Boyd is seeing. For example, while MySpace allows a user to create an anonymous account and connect to anyone they want, Facebook requires you to be “yourself” on the site, and allows connections only through referrals or pre-existing offline relation (such as being from the same school).
here are other, more subtle rules-based structural differences discussed throughout.

To me, this is central to what information architecture (at least as I see it) is all about: creating structures (whether categories of content or logical rules for what can and can’t be done and how) to channel people in particular ways.

I mean not so much the tabs/categories/taxonomy but the rules-based structures: who can friend whom; whether or not you can use a pseudonym; what channels can be used to form networks; how much you can customize your personal page, etc.

I wonder why these kinds of design decisions don’t get talked about more among IAs? Though to be fair, it’s on the rise. There were some great sessions about it at the last summit.

I can’t help but have a strong gut feeling, though, that the IA of “categorization and organization” of static structures is going to pale in comparison in terms of importance and impact next to the design decisions behind rules-based structures such as this.

Two colleagues in the last week or so have posted in their blogs about persona-based design.

Austin Govella gives us a nice set of links about Personas, and Antonella Pavese touches on some counterintuitive truths about personas after reading Jason Fried’s Getting Real in her post Get Real: How to design for the life of others.

Antonella in particular mentions that one way to ‘get real’ about design is to realize you can’t design for anyone but yourself. That is, you can’t read a bunch of facts and figures about your users and somehow methodically design for them; that it takes a kind of roleplaying, and how that was Alan Cooper’s approach when he initially articulated a persona-based approach.

I only recently realized how powerful persona design can really be, and even more recently realized why.

When most people talk about “personas” they’re really talking about deliverables: documents that describe particular individuals who act as stand-ins or ‘archetypes’ for other users.

The truth, however, is that personas aren’t the documents, or the method, or any of that. Personas are people! But they’re people a designer needs to “get” in a visceral, intuitive way.

I was actually fairly confused about what personas should be, how they were different from marketing segments or “user profiles,” until I read Alan Cooper’s own column about “The Origin of Personas.”

A few paragraphs of it are so important that I think they deserve quoting in full:

I was writing a critical-path project management program that I called “Plan*It.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of Plan*It to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

There are several very important insights I had from reading this:

1. Persona design didn’t start as a ‘method’ or especially not a ‘methodology!’ It was the intuition of an empathetic software creator, someone with a personality and mental frame capable of putting himself as much as possible not only in the ‘shoes’ but in the voice, body and life of his user.

2. Persona design was this activity of enlightened empathetic roleplay, not a deliverable or procedure to produce it. This explains to me why, in so many situations, I’ve seen personas created and wondered what use they were. The answer: they’re useless on the page, unless the page is used to help tell the story.

3. Personas didn’t start as collaborative artifacts, but that’s how we almost exclusively think of them in UX circles. Cooper was working essentially alone on this: he wasn’t using his persona to explain things to an executive stakeholder — he was just designing, in the present.

4. Cooper was doing this in his ‘spare time’ while things were rendering, away from the system, away from the cubicle. I wonder if this would’ve happened if he’d had a more responsive system, like we typically do today? And yet, I’ve *never* seen in any description of a Persona method a direction to get away from the cubicle or meeting room, and breathe fresh air, and talk to yourself!!!

5. His persona was based on a real person, not a mashup of users. Typically, we make personas that cram a number of different characteristics into one person. But I think this approach may lead us astray at times — not that we have to use only a single actual person for a persona, but maybe we should *start* there, before creating a frankensteined non-existent user from the cherrypicked parts of the ones we’ve observed?

Essentially, personas aren’t a method that you follow step by step and end up, automagically, with a reference-facsimile of your user. It’s really an emotional, almost theatrical leap that takes imagination and deliberate, focused empathy.

It makes me wonder if, as designers, we should have some kind of method acting seminar, to get us out of our geeky skins?