How can designers pinpoint areas of their social application that aren’t working?

Well, first there needs to be agreement on what “working” means. There are lots of ways something can fail to work…but usually it means that the site isn’t doing something that it’s supposed to. And ideally every design team has a list of their most important metrics…those things that really matter to the success of their product/service. I’ve found that without a clear picture of which metrics are important, design teams tend to lose focus over time and fail to continually iterate and improve.

Designers have relied on metrics since the beginning of the web. We first started with metrics such as hit counters that measured the number of hits to the web server. Unfortunately, the hits were typically meaningless because they included hits to pretty much anything, including images, JavaScript, and other files, failing to provide any real insight into what was happening. As time has gone on, however, the metrics we examine have become much more sophisticated.

The latest focus for many design teams is to understand ways to measure user engagement. These metrics include the number of return visits and the average time on site for visitors. These metrics have important implications for your business.

For example, Google wants people to spend as little time as possible each time they interact with their search engine. They want people to come to the site, find what they want, and leave. On the other hand, Facebook wants people to spend more time on their site, so they can gather more data about visitors and expose them to more ads. The time on site success metric is radically different based on the specific site’s business goals.

When building an application, it’s essential for design teams to identify 3-4 core metrics to assess the success of the application and the health of the business. If these metrics go up, it’s a sign your business is healthy.

If you just build interactions without respect to core metrics, you can get into a situation where people use your web site — but not in the way you intended. This is why free applications that were once all the rage are now being downgraded to free trials. Design teams found that so many people were using the applications without paying and it was a huge drain on a business.

In your book, Designing for the Social Web, you recommend that design teams take advantage of the funnel analysis to uncover areas of their social application that aren’t working well. How does this analysis work?

It’s really important to have solid metrics at each stage of the lifecycle to uncover where a site or application has an opportunity to improve. A funnel analysis is a good way to find out what’s broken. It can show you how well your site moves people along the stages of the lifecycle, from Interested to Passionate.

Designers can picture their site as a funnel, where at the top they have everyone who is interested in the application and at the bottom is everyone who is passionate about the software.

For example, of those people who are initially interested in your application, only a subset of them will decide to ever actually use your application for the first time. Of the people who use the application for the first time, only some will use the application regularly. Of those regular users, only a small percentage of visitors will become passionate users. By examining where users drop off in the funnel, you can pinpoint opportunities for improvement on your web site.

However, if you’ve ever done funnel analysis you know that people do all sorts of things besides progress step-by-step through a series of screens. They visit multiple times, they skip around, they email you, they do all sorts of multi-channel communication, etc. This makes it more difficult to determine what’s wrong with your funnel.

As an aside, this is why we’ve built what we’ve built at Performable, which is an events-based analytics tool. Events-based means that the tools analyzes all actions of users, not just the ones that happen in a pre-specified 4-step funnel. This is necessary to truly capture the rich experience that your users are having over time.

Have you found that social applications are evolving over time?

Social applications have definitely been evolving. Over the last few years, I’ve seen that people have really embraced these applications. Users are now used to the concept of social applications. Three years ago, people had no idea what a News Feed was. Now everyone knows what it is.

I’ve seen a lot of changes. For example, many applications are now focusing on location. Location applications, such as Foursquare and Gowalla, are doing some really interesting things. These apps are essentially erasing the difference between being online and offline.

All of the social applications are also going mobile. People are using them everywhere. With devices like the iPad taking off, those trends are only going to accelerate. It’s insane how fast mobile is growing.

So those two trends, social and mobile, have accelerated everything.

MySpace was one of the first really popular social web sites, but has since become less relevant. What happened?

A couple of things happened. MySpace was the first national social network that caught the attention of everyone. We’d hear about it on the news and people started talking about privacy. MySpace really brought social networks to the general public and millions of people were using it.

Then Facebook came along and the momentum shifted. It’s difficult to pinpoint the exact reason for the shift, but I think engineering was Facebook’s big win. From an engineering standpoint, Facebook executes extremely well. They roll out changes quickly and the site always seems to work. Facebook’s uptime was excellent, whereas MySpace had a lot of problems.

From a design perspective, Facebook has always been much cleaner and much more consistent than MySpace.

From a social design perspective, it could be argued that MySpace’s themed pages was a good idea because it was offering users a unique identity. Why do you think this approach failed?

While users on MySpace were allowed to theme their pages, I believe this actually hurt the usability of the application’s design because it allowed people to make very difficult to read (and use) pages. Even though it allowed MySpace users to express themselves how they wanted, it wasn’t the best choice for the readers of those profiles.

So yes, theming a profile is important for identity. And I think on some level, this was an important feature for MySpace, at least early on, because people liked to be able to change their profile to reflect their personality. But the ability to personalize MySpace was trumped b/c Facebook rose to prominence and had more momentum…personalization is interesting but unimportant when compared to where your friends are. (And, it should be pointed out that MySpace is still gigantic and has not really failed but rather become the 2nd biggest social network.)

So, why did Facebook rise to prominence? I think the big reason is that they recognized what was most important to people and then out-engineered MySpace in building their platform.

For example, in 2007, Facebook implemented the News Feed, an activity stream. If I had to point to a single feature this would be it (or perhaps photos…) The designers at Facebook realized people were coming for their friend’s content, such as links, messages, and photos and that a stream was a much better way to display these things because it ordered things by time. While MySpace gave users the ability to statically change the background and text of their profiles, there was less sense of immediacy when people made updates. Viewers still had to go and find what was updated on their friends pages. The Facebook News Feed made these changes front and center, and set a new bar in engagement. Thus the themes in MySpace were trumped by Facebook’s realization that content sharing and status updates were much more important to users than profile personalization.

But other social networks are growing. Twitter is adding photos now and this will take them to the next level. And I think in the future more social applications will focus on specialized features for specific activity groups. For example, Dribbble is a social network where designers share what they’re working on. You have services like PatientsLikeMe, which is a social network for people living with diseases, and Ravelry, a social network for folks who knit and crochet. These services have people who are as passionate about some specific activity and are extremely active within that world (maybe moreso than on the big networks), these networks just happen to be smaller populations so they aren’t in the news everyday.

Christine: In the first edition of your book, Designing for the Social Web, you emphasized that teams need to rethink their design approach and focus more on the Usage Lifecycle. How is this a shift in thinking for most design teams?

Me: The Usage Lifecycle is the lifecycle of the people who use your application, service, or product. Typically, when teams approach their design, they often end up looking at a homogenous set of users. However, when we look at users from the Usage Lifecycle standpoint, each user becomes different immediately because each person is at a different stage of their lifecycle.

There are five main stages that users traverse through with web sites and applications: 1) Unaware, 2) Interested, 3) First-time User, 4) Customer, and 5) Passionate Customer. Design decisions are best made when designers know what lifecycle stage someone is in and what they’re trying to do at that moment. It’s a very simple idea, but it changes the entire approach to design.

When design teams focus on the Usage Lifecycle, they take an approach similar to what a great salesperson would do. When a salesperson approaches a customer, they first find out where the person is in the sales process and what their ultimate goal is. When you think about your application as something someone is using or purchasing, it’s very similar to a sales cycle.

At each stage of the Usage Lifecycle, users have very different needs and questions. Can you talk about these differences?

When most people first come to your application, they are unaware of what you have to offer them. It isn’t so much a stage, as a starting point. Most people are in this stage: completely unaware of your product.

Each of the stages are separated by hurdles. The hurdle between the “Unaware” stage and the “Interested” stage is “Awareness”. When people are in the Interested stage, they have a unique set of questions. For example, they ask: How does this product relate to what I’m currently using? Will this product or service fit my needs? How does it compare with other products and services on the market?

Most startups need to focus on solving the challenges in the Interested Stage. The problems they need to iron out are Awareness problems. Startups must help users learn about the application, gain confidence, and get users started most effectively. In this stage, I recommend that teams focus on messaging and emphasize the value proposition of the application.

Typically, once users start interacting with the application, most of these initial concerns disappear and now they are Users of the application. As Regular Users, their concerns are now completely different. They are using the product to accomplish a task and fulfill their end goals. When they use the application, they have a different mindset. At this stage, teams need to focus on helping users accomplish their goals and move beyond just making people aware of the product’s features and benefits.

For me, this level of distinction is incredibly valuable. I’m more and more convinced this is where to focus: where users are in their lifecycle and environment. If you can understand this about people, you can help users more effectively.

(Here’s a full summary I’ve written on the Usage Lifecycle.)

What are the best practices you recommend design teams use to first start getting users engaged in a product?

There are a lot of small and effective strategies design teams can use. If your team knows ahead of time when you’ll be launching, I recommend having a beta phase or set up an invitation list to tell people about what you’re doing.

For example, at Performable, we asked prospects to give us their email address to contact them when we launched. When we offered this option, thousands of people signed up. This is a simple thing, but a lot of startups don’t do it.

Another great tactic is message testing. With message testing, teams design two or more home pages (or landing pages) for their application and see what message resonates better with visitors. Once traffic starts arriving at the page, you can easily quickly see which message variations convert the best. Conversion can be different things depending on your business goals, such as users giving you email, signing up for a beta, or signing up for the product.

This technique helps companies find out whether their value proposition is being communicated effectively with visitors. In almost all cases it can be strengthened. In some cases the initial message is the wrong one, such as focusing on a benefit that just doesn’t resonate with the target audience. There is a lot of action in the testing space right now and I’m excited to be a part of it.

A common problem with many applications is that people sign up and then never consistently use it. How can designers combat this problem?

?Yes, I see this happen all the time. I call this phenomenon the “Getting Started” problem. This is when people sign up or register for your application and then don’t know what to do next.

To solve this problem, I often recommend that clients pre-populate the initial application page with content. For example, if you have an application that allows people to make a widget, it’s very powerful tactic to pre-populate with a widget already made. People are far more engaged when they get to see how the application works instead of starting with a blank canvas.

?With the Usage Lifecycle, most of the solutions are relatively small solutions, but taken together, it really adds to a positive experience if you’ve gotten each step right. With your application, you can’t just have one cool thing happen with your product. It’s the sum total of interactions that make up a successful user experience.

How can design teams create passionate fans of their product?

This is a question I often get from marketing teams. They will often try and add social features to create passionate users. They’ll say, “Let’s offer more sharing buttons or more opportunities to share.” However, while putting a social feature in the interface may result in users completing the interaction more frequently, that’s not the right way to create passionate users.

The best approach is to make users good at something. For example, imagine you are tasked with designing an email marketing software, such as Mail Chimp, Emma, Constant Contact, or Campaign Monitor. The best way to get users passionate about these types of applications is to make them better at their jobs as email marketers.

This really has to do with focusing on the experience users have when they interact with your product and working on getting users good at what the application does. The best design teams focus on a single activity set and ensure that the product successfully supports these activities and makes them simple to do. Once people are good at using the product, they’ll talk about it and share with others. This will also be more authentic. Campaign Monitor is a great example of a relatively small team doing great things by teaching their users how to be better email marketers.

So, the best teams move beyond just thinking about what social features to add to their product. In your writings, you’ve said it’s really more about the personal value of what people are doing. How did you first come to that realization?

Many years ago, I had a conversation with a designer who was building an application for runners. At the time, tagging and folksonomies were the trend and I was really excited about the topic.
?
The running application enabled users to enter their running time. I’m not much of a runner myself but I was really excited by the social opportunities around sharing running data and the competition it would engender. Knowing that many people thrive on competing with others, I thought there was huge potential there.

But the designer of the app was adamant that I was missing the forest for the trees. He wasn’t all that excited about the social possibilities. While the application would let users share their running time online with others, social influence isn’t the real motivation for serious runners. The people in that market valued their own improvement much more than seeing what others were up to. While sharing was a nice side effect, the most important thing to runners was to see if they were faster than the day before.

This was an eye opener for me, as I suddenly saw this same mistake applied over and over in social software projects. For users, personal value comes first, it precedes social value almost all the time. I call this the Del.icio.us Lesson, named after the popular bookmarking site. With Del.icio.us, people were tagging articles and sharing with groups and there was a tremendous focus on the social aspect of it all. But most people didn’t use Delicious to share stuff with others. They primarily used it for bookmarking stuff for themselves so they could read later.

I try to keep this in mind. If you focus on giving users personal value first, then and only then will people start sharing that value with others.

(Read more about my thoughts on the Del.icio.us Lesson.)

Updated: Read Part 2.

Also, discount code! Use the code bokardo to get 10% of the registration price.

Designing for Social: 3 Core Principles

My talk is going to be about three core principles of social design, the ones that really matter whether you’re building a social network or considering “adding social” to your current product/service. These principles are not nice-to-haves or simply ideas to get philosophical about…they affect every design decision you make from what features to have to how to lay out a page. I’ve got lists of hundreds of principles, psychological angles, game mechanics, you-name-it, but these three stand out…they are the ones that keep coming back.

If you’ve read my stuff at all you know that one of these is The Delicious Lesson, on which I dashed off a quick post on years ago but then grew a life of its own and has continually come up on nearly every project I’ve worked on. (it’s still the most popular article on bokardo.com four years later). It’s really taken on a life of its own…I’ve actually been introduced as the guy who came up with the Delicious Lesson! (I’m not kidding). It’s odd to be sure…but that signals to me that the principle really helps people think about and design social software. So, I’m going to tell the story of that lesson and show how it applies to some newer software as well as talk about two other principles that are just as important. So I’m excited about the talk, to say the least.

I’m also excited about the conference because I think it is the right topic at the right time: an awesome intersection of designers and businesses…which is exactly what both need right now. Businesses are realizing that Design is a major differentiator while designers are realizing the power of the work they do, but also the need to quantify and pay attention to metrics.

The conference is presented by 500 Startups, the brainchild of Dave McClure who is spear-heading the idea of design as a differentiator. I’ve been a fan of Dave’s for a long time…check out his talk on metrics for startups and you’ll see why. Incidentally, Dave’s work around metrics dovetails very nicely with my work around the Usage Lifecycle.

The speaker list is ridiculous…I’m extremely honored to be speaking with these folks. In particular, I’m excited to hear what Irene Au from Google and Kate Aronowitz from Facebook are going to talk about…given that they’re in very senior design! positions at two of the strongest companies in the world right now, both working hard on social and both competing in various ways.

Anyway, remember the discount code (bokardo) and I hope to see you at the conference!

The workshop is for designers, design managers, product folks, and other people responsible for web sites who are struggling with creating a great user experience.

The workshop will cover, among other things:

• How to design for the psychology of sign-up. You will learn four design strategies for improving your sign-up process right away.
• How to get users immediately engaged in your product. You’ll see how successful social sites get users engaged early on in the lifecyle.
• How to create seamless sign-up sequences. You’ll see how techniques, such as explaining your product’s benefits and showing how your product works, can make dramatic improvements to your user conversion rates.
• How to write online copy that motivates users to act. You will see how copywriting is the easiest and fastest way to improve your sign-up process.
• How to take advantage of the psychological principles to persuade users to convert. I will share several psychological principles, including the principles ofSocial Influence and Reciprocity, to effectively motivate and engage users.
• How to design for ongoing participation by users. You will see how users are more willing to continue to use your product if you reduce the amount of commitment on their part.
• How to measure how well your site or application is converting first-time visitors to loyal customers. The funnel analysis is an effective method to show how effectively your site is moving people along the usage lifecycle.

This is a full-day, immersive workshop for design professionals. (btw: If you sign up by September 10th the workshop is only $695 – a savings of $200 off the final registration price.)

For full event details: Designing for the Social Web Workshop

Although the idea of the usage lifecycle came from my book: Designing for the Social Web, most of the content in the workshop is new, coming from consulting work I did after I wrote the book as well as a lot of the work we’re doing at Performable. We’re learning a ton of stuff building a tool to help others improve their customer experience, and I’ll share some of what we’ve learned during the workshop. Here is an example of the type of stuff we’re learning: Why A/B Testing isn’t just about Small Changes

I’ve given several versions of this workshop already at private companies and at conferences (like UX London). I’m very happy with it so far…the feedback has been extremely positive and I feel like it’s core content that companies can implement immediately.

The workshop is being organized and run by my good friend Christine Perfetti, who ran events at UIE for years and who is currently starting a solid set of events under her own brand PerfettiMedia. She’s already given two successful usability bootcamp events herself (in Boston and SanFran) and is planning more events in the upcoming months.

So I’m really looking forward to this…I get to come in and focus on giving the workshop and have all the hard details taken care of by Christine. If you’ve never run events yourself then you are missing a whole lot of behind-the-scenes planning and organization…I’m happy to have Christine do that for me. I think the workshop will be fun and we’ll learn a lot from each other.

So, October 25 we’ll be holding a workshop on creating great user experiences, integrating social features into your app, and the usage lifecycle. Sound good?

Please let me know if you have any questions!

Image by Paul Adams (screenshot hosted on Flickr)

“But the reality is, social networks rarely add to our number of connections. We’ve already met almost all the people we’re connected to on social networks. We’re already connected to these people offline. Social networks simply make the connections visible. For example, we often connect with old school friends, and catch up over a couple of wall posts. But rarely do we continue the conversation once we’ve connected, and over time we forget that the connections exist. In fact, Facebook users often have no interactions with up to 50% of their connections.1 When we study how people are interacting on social networks, we see that most interactions are with a very small subset of the people we’re connected to.

The average number of friends on Facebook is 130, and many users have many more. Yet despite having hundreds of friends, most people on Facebook only interact regularly with 4 to 7 people, and for 90% of Facebook users, 20% of their friends account for 70% of all interactions. We also see this with phone usage. We have hundreds of people in our phone contacts, yet 80% of phone calls are made to the same 4 people. We know dozens of people who use Skype, yet 80% of Skype calls are made to 2 people. Even when people play computer games online, they mostly play with people they know offline.”

This is important data, as it grounds the social interaction/UX designer in the reality that most people aren’t doing anything crazy online, they’re mostly cultivating and managing the relationships they had offline.

Paul then digs deep into what he calls temporary ties, those people we meet only quickly for some relatively important reason. I really like temporary ties as an extension of strong and weak ties because it suggests clear use cases to design for. When designing for those situations in which two people want to interact but have never met, you need a reputation framework and a way for people to provide feedback to each other. This helps people make a fast decision about whether or not to interact with their temporary tie.

Also check out Paul’s IASummit talk: Bridging the Gap between our online and offline lives

Curiosity is one of the most underrated phenomena in the world. It’s ironic that people aren’t more curious about curiosity. It’s a powerful thing.

For example, if you ever wondered if someone is attracted to you, the answer lies in curiosity. If someone asks personal questions about your past, your plans, your likes and dislikes, that is an unambiguous sign of attraction. If someone tries to steer you into the bedroom without some conspicuous data gathering, that is a sign of simple horniness.

The friend variety of attraction is milder than the lover type. You can be friends with someone for years without remembering the names of his or her siblings. But if you love someone, you automatically develop a voracious appetite for information about that person.

When someone you are not attracted to talks a lot about his or her own life, you get bored to death. When someone you are attracted to talks a lot, you might find that person to be full of life, and fascinating. Attraction and curiosity are inseparable.

via Scott Adams Blog: Curiosity.

As I sit looking at Tweetdeck this morning, looking over 40 avatars of people I know and don’t know, I wonder how much of my interaction is influenced by what a particular avatar looks like. Am I more willing to converse with someone who has a realistic avatar? A smiling avatar? Does the offbeat, non-human, text-based avatar inspire better communication or worse?

I have my hunches, and will write them up after I have done more research on the subject. In the meantime, here is some info on the origins of avatar.

From the Wikipedia entry for Avatar:

“An avatar (from the Sanskrit word for “a form of self”) is a computer user’s representation of himself/herself or alter ego, whether in the form of a three-dimensional model used in computer games, a two-dimensional icon (picture) used on Internet forums and other communities, or a text construct found on early systems such as MUDs. It is an object representing the embodiment of the user. The term “avatar” can also refer to the personality connected with the screen name, or handle, of an Internet user.”

One of the first references of avatars as digital representations was in the 1985 game Ultima IV: Quest of the Avatar. In this game the users goal was to become an avatar…it wasn’t until later versions that the user’s representation was called an avatar.

The first use of the term avatar in its current incarnation is possibly the work done at Lucasfilm Habitat Chronicles, created in 1986. Here is a nice piece in New York Times Magazine which digs into this a bit: On Language: Avatar. In this piece Aaron Britt interviews Randy Farmer, one of the creators of Habitat Chronicles, where the term was used to describe the online form of users. Says Randy:

“Chip (Morningstar) came up with the word avatar because back then, pre-Internet, you had to call a number with your telephone and then set it back into the cradle. You were reaching out into this game quite literally through a silver strand. The avatar was the incarnation of a deity, the player, in the online world. We liked the idea of the puppet master controlling his puppet, but instead of using strings, he was using a telephone line.

Here is a promotional video of Habitat which shows the avatars in action: Lucasfilm’s Habitat Promotional Video. Also check out The Lessons of Lucasfilm’s Habitat.

Another early exploration of avatars was in Neal Stephenson’s 1992 book Snow Crash. Here is a fascinating excerpt, in which Stephenson foresees a time when social norms build up around the fidelity of avatars, with sophistication being communicated in the rendering of realism:

“As Hiro approaches the Street, he sees two young couples, probably using their parents’ computers for a double date in the in the Metaverse, climbing down out of Port Zero, which is the local port of entry and monorail stop.

He is not seeing real people, of course. This is all a part of the moving illustration drawn by his computer according to specifications coming down the fiber-optic cable. The people are pieces of software called avatars. They are the audiovisual bodies that people use to communicate with each other in the Metaverse. Hiro’s avatar is now on the Street, too, and if the couples coming off the monorail look over in his direction, they can see him, just as he’s seeing them. They could strike up a conversation: Hiro in the U-Stor-It in L.A. and the four teenagers probably on a couch in a suburb of Chicago, each with their own laptop. But they probably won’t talk to each other, any more than they would in Reality. These are nice kids, and they don’t want to talk to a solitary crossbreed with a slick custom avatar who’s packing a couple of swords.

You can look any way you want it to, up to the limitations of your equipment. If you’re ugly, you can make your avatar beautiful. If you’ve just gotten out of bed, your avatar can be wearing beautiful clothes and professionally applied makeup. You can look like a gorilla or a dragon or a giant talking penis in the Metaverse. Spend five minutes walking down the Street and you will see all of these.

Hiro’s avatar just looks like Hiro, with the difference that no matter what Hiro is wearing in Reality, his avatar always wears a black leather kimono. Most hacker types don’t go in for garish avatars, because they know that it takes a lot more sophistication to render a realistic human face than a talking penis. Kind of the way people who really know clothing can appreciate the fine details that separate a cheap gray wool suit from an expensive hand-tailored gray wool suit.”

And, of course, the upcoming movie Avatar.

More on avatars:

How Important are Avatars?

If you sync seamlessly across devices, people will love you for it. It’s why I love the Apple ecosystem. I add a calendar event to my desktop, iPhone, or web app, and it automagically appears on the others. All of my mail is synced in all of these places so I never have to worry about missing email or knowing whether I replied or having to delete the same messages over again. The amount of time that this saves is invisible, yet invaluable.

Thanks to Flickr for hosting this pic

Yesterday during dinner with a few tech folks we hit on the topic of Dropbox, a file-syncing application that teams can use to collaborate. Dropbox is as simple as an app gets…simply install it, throw some files into your Dropbox folder, and it syncs to other computers or other people you want to share with. The reason people love it is that it just works, automagically. It simply syncs your files…that’s all it does. But it does it so well that people use the language of love to describe it.

Isn’t that a bit odd? Saying things like “I LOVE Dropbox!”? Well, in a world where we value any time savings like it were gold, seamless syncing becomes the gold standard. There is nothing worse than trying to figure out which copy of data is the latest, best, or primary copy. We know what we did last…if all of our devices knew then software would seem truly smart.

Today Robert Scoble tweeted about his love for the Kindle:

This is not ridiculously sophisticated functionality. It’s straight-forward…when Scoble reads something on his Kindle and then views the same thing on his laptop the software remembers where he was. It’s a bookmark, that’s it. And because it’s such a simple feature it might get overlooked…

So if you’re building an app used across devices consider focusing like gangbusters on the simple ability to seamlessly sync everything, so that people can immediately start in using one device where they left off using another. After seeing the rapturous language people use around this simple feature, I’m convinced it might be THE feature of a multi-device web.

Flickr: Microcopy

Creating the group was prompted by Relly Annett-Baker, a web copy-writer from England who is putting together some materials on the subject and asked if I had some good examples. I had a few, but most of the good ones have come from other folks who are working on cool things. It occurred to me that a Flickr group might be a good way to garner more interesting, curious and far-flung examples.

So feel free to add your examples directly to the group…it is open to the public.

And, if you’ve never heard this term before, read Writing Microcopy.

And the answer Ev gave is exactly the same one they’ve been giving for a year now, which essentially is: “We’re not focused on revenue. We’re focused on growth”. When you hear a CEO say something like that, you know a lot of people’s reaction will be “They’re doomed. They’re a flash in the pan. They’re not successful yet, etc”.

But Twitter is not playing at the $1.00 blackjack table. They’re playing at the $1B blackjack table. Forget for a moment that Twitter has smart investors and they’re very aware of what’s going on at the company and that if they wanted revenue over growth right now things would be different.

The fact is that Twitter has made the business decision to focus on growth over revenue. That’s their prerogative. If you disagree with that choice, that’s one thing. But you can’t say that Twitter is unsuccessful because they haven’t made money yet. They’re not trying to! You end up measuring apples while they’re growing oranges.

There is another side to this story, the story of how Twitter makes design decisions to support its business goals. When I hear Ev say that they’re focused on growth and not revenue, from a design standpoint I think…they’re doing a damn good job! I think Twitter is very successful in this regard. Why? One simple reason…

Twitter aligns design decisions with actionable business metrics.

This sounds straight-forward, but it’s really hard to do. In fact, most companies fail to do it. Most companies fail to consistently align their design decisions with their business metrics. There are many reasons for this, including unclear business metrics, unclear design direction, politics, competing factions, and simply not knowing how. (I wrote What metric are you designing to improve today? as a result of my frustration with this)

In Twitter’s case, their overall growth metric most likely includes some version of the following:

1. Sign-up: (number of new user sign-ups per day/week/month)
2. First-time Use: How many people actually start using the service. (one or more tweets)
3. Use over time: A measure of how many of those users stay and use the service over time (often done with a cohort analysis)
4. Engagement: A measure of how engaged those users are (often expressed as daily visits, time on site, # of tweets, or similar)

(If you read my blog with any frequency you’ll know that these are the key stages in my Designing for Social Traction talk. Take a look at my slide deck for more on design decisions in and around these key stages.)

In order to make these metrics go up over time, Twitter has to make changes in their design that lead to an improvement in the metrics. Here are several ways Twitter makes appropriate design decisions:

As Ev suggested in the interview, they’ll be phasing out the Suggested Users List as their new lists functionality comes online. (check out the lists I’ve created if you’re not familiar with the feature) The lists feature directly relates to first-time use as well as engagement. Lists can be used for first-timers to get them following valuable people and it can be used over time to help people organize those folks they follow.

Suggested Users, while it’s good to get people started, also carries the baggage that it shoots some people to the moon, inflating their follower numbers by several orders of magnitude. This, to put it gently, has an adverse affect on the morale of the community. Some people can’t stand others having such privileged treatment.

Twitter is also going to support retweeting in their API. This will allow both Twitter and 3rd party software vendors to better track conversations on the service. This relates directly to engagement…as retweeting gets easier to track it’s going to improve engagement over time.

Twitter recently announced they’re adding anti-spam tools so that the community can help weed out bad behavior. This relates to all of these things as well…when people see SPAM it degrades the Twitter experience…especially if they’re using Twitter for the first time.

Now, don’t get me wrong, Twitter has a lot of room for improvement and a lot of things they could do to help improve growth. I’m sure they’ve got a thousand ideas about what to do. For example, one easy thing they could do is what Friendfeed did earlier this year: offer a feature directly in the stream to invite your friends. Here is a screenshot:

This is an interesting feature for several reasons. One, it breaks the rules of the stream a little bit because it’s showing information that people haven’t explicitly subscribed to. But breaking the rules of the stream isn’t always a bad thing, as Socialcast found out with its broadcast stream feature. Two, the feature works really well. After Friendfeed added this widget to their streams, the activity level on their site shot up…and rumor is that it was effective generally. (a symptom I and others saw was an immediate increase in connections on the site). Three, flowing items in the stream is risky because it might upset people…the trick is to do it almost never…and only do it when you have a feature that works extremely well. Or, choose to add this item into streams as people are new to the service (and haven’t uploaded their address book yet). This will help newbies get up to speed during their early use.

These are some of the ways that Twitter is improving (and one way they could improve) their service. I, for one, am impressed with their laser-like focus on growth and their ability to align design decisions with business metrics. There are a million things Twitter could be doing, but they remain focused on the nuts and bolts of their service. You might not agree on the metrics they’re currently trying to improve, but you can’t claim that Twitter isn’t successful.

One of the startups, Fanfeedr, was in super-early alpha at the time. The primary finding from testing their site was that people didn’t immediately grok what the service was. A feed for fans wasn’t entirely clear…were the fans creating the feeds? What did the feed look like? Was it something people used on the site or off the site (like RSS)? These issues compounded to make the service unclear.

The end result was that people didn’t realize that the service was built around the idea that you declare your interests and then Fanfeedr essentially sets up a firehose of information for you around the teams you like. You come to Fanfeedr and get a personalized sports page. When talking with folks afterward, most people loved the concept and wanted a service to do this. The problem was that it wasn’t being communicated in the interface.

Well, Fanfeedr has been evolving since Testcase and now has a nice intro screen (you might even call it a splash page) for new visitors. They’ve directly addressed some of the issues we saw in testing, and now it’s much more clear how the service works.

Notice that Fanfeedr is now being explicit about cause and effect. They say “Pick your favorite team and players, and we’ll give you the most up-to-date collection of news, videos, tweets, scores, and information about them”. This is it…the primary value of the service in a single sentence. If Fanfeedr is around five years from now this will still be their primary value proposition.

They’ve also got an example of microcopy in the line “we won’t publish anything to Facebook without asking you first”. This is a concern that lots of folks have with 3rd party sign-ins, and Fanfeedr is addressing it up front.

And finally they’ve included a nice list of how to get started. (I recently wrote about a variant of this technique that I call The Strikethrough Method)

While screens like this are trivial to build, they are not always easy to design. In some cases, you simply don’t know how best to explain what you’re building (this is the elephant in the room in many startups). In other cases, the value you think you’re providing isn’t the same value that people are hearing (more common than one might think). Doing quick user tests can get you over this hurdle, teaching you about what people see as the core value, and also telling you about what microcopy you might need for contingencies.

The screen is not perfect, however. For one thing, the statement of value is by far the most important content on the page. Bolding that sentence, at the least, would help. In the current design attention is drawn to the red numbered list first (red is powerful at drawing attention, as is the visually outdented list) Some people won’t even read the starting paragraph containing the value proposition…they’ll simply skip it and start at the list.

Visual design aside, Fanfeedr, in a few lines of html text, now give a much more clear picture of what the service does than they did back in April. This is the essence of design…iterate…test…iterate…test…ad infinitum

So who else communicates their value well? As part of my upcoming book Make them Care!, I’m looking for exemplars of this sort of clear communication around service value. If you’ve got a service that does this well, or know of one, let me know and I’ll consider it for the book.

One of the guiding principles of interaction design is to support existing behavior. This means to figure out what is already happening, what activities, tasks, and interactions people are already doing, and build support for them into software.

This may not seem like a glamorous way to approach design, but from my experience it’s the fastest way to make people happy. Let them do what they already do faster/better/easier, and then you’ll have their attention in order to push the envelope after that.

http://www.flickr.com/photos/bokardo/3841850885/

Here is an example of a feature I worked on recently that supports existing behavior. The feature is called “broadcast stream messages”. It is part of the enterprise software collaboration tool Socialcast, a powerful activity-stream based application that allows people in a company to communicate in near real-time in a more efficient way than they can with email.

Here is how the feature works within the Socialcast software: When someone signs up to use Socialcast for their company, they automatically become the administrator of the account. As an admin, they can appoint others as admins as well. In many cases the initial user appoint executives of the company as admins so they have access to everything.

As an admin you have certain privileges. The new feature, broadcast messages, is a privilege that allows admins to post a message to the stream for everyone to see, regardless of who is following who. This is why it is called broadcast, because one person is broadcasting a message to all the rest. Here is a screenshot of a broadcast message I created using the account I have for Bokardo Design.

The message looks different than normal messages in the system. It has a blue background and a broadcast icon next to the avatar. Also, like the broadcast message itself, any discussion that starts around this message will be available for all to see.

Some people have called Socialcast “Twitter for the enterprise”, and while that does communicate some idea of what Socialcast does (it is a stream-based app), it is becoming clear that the two products are diverging. Broadcast messages are a good example of the divergence.

The feature was not received by everyone positively. At ReadWriteWeb Enterprise, Steve Walling has suggested the mere existence of a broadcast feature means the software is making decisions for people. In a piece titled Socialcast: CEO’s Status Should Be Louder Than Yours, Steve says:

“(Socialcast) thinks that HR and C-level executives deserve extra recognition in the corporate status stream. Its new Broadcast Message feature gives announcements by higher-ups priority if they want it, effectively creating the Reply All of the micro-messaging world.

For a startup whose entire value proposition is software that transforms work, the idea of enabling preexisting corporate hierarchies is an ill-considered move. Corporate hierarchy is what makes the enterprise tick, no doubt about it. But in communication, what’s needed is reducing noise, not the means to create more of it.

For our bet, the best part of enterprise microblogging is that every employee decides what messages they receive. The ability to filter and follow selectively within the company is the feature that makes it more attractive than email.

In the open world of consumer activity streams such as Twitter or Friendfeed, I think Steve has a point: no user of the system should have the power to broadcast messages to everyone. This would quickly lead to undesirable behavior. (it’s why email is so SPAMMY) But in the corporate world things are different. First off, users are invited into the system and are all part of the same company. This means there is some level of accountability in the system: bad actors can be found and dealt with. Second, in the corporate world a hierarchy not only exists (as Steve admits) but it is important to the workings of a company. If the CEO needs to get a message out, then that’s what should happen. (S)he shouldn’t have to worry about who is following who or other details about how the software works.

I can imagine situations in which the broadcast message is abused, but that would be a result of the corporate culture (or the individual), not the software. In general there are no lasting technological solutions to social problems.

So back to the feature. Here is some of the thinking around use cases we talked about when working on it.

While many people are on Socialcast much of the workday, leaving it open in a browser window or using the desktop app (for many it is an everyday app), there are several times during the day that they step away from their computer. They go to lunch. They go home for the evening. They run errands. They’re in meetings all day. Even for a highly-engaged start-up, there can be long periods each day where people are away. This is very similar to email, with a slight difference. Socialcast is more synchronous than email. Sometimes people hold conversations in near-real-time on Socialcast. This comes from the nature of the software: messages are sent very quickly and as a result more messages get sent.

When people come back to the software after a break, they go through an updating activity, getting acquainted with what happened while they were away. We observed that when people do this they often skim extremely fast to find out if they missed anything. The slight fear of missing something important is a motivator in lots of social software, so it is with the corporate stream.

Over time, as people settle into using Socialcast and find an equilibrium they are comfortable with, their following habits normalize. Some people only follow those they work with on projects. This is powerful way for them to increase the signal/noise ratio of their stream. If the only people they follow are the ones they are working closely with, the messages they see are on average very valuable to them. This is the power of the asymmetric, or follower model of relationships.

However, we observed that this behavior also created another problem, especially in some of the very large organizations who are using Socialcast. In some cases when an executive made a company announcement or had important news to share, some people didn’t get the message because they weren’t following.

It didn’t always have to be super important, either. For example, on one friday an executive of a relatively small, distributed company decided to give everyone the afternoon off to go see The Watchmen. The message went out to everyone following the boss and they were aware of what was going on. Some people were working remotely (an increasing trend) and not following that particular boss. They simply didn’t get the message. They were expecting to have people at the main office to work with that day. Well, they found out too late that their afternoon was going to be vastly different than what they had planned.

This is simply one instance of the follower model breaking down. (a relatively innocuous case) We have since seen several more cases like this. While the follower model is powerful it wasn’t supporting broadcast messages very well. Our resulting broadcast feature is designed to fix this. To put it another way, people were used to being able to send messages with relatively strong assurance that they would be read by everyone. That was the existing behavior. Once we identified it, it was easy to come up with the new broadcast message feature.

Since the feature has gone out, we’ve seen some interesting uses for it. Here are some of them:

• Emergency Alerts
  Emergency alerts at a University campuses that require faculty awareness and frequent updates.
• Companywide Congratulations
  Congratulating a team on the major accomplishment of finishing off a multi-year project.
• Breaking News
  Lots of teams have used the feature for breaking news, from mundane things like changes in company policy to important things like crisis response.
• Help & Support
  Helping people become aware of new resources on the intranet that they may not have found themselves.
• Company-wide Initiatives
  Relaying organization-wide initiatives, informing all users of conversations being held by leadership, increasing transparency and diminishing ambiguity.
• Calendaring Updates
  Sending quarterly meeting dates and basic agendas for people to put on their calendars and prepare for.
• Tool Tips & Tricks
  Explaining best practices for Socialcast to all members. Depending on the organization, there is a wide variety of people who may or may not have experience using streaming systems. Teams are helping each other out by pointing to resources and best practices.
• Required Reading
  In an effort to get everyone on the same page, some companies have required reading lists. We’ve seen the broadcast feature used to inform folks of the latest readings that will be discussed at upcoming meetings/events.

In general, we’re seeing uses of the feature that we didn’t anticipate. We think this is a good sign, as it suggests that broadcast messages are providing value in different ways. And, because all of the messages and resulting conversation are archived in a single place, it’s easy for people to reference going forward. (unlike email, where everyone has their own, incomplete copy)

While I was writing this piece I ran across another review of it from Bill Ives over at Pistachio Consulting. He also views broadcast messages as a good thing in general. He says:

“Broadcasting is one examples of an emergent capability not appropriate for use on the broader web, that can work well within the enterprise. This feature would not even be relevant to Twitter because users have access to only one follower pool and the system depends on its distributed nature. In an enterprise you can have layers of participation and parallel systems for those who aren’t microsharing yet. This feature can provide a greater sense of community within the enterprise as all levels of the organization can now respond to breaking broadcasted news through a channel that provides greater collaboration than email. We look forward to more innovations like this one within the market as it adapts to the needs of the enterprise.”

Bill sees the potential of broadcast messages: as a small, helpful feature that solves a particular problem in enterprise software. But, as with all features this one is a work in progress. For more information about the broadcast feature and the collaboration tool in general, check out Socialcast.com.

I recently ran across an interesting way to qualify people using sign-up forms at monotask.com. Monotask is a yet-to-be-released application for simple attention management. It is being developed by Charlie Park, who also built PearBudget, a really simple budgeting and expense tracking service (which also has a strong sign-up process). To help build awareness of Monotask Charlie set up a landing page allowing people to sign up to be reminded when the software is released. Here is what it looks like:

This is a special kind of sign-up page. You’re not really signing up for the service, but you are signing up to be notified when the service is released. This type of page can be used to promote almost anything. It helps build up a little buzz and give you a list of people who are interested in your product. I’m using this same type of page for my new book.

After someone signs up to be reminded, this is what they are presented with.

This screen first thanks you for signing up. But then, and this is the interesting part, it asks you to fill out a short survey. This is curious…a hidden survey! So I looked closer at the design.

First off, I love the copy here: “Help us build something you want.” This is a great way to communicate to someone that they are an active part of the product development process. “You mean I can help you build cool software that I will use? Why, I never thought you’d ask!”

Second, I wanted to know the rationale behind the design choice to put the survey here and not on the front page. Surely the designers would get more people filling out the survey if it was on the front page of the site? Why place it here, instead?

Thankfully, Charlie was obliging. I asked him why he put the survey here. Here is his reasoning:

1. Less Sign-up Friction
   Charlie was tempted to put the survey on the front page as part of the sign-up process. But if he did that the sign-up form would look more intimidating…and seem like a larger commitment. By placing the survey after the submit, he’s not overwhelming people with a long form. He’s keeping the user’s initial attention on a single goal.
2. Qualified Reponses
   Charlie told me that by putting the survey after the sign-up (without telling people it was there) he was putting the odds in his favor that the people who gave him feedback would be the type of person he wanted feedback from. In order to reach this survey they need to first declare their interest in attention management…that’s the qualifying hurdle. If people land on his homepage and don’t sign-up, then its likely they aren’t as interested in attention management.

This second reason is the more interesting one. By placing the survey behind the qualification wall of the sign-up page, Charlie can expect a much better signal-to-noise ratio in the answers. Otherwise, he would have to sift through more responses but not really be sure that they survey taker was all that interested.

Qualifying people like this is a clever way to make your feedback more efficient. You might not get quite as much feedback, but what you do get will be higher quality. And as with real-estate agents, that higher quality might just be money.

If you would like to see this technique in action, visit monotask.com.

It’s a simple feature: the designers simply cross out one of the normal, expected steps of getting started with the service. On the home page of the site they show the usual, expected step of creating an account and then put a red line through it. Easy.

Here it is on Posterous:

Here it is on SignApp:

Notice that striking through text actually adds information to the sign-up page that doesn’t need to be there. By informing people they don’t have to do something (create an account), the designers are adding extra information to the page. Why bother doing that?

It has to do with expectations and psychology. Our expectation is that we have to create an account to use pretty much any software online these days. We have been conditioned to think so…and this method plays against that concern.

By explicitly pointing out that you don’t have to create an account, these sites defy our expectations and strive to delight us with the welcome news. You mean I don’t have to create an account? Wow…that’s nice. The simple idea that we don’t have to create a username and password might be enough to start people using the software. At the very least it has our attention.

Not all applications will be able to use the strikethrough method because they will require a password for increased security or other reasons. (a password could be either a site-specific password or a 3rd party sign-in such as Facebook Connect or OpenID). In fact, Posterous becomes much more friendly when you do create a password: in the email they send you in response to your initial email they provide reasons to create a password. (customize your site and choose your own subdomain)

The strikethrough method is an example of microcopy done well. It serves to address a common concern and helps reduce the commitment we feel as we sign-up for the service.

If more and more sites start using the method and people begin to see it everywhere the strikethrough method might lose its novelty. But we are far away from that day. Right now it is a nice touch for lightweight apps that can make use of it.

Since going out on my own two years ago I’ve worked on many different kinds of projects. Some small, some big. Some simple. Some complex. But even though projects vary in lots of ways there always seems to be one constant: the problem of sign-up. If you’re doing business on the Web chances are you have some sort of sign-up process.

Make them Care! covers different kinds of sign-up: everything from email newsletters to marketing sites for products to web-based applications. It also covers the whole spectrum of design issues: copywriting, visual design, information architecture, strategy, and marketing. This is why I’m so excited about the book: it’s a comprehensive view of the entirety of the problem. (this is also why I love what I do…at various times during the day I’m writing, designing layouts, or thinking strategy)

One of the primary focal points of the book is the psychology of sign-up. I’ve been researching this for some time now (haven’t blogged about it much yet) and I can’t wait to share with you what I’ve found. I have started to get some of the ideas out there, such as my recent slide deck Designing for Social Traction.

Also, I’m looking for sign-up case-studies. If you have been working on sign-up and have a unique story to tell, please get in touch. In particular, if you have done testing (such as A/B or multivariate) and have examples of what works (or what didn’t have an effect) in your sign-up flow I am greatly interested in talking with you.

The early feedback that I have received has been tremendous. I’ve had several people approach me and tell me that this is the #1 problem they have and that they can’t wait for a book on the topic. While I (obviously) love to hear this, I also am determined to make the book a valuable one. So I’m not hurrying anything: as of right now I don’t have an official publish date. But you can get reminded when it’s published.