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.

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.

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?

I am trying to deepen my understanding of “social networking” by creating a classification system based on the user goal. As a test of the system, I have looked at many of the http://mashable.com/2007/10/23/social-networking-god/ examples to see if they would land neatly in the scheme.

Proper taxonomies are parent-child or type-subtype, where each subtype has the same properties or behaviors as the parent plus one or more additional properties.

I grant that this will not be an orthogonal taxonomy – there will be shared properties of course among siblings – I am attempting to classify a top level according to primary user goal – what sites would appeal to a player if they have a particular objective in mind?

LinkedIn for example would classify as Personal/Professional Marketing, but as one joins LinkedIn groups and makes contacts it can appear more like Shared Project or P2P.

BTW, to classify as an OC, I posit that players must have access to the social graph. An online job or resume bank therefore would not be a community, as a job seeker cannot befriend, and access the profiles of, other job seekers. Yahoo Groups and Google Groups likewise do not fit as a VC or an OC because the members are not directly knowable to one another within the group structure.

So here are the top-level categories with some of the http://mashable.com/2007/10/23/social-networking-god/ sites dropped in. In 90 minutes of reading the GOD list I found none that did not fit. The GOD list categories would be subsumed beneath these.

P2P. Objective: Knowing other individuals.
FaceBook, most avatar chat, Jambo, Amiglia, CafeMom, Cingo, Famster, Kincafe…

Personal/Professional Marketing. Objective: Persuading others to back your social agenda, furthering your career.
MySpace, LinkedIn, ImageKind, Doostang, mediabistro, Ryze, XING, Twitter…

Entertainment. Objective: play and win online games, listen to music, watch video…
World of Warcraft, Pandora, YouTube…

Shared Project or Support. Objective: cooperatively creating and learning approaches to RL activities such as work-related strategies, stock trading, horse betting; providing mutual support for RL problems a la an encounter or therapy group.
Connectbeam, MothersClick, Parentography…