My Proposals for 2009 SXSW Talks.

I’ve submitted two talks to SXSW 2009:

• Designing for Sign-Up
  This talk is for anybody who has ever had the problem of getting people to sign up for their web application. I got frustrated trying to find good resources on how to do this effectively that I decided to write it up myself.
• Managing Your Online Identity Outside the Walled Garden
  This is a copanel with fellow Newburyporter John Eckman, who knows this stuff cold. We’ll be focusing on those tools that exist outside of walled gardens that help rather than hinder you in sharing your identity.

I was also invited to speak on a panel: The Problem with Design Research with Robert Hoekman, Jr. and Jared Spool, in which we’re going to be talking about when design research actually gets in the way…but we’ll each be taking different viewpoints so as to keep it interesting.

If these talks sound interesting to you, please let the SXSW folks know by voting for them or leaving a comment, as part of the way that SXSW filters through so many submissions is by aggregating public feedback.

See you in Austin!

Free chapter of Designing for the Social Web available.

You can now check out a free chapter of of my book Designing for the Social Web on the publisher’s web site:

Design for Sign-Up: How to Motivate People To Sign Up For Your Web App

There is also a one-page version for easier reading/printing, which you can find here: http://www.peachpit.com/articles/printerfriendly.aspx?p=1216150

Enjoy!

Activity-Centered Design.

Is the future of design activity-centered?

Quite some time back I argued that Information Architecture was the wrong frame in which to approach design. My post got a lot of push-back from the established IA crowd, who claimed that I was either wrong or claimed that my view was just rehashing existing debate. I probably deserved this push-back because I really had no idea what arena I was entering or what sacred cows I was actually attempting to kill. After talking with many folks afterward, it was clear to me that this debate has been around for a looooong time. Apparently the forces of interaction design have been facing off against the forces of information architecture in an epic battle for quite some time. I was flying a flag I didn’t know I was flying.

Thankfully, I didn’t burn too many bridges. I attended my first IA Summit this past April and found it quite enjoyable…in fact everyone I talked to had a strong opinion about it no matter what side they come down on.

Anyway, the conversations I’ve had since seem to prove one thing right: that the issue of how to frame design is an important one, no matter what you believe. In a piece written a few months after mine, Peter Morville agrees that framing is important, and actually seems to agree that IA isn’t always the right frame.

Morville includes a brilliant quote from George Lakoff, the Berkeley professor well-known for his ideas on framing:

“Frames are mental structures that shape the way we see the world. As a result, they shape the goals we seek, the plans we make, the way we act, and what counts as a good or bad outcome of our actions…Because language activates frames, new language is required for new frames. Thinking differently requires speaking differently.”

This is the gist of framing, and it is applicable to every part of life. Lakoff recently wrote a piece about how Barack Obama could reframe his campaign messages concerning John McCain. Lakoff’s underlying point is that the way we talk about things affects the way we think about them, and ultimately the way we do them.

Lately I’ve been arguing that the activity is a good frame for design. I started fleshing this out in my book, but admittedly it wasn’t as deep as I wanted to go. I believe that thinking about design from an activity-centric viewpoint is the most efficient way to get where you need to go…which is to create a piece of software that is valuable to people.

This, like my argument about IA being the wrong frame, is not a new idea. In fact, activity theory has roots going back quite far, and lots of HCI publications are putting forth articles on activity-centered design. But it’s still academic, as far as I can tell. In 2005, Don Norman published Human-Centered Design Considered Harmful in ACM Interactions magazine, which turns out to be as much a screed against human-centered-design as it is a positive piece about activity-centered design.

Norman says:

“Many of the systems that have passed through HCD design phases and usability reviews are superb at the level of the static, individual display, but fail to support the sequential requirements of the underlying tasks and activities. The HCD methods tend to miss this aspect of behavior: Activity-centered methods focus upon it.”

Norman makes the case for activity-centered design by looking at everyday objects and suggesting that few in-depth studies of users helped create what they are…instead they evolved over time as people used them. Read any of the works of Henry Petroski to get an insight into the evolution of designs in this way…he writes a lot about how tools like forks and knives evolved over time and use.

Larry Constantine also wrote about activity-centered design in Designing Web Applications for Use. Constantine echoes Norman’s argument by also explaining further how user-centered design can be harmful.

“Focusing on activity and use is not a retreat to the bad old days of technology-centered, inside-out design in which developers arrogantly assumed they knew what was best and threw it at users. It is just an easy way to avoid the pitfalls of human-centered design without giving up its advantages. In the final analysis, understanding your users as people is far less important than understanding them as participants in activities.”

I agree with both Norman and Constantine, but I’m not convinced by them alone. I think we need more evidence that activity-centered design is indeed a good frame. In writing the book and pushing further on the matter in recent talks and discussions, I’m more convinced than ever that this is an avenue worth pursuing. To that end, I’ve been showing the following list when I give presentations, a list of sites and the activities they support.

• Amazon: shopping
• Dogster: taking care of dogs
• Ravelry: knitting & crocheting
• PatientsLikeMe: treating disease
• Upcoming: managing events
• YouTube: sharing videos
• Remember The Milk: keeping to-do lists
• Del.icio.us: bookmarking
• eBay: auctioning
• Netflix: watching movies
• Last.fm: listening to music
• Burdastyle: sewing
• Bigtent: group management
• Flickr: sharing photos

This list is a small one, but it shows how most popular web applications can easily be described in terms of the primary activity they support. I’m sure if you go down through your favorite sites you’ll find it very easy to do the same exercise.

More interestingly is how you can map almost every single feature in these applications to the primary activity. In How Social is Amazon? I pointed out how most of Amazon’s features are like this: each one directly supports the activity of shopping (made up of the actions of choosing an item and purchasing it) A simple rule of thumb: if it doesn’t support the primary activity, it’s not a good feature!

So…to summarize.

1. Framing is important, as it changes the way we think about design and ultimately how we actually do design.
2. Activity-centered design is about framing design in terms of human activity, unlike user-centered design which frames design in terms of the specific people who will use it or information architecture which frames design in terms of information.
3. It’s easy to show how much of the software we use daily can be recast in terms of supporting a primary activity, which suggests that this is a valuable frame for the design process.

So there’s a start on the subject…I would love to start a dialog about what you’re currently finding useful in your design practices…what’s working/not working for you?

Slides from Leveraging Cognitive Bias Talk.

Here are the slides from the talk I gave at d.Construct in Brighton a few weeks ago.

Leveraging Cognitive Bias in Social Design

View SlideShare presentation or Upload your own. (tags: dconstruct08 interface-design)

The Live Web.

We’re building tools to watch the world change…

Doc Searls has a wonderful post on his long-time meme: The Live Web.

What I like about Doc is that he knows words matter. So when he talks about the Web he uses specific words and phrases that frame discussion.

He says that when people treat their web sites like buildings, when they treat them as something to visit, then they become static and end up not worth visiting. It’s like a museum you’ve been to before…it gets old pretty quick if the exhibits don’t change.

But when people treat web sites like an environment, an ecosystem where human activity occurs, then people come and participate when they need to do the activity, your architecture being a place to do things as opposed to something to look at or experience.

If all you want is people to visit you, you’re not asking for much and will not get much for asking.

The essence of Stewart Brand’s book How Buildings Learn is an observation that the most successful buildings are ones that adapt to the changing activity of their inhabitants. This should be obvious, right? But it’s not, because we treat architecture as unchanging…we’re usually not around long enough (or paying enough attention) to notice the change.

This dichotomy also brings to mind Jesse James Garrett’s original 2000 diagram (PDF) in which he compared the “web as software interface” (task-oriented) with the “web as hypertext system” (information-oriented).

This is the distinction between a web of pages and a web of applications. What’s increasingly clear to me is that applications are becoming primary…even hypertext systems of slowly changing web pages (like Wikipedia, corporate web sites, and Apple support documentation) are now merely repositories of documents for information-organization applications like Del.icio.us, Ma.gnolia, blogs, and even themselves in many cases. Without an application to remember, organize, favorite, share, and filter what you’ve found, hypertext systems are not that useful. This is why directory sites like Yahoo and browser bookmarks were very early features of the Web, as they reduced the need to remember where everything was.

Serendipity, the much admired quality of browsing, is much more successful when you know what someone has already done…give me recommendations based not just on chance, not just on the fact that I’m walking past, but based on what you know about me and where I’ve been. Amazon is the example…not so much a product information space as a souped-up personalized shopping application.

We are building a web of tools. Tools that augment us, tools that help us organize what we’ve done, filter out what we don’t want, allowing us to pay attention to ever-specific topics with greater fidelity. We don’t need to “go somewhere” every time we want to know about something: that’s a constraint of physical space. If we can bring it back with us, or at least save a URL, then we have it with us at all times. This completely changes the game we’re playing. The challenge becomes to comprehend it all, not to remember where or when. Memory is the computer’s job…our brains for making sense.

We can watch the creation, growth, maturity, and death of opinion on Twitter Search. We can watch as we build evidence for something within our Del.icio.us bookmarks. We can watch our own interests change in our Amazon book list. We can watch public opinion sway back and forth at FiveThirtyEight. These applications are not trifles. They are the future.

This is a long way from static architecture. The very value of this ecosystem is that we can observe the only constant is change. We are building tools for watching the world change…

As Doc says:

“The Web isn’t just real estate. It’s a habitat, an environment, an ever-increasingly-connected place where fecundity rules, vivifying business, culture and everything else that thrives there. It is alive.”

Book Recommendation: Letting Go of the Words.

If there is one book you should read next, it’s “Letting Go of the Words” by Ginny Redish

The other morning I changed my about section here on Bokardo to this:

“Bokardo is a blog about interface design for social web sites and applications. I write about recommendation systems, identity, ratings, privacy, comments, profiles, tags, reputation, sharing, as well as the social psychology underlying our motivation to use (or not use) these things. If this sounds interesting to you, grab my RSS Feed.”

This rewrite is an attempt to be as descriptive as possible. I need to explain exactly what I’m doing so that people who are new to the site know what they’re in for. I’m also giving people something to do with this information, asking them to grab my RSS feed if they find those topics interesting. If I can do this, then I’ve had a positive interaction with them.

Worrying about words might seem like a trifle, but from an interface design standpoint words are everything. If there is one thing I’ve learned as an interface designer, it’s that words are absolutely the most important part of interface design. If you don’t have the right words on the screen, you better hope you’re building a porn site.

To prove this, try to get rid of the words in your interface and see if people can use them. One thing you’ll find is how useless they are. This might lead us to believe that we need more useful graphics…and in general I think we do…but graphics can’t do the bulk of the work. Text must handle that job.

In her recent book Letting Go of the Words, Ginny Redish, who has been working on the web and building usable software as long as anyone, writes:

“People don’t come to the web to linger over the words. Most uses of the web are for gathering information or doing tasks, not for the pleasure of reading.”

This is exactly the mindset that most interface designers need. Now, there will certainly be exceptions to this, but the vast majority of people just need to know the basic facts.

1. What is this?
2. What good can it do me?
3. How do I get that good to happen?

Other nuggets that Ginny talks about in depth:

• Write in the inverted pyramid style, leading with the main point
• Use bullets to help focus people on the steps you want them to perform
• Layer information, with periodic calls to action to grab people as they gain momentum
• Use questions in headers, which allows people to graze information and read what they need to
• Think about your writing from an information level, not a document level

The book the most solid reference I’ve seen on these topics. Don’t be dismayed at the book’s odd cover and somewhat disjointed page design…the content, as Ginny would tell you, is what you’re coming for.

I haven’t read the whole book yet, but the sections I have read lead me to believe that this book could be the most important web design book since Steve Krug’s Don’t Make Me Think.

In other words, I highly recommend Letting Go of the Words.

Are Designers also Marketers?.

Kathy Sierra says we’re all marketers:

“In this new open-source/cluetrain world, I am a marketer. And so are you. If you’re interested in creating passionate users, or keeping your job, or breathing life into a startup, or getting others to contribute to your open source project, or getting your significant other to agree to the vacation you want to go on… congratulations. You’re in marketing.”

Henry Dreyfuss, who wrote the industrial design classic Designing for People, includes marketing as part of what designers do:

“We bear in mind that the object being worked on is going to be ridden in, sat upon, looked at, talked into, activated, operated, or in some other way used by people individually or en masse.

When the point of contact between the product and the people becomes a point of friction, then the industrial designer has failed.

On the other hand if people are made safer, more comfortable, more eager to purchase, more efficient—or just plain happier—by contact with the product, then the designer has succeeded.

It it interesting that Dreyfuss would include the words “more eager to purchase”, which is certainly not a widely-agreed-upon task of most designers. This is most often relegated to another part of the company. While Dreyfuss was focusing on industrial design (the building of physical products) he was writing in the 50s, before virtual products/software were around. So, can we apply this notion to web application design as well?

We chatted about this idea during a talk I gave to the NHUPA folks last night in Portsmouth. One interesting supposition bubbled up…when designers are tasked with selling their product they make better products. When they are not tasked with selling their product they have less responsibility, and thus aren’t forced into getting feedback on what they’re making. It’s that feedback you get from selling, from your success/failure at marketing, which pushes back positively into the design process. Of course, this idea of marketing is different than the common one of a snake-oil salesman…

So do you buy that idea? Do you think designers are also marketers? Should they be?

What if Gall’s Law were true?.

An interesting bit came across my twitterstream the other day:

Gall’s Law

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

Yup, seems to hold for the complex systems we know and love: organic life, government, law, medicine…and of course Twitter.

Let’s imagine for a moment that it does hold. This would change lots of things, including much of the software world, which is laden with complex behemoths who frustrate us daily.

1. Building simpler software from the start
   Obviously, if Gall’s Law is true then more teams would start out building really simple software instead of overly complex stuff. Sometimes, though, it’s hard to think that way. Instead, the thinking seems to be, if we’re going to be as successful as (X), then our system needs to do more than (X). But in complex, social software, that may actually be impossible, since (X) didn’t spring fully-formed into life, either. Most of the software people try to emulate quickly took years and years to evolve to where it currently is. (as an aside, my recent argument is to focus on designing to support a specific activity and nevermind emulating success for its own sake)
2. Meeting solid metrics before adding features
   This is an interesting idea: make sure that your software works at some basic thing before you add features to it. I’ve seen on a couple projects in which there was a tension between the current under-performing software and the ambitious engineering plan that adds a lot more features. Which do you do? Stop and get people using the simple software first or push on and hope that people will come flocking after you’ve added a few more features? Well, according to Gall’s Law you get the simple software working first. My question is…are there teams who actually do this? Are there any that have actually said: “we have not reached our initial goals, let’s stop adding features and work on the ones we already have”?
3. Changes by design
   The overall effect of Gall’s Law is that most software would start off simple and evolve over time. So we wouldn’t end up with the software we imagined, but the software that managed to live through the early use and subsequent selection process. Accepting this as a rule, could we somehow plan for this evolution even though we don’t know what it will bring? Can we plan for this change? I think so, by building in feedback and reporting mechanisms and merely acknowledging to change the design based on such feedback.

Of course, the reason why we add feature after feature is because we don’t realize we’re doing it: we don’t see the accumulation of complexity…we only see adding “one more thing”. In the same way that a camel wouldn’t feel the slight addition of weight but ends up with a broken back, we don’t really feel each additional feature until its too late.

Gall’s Law might not be an actual law, but it sure seems like a good thing to keep in mind when you get into those inevitable project debates about improving what you have vs. adding new features.

Tripit’s innovative design evolves (but is it for the worse?).

One of my favorite examples of sign-up is from Tripit.com. They have a unique way of signing you up for the service. Instead of filling out a form to sign up, which is the norm, you simply forward them a confirmation email from a travel service. So you book your flight on Orbitz, they send you confirmation, and you forward it to tripit.

That’s all it takes for Tripit to create you an account. After all, they have all they need: your email. But they also have started you using the service. From the email you sent they’ve already created a travel page for you, without you having to do anything. This is a really great way to do sign up because it takes most of the pain out of the equation and gets you started instantly.

I’ve been using Tripit in talks for a while now. In a talk I gave a while back at a New Hampshire UPA meeting, I showed a screenshot of Tripit and described how they use levels of description effectively on their site. Here is the screenshot:

Levels of description is where they give you some information, in this case the How it Works graphic, and ask you to sign up. If you still want more information, they give you another level of description, and ask you to sign up again. If you still want more…the process is repeated until you either sign up or leave the site.

This is usually represented with a “Sign up or Learn More” sequence of buttons. This explicitly gives people a choice: either sign up now or continue to learn about our offering. Sign up/Learn More is the new Ok/Cancel.

One of the people watching my presentation, Jeff Leombruno, pointed out that although the forward an email technique was cool, it might be confusing to someone who expected to sign up like they do on other sites. His first thought was…can I send them an email without signing up? In other words, his expectations have been set by all the other web applications out there…he expects to have to sign up for the service before he can use it.

The answer is that yes, you can send an email without signing up, but that is not made explicit in the interface. The only text is “just forward your travel confirmation emails to plans@tripit.com”;. While the words “just forward” imply that that’s all you need to do, it’s not entirely clear.

So Jeff and I figured that simply improving that text a bit would be helpful. Instead of Tripit’s current copy we might say “No need to sign up, simply forward your emails to plans@tripit.com and we’ll get you started immediately” or something similar. This would make it absolutely clear that the sign up process isn’t required to get started with the service.

Since I took the above screenshot, which was at least 3 months ago (when I first started putting together screenshots for the talk) Tripit has made a change to the homepage. I didn’t realize it until I went back to the site the morning after the talk to follow up on our discussion. Instead of the “Learn More” button being what gets your attention, Tripit has changed it to the very explicit “Sign Up”. Here is what it looks like:

Obviously this is a stronger call to action. It is entirely clear that Tripit wants you to sign up. However, when you click on that sign up button, you’re presented with this form:

This form surely doesn’t have the smoothness of the email option. It directs ones attention to a form instead of a clever way to sign up. If you weren’t sure about the email option before (as Jeff wasn’t), then you surely would be led to believe that you must sign up for the service given that the call to action is so strong. It’s darn near impossible to ignore that huge orange button.

But I wonder: does accentuating the sign up option diminish a great selling/talking point of the service? I say this because several people have mentioned the cool email option feature to me as they tell me about their use of the service. In other words, in explaining how the service works the ease of starting off automatically comes up…as they are one in the same. To use the service you just start using is…it’s brilliant in its simplicity.

So here’s the question: is Tripit hurting themselves (in some small way) by placing more weight on the sign-up call to action instead of the email option? Or is the stronger sign-up call to action more appropriate?

Oh by the way, I’ll be showing many more examples of good and bad sign-ups in a virtual seminar on Designing for Sign-up next week with the fine folks from UIE.

The Tyranny of Context.

Are we hypocrites when it comes to technology? Or are we merely suffering from the tyranny of context?

My wife and I are currently staying at an amazing farmhouse built in 1745 along the Merrimac River. Our lovely hosts, Windy and Brent, are caretakers of the house and estate and are what you might call a progressive farming family, sticking to a mostly agrarian lifestyle in the technological swirl of the 21st century. In the same day they pickle hundreds of cucumbers they’ll watch a Winnie-the-Pooh YouTube video with their 1 year old. They combine the past and the future as well as anyone.

Yesterday during lunch we got into a conversation about technology, with Windy taking the stance that technology is breaking us away from face-to-face conversation and to that end is not a good thing. She summarized her view by saying she would rather “sit down and drink tea than to text message”.

I reluctantly agreed, but felt compelled to point out that technology isn’t used as a replacement so much as augmentation…we communicate with who we would normally communicate but we do it more often, in more places, and perhaps at the expense of quality alone time.

And thus the argument was set. Either you view technology like cellphones and Twitter as a distraction from quality time or you view it as a helpful add on.

Our argument continued with each of us digging deeper into our trench, if only for the fun of conversation. I mentioned the recent MacArthur foundation study suggesting that teens are learning social interaction skills even while embroiled in new technology: New Study Shows Time Spent Online Important for Teen Development.

My combatant wasn’t buying any of that, and at one point Windy said “I don’t mean to insult you, I know you make a living from technology”. But I didn’t have time to respond (as I was running out the door) and thus our argument ended in a stalemate: each of us unable to sway the other in the time we had.

But in that moment I realized that it is these technologies, blogging, twitter, and cellphones that make it entirely possible for me to have more face-time with the people I want to see most: my wife and kid. If I had to commute every day to an office that wasn’t in my house, I would get hours less time with my 2 year old.

But a funny thing happened later on as I reflected on our discussion. I knew that Windy wasn’t a Luddite, knowing she regularly emails other local mothers (including my wife) about getting together, what products are safe, etc. I knew she used technology, watched YouTube, but I hadn’t been able tie it into our conversation because of the dichotomy we had set up.

So the next time I saw her I asked (knowing she’s a knitter) if she knew of a site called Ravelry.com, which bills itself as a “knit and crochet community”. She said, “Yes, in fact I recently signed up to get into their site, but I haven’t got in yet”. Ravelry is still in beta, and they have a waiting list to get in. The current wait, according to the web site, is 4 days.

So it appears that Windy, while arguing that all this technology is distracting, uses it herself all the time. And I, while arguing for the merits of the technology, actually use it to gain more face time. In this way it would be easy to see each of us as living opposite of the way we argued.

What I learned from this discussion is two-fold. First, we let the dichotomy of the discussion overrule our values. We both value face-time, yet we both use technology to help us in our lives. She uses Ravelry, YouTube, and email, but doesn’t think about it in the same way as we imagine teenagers using technology. We assume that when teenagers are texting, emailing, and video sharing that they’re fooling around, wasting time, and losing out on valuable face-time.

Similarly, I use technology to gain more face-time with the people I love. I’ve even held a client phone call from Martha’s Vineyard when I was there on vacation, and I have to say that it’s not that bad. If you can take 15 minutes to make a client happy while on vacation and then immediately return to that vacation, well it sure beats staying in the office for a single phone call.

Anyway, I think this all comes down to what I’m going to call The Tyranny of Context. When we’re in the context of our lives, using technology to augment our daily activities, we don’t think about it as technology, per se. We see it as a tool to help us do fun things. But when we sit back and look at technology from afar, away from the details of context, well we often have a less positive view of it. This is precisely how the very same person who says that people watch way too much TV are then absolutely captivated when they can see the beads of sweat on Kevin Youkilis’ face when viewing a Red Sox game in HD. (that would be me)

And I think this is why context is so hard to design for. We often don’t know why other people find technology valuable…they’re using it in countless ways within their own life. To the causal outsider it looks like they’re just wasting time, but to them it’s merely what they do. To us its merely what we do.

And for those of you who have read this far, MMORPG pioneer Randy Farmer has a great slide deck called Context Is King: Lessons from Online Communities, shown below. His talk begins to formalize some ideas around designing for context, and its a good introduction to what surely will be a very deep iceburg.

View SlideShare presentation or Upload your own. (tags: communities incentive)

Upcoming Speaking Events.

Just a quick update on the various speaking events I’ve got coming up.

• UIE Virtual Seminar: Designing for Sign Up
  This thursday, December 9, I’ll be giving a UIE Virtual Seminar on Designing for Sign Up. This presentation is for folks struggling with getting people signed up for their product/service. I’ll go over some of the psychological reasons why sign up is so hard, while showing a boatload of examples of how designers have overcome those hurdles. Use the promotion code BOKARDO to get a discount: $99.00 for the seminar as well as lifetime archive to watch it again and again. (Or, perhaps closer to reality, to show to others who may want to see it)
• Webstock ‘09
  In February, I’ll be heading down to New Zealand for Webstock, the Woodstock for the Web Set. I’ll be giving a full-day workshop on social design as well as a short talk. I’m completely honored to be speaking alongside this cast of characters…a bunch of my web heroes. I’ve never been to New Zealand before, and I’m really excited to go, so please let me know what I *must do* while I’m there.
• SXSW Interactive
  In March I’ll be giving a talk about Designing for the Social Web at SXSW, the annual convergence of all things Web in Austin, Tx. I hope to see you there!
• UIE Web App Summit
  In April I’ll be heading to Newport Beach, California to the UIE Web App Summit. I’m thrilled to speak at this event which I helped put together a few years ago. I’m giving a short talk on Designing for First-time Use, but I’m really anxious to attend the full-day seminars. As usual, it will be hard to choose from this lineup.

Want me to talk to your group?

In the last year or so I’ve put together several talks as well as in-depth workshop material on designing for the social web. The early feedback has been very positive, so I’ve decided to offer them as official services for web teams and design groups. I’ll be posting much more about this in the coming days, but for now I can tell you that the content goes way beyond my book (and I even usually add to it every day). If you’re interested in having me speak with your team or group, get in touch.

Why the larger text?.

Several folks have noticed I’m using a larger font size on bokardo now…here’s why.

In short, the text is easier to read now. Not just the body text, but the text in all columns. The inspiration for this change came from an image in the blog post relative readability by Wilson Miner, who explained his reasoning for larger text by holding up a page of 12pt text next to a screen with 16pt text, and they were the same size. That’s a great visual…nothing more need be said.

What Malcolm Gladwell’s book Outliers can teach us about interface design.

I recently finished Outliers: The Story of Success, the latest book by Malcolm Gladwell. More than any other writer, Gladwell can take any topic, even the most dry and boring, and turn it into compelling reading. Each time I receive a New Yorker magazine and see Gladwell’s byline inside, I immediately read whatever he wrote and end up enjoying it.

The entire Outliers book is good, but Chapter 7: The Ethnic History of Plane Crashes, is amazing. It’s worth the price of the book just to see how Gladwell stitches this chapter together. In it Gladwell tells the story of several plane crashes and uses the last radio conversations between the pilots and the control tower to paint an incredible picture of how they happen.

Here is the part of the transcript of Flight 052, a Colombian jet that crashed in January 1990:

(Captain): The runway, where is it? I don’t see it. I don’t see it.

ten seconds pass

(First Officer) We don’t have fuel…

seventeen seconds pass

(Captain): I don’t know what happened with the runway. I didn’t see it.

(First Officer): I didn’t see it.

Air Traffic Control [ ATC ] comes in and tells them to make a left turn.

(Captain): Tell them we are in an emergency!

(First Officer) [ to ATC ]: That’s right to one-eight-zero on the heading and, ah, we’ll try once again. We’re running out of fuel.

Gladwell points out several heart-breaking details of this exchange. First, the phrase “running out of fuel” means nothing to air traffic controllers as all planes are running out of fuel when they land. Planes are only given enough fuel to make it to their destination plus a little farther. So running out of fuel is in the plan. Second, ATCs are taught to respond to the word Emergency, and the First Officer never uses that word in his dialogue. The Captain uses it when he tells the First Officer to tell ATC that they’re in an emergency, but the First Officer fails to repeat it. Third, the way the First Officer spoke was completely non-chalant. He responded to the ATC as if everything was fine, acknowledging the change in route, and only added as an after-the-fact that they were running out of fuel (which didn’t mean anything). Those three things, taken together, makes one sick to their stomach. It would have been so easy to remedy this situation, but something stopped the First Officer from doing so and they ended up crashing.

Gladwell makes the case that what stopped the First Officer, in part, was his cultural heritage. The First Officer was Colombian, and in Colombia people are (in general) more respectful of authority than in other parts of the world. So whatever the control tower says, goes. But if the pilot were American or from some other country where people generally treat each other as equals, Gladwell argues, the conversation would have been different. If the plane were going to run out of fuel and crash, an American pilot would simply tell ATC something like: “We have an Emergency. You need to bring us in NOW. If you don’t we’re going to crash”. They would know that it’s more than OK to breach whatever social norms exist if your plane is going down. But in the case, being Colombian, the First Officer could only accept the delayed landing instructions he was given.

Whether or not you agree with the argument Gladwell makes about why the First Officer failed to communicate clearly is one thing. But, given the evidence we have of this conversation, there’s no denying that the First Officer failed to communicate his situation clearly. This is a story, afterall, of context. The First Officer failed to convey the dire situation they were in and thus ATC did not know to react accordingly and land them immediately.

Design Implications

This story, though extraordinary, can teach us very clear lessons about how to communicate in general and through design in particular. When we design sign-up pages, for example, we are in a similar situation as the First Officer is when talking to ATC. We’re dealing with people we probably don’t know, and likely haven’t talked to before, and we’re not talking face-to-face. We can’t see their body language, which by some estimates is 90% of communication. But designers have it worse than the pilots. Where the pilots can actually talk to ATC, using their voice to embellish the words they use, interface designers only have the words and visuals on the screen. There is no chance to react in back-and-forth understanding like there is in a vocal conversation.

So, here, are some points that we can learn from the Flight 052 situation we can directly apply to interface design.

1. First, you have to say the obvious!

The pilots know that their plane is going down. This is obvious to them, as they are intimately aware that they have almost no fuel left. But ATC has no idea, it is definitely not obvious to them. But for some reason the First Officer thinks that by suggesting they’re running out of fuel, the need to land immediately will become obvious. But that’s not the way obvious works…obvious does not work by indirection.

In a similar way, interface designers know all sorts of things about what they’re doing. They know what they’re trying to communicate, they know why their content is the best, they know why their product/service is awesome. Many of those things seem obvious to them, and some designers (myself included) will invariably think that others would find them obvious as well. But in the same way that merely saying the obvious would have changed the fate of Flight 052, we have to make sure that our interfaces are saying the obvious at every step. Saying the obvious gets everyone on the same page, it equalizes expectations.

In some cases, people assume things are obvious to an amazing degree. I’ve actually sat in on an interface design meeting in which a designer rightly suggests some completely obvious text, and someone else says “I don’t think we need that text…it’s completely obvious. Let’s put something else there instead.” But being obvious is exactly the point in most interface design! If everything were obvious, then people would be able to use interfaces without any trouble at all. Isn’t that what we’re shooting for? Until our conversion rate is 100% we should probably shy away from assuming anything is obvious…

2. You have to use the right terminology

One word would have completely changed this situation. If the First Officer had simply said the word emergency, and the ATC heard it, the ATC would have reacted completely differently. They are trained to respond to the word emergency. For some reason the Captain seemed to know this but the First Officer didn’t take advantage of it.

Words are crucial in interface design as well. For example, while many people don’t want “Help”, they’ll take “hints” instead. Help implies a need, a weakness, and so people often avoid the built-in help systems in software. “Hints”, or “tips”, on the other hand, implies a bit of a push, a lot like help, but it doesn’t sound as weak. Thus, the word “hints” often gets more interest in interfaces than “help”.

I find stuff like this all the time when I do interface evaluations (an interface evaluation is a service I offer in which I evaluate and give recommendations for improving interfaces). One of the first things I do in an evaluation is to read all of the copy on the web site. I jot down all of the inconsistencies I find, where a different term is used in different places. For example, the terms for sign-up are often different. You’ll see “sign-up”, “login”, “registration”, “join us”, “start now”, and a whole host of other things, all on the same site! While these differences seem trivial, they are not to someone who is trying to do the most basic of learning. It can be like the site is saying “we’re running out of fuel” when it should be saying “Emergency”!

3. You have to be clear about what you want

The First Officer never tells ATC that they need to land immediately. He seems to assume that ATC will figure this out from the phrase “we’re running out of fuel”. But as Gladwell points out, in this context that doesn’t mean anything special. If the First Officer had said what he wanted, that would have completely changed the conversation away from the routine and to something necessary for what was happening.

In the same way our calls to action in our interfaces need to communicate what we want. In general, every interface needs to communicate 3 things to users: where they are, where they’re going, and how to get there. Here is an example from Netflix, which I’ve annotated, that does this very well.

Again, this isn’t a mysterious process. All it takes is an attention to detail.

4. You have to order information correctly, with the right emphasis.

The First Officer tells ATC that they’re running out of fuel at the end of a sentence. This is the wrong emphasis and at the wrong time. Never mind that what he said didn’t mean anything…imagine if instead of attaching it after the fact he had screamed “WE’RE RUNNING OUT OF FUEL!” right at the start. That may have gotten ATC’s attention, not because it meant anything but because of the emphasis (the yelling) and the timing (at the beginning). At that point the conversation may have changed course.

In interface design order and emphasis manifests itself as visual hierarchy. Visual hierarchy is the order in which people view (and read) on a screen. If an interface designer were designing a screen to represent how this conversation should have gone, they might place the copy “EMERGENCY. WE NEED TO LAND THE PLANE NOW!” at the top of the screen in huge, red letters. That would give it the appropriate emphasis: no reader could view the screen without getting the point that something dire is going on.

When designed correctly, a design coaxes users to view the same information in the same order, with appropriate emphasis. When it successfully does this it can be said that there is a strong visual hierarchy. When it doesn’t do this the interface can be said to have a weak visual hierarchy. In most applications a strong visual hierarchy is desirable.

Most Design, like a chat with ATC, is about Clear, Obvious Communication

As most designers know, design is about communication. And getting that communication as clear and straight-forward as possible is one of our primary goals. As we can see with Flight 052, even in the most serious, agreed-upon situations communication can break down. So returning to the basics can be a good way to make sure we’re communicating exactly what we need to.

Thoughts on the Friendfeed interface.

Some modest suggestions for improving the Friendfeed interface

Friendfeed is getting a lot of chatter in the blogosphere about what they should do with their service. I’m sure I don’t know the bigger issues that Friendfeed are dealing with, but I do have some observations about the interface, which I’ve summarized below.

But first, a little rationale about how I got to these suggestions. We must start with the simple question: What is the core mechanic of Friendfeed? What is the one thing that Friendfeed does that makes it a valuable service? I would argue that it’s reading the feeds of friends in order to discover valuable content.

The first thing you’ll notice when you set up an account, however, is that Friendfeed is a fire-hose of content. Like other streams, it produces way too much content to keep track of comprehensively. To that end, one of Friendfeed’s primary goals has to be the efficient management of the fire-hose. The service can do this in two ways: by providing powerful search and filtering features to reduce/organize the content one sees or by making the interaction with each piece of content more efficient.

Friendfeed seems to have a good handle on the first way, providing powerful search features and filters in the form of lists, rooms, ways to hide content, etc. I’m sure there are other good ways to push forward here, like a better notion of “quality” or recommendations or something similar. But the features Friendfeed has now are pretty good at letting people filter and organize content.

I think Friendfeed could focus more on the 2nd way of dealing with the fire-hose: make the interaction with each piece of content more efficient. The core problem with the Friendfeed interface, to that end, is that it is not easily scannable. By making the interface more easily scannable, the value of the entire application would increase.

Here’s a screenshot I’ve annotated illustrating how Friendfeed might make their interface more scannable:

(click for full-size)

Too few items per screen

There are, on average, 4 to 5 items displayed per screen. This means that you can only see 5 items before you have to scroll down the page. It could be a lot more, like up near 15, if not 20 or more. Gmail, for example, which uses a mere 20 pixels of vertical screen height per item, can fit 25 items in the same amount of space. This allows for much faster scanning. (obviously the Friendfeed guys know this, as Paul designed Gmail, so I’m really curious about their design decision here)

Secondary information clogs up each item

The reason that there are too few items per screen is that Friendfeed uses a tremendous amount of vertical space to show items of secondary importance, including Likes, Comments, and the time the entry was posted. These items should be available, of course, but they needn’t take up so much room.

Now, it’s probable that Friendfeed keeps these comments inline because they are trying to bring conversation to the forefront. This makes sense. As you show more conversation, you get more conversation. But there are also ways to show there is a conversation without showing the actual comments…like for example displaying “5 comments” near an entry and allowing people to view the comments if they so choose.

Difficult to scan content titles quickly

As you can see from the screenshot, the element with the most visual weight in the Friendfeed interface are the names of people where the content originates. But is this the most important part of that content? I think that the title of the content is the most important part, and thus that should have the most visual weight, and thus be the most scannable. The person who submitted it is important, but secondary in my opinion, especially because these people are already in our good graces (we’ve subscribed to them).

People who aren’t my friends

By default, Friendfeed displays a whole bunch of content from people who are “friends of friends”. This content isn’t from people who you have chosen to receive content from, but from the people your friends have chosen to see content from. This is one of my long-standing frustrations with the interface. I have a hard enough time trying to make sense of the fire-hose of just my friends. Including more people that I don’t ask for is just too much.

So, in a word I think it’s all about scannability. I’m not suggesting that Friendfeed remove any of these features, but in the current design I just see too many distracting bits of information. Since Friendfeed opens up a veritable fire-hose of content, the interface needs to make the interaction with each bit of content as efficient as possible.

Why I like 37signals Design Decision Posts.

I really like the design decisions blog posts at 37signals. A recent example: Design Decisions: Saying more in less space on the new Highrise site, in which a designer (in this case Jason) discusses how he made changes to a certain design. He shows the initial design, lays out the rationale for change, and then shows the changes. The structure of the post couldn’t be more simple.

But the reason why I like the posts isn’t because of the content (although it’s good). I really like the posts because they do it and nobody else does.

Now think about this. 37signals is a well-known company in web design circles and have a solid reputation as designers, and they’re releasing a beta design on their site, talking about its shortcomings on their blog. They’re designing in public. They have no need to do this. They’re risking their reputation here. Can you imagine if their design is less than perfect? Imagine what people will say? Holy cannoli…people might actually find something not-so-good about what they made.

In fact, it’s happening already. Just read down through the comments…many folks give their honest feedback about what’s wrong with the site. And you know what? In some cases the commenters are right. For example, several people are complaining that the headers in the page are getting squeezed by the content around them. I agree…I can feel myself not wanting to read them.

But those are minor details and will be taken care of eventually. Look at the overall outcome. The page will be better, and that’s the only thing that matters. If the goal was to protect the ego of the designers, they wouldn’t do this. If, on the other hand, your goal is to get the best design possible this is one way to get closer.

If you sweat design, if you want the best design you can possibly get, you want feedback all the time. You want criticism. You want people to push you to make things better. It’s a hard pill to swallow. But even the most attentive designers miss things.

So while the vast majority of designers sit back and hope their designs are solid, deciding not to talk about them, those who put themselves on the line publicly will end up with the best design. Sure, they take a hit on their ego…but that will always be reparable later when the design is bringing in the love.

It also shows that the team cares about the experience of their customers. If it’s apparent that they sweat the details of things like the number of pixels in a specific screen element, that transmits a powerful message to their audience. We care. We’re working on it all the time. You’re in safe hands. Etc.

It also is great publicity for their software. Having read 37signals for a long time, this is likely one goal of the posts, and I bet that these types of posts are among their most read. I know from my own experience that people love hearing about design rationale. My post Digg’s Design Dilemma, in which I look at how the design of the Digg site actually promoted gaming, remains a well-read post even though I wrote it two and a half years ago. And when I give talks people really like slides like this: How Social is Amazon?.

I also like the design decisions blog posts because they are perfectly aligned within a larger strategy…37signals is working at several levels to make their product better, show users they care, and grow publicity for their offering.

So, I wish more designers did this. I wish I knew what more designers thought. I wish designers would explain their rationale more often. I’m positive that 37signals takes a much different approach than many other designers. I know lots of folks who would design these pages in a completely different way. But you know what? Most aren’t talking about it on their blog, sharing their process, or going through this public ritual.

I think that design education in general needs to be more public. Design shouldn’t be mysterious! It should be everywhere, part of the culture, part of daily life. Kids should be designing in school. Design should be part of the curriculum. We should be soaked in it.

Who doesn’t like hearing about how things were made for them?