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

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.

Whenever anyone asks about my approach to user experience design, I always frame the answer by asking this first:

Who is it for?
What do they need to be successful?
How do they know when they are done?

From those three questions the UX designer can elaborate all of the steps required to perform user research, wireframes, flows, interface design, and usability evaluation.

UI and UX designers and user researchers live their lives on lists. Many lists, long ones. This is the shortest list I have seen that can actually guide the designer each step along the way (with reference to the more detailed lists of course).

Who is it for:=

This covers user research and persona development. Embedded in the answers is the profile of behaviors and preferences users of your particular application will exhibit.

What do they need to be successful:=

This starts with a list of tools and extends to the motifs, wireframes, and flows.

How do they know when they are done:=

This also appears in the flows, but leads to user evaluation of the builds or finished app.

UX or user experience is the aggregate experience or assessment a user makes of a situation… I am reviewing some of the social media questions and objectives through the UX lens as the answers are often more applicable than many of the egghead approaches… read on…