The UX of Social Media

In my work to integrate UX design into Agile scrum, (related post) I discovered that about 30% of the usability bugs found were  seen in tests of previous features. The bugs were often small, but were distracting and had to be fixed.

This meant that mistakes were being designed into the product.

Acceptance criteria are the most concrete way to measure the completion success of an Agile story.

But while each Agile story has its acceptance criteria – yes/no questions about does the feature do X, or is X possible? – the stories needed something further, some form of general design guidance.

I introduced the concept of acceptance principles, which are purely guidelines, not measurements. Although designed to be de facto requirements of any story, a given principle may not apply to a particular feature. So they amount to best UX practices that need to become part of Development’s DNA so that repetitive mistakes are avoided.

From acceptance criteria, the tester will create test cases. From acceptance principles, the developer will add basic thinking to her repertoire: such as, consult a tech writer when drafting text for dialog boxes, or refer to the pattern library instead of using a solution from a previous project.

Acceptance principles are by their very nature brief, so they will invite thinking, and questions for UX, thus uncovering things the principle might not specify.

Agile is about balance. The completness standard is working software; Agile wants to document just enough to know what was built, preventing the documentation from being wasteful overhead. That is achieved not by strict rules, but by maintaining balance.

Acceptance principles are thus an ‘acceptance criteria conversation’, as noted in this interesting piece fom the Agile 2009 Conference: http://agile2009.agilealliance.org/node/622.

But how should acceptance principles be implemented? Whose responsibility are they? It will likely be the responsibility of UX to link principles to each particular story. That linkage will drive acceptance and usability testing to cover those points. If bugs are found, then the Agile nature bas broken down, and the fix must be implemented.

The design of acceptance principles is to prevent repetitive mistakes. It is through repetitive attention to the source of those mistakes that the cause will be avoided.

First, a basic assertion: positive user experience depends on simplicity, user satisfaction, and brand loyalty, which means increased profits.

Let’s unravel that. Usability is a measure of quality, but it is in part subjective. Whoa, you say, I’m not paying real money for a feeling. Well, that is the definition of UX. People prefer one product over others, give recommendations, and make purchase decisions largely due to the way they feel about it.

More concretely, user experience is strongly connected to the time it takes to complete a certain action, including wrong turns, recovering from errors, consulting help documentation, and so on. Those actions are completely non-productive. People don’t like the feeling of being frustrated, and are sharply aware when they are wasting time with a bad design. Website usability is determined by users’ ability to avoid navigation errors and deal with new information.

Can you sell a product based on the time a task requires? You bet you can.

Discoverability, learnability, and efficiency.

All of those are time factors. The key to all is basic human nature: users will grant you a small time slice in which to earn their trust before they move on. And if we are learning anything from the social networking hubs that are emerging, trust is the core of network participation.

OK I grant you the following is old stuff. But water hasn’t changed much in the last seven years, either.

Jakob Nielsen completed a study in 2003 which concluded:

“Development projects should spend 10% of their budget on usability. Following a usability redesign, websites increase desired metrics by 135% on average; intranets improve slightly less.”

A project can conduct usability testing iteratively, beginning with paper wireframes, sharpen focus on the user group, and catch design problems. It doesn’t have to cost a lot to be effective.

The Nielsen study collected data from 863 redesign projects which employed usability activities, and found that costs of those activities were around 10% of the total budget. But this data revealed a non-reciprocal cost curve: the larger the project, the smaller the usability cost percentage, sometimes a low as 4%.

Repeat: The larger the project, the smaller the percentage cost of usability.

The Nielsen study reviewed data from 42 redesign projects where like usability metrics were available for both the original and revised system. They found that usability increased by 135% or higher. That means, if the original usability was 1.00, then usability of the revised system was over 2.35.

Nielsen found average improvements in sales and conversion rate of 100%, traffic and visitor counts of 150%, user performance and productivity increased to 161%, and use of specific features of 202%

Numbers and stats – blah blah blah. But it all comes down to the fearless predictions made clearly by UX professionals over the last ten years… companies who build user experience design into the way they create products are the literal butt-kickers of tomorrow.

The software industry is known for inflicting pain.

This instant, millions worldwide are attempting to use software or an electronic product that is difficult or confusing. Is that your product? As soon as they lose confidence, the moment trust evaporates, one of your business opportunities goes away. Poof.

And as they X out of your life forever, they will be muttering, “Why did they make it so hard?”

We know people benefit from ease of use. We know making products easier to use increases customer loyalty, brand lustre, market share. We know that companies investing in ease of use enjoy those benefits. Studies prove this point repeatedly. Usability equates to profitability.

So why is good usability not the norm?

There is always the features vs. usability battle in development projects. You can’t see usability or good user experience in a list of features. Usability is like breathing, and equally difficult to explain. There is always the time-to-market battle, which usability often loses. When the almighty release schedule shoves usability design, testing, and the fix cycles aside is when we agree that:

“We don’t have time to do it right, but do we have time to do it over.”

At least one study by Dr. Clare-Marie Karat shows that companies that commit to ease of use can exceed anticipated earnings, or in common parlance, ‘beat the Street’. Building user experience design into product development saves money. It is more economical to consider user needs in the early stages of design than it is to solve them later – it has been shown that every dollar spent to resolve a problem during design is worth $10 during development and ten times that much after the release.

You can do usability testing on paper prototypes. How cheap is that? Even the most basic click-through prototypes cost time and money. You can do 1-1 focus reviews with users of existing products and let them steer you. The UX designer’s job is to keep your users and customers involved through the entire development cycle, not just at pre-release testing.

Dr. Karat’s work has shown that focusing on user experience can advance release dates. Avoiding the urge to skip usability concerns in design can save a large fraction of service costs down the road – help requests, change requests, bugs, and worst of all, product returns.

One hidden advantage of integrating good UX design – a happier project. Your company has a vision statement, right? Your project has a mission too. If it is clear that everyone involved is saluting those goals, the level of frustration at meeting user needs will be low.

The core of usability is reduced time on task, ergo, productivity.

References (yes I know – same title, but different documents):

Cost-Justifying Usability

Cost-Justifying Usability

Start reading anywhere about Tim Berners-Lee’s early Web pipedreams and you see semantic web and the emergence of data as the only resource worth bothering about. What data truly matters? Personal profiles matter. A lot.

Today, you can belong to any of a number of social networks and Web 2.0 services and what to you do first off? You enter the same personal data you provided the last time you joined something.

There are several things wrong with that. After the fact, the user or member has little control, and no idea of what they ‘look like’ to admins and others scanning or looking into that network. Plus the data in those networks goes out of date – and the members have to backtrack on that for each network joined (and forgotten about) to update individually.

Bah, humbug. We won’t get to the semantic web so long as applications think they own data.

What would be the advantages of a single social graph? Uniformity is a big one – all the data the user wants to make available to any SN will be there. Members can check off what they want to share or hide, using the Mother Ship as a reference. Efficiency is another, it will be much quicker for users to sign up for the latest fad, thereby lowering the bar to adoption. Visibility is a biggie for the user – what if I want to know what Facebook reveals about me? I should be able to see my profile in an editor window, and see such a view for every SN I belong to.

Also, perhaps members want to flex their personality for each service they join… the Spring Break persona for MySpace and the college grad persona for LinkedIn. And in the same breath what about control over who can see your various profiles?

Every so often, users would receive a reminder to review their data. Changes radiate out into each SN they belong to.

One obvious win will be for corporations to manage their employee data. A large company might own a dozen social graphs – all replicating much of the employee data and with no common view or update capability. Hard drives are cheap but human toil to verify the currency of data is not.

Right now there is a sort of format war going on among the major SNs – think VHS vs. Beta or Blu-Ray vs. Toshiba – Facebook, MySpace, Flikr, LinkedIn and a dozen others ‘own’ the most user profiles. Some apps are setting themselves up as plugins to Facebook for example to lower the bar to adoption and promote uniformity of data. Perhaps one of these will overwhelm the space and become the de facto standard. Or not.

The focus of this discussion so far has been uniformity and maintenance of user data, and a facility to join new social services without re-creating yourself by hand. But what about managing your various friend lists?

I for one think the friends management should take place within each particular service, e.g., MySpace. While it may be powerful to extend friends lists across networks, working with growth edges will make more sense to most users if controlled from each social context. Many people find it desirable to have multiple personae so a bulk importer might seem dangerous. A “friend” in one space may not be desirable in another (think LinkedIn vs. MySpace). Also, with mass import, blocking hostiles and other micro control of the list for each network would be required, which could lead to user errors and misunderstanding of what is going on.

Who should or could own a central profile store? The largest existing networks have the best shot if they can open the box in a secure, user-controlled way and allow users to export data into the format of any other service. Traffic would be the key, and with high volume and user trust, various services would see it in their interest to work toward shared or compatible formats.

A few related links:

http://etailology.com/blog/archives/116

http://microformats.org/wiki/social-network-portability

http://www.wired.com/software/webservices/news/2007/08/open_social_net

http://notsorelevant.com/2007-08-02/portable-social-networks-a-vision-becoming-true/

In my nearly 15 years of work in user interaction design, I have come to see user experience as tightly coupled with customer experience and corporate brand. Even with that view, I understand the need for ‘guerilla UX’ in today’s environment and look for ways to shape the product with rapid development and testing cycles. We have to get products to market faster and cheaper than before, yet with a higher caliber of information built in.

I’ve found several interesting ways to flex the UX process to suit Agile scrum development in particular. When working in Agile, a superior UX designer will earn a seat at the release vision/release backlog table to bring user views to that forum. As a corollary to that, the single most important responsibility of a UI designer is likely liaison between various roles around the product, such as users, product owners, and stakeholders, all of whom have distinct goals.

Can you think of any others on the project team who have those skills?

When I noticed that about 30% of usability bugs reported in testing were mentioned in feature after feature, I began developing a set of acceptance principles for all stories that touch the UI, which are designed to become part of the project DNA. These principles included getting developers to consult a tech writer on the verbiage for dialog boxes and screens. What came out of this from the writers was an unexpected degree of insight on the entire UI, not merely the wording of messages.

The not-so-great way to guide edit actions:

This forces user to compare four concepts: OK, Cancel, Stop, and Delete to decide on an action

The short and sweet way to guide edit actions:

A technical writer suggested leaving
Yes and No out of the text entirely

I came to see technical writers as quite akin to UX designers. Most are skilled, some are visionary, and experienced with many types of software products. I began to use the writers as my first line of prototype review, and saved my team a good deal of cycles in the process.

The conclusion I arrived at shortly thereafer was that the tech writers should simply write the doc first, including all the screens etc., and have Dev build that. Tech writers do all that when they document after the fact, and this move would save all the scrambling at the end interviewing developers and improve product quality to boot. It would save us from some of those misbegotten features that have ‘coding coolness’ as their reason to be.

User experience (UX) design has its own process. Briefly, it’s about developing flows and wireframes, a spec, assets to be incorporated by Dev, usability testing, and feedback of test results to Dev. Lather, rinse, repeat. In an Agile scrum environment the spec becomes a story, and the process otherwise behaves typically. Everyone runs with their hair on fire until the last week of the sprint or release, when code freeze arrives.

It doesn’t do any good to provide usability input to Dev after they have put away their bits. And it is unlikely to find the features tested on the slate for the next sprint or even the next release – modern software programs are too large for that. So usability feedback that comes too late simply falls into the black hole of coulda, woulda, shoulda…

What the UX designer can do to accommodate the pace and code freezes of Agile takes in a number of things, including:

Test faster!
Approaching code freeze, work with the developers to get their last testable features as early as possible. Test with fewer users (two instead of five) and rely more on heuristics. Don’t spend so much time on the report itself, and stick to the major complaints.

Do the risky features early in the sprint.
Work with Dev on this so that toward the end of the sprint it is the small features being worked. If there is a delay due to feature creep or unforseen problems then only the small features will fall off the schedule. This also allows more leeway for UX testing and feedback of the first features completed.

Agree on acceptance principles.
Establish on the Wiki (you are doing Agile, remember?) a list of acceptance principles by which Dev can avoid repeating the same mistakes. Testing often turns up the same type of usability bugs in feature after feature. Get the scrum leaders and other stakeholders to agree that those principles are nominally part of any story that touches the UI.

Acceptance principles (not the same as acceptance criteria, as criteria require yes/no answers) are essentially best practices packaged to make sense to the particular team or project. For example, one might remind developers to match the OK/CANCEL button text in a confirm dialog to the descriptive text in the panel. Doesn’t make sense to ask a user to click YES or NO when buttons are labeled otherwise.

This forces the user to compare four concepts, Stop, Delete, OK, and Cancel to find the desired action.

Another good principle in this regard is to suggest that developers consult a technical writer for verbiage in dialogue boxes. Tech writers are very close to user experience designers in their thinking, and the writer will likely make other good suggestions as well.

The three previous paras align with the fact that a change costing $100 on a finished product costs about $1 in design. Please see ibmdesign’s post on ROI of usability.

Build in a post-freeze usability test cycle

In a perfect world, where user experience is a priority, the team will allow more time after code freeze for proper usability testing and feedback to take place. Yes with promotion and patience on the UX designer’s part, this can actually happen! When it does, stay cool. Act like such advanced thinking is totally normal.

The monetization of suffering

The ship of fools is an allegory satirizing the human comedy as a voyage of frivolous or oblivious people without a leader or pilot, each one seemingly of the belief they are the savior. The concept is framed in the 1484 novel Ship of Fools by Sebastian Brant, and later by other writers including novelist Katherine Anne Porter (1962).

In Porter’s novel, each character is an archetype representing human vanities. She makes use of the Jungian archetypes such as the Hero, Scapegoat, Outcast, Devil, Earthmother, Platonic Ideal, Temptress, Unfaithful Wife, Star-Crossed Lovers, etc., and situations including the Quest, Fall, Task, Initiation, Journey, and so on. The way so-called Reality TV serves up these heavily-edited and therefore unrealistic segments varies only slightly between shows. There is always the one I like to call Grim Executioner. This is ostensibly the show’s moderator (speaking dialog spoon-fed from behind the curtain) whose job it is to deliver the bad news with a hatchet face.

The Grim Executioner is in love with Schadenfreude, or ‘enjoying the suffering of others.’ This the Grim Executioner’s daily diet, and the producers make sure there is enough drama and suffering to go around.

The suffering of others is also the staple of millions of viewers who tune in from squalid rooms and palaces alike to watch someone besides themselves become the latest humiliated outcast.

Larry Wilmore, who created Reality Junkie for Fox, said, “It’s like watching a car wreck… the drama of it… because there’s so much cruelty and tearing people apart. I feel like I need to take a shower when I watch that.”

As the producers of Who Wants to be a Millionaire? quickly discovered, reality TV is incredibly cheap to produce, and collects better market share than scripted dramas, soaps or sitcoms. That is putting pressure on scripted shows to reduce budget, which is not going to add literary value to our life and times.

Because the brain is malleable to the way it is used, and because sensory tolerances develop, it is inevitable that audiences will become jaded on current fare, and require more extreme and exotic reality entertainment. Just consider that about 1/4 of Web servers worldwide are devoted to porn, and you’ll get a sense of where the ship of reality TV fools can really take us.

One possible destination was illuminated at least as far back as 1958, in the short story Mr. and Mrs. Saturday Night by Robert F. Young (1915 – 1986). The story depicts a lottery in which a lucky couple is chosen to be on television from their own home, for the entertainment of millions. Crews come in and wire the whole place for video and sound. The couple’s elation turns to dread when they realize they are supposed to spend the entire evening in their bedroom. But the year 1958 provided a very moral setting: they were, after all, married to each other.

3SBVCTUQ2PCV

Chapter 2.5 of:

Abuse, Sex and Addiction in Online Communities
Copyright Lee Baldwin 2009
@ArtOfSilence

The reason to be for Second Life, IMVU, Maple Story, Bratz, Habbo Hotel and most of the others is to make money. Which is a good thing. But through that lens, a particular new Internet trend (or phenomenon) appears: the sale of virtual goods.

What are virtual goods? One category is any asset or perk a chat player can buy for use with their online avatar: clothing, hairstyles, rooms, furniture, poses, music and so on. The goods are virtual because they are available only within the context in which they are used.

It makes sense that clothing such as a leather jacket for instance is available only in the 3D world where it is sold, but music is sold the same way. You might have a tune on your iPod, or on a CD, but if you want to hear it (and have others hear it) in your favorite chatroom you are going to have to buy it again. If you play in more than one chatroom, guess what – you will be forced to buy the same tune again.

VG sales are the latest major bubble in ‘monetization’ of the online experience, and the US market for virtual goods is near $1 Billion, a near 100% growth from last year, with another 80% growth expected in 2010. Some 11 million Americans buy VG products each month, and most of the purchases are made by women.

That is real cash for… real pixels.

The Asian market is $7 Billion, and in China, VG revenues are greater than on-line ad revenues. Stay tuned…

Recently I was asked to prepare a written estimate to upgrade the usability of a software product. I had spoken to several of the company principals, who assured me that usability was the central problem they must overcome to be competitive and secure key customers.

So I spent half a day looking at their software, and wrote up my estimate.

Being a user experience designer, I naturally gravitated to such activities as talking to users and integrating their evaluations of the product before, during, and after the rebuild. The tasks included heuristic evaluation, initial usability testing, revised flow models, key flow prototypes, visual design, usability testing of builds, final usability and acceptance testing, and normalized scoring of the finished package to provide a baseline for future projects.

The response I got was classic:  “How much would that cost without the usability testing?”

This goes back to one of my earlier rants, the conflict of features and usability. Features always win, because you can see them. Usability is assumed, like breathing, and is just as hard to explain. But if anyone still wonders how Apple, for example, managed to secure such customer loyalty in the early years, it comes down to that single idea:  they thought about their users and created tools that were easily understood and easily used.

Investing in good usability makes sense only when the time horizon is far beyond the next quarterly report or the next board meeting. Usability is not a quick hit that will produce instant gains. Usability is part of corporate good will, the customer loyalty, and these are not things that an ad campaign can bring in six months. Usability thinking will be in the DNA of the next wave of companies that reach the heights of Amazon, Ebay, Google, Yahoo, and Netflix. Those companies made a science of customer relationships and did not let up when they were successful. Customer experience growing from positive user experience is one solid reason those companies are at the top today. Please see ibmdesign’s post on the ROI of usability.

And yes usability work does cost, and it does take time. But if you don’t have time now to do it right, when will you have time to do it over?

Start with a pet peeve… you see an interesting job posting at XYZ Inc. and wish to explore it. You find yourself once again entering the same personal data into a format that some middle manager thought was so precious. How many times have you found yourself doing that? Can’t tell you how often I’ve bailed because it was too darn much like crawling over broken glass. Who the heck is XYZ, anyway?

What this amounts to is joining endless social networks that want basically the same info on you. You are required to create yet another data mirror by hand.

It is analagous to a merchant asking, “Do you have our rewards card?” Great. Yet another piece of plastic for my wallet that accomplishes an identical function to the ones I already own. Only diff is – it’s for someone else.

The Semantic Web is about data, and we won’t have the semantic web as long as applications are data hoarders. But there are a number of popular SNs that do have most of the data you would like to include in your job app, so why can’t they be available as sources?

A single social graph is a bit much to swallow all at once, but it would be really helpful if at least the major social nets were recognized as templates by all the companies that would just love to have you in their database. Then you pick one on the way in (you are professional and pick LinkedIn or Dice over MySpace for example), hand over your password, and most of your data shows up in XYZ’s template. You modify the info as necessary, you are done. Every so often, or on some trigger, your data could be updated the same way.

The APIs do exist. HR departments, wake up. It ain’t that hard.

Oh… plastic rewards cards. Merchants, forget your precious logo on plastic and let your customers give you a credit card number. Whenever the card is presented the rewards account provides its data without bother. No questions asked.