Steve Portigal, whom I’ve met and whom I don’t think is insane, recently said in a presentation that “personas are user-centered bullshit”.

But he didn’t stop there. He then went on to write an article in this months ACM Interactions magazine extolling the evils of personas which is provoking quite a reaction among designers. He says:

‘Personas are misused to maintain a “safe” distance from the people we design for, manifesting contempt over understanding and creating the facade of user-centeredness while merely reinforcing who we want to be designing for and selling to’

Portigal isn’t the only one to argue against personas. Jason Fried said recently that personas “lead to a false sense of understanding at the deepest, most critical levels.”

Each of these pieces has received a mountain of pushback from certain members of the design community, who feel that in many ways personas are the best tools for communicating design research throughout heterogeneous groups made up of designers, marketers, managers, and executives.

Peter Merholz, in describing a recent project, found personas quite valuable:

‘So on the morning of the second day we dove into a discussion of personas – those archetypal users of the product. We had three personas (Casey, Jessica, and Eric), and we talked about (and occasionally argued about) them for quite a while, until we arrived at a shared understanding of who they are, and what they would get out of the product.

This discussion proved enormously valuable – it lead to some coherence around who the product was for, and it helped focus our discussion of desired experiences, and, in turn, functional requirements. We referred to these personas for the remainder of the workshop, and they came in handy for resolving conversations that got stuck in “Well, I think…”

Definition, please?

But while all of this arguing is going on, nobody is really defining what personas are. This, of course, is a big part of the problem.

Here is the Wikipedia definition:

“Personas or personae are fictitious characters that are created to represent the different user types within a targeted demographic that might use a site or product. Personas are given characteristics and are assumed to be in particular environments based on known users’ requirements so that these elements can be taken into consideration when creating scenarios for conceptualizing a site or product. Alan Cooper (in The Inmates are Running the Asylum) outlined the general characteristics and uses of personas for product design and development.

In the context of software requirements gathering, a user persona is a representation of a real audience group. A persona description includes a user’s context, goals, pain points, and major questions that need answers. Personas are a common tool in Interaction Design (IxD)”

As the Wikipedia definition suggests, personas are often realized as a document that is passed around design teams. A document is created so that everyone is on the same page (otherwise each person would have to remember a tremendous number of details). Personas (persona documents) might be a poster, a word file, or a PDF. Whatever the format, they represent an archetypical person. (While it isn’t technically necessary to create a persona document, it is done in every case I’ve ever heard of) Kim Goodwin, who has refined personas over the years at Cooper, suggests that describing your personas in narrative form is an important part of their creation:

“A list of bullet points might contain the same essential facts, but since personas do double duty as communication tools, a narrative is far more powerful in conveying the persona’s attitudes, needs, and problems. The Cliff’s Notes edition may convey the basic ideas, but it will never be as compelling as the story.”

It should be clear that personas are only one way of organizing research. Other ways include user profiles, user scenarios, mental models, and simple storytelling. Many design teams have their own way of organizing and summarizing their research data.

Personas should not be construed as the act of doing research! They are merely one way to summarize research. What’s really important is not that teams create personas (or some other organizing mechanism) out of their research data, but that they do research in the first place! This will help prevent the arbitrary decisions that plague so many design efforts.

But let’s return to the subject at hand, personas.

As mentioned, personas were formulated by Alan Cooper. He wanted to be able to design for a “broad audience of users”. When you design for a broad audience you can’t design for each individual, you must make generalizations and design for those. To quote from Cooper’s book About Face: The Essentials of Interaction Design:

“the key is in choosing the right individuals to design for, ones whose needs represent the needs of a larger set of key constituents, and knowing how to prioritize design elements to address the needs of the most important users without significantly inconveniencing secondary users”.

Cooper’s solution is to do real research on folks, grab the trends out of that research, and create personas out of them to help spur discussion and decision making. Part of that “creating personas” step is to give them a name, a face, so that they are easily referenced.

From my experience, this anthropomorphism leads to difficulty. The problem is that personas are, by definition, an abstraction of research. Personas represent a summary of research from many different people. In other words, it’s a generalized construct.

But when you place a very specific picture of a person on that persona while giving it a name, you’ve made it particular again. You’re asking people to treat it as an individual person. You’ve taken the summary and made it specific. This is confusing.

Abstractions, which are the quality of dealing with ideas instead of events, can be particularly confusing in design, especially in web application design where events are crucial.

Cooper, however, says that this is necessary:

“this is appropriate and effective because of the unique aspects of personas as user models: they engage the empathy of the development team twoards the human target of the design”

Empathy is important. But I would argue that empathy is something that has to happen within the person designing, it’s not something you can make someone feel through generalization. But whether or not personas help to create empathy, they might help designers get into the right mindset for design. Andrew Hinton wrote a nice piece on how personas are really about role-playing. This is directly from Cooper as well. Personas help designers get into the right mindset if they aren’t already.

Cooper goes on to say:

“Although personas are represented as specific individuals, at the same time they represent a class or type of user of a particular interactive product. Specifically, a persona encapsulates a distinct set of usage patterns, behavior patterns regarding the use of a particular product (or analogous activities in the domain if a product does not yet exist). These patterns are identified through an analysis of ethnographic interviews, supported by supplemental data if necessary…”

(my bolding added…they represent multiple things at once…again I find this confusing)

Ok, let’s get more concrete. What does a persona look like? Well, it’s quite like the Loch Ness Monster…everybody talks about it but nobody shows an example…especially during a heated debate!

A concrete example of a persona?

Christoper Fahey, picking up on a comment to Jared Spool’s reaction to Fried’s piece, proposes a novel solution that would help clear the air in this debate. Why don’t we: actually publish good personas?

He says:

“It’s all just talk, and highly idealized, too. Advocates of personas unfailingly paint dreamy idyllic pictures of wondrous projects where the team has hundreds and hundreds of person-hours budgeted for persona research. But we readers are left having to imagine how great, how non-crappy, their personas are. Show us the goods!”

To that end, here are a few examples. But before I show them to you, realize that I am 100% sure that these will not be satisfactory to all interested parties. Some folks will look at them and say “Ok, I guess” while others will claim that these personas are the worst blight on all humanity. But these are a necessary first step in coming to some agreement here.

• Kelly
• Linda
• Evan
• Bob
• Emma

That people will have problems with these personas suggests there is widespread disagreement on what a persona actually is. If we can’t agree on what they look like on paper, how can we have any confidence that we’re even talking about the same thing?

However, I’ve seen Kim Goodwin give talks where she walks through documenting personas. I thought it was great. Unfortunately, Goodwin’s confidence in showing personas doesn’t carry over to many others. My gut tells me that people are really quite afraid of showing their personas in public, for fear that other practitioners will condemn them as rubbish. This is the elephant in the room of this discussion.

Thus, the confusion about what a persona is will likely persist.

In general though, the primary benefit of personas, that most of those arguing for them suggest, is this:

On projects with more than a couple stakeholders, you need to be able to communicate the needs of users to everyone on the team. Personas are a nice portable artifact that allows you to do so. They allow you to communicate with stakeholders, developers, other designers, and any other interested parties.

Note that this is different from Hinton’s piece above. We are now using personas to communicate with others, not to get into the right mindset ourselves (as designers). This fundamental issue leads to the question: who are personas for? Cooper and Goodwin seem to explain that you do make design decisions from them. Others view them as simply a communication tool with non-designers to get them up to speed.

You don’t always need personas

Both Jared and Andy Budd have pointed out what might be the most interesting issue with personas: You don’t need them when you’re designing for yourself. That is, when you are building something for yourself you simply build what tool you want to use. You don’t have to worry about the needs of others.

This is interesting for several reasons. First, it admits that personas aren’t necessary for good design. Good, so we got that out of the way. Don’t use them if you don’t like them, or more appropriately, if you don’t need them.

Second, it begs the question: why don’t more people design for themselves?

I’ve been thinking about this much more lately, as I’ve gone out on my own and am starting to decide what projects to work on and what projects to pass on. Obviously, most of my decision has to do with how much time I have available. But I am more interested in projects that I would get value out of: the ones that I would use myself.

This might be about selfishness…I want better software…but it might also be about self-preservation, too. It makes sense to me that I’ll do much better work (and help my clients much more) if I’m an actual user of the very software we’re designing. So not only am I more interested in those projects, but I would also do better work for my client since I don’t have that wall of the unknown sitting between me and those I’m designing for. That’s why we do user research…to get over that wall of the unknown.

Degrees of Separation

I think we can make a general statement here:

The further a designer is from the people they’re designing for, the harder it is to design for them.

The immediate outcome of this is that those designers who design for themselves will make better designs more easily. The secondary outcome is that those people who are designing for others are at a known disadvantage: they’re at least one degree of separation away from the people who will use the design. Their challenge is harder.

This next paragraph is a joke.

Even the hugely successful iPod, which has taken its place as one of the best designs in human history, was created by music lovers. Jonathan Ive, chief designer of the iPod, is known to have designed the iPod while listening to the very music he would one day play on it.

Designing for self in practice

But does this hold up in practice? Are those people who design for themselves more successful than those who don’t? Here are some examples (off the top of my head) of people and/or products who are designed by people for themselves:

Netflix, eBay, Google Apps, Wufoo, Basecamp, Freshbooks, Yelp, Craigslist, Blinksale

Most of these examples came from folks who were designers/developers first, created something for themselves, and then when others clamored to get their hands on it, they decided to get into the software business.

Coincidence?

The missing piece: Passion

A year ago November I wrote a piece called Users as Developers. In it I argue that there is another important element at work here: passion. I’ll reiterate a quote from Dan Cederholm (who designed Corkd for himself) from that piece:

“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people.”

I think passion is a real issue with personas. Personas might elicit empathy with the people you design for, but they don’t elicit passion. Passion comes from having a stake, having a long-term commitment. Passion is what gets you that last 10% to make something great. Designers designing for themselves are often passionate. It’s hard to get as passionate when you’re designing or doing research for someone else as a freelancer or consultant.

Obviously, being a freelancer myself this brings up a quandary. How can I do great work when I’m only being brought in for a portion of the lifetime of the web application? How can any consultant or designer?

Well, I think the answer (for me, at least) is to only work on those projects that I won’t really leave. Work only on projects that I’ll continue to use, that provide me with value over time. Software that I actually use myself and would want to even if I wasn’t part of the design team. So far, this has happened on about half of the projects I’ve worked on. I’m hoping to increase that over time to all the projects I work on.

If the only thing I have after a project is over is an artifact of the design process like a persona, that says something very important about my relationship to the project and the people I’ve worked with.

So I think focusing on personas is actually a red herring. If you’re doing research and learning about your users, then it doesn’t matter if you create personas or some other summary of your research. Whatever works for you. What is really important is having passion for what you’re doing and putting all of your energy into it. If you are a designer and you’re not a potential user of what you’re designing, you have a higher hill to climb. Better get started now.

Personas may or may not be right for your project. It depends on the group of people you’re designing with. If you can’t communicate what you need to without personas, then consider using them. If you do end up creating a persona, great! But that doesn’t mean it’s the right process for other designers and it doesn’t mean that someone else’s personas are right or wrong. Stop defending turf you don’t need to!

Artifacts of the design process are insignificant compared with the design artifact itself.

It’s too fun to play pundit. When MySpace was growing hugely popular, about the time that it was sold to News Corp. for 580 million dollars, everyone had an opinion about it.

It’s ugly. It’s horribly designed. They got lucky. It’s just perfect timing. The page views are way out of whack. It’s a fluke. Whatever the reason, it was en vogue to trash the site. Very few people who didn’t use the site (other than investors) gave much credit to the amazing growth and success they were enjoying.

The people sharing their opinions …designers, technologists, journalists, weren’t the people who mattered. They (we) didn’t matter because they (we) weren’t using the site.

Then I had a conversation with an actual MySpacer, and I never thought about MySpace the same. Kelli was despondent. I asked her what was wrong, and she brought up MySpace. “My boyfriend…well now my ex-boyfriend…completely deleted me from his MySpace account. I was first on his Top 8 list, and now I’m not on his list and I can’t even view his profile. He un-friended me.”

To her, MySpace wasn’t just a web site, it was an integral part of her social life. What happened there was as real as anything offline. She explained that since all of her friends were also on the site, being removed from a Top 8 List was a form of public punishment. Her boyfriend might just as well have stood up in the school cafeteria and shouted that the relationship was over. It was a statement about social standing, about being accepted as a part of a group, and it affected her emotionally as much as a face-to-face interaction.

That kind of thing happens every day on MySpace: to people who are invested in the site in a way that no pundit ever could be, even if they tried. There are relationships being broken, fixed, and created all the time and people who don’t use the site will never know it until they ask.

So don’t listen to pundits, loud bloggers, or any individual just because they have a large following or can make a lot of noise…especially if they haven’t used the site on a regular basis! Make sure that the sample of people you’re listening to is part of the actual user population. It will completely change your conception of what social software is.

How “information architecture” is defined much too broadly, frames design in the wrong way, and suffers from infoprefixation.

One of the more insightful social design books of the last decade is John Seely Brown and Paul Duguid’s The Social Life of Information (ch. 1), in which the authors suggest that we suffer from “tunnel vision” caused by an over-focus on technology. Certainly, the technological explosion of the Web has brought about huge changes, as Brown and Duguid should know: Brown works at Palo Alto Research Center (PARC) and Duguid works at UC Berkeley, two of the most distinguished technology havens on Earth.

Infoprefixation

One emergent problem Brown and Duguid describe is called “infoprefixation”, or being over-fixated on information instead of focusing on the people who use it to enrich their lives. Here’s how they explain it:

“…you don’t need to look far these days to find much that is familiar in the world redefined as information. Books are portrayed as information containers, libraries as information warehouses, universities as information providers, and learning as information absorption. Organizations are depicted as information coordinators, meetings as information consolidators, talk as information exchange, markets as information-driven stimulus and response”

This tendency to reframe things in terms of information echoes my frustrations with “information architecture”. Whereas “architecture” started off in the physical world, we now have to imagine (after merely placing “information” in front of it) what it means in the conceptual world. The once solid word “architecture” is now unclear.

The ever-expanding definition of IA

Worse, the term “information architecture” has over time come to encompass, as suggested by its principal promoters, nearly every facet of not just web design, but Design itself. Nowhere is this more apparent than in the latest update of Rosenfeld and Morville’s O’Reilly title, where the definition has become so expansive that there is now little left that isn’t information architecture. One definition in particular sounds exactly like a plausible definition of Design: “The art and science of shaping information products and experiences to support usability…” Sounds familiar, doesn’t it?

In addition, the authors can’t seem to make up their minds about what IA actually is as the above definition is only one of 4 definitions in the book! (a similar affliction pervades the SIGIA mailing list, which has become infamous for never-ending definition battles) This is not just academic waffling, but evidence of a term too broadly defined. Many disciplines often reach out beyond their initial borders, after catching on and gaining converts, but IA is going to the extreme. One technologist and designer I know even referred to this ever-growing set of definitions as the “IA land-grab”, referring to the tendency that all things Design are being redefined as IA.

Time for clarity and a return to design

Normally all of this wouldn’t be a problem and we could continue to live while this confusion reigns. But at this point on the Web, when most people are comfortable with it becoming a real and lasting part of our lives, we need solid practices and clear direction. But the more I read anything about information architecture, the more confused I become. I continually ask myself: Aren’t we just talking about design here? And, if so, why aren’t we trying to find a common ground rather than trying to redefine everything?

Brown and Duguid continue:

This desire to see things in information’s light no doubt drives what we think of as “infoprefixation.” Info gives new life to a lot of old words in compounds such as infotainment, infomatics, infomating, and infomediary….Adding info or something similar to your name doesn’t simply add to but multiplies your market value.

Undoubtedly, information is critical to every part of life. Nevertheless, some of the attempts to squeeze everything into an information perspective recall the work of the Greek mythological bandit Procrustes. He stretched travelers who were too short and cut off the legs of those who were too long until all fitted his bed. And we suspect that the stretching and cutting done to meet the requirements of the infobed distorts much that is critically human.”

The Procrustes analogy is apt. When we begin to view human beings through a single lens (information), then the other rich threads of our existence are cut off. If we begin to see people as simply information finders, as the term information architecture inevitably leads us to, then we begin to cut people off when they don’t fit the architecture we’ve created for finding. Joel Spolsky, in his piece Architecture Astronauts, warns against viewing human activities in this way:

“When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there’s a general pattern: sending files. That’s one level of abstraction already. Then they go up one more level: people send files, but web browsers also “send” requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It’s the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging, but now it’s getting really vague and nobody really knows what they’re talking about any more.

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.”

Focus on people’s problems, not information

The danger of infoprefixation is that it recasts human problems in terms of information. It’s a subtle, but detrimental, shift because we risk losing sight of the reasons why people wanted or needed the information in the first place. If we see the world as a whole lot of information that needs to be catalogued, shared, and organized, then the problem becomes one of organization, not one that is based on the lives of the people we design for. It also moves us away from the rigor of design, which is to continually ask: Why do people do what they do?

While it’s fun and academically interesting to talk about the millions of ways to structure information, the entire value proposition of design rests on whether or not the person we’re designing for is successful. Success means that they achieve what they want to achieve. Therefore, we must move away from an information-centric view of the world, as Brown and Duguid argue, and move toward an activity-centric view. This would alleviate the problem of focusing on the information and not the person. When we focus on activities, we are forced to continually consider: “what is the user trying to achieve?” instead of “how do we organize this information we think the user needs?”.

Web applications and the shift toward experience

This is already happening in the form of web applications. Web applications don’t fit into the world of information architecture very well, because they don’t take an information-centric view of the world. They take an activity-centric view instead. And, to that end, web applications look a lot different from much of the early Web. As Richard MacManus and I wrote two years ago “the web of documents is becoming a web of data”. And that data only has meaning when attached to the activities for which it is used.

In addition, this shift is already happening to information architects, who, recognizing that information is only a byproduct of activity, increasingly adopt a different job title. Most are moving toward something in the realm of “user experience”, which is probably a good thing because it has the rigor of focusing on the user’s actual experience. Also, this as an inevitable move, given that most IAs are concerned about designing great things.

IA Scott Weisbrod, in the comments to David Armano’s reply to my earlier piece, sees this happening too:

“People who once identified themselves as Information Architects are now looking for more meaningful expressions to describe what they do – whether it’s interaction architect or experience designer”

Scott’s examples are curious in that they don’t suffer from infoprefixation. This is not an aberration, but yet another signal that IA as it has lived is dying.

In that post, I used an analogy that pissed people off. I used the analogy that great-looking interfaces can at times be like a public speech out of touch with an audience…solidly executed but sending the wrong message.

I used our beloved President Bush as a public speaker who delivers solid speeches, but often says things that just don’t agree with the facts on the ground. I don’t think I need to go into the number of ways that this has or might happen.

(Update: Please feel free to substitute your favorite politician or speechmaker here…I’m only using Bush because his SOTU address is so fresh in my mind, and I’ve felt for a long time that he’s sending the wrong message…but most politicians do this at one point or another…of any stripe)

This completely angered a few people, who emailed me directly and said “How dare you mix design and politics! You #$%ing &@$% *^%#!!!!!

Now, I don’t know if these people were simply angered that I called out our President in such a fashion, or they really believe that design and politics shall not meet.

This reminded me of an interesting article at Core77: Is Design Political?. It’s a deep article, and one that is worth getting through if only to have a bunch more questions to answer. One of the choice quotes is this:

“Crucially, good user-centred designers look at a problem from the point of view of the user, not the priorities of system, institution or organisation. You could say that user-centred design is a political standpoint in itself.”

Obviously, the author of the piece, Jennie Winhall, has little problem discussing the two. But is it right to do so?

My question is: Why not?

Why can’t we talk about politics and design at the same time?

“Is there any living, breathing example of a taxonomic approach working (scaling) to keep-up with the hyper-efficiency we see in peer-production systems? I’m being quite serious here. Can you point me to a working model?.”

Why is this an important question?

This is an important question because of the widely-held assumption that taxonomies are the right answer for most of our information organization problems.

The thing is, I’m not happy with any taxonomy, really. I can’t think of a single one that works well for me, let alone works perfectly. Even a site with as simple a taxonomy as Apple.com confuses me, with some links on the 2nd level nav (like software and hardware) that are clearly a wider scope than those on the top level. I have to remember that this is the case when I want to find the software page…I have to remember the taxonomy, which to me is a mark of a poor one.

Even the taxonomies I build for myself don’t work all the time, though they work much better than those that others build that I have to use.

A reasonable response might be that taxonomies are the best tool we’ve got. Most of that argument rests on these facts:

1. Taxonomies have been around for a long, long time and are the core of several disciplines including library science and are thus trusted by many practitioners as the Right Way to Do Things.
2. Taxonomies are easily implemented without the input of users. This is a bad idea, of course, but that’s a big reason why there are so many of them.
3. Folksonomies are new and therefore scary. Even the best example of them, Del.icio.us, has only been around for a couple years and only been working at a huge scale for about a year.
4. Folksonomies suffer from the Cold Start Problem (CSP). You have to build up tagging datasets over time, so at the beginning there is really no navigation to build on top of them.

Now, I don’t think that it has to be either/or. We don’t have to build either a taxonomy or a folksonomy, necessarily. They might co-exist in some way, as Thomas Vander Wal has argued.

But the question still stands…are there any examples of knock-down, drag-out taxonomies that scale in today’s world and generally work well for those who use them?

UPDATE Donna Maurer at Digital Web has taken me to task for blurring the question, saying I’m asking for a scalable taxonomy while really wanting one that works. She’s absolutely right…I’m assuming that while it scales the taxonomy still has to be useful. Can’t we have both?

He quotes the article (which I had read quite some time back, but now with renewed interest)

“The motivations to tag can be categorized into two high-level practices: organizational and social. The first arises from the use of tagging as an alternative to structured filing; users motivated by this task may attempt to develop a personal standard and use common tags created by others. The latter expresses the communicative nature of tagging, wherein users attempt to express themselves, their opinions, and specific qualities of the resources through the tags they choose.”

It should be noted that some folks have much more strict rules governing their own organizational needs than others. For example, some spend hours organizing their del.icio.us tags into hierarchies, while others don’t. (I don’t). Some tag each and every one of their photos on Flickr, while others do when it suits them. (like me)

This, to me, is a very powerful benefit of tagging. You can do how much you want, when you want, according to any rules you want (or don’t want). And, because of the effects of scale in tagging, it’s still OK, and there will still be social value even if you aren’t comprehensive in your tagging.

So, why do people tag? Well, part of the reason might be that there isn’t a penalty for not tagging. Tell me I have to do something, and I won’t do it. Give me a choice, and perhaps some positive reinforcement, and I just might do it.

That’s how software should work. User first. System second.

Jeffrey Zeldman on how he softened up to usability:

“Like many design professionals, I rejected usability when I first encountered it. That’s mainly because I first encountered it as a series of rules, put forward by business-oriented, lab-coat-wearing experts who were hostile to the aesthetic component of user experience. Later, the rules would soften. “Only use blue, underlined links” would give way to gentler and more flexible guidelines.

And even before this softening, there was much in the early, fire-and-brimstone approach to usability that was actually of value to web designers. I should have been open-minded enough to benefit from the helpful bits and wink at the rest. But I was too busy defending my creative turf (not to mention reliving old battles with badly run focus groups and cocky account execs) to look closer and see that usability mainly means designing for the people who use my site.”

Zeldman talks frankly about a tension I’ve come to think will always exist, at some level, in the hearts and minds of every designer. As creative beings, we want a little bit (or a lot) of ourselves in our designs. On the usability front, however, we realize the person on the other end is focused resolutely on their own goals. The challenge is to find a common middle ground.

“Technology doesn’t matter. Design doesn’t matter.”

Later, he refines:

“Of course design matters. Technology matters. But they have no causal relationship with success any more than the color of a logo does. Don’t focus on the wrong thing!” (my emphasis)

Mullenweg’s point, which is a good one, is that most of what we know about design and technology is generalized to the point that we can’t be successful without something else. We know that something needs to be usable, but what exactly does that mean in relationship to our product? We know that contrast is important in design, but how much and when and how? We know that we should write in the user’s language, but what exactly does that mean?

These principles of design are important, but only in the sense that we know what we must manipulate for success. The design itself will determine how we manipulate them. How we manipulate the principles determines whether or not people use the design. The best we can say is something like: “contrast helps us deliver a clearer message”…we don’t know how much contrast will be necessary until we examine the message, or the actual screen where we deliver our message. We know that contrast is important, that’s been generalized very well, but that’s all we know until we start getting into the nitty gritty details of our unique project.

The problem is that each design project, and the people who use them, live in their own context, and therefore have their own solutions. My design solution won’t work for your project, just as well as your design solution won’t work for mine. Our projects are different, our users are different, and their worlds are different.

Mullenweg suggests we focus on something else…something he can’t quite articulate:

“I can’t tell you what you should be focusing on, no one can. I can only tell you it is not design or technology. It’s different for every company, service, and person.”

I disagree with Matt that what we should focus on isn’t design. In fact, I think that’s exactly what we should be focusing on…how our design helps people lead better lives.

I think we need to make a distinction between the activity of visual design (using principles of perception to make something more clear) and the activity of strategic design (deciding what we’re creating in the first place). This is a crucial distinction to make because it separates what many of us think of design (communicating a message) from the actual decision of deciding what message to communicate.

I’m arguing that the common notion of design (communicating a message) is only half the battle. The other half is just as, if not more, important to the design: deciding which message to communicate in the first place. In other words, the what as opposed to the how.

Generalizing is often about the how. How to communicate messages more clearly. How to publish on the Web. How to make a button look clickable. These are all design practices. But there is also the process of coming up with the message in the first place…the function on which we apply the form.

Many folks don’t agree with the notion that functionality is part of design. I’ve argued, and am still 100% convinced, that functionality is the soul of design. The decisions about what functionality to offer our users is as crucial as the clarity of presentation.

Consider, for example, taking away the functionality of a chair. Taking away the decision that we’re providing a place to put someone’s rear-end so that they can give their feet a rest. Is it still a chair? No, not in any functional sense. (In an artistic sense, maybe)

Yet, dozens of industrial designers create new chair designs each and every day. But they all do the same thing…because everyone knows what a chair needs to do in order to be considered a chair. It is such an obvious decision made by the designer that we tend to forget that it is being made at all. We gloss over it as if it isn’t being made each and every time a designer begins a new chair. But without that decision, without the decision that there needs to be a relatively horizontal part of this thing that serves as a place to rest the butt, we wouldn’t have a chair, and the designer would have failed. In other words, the soul of the design (the ability to sit on this thing) is decided upon by each and every designer who approaches the problem…and without that decision the design is something else. This decision has little to do with technology and little to do with visual design. It’s a design decision about what the thing does.

When it comes to the Web, we have few clear cases of functionality like we do with a chair. That’s because the Web is so new, while we’ve had chairs for millenia. We are coming up with certain conventions, however.

So I think Matt is correct, whatever problem you’re solving for people probably has a unique solution outside of the realm of technology and visual design. But I think the answer lies within the design process. It’s all about the functionality of what you provide…and over time markets will sprout up to commodify them. The functionality of a chair is commodified…we know what functionality they need to work. But in the software world we are only just begun.

“To design is much more than simply to assemble, to order, or even to edit; it is to add value and meaning, to illuminate, to simplify, to clarify, to modify, to dignify, to dramatize, to persuade, and perhaps even to amuse.”

Note how Rand goes way beyond the common notion of design, incorporating not only the editing of content, but the embellishment of it. I think we need that sort of broad view of Web design, a field that is far too focused on the technical aspect of publishing, and hardly, if ever, focused on the verbs Rand was occupied with.

Also, Rand was a graphic designer, as opposed to an interface designer, so he only had to deal with one-way communication instead of two-way. In addition, today’s Web designer is also tasked with the social aspects of design, concerns that go beyond the conversation between the corporation and the person, but include conversations between people as mediated by the corporation as well.

I was in a Barnes and Noble this weekend looking at web design books. There were lots of them! I saw old favorites like Eric Meyer’s CSS: The Definitive Guide and new favorites like Dan Cederholm’s Bulletproof Web Design. I have a collection of these books, and my life has been made easier by them. I’m grateful for that.

But these aren’t really design books, per se. They’re more like books about web development, a similar and related field but not quite the same. They’re books about how to publish web sites in HTML and CSS. That’s publishing, not design.

And those are just the cream of the crop. There are countless others whose tables of contents look exactly alike. How many more books do we need showing us how to create table-less layouts in CSS? 10, 20…50? If you want that many books on the subject, you can get them! And every once in a while a new book will come along that adds to the discussion. But the number of books that simply echo each other is growing…fast. You can get multiple titles each from New Riders, O’Reilly, Sitepoint, and dozens of other publishers. Two Sitepoint titles that I looked at were both 500 pages each…all on HTML and CSS. They were brand new books on years old subjects for which dozens of titles have already been printed! How much more can be written on these subjects? Didn’t Eric Meyer lick this stuff years ago?

HTML and CSS ain’t easy

Part of the problem is that HTML and CSS ain’t easy. No matter what people tell you, the CSS layout scheme is not for the faint of heart. Figuring out absolute positioning and floating elements takes months and lots of trial and error. I’m still having to stop myself and say…OK…where was the last relative or absolutely positioned element in the tree above this one? Oh…that’s why this layout is broken! Doh! Perhaps this is partly why there are so many books on the subject.

For years now I’ve claimed that when IE comes out with display:table support that half of the developers out there will switch back to table-based layouts. This way, they can get the layouts they want easily and not have to answer to those folks who claim that it’s unprofessional to use tables for layout because it’s not semantically correct. What they don’t tell you is that no user agent in the world gives a damn what you use for layout…so you might as well use what you want. What they also don’t tell you is that there is absolutely no correlation between table-less layouts and creating a successful design that people are happy to use.

Unfortunately, however, IE7 doesn’t seem to be getting display:table support, so I guess I’ll have to wait a little longer to see if my prediction comes true.

Sometimes technology influences design

Sometimes publishing technology influences the design of the publication. For example, I design interfaces differently knowing what I know about how to make them display well in browsers. The nuances here are many. Sometimes I create content boxes with obvious handles for CSS properties like border, padding, and margin. Sometimes I use text sizes that will be easy to replicate in CSS font properties. Sometimes I even lay out entire navigation bars knowing that I can use a certain technique to make them semantically-correct list items. Ugh. This is work that I shouldn’t have to do, I don’t want to do, and it takes up too much of my time. Talk about a separation of content and style? We need a separation between content, style, and user agent.

Design ain’t easy, either

Maybe we see a glut of “web design” books focusing on technology because design is such a difficult topic to pin down. “What is design?” seems to be a universal question that any designer can give you an opinion on.

To me, design is about solving problems. But not the problems of designers, the problems of users. It’s a not-so-subtle distinction. And I’m not saying that we shouldn’t have these discussions…obviously we need to know the technical details of how to publish. But the inordinate amount of time we spend focusing on technology is wasteful…imagine if we could shave off 50% of the time we spend publishing…would we use that time to focus more on the other problems?

The problems that matter are the ones that aren’t ours. They’re the ones that live in a different context than the one we find ourselves in. Our context is one of a designer and publisher. The users’ is one of goals and activities. They don’t care about browsers compatibility or semantically correct…anything. They care about paying bills, purchasing toilet paper, being entertained, and getting the latest news. That’s their problem set. It doesn’t include HTML or CSS.

Design is as designers do

I’m not one to get hung up on nomenclature. Usually, when I see the words “web design” I understand that it probably means “web development”. But I wonder: is this hurting the web design profession? If readers and publishers continue to use the words “web design” to refer to HTML and CSS publishing, and countless more books get published on the subject, what effect will it have on those of us who consider ourselves web designers?

Should I continue to call myself a web designer even though that might mean to someone that I write code? I don’t want that. I want people to know that I help figure out what goes on the page depending on the needs of their users, how the interface should act to help solve their user’s problems, and how their users will be more happy as a result. That’s the type of web design that I do. And it’s a long way off from writing code. Writing code is only a means to an end. In the future I might be writing some other dialect of XML, or even some completely different language or publishing structure. But even then web design will still be about solving somebody else’s problems, no matter what 99% of the web design books say.

Using his own tendency to shy away from them as evidence, Ryan wonders if the excitement of social networking apps is a bit over the top. He asks: “is the market already saturated with products that no-one yet uses?”. His reason for not using social networking apps is a good one: he doesn’t have time because he’s busy getting work done. But even if he were to use them there are still too many services out there competing for our limited attention. So how would we find out about them in the first place?

You Don’t Find Social Software, It Finds You

The answer, I think, is that we would rarely find them out by actively seeking them. Ryan is right, most folks outside the teenage demographic don’t have time to spend actively seeking out new social networking tools. Instead, if we did hear about it we would probably find out by someone else telling us or by somehow inviting us to participate. As I’ve heard it described, social software can be defined as software that is better when our friends are using it.

The Identity Playing Field

Part of the problem with social network sites is that they all require setting up a profile, which becomes your identity in that system. It takes a commitment to each service to create an account, populate it with your personal information, and come back regularly and update it.

But this is about more than the time and energy of setting up profiles. This has huge economic implications…there is a race on to be the identity system of the future. As MySpace has already shown, they who have the users have the advertisers. If advertising is your business model, then hosting identities is a huge playing field right now.

Are Web Apps Here to Stay?

As part of his upcoming web app summit (which sounds really good), Ryan has asked a few of his presenters if they think that social web apps are here to stay. Most say “yes”, pointing to the increasing numbers of applications and the room for innovation as indicators that we’ve seen just the tip of the iceberg, and I think they’re right.

But there’s a longer angle we can view this from. If we look at the history of software, we see that it trends toward modeling human behavior (as I’ve mentioned before). So I don’t see this as a passing fad, but a kind of coming up for air on the way to the destination.

Modeling Human Behavior Increasingly Well

In general, computers and software are taking an increasingly social role for us. Our behavior hasn’t become all that much more social (although it certainly has for some) but we’re learning how to effectively model our social needs in software. Three years ago the social aspects of software was email and chat messaging. Now, it’s forging online identity as profiles and embedded messaging within applications. It’s become always-on, which means that there is no distinction between “offline” and “online” anymore. We are not just modeling messaging, we’re modeling presence as well. This is a big shift…and our language reflects it. I’m “on MySpace” means that we are figuratively and literally on the site.

I quoted Wil Wright recently, and I think he’s (pardon the pun) right on. First thought of as super calculators, computers are now part of the social fabric of our lives. They are becoming integral to how we communicate with our family, friends, and colleagues. They’re still doing calculations of course, but the software that we’ve designed for them is all about human-to-human contact. Social contact. And since we’re social animals in the end, the trend of modeling this in software won’t be reversing any time soon.

In addition, so many students use chatting tools and social networking sites that MSU is even considering phasing out the #1 internet tool of the last 30 years: email accounts. Because students are online all the time and messaging through other means, there is little need for personal, school-based email accounts. Everybody simply uses the built-in tools in the virtual spaces they inhabit.

When I was in school it was all about email. You’ll have an alumni email account for life, I was told. There was an assumption that I would need an email account for life. Maybe that’s not true anymore…

I recently talked with a father of a MySpace user who said that he tried to email his daughter using regular email and she never responded. He asked her why and she said, “I use MySpace for email. Send me mail there”. So he created an account and now he messages her there. Wow.

This is a profound change in the way we use the Web and build software. Email is now a commodity feature: we can almost assume that we’ll always have some sort of messaging system no matter what software we use. Messaging puts the social in social software…

This tremendous uptake seems to make sense. Why email someone outside of the context that we’re in? Better to message them within the context of the application, where we’re virtually meeting, instead of sending them an email from an account they may not recognize, or to an account they check less frequently. In addition, because most people realize that we don’t need to keep messages unless they’re really important, it’s not a big concern if they all go poof tomorrow.

Social networks are killing email. Slowly, but surely.

“If web design were not an art, then we would always get every part right. But it is an art, and, like all arts, it deals with the subjective. The subjective is something you can never get 100% right.”

I think Jeffrey is right: no designer can expect perfection in design. They can neither expect to create the perfect design nor expect to be able to know it if they did. And even if they did, somebody would hate it just because it was perfect.

Web Design

But web design is design after all, and as such we need to know when it works and when it doesn’t. If people use it, it works. If people don’t use it, it doesn’t work. Though people’s comments about it might be subjective: “I like it!” or “It’s ugly”, web design, like all design, succeeds or fails based objectively on how well people can use it. We may argue about metrics: (do 60% or 80% of people need to succeed in order to call it good design?) but we aren’t talking about someone’s subjective opinion…we’re talking about their actual behavior. That’s the beauty of behavior: it’s verifiable and objective.

The obvious way to find out what works and what doesn’t work is to watch what people do with your design: how they use it. Every designer who has done this has undoubtedly been shocked to learn that non-designers don’t see the world in the same way that they do. When non-designers use web sites, they ignore everything that doesn’t help them achieve their goal. They are amazingly narrow-sighted in that way…pigeon-holed into their own context and problems. And the funny thing is: designers are this way, too, when we’re not designing. That’s even what prompted Jeffrey’s post: as a Flickr user he was a befuddled.

Designers Don’t Want to be Judged Objectively

The truth is, web designers are nervous that their (read: my) work will be judged objectively. They fear that their designs will prove less than useful. They hate the notion that their work will be edited, or even worse, redesigned because of user feedback. But it happens, to very well-respected designers and professionals. I know of many cases where the work of someone you probably have heard of was completely scrapped in favor of a redesign that just worked better. Unfortunately, we hear little of these stories that could serve as valuable lessons.

There is a lot of ego tied up in design. What makes designers want to achieve great things for users is the same urge that makes them hold passionately to their original ideas. It’s a conundrum. Designers are rebels, for the most part, and most of them don’t want people changing their stuff, which would inevitably happen if someone were to objectively judge it. Part of their resolve to distrust evaluation is that designers have a clear vision other people aren’t privy to. I sure as hell wouldn’t allow someone to change Bokardo, even if in some small way they were right. This is my design. My creativity. My colors. My flag.

I think that’s partly why MySpace is so successful. Even though we might find someone’s profile pages revolting…it’s their revolting page, not ours. As a few people have said to me since I wrote The MySpace Problem, MySpace is very much like a teenager’s bedroom…

For my job and my hobby I’m a designer. The other part of my job is that I watch how designers work and how designs fail or succeed. I get some perspective from both sides of the fence…but it’s really difficult to articulate the issues that I feel strongly about. The tension between creativity and success is one of those issues. I will probably continue to struggle with that…sometimes Jekyl wins and sometimes Hyde wins.

Art and Personal Expression

Many designers that I know design to express themselves…they are more like artists than designers, really. I’m glad that in this day and age artistic people can make good money doing web design, but they will often be judged objectively, not subjectively. It’s just a part of the design world. I think there is a trend here, too…and it’s not the direction that artists will want.

I want design to be personally expressive, too. I want people to appreciate my work and the time I spend doing it. The cold hard fact is, however, that my expression is subordinate to the needs of the user. No matter how great I think my design is, the resolution of success comes only after other people have used it. I have very little control over that. In this way I become transparent as a designer: my work becomes defined not by what I’ve done with it, but by what other people have done with it. Their achievement is my achievement. In Art, it can work the other way around. Not so in Design.

Reconciling Design and Expression

Thankfully, if we recognize this we can still win the game. We can design things that work for others but that still satisfy our own needs as creative beings. Kevin Mullet and Darrell Sano, in Designing Visual Interfaces, put this nicely:

“Unlike the fine arts, which exists for their own sake, design must always solve a particular real-world problem. Functional criteria govern the range of possibilities that can be explored; aesthetic possibilities that are not compatible with this minimum standard of usability must be quickly discarded, if they are considered at all. Fortunately, there is almost always a wide latitude for aesthetic expression within these bounds, and experienced designers realize that solving a problem in a manner that is uniquely appropriate brings an aesthetic satisfaction all its own”

It kind of sounds like killing two birds with one stone. We’re designing first to solve a problem, while also satisfying our own artistic needs. As long as we can do both, we can choose which one is the real reward.

Many weeks ago I contacted Ryan Carson over at Vitamin to talk to him about writing an article on successful, but ugly, web sites. I had seen a lot of designers dismiss sites like Google and MySpace because they are ugly, failing to talk about their merits or what makes them successful. ( I also wrote Does Google Succeed Despite Bad Design? in response to two of them, but that was more focused on Google than it was on the general problem of being ugly and successful. )

In particular, I kept coming back to the question: is MySpace well-designed? Obviously, they’re doing something amazingly right…to have grown so fast and so big. I read Kathy Sierra’s piece: Ultra-fast release cycles and the new plane and it dawned on me that all this ugly-design talk is basically monday-morning quarterback. What matters is the perception of MySpace users. A few I talked to confirmed this: the service is their social life.

So I wrote The MySpace Problem, over many weeks, through many stops and starts, and it is now getting some good conversation going. I’m happy with the piece, even though it ended up being much different than I had originally planned.

The reason why I wrote this piece is because I want to have discussions about what works and what doesn’t work on the Web. This is part of what I do for my job but it’s also what I’m really interested in: social web design. We can all go take graphic design courses to make things look great (which I strongly suggest we do) and communicate a message well, but that wouldn’t help us create something like MySpace. To create something like MySpace, we would need a completely different toolset, made up of skills yet to be determined…

The big takeaway for me was that design is much more than what “web designers” do. It’s the whole package, from research to engineering to marketing. If we think about design as how something works, then we open ourselves to a much broader picture of design.

Most people’s conception of design, right now, is the wicked worn look or rounded corners. But we need to move beyond that, to recognize that graphic design is but a small part of focusing on how things work for people, how they include design in their lives, and, ultimately, how successful the design can be.

“If you have been thinking that there is anything whatsoever in design that requires artistic skill, well, banish the thought. Immediately, swiftly, and promptly. Art can enhance design but the design itself is strictly an engineering problem.”

What I like about Joel’s piece is that he focuses on design as creating something for real people in real-world contexts with real-world constraints to use.