Bokardo: Social Web Design
February 8th, 2010
Conversion Room: Improve your web-forms and increase conversions
A fascinating post by Googler Gavin Doolan:
If you are considering making changes to your website design, take a moment to consider the potential revenue impact of your redesign. (This graph) shows a theoretical overview of the ROI impact of various parts of your website.
I love that: “theoretical overview”. In other words, they really have no idea. But, if this is true, think about how it would rewire the way the design world works. Almost all money is pushed into technology and branding. Homepage, site redesigns, and custom CMSes are the cash cows of the design industry…imagine if most projects were not about those things but about simply improving these decision-oriented pages. Probably won’t happen, but fun to think about.
via Conversion Room: Improve your web-forms and increase conversions.
February 7th, 2010
Dreamers of Day - 52 Weeks of UX
I recently posted this quote on the 52weeksofUX site, but I like it so much I’m going to post it here as well:
“All men dream; but not equally.
Those who dream by night in the dusty
recesses of their minds
Awake to find that it was vanity;
But the dreamers of day are dangerous men.
That they may act their dreams with open
eyes to make it possible.”
T. E. Lawrence (aka Lawrence of Arabia)
December 8th, 2009
On the Origins of Avatars
by Joshua Porter | 
8 Comments | shortlink: http://bokardo.com/p/1582
Updated: Thanks to several commenters, I’ve updated the piece to cover some more early references to avatars.
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
“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:
November 19th, 2009
The Most Important Feature of a Multi-Device Web: Syncing
by Joshua Porter | 9 Comments | shortlink: http://bokardo.com/p/1570
As the ecosystem of devices proliferates, with the iPhone and Android platforms coming into their own (along with the ever-impending iTablet), we’re seeing a single feature become the most important and critical piece of new technology: syncing.
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.
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.
November 12th, 2009
Looking for examples of microcopy
by Joshua Porter | 4 Comments | shortlink: http://bokardo.com/p/1564
I’ve set up a new Flickr group with the express intent of aggregating examples of microcopy, that tiny copy (often shorter than a sentence) that helps clarify, explain, reduce commitment, or otherwise assuage someone performing (or considering) a task. You can find the group here:
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.
October 21st, 2009
Is Twitter Successful?
by Joshua Porter | 14 Comments | shortlink: http://bokardo.com/p/1537
The big question everyone has with Twitter is, and the very first one that John Battelle asked Twitter CEO Ev Williams when he interviewed him yesterday, is “What’s the revenue model?”
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:
- Sign-up: (number of new user sign-ups per day/week/month)
- First-time Use: How many people actually start using the service. (one or more tweets)
- Use over time: A measure of how many of those users stay and use the service over time (often done with a cohort analysis)
- 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 nuts and bolts of their service. You might not agree on the metrics they’re currently trying to improve, but you can’t deny that Twitter isn’t successful.
September 17th, 2009
Communicating Value through Cause & Effect on Fanfeedr
by Joshua Porter | 7 Comments | shortlink: http://bokardo.com/p/1524
A few months ago we held an event called Testcase at Betahouse in Cambridge, MA where we asked four startups to come and user test their web sites with local folks who showed up. Despite the super informal user testing method we used, we clearly saw that each startup struggled with communicating the value of their service. This is a common problem…founders have a really awesome idea but it just isn’t communicated to people clearly.
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.
August 21st, 2009
Feature Development in Action: Broadcast Stream Messages in Socialcast
by Joshua Porter | 3 Comments | shortlink: http://bokardo.com/p/1487
In which I describe how we discovered the broadcast stream message feature in Socialcast.
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.
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.
August 19th, 2009
Using your Sign-up form as a Qualifier
by Joshua Porter | 5 Comments | shortlink: http://bokardo.com/p/1479
In many industries people pay lots of money for a qualified lead. A qualified lead is a person who has expressed interest in a product or service and meets general buying criteria. For example, my neighbor told me that in the real-estate business agents often pay 1% of a resulting home sale for qualified home buyers. If someone can send an agent a home buyer who is serious about purchasing and eventually purchases, that referral is worth several thousand dollars.
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:
- 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. - 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.
August 18th, 2009
No Sign-up Necessary (the strikethrough method)
by Joshua Porter | 9 Comments | shortlink: http://bokardo.com/p/1470
Two apps, Posterous and SignApp, have a novel way to communicate how easy it is to start using their product. I call it the strikethrough method.
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.