The UX of Social Media

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.

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?

Having worked extensively in the UI/UX design arena since 1995, and pursued user inquiries for tech doc and marketing programs before that, I can’t say I’ve witnessed UX considerations win out over feature choices for the next breathless release. Ever.

Is it because the stakeholders never spend a second in the product support department, or listen to the teeth-gnashing of the tech writers and marketing copy writers as they return from a dev meeting trying to explain something in mere words that was built around an esoteric mental model? Or because the feature’s reason to be is based not on user research but on ‘coding coolness’.

I asked one developer to tell me who was supposed to understand a feature they were building. Answer: “Me and Tim.” Attempts to introduce a more accessible mental model failed because there was ‘not enough time’. Or maybe there weren’t enough Tims.

Is it because the same copy writers fail in their ability to explain the qualities of the user experience, or what the UX actually is to begin with? That is admittedly a tough problem. How does one explain breathing, anyway?

It is hard to explain user experience as a feature.

It’s because we all overlook the difference between quick judgements (e.g., usability evaluations) and long-term use (e.g., a beta trial). Malcolm Gladwell in his book Blink spent a good 45 pages with the issue of market research, and came up with the notion that we often ask questions that are exactly wrong for the important issues. The key comment the UX professional hears is there is not enough time. Not enough time for what? To do the job right?

UX designers chime in – what is your take? Same? Better? Worse?