design | UXtraordinary

Home » design

Posted by alex on May 22, 2012 in design, strategy

Actual, practical UX strategy

Paul Bryan, of the LinkedIn UX Strategy and Planning group, contributed There is no such thing as UX strategy, on UXmatters. Bryan’s clearly got a handle on the subject, but some of the user responses (“This UX Strategist role should be a skill of a PO;” “I thought we decided there was no such thing as UX Strategy…and that UX was strategy?”) revealed a widespread lack of understanding on what it is and who should do it (and no, it’s probably not product owners. A PO truly gifted in UX is not only extremely rare, but has many non-UX roles to fulfill. Adding this to their plate is the wrong call.)

While I agree with Bryan’s thesis that there should be better understanding and use of UX strategy, but in the article he behaves as though this is a goal. Having seen UX strategy happen and consciously done it myself for the better part of a decade, I submitted the following comment:

It is real, and it’s happening in some places. I think the reason for the confusion lies in lack of definition about not simply what UX means, but what strategy means.

For me – and I’ve been doing user experience under one title or another for over 14 years now – UX is “everything that is the case;” it’s everything the user experiences in the context of your brand. Designing good UX is not possible without understanding product strategy; designing great UX is not possible unless product strategy integrates UX strategy. Frequently the only person who can do that is the UX designer, unless you’ve hired product people with design backgrounds, which is rare. User experience rests on the three pillars of user research, usable IA/UI/IxD, and purpose-driven vision. You have to understand your users’ goals, your client’s goals, and be able to bridge them.

So there are different flavors of UX strategy, and a good UX strategist uses them all at different times.

Brand-integrated user experience design that is not only usable and delightful, but actively furthers the brand. For example, it’s not enough to simply provide a space for a promo on a page; the UX designer should help drive which promos will not hurt the purpose of the page, and may even increase user value and enjoyment. You have to integrate the web, print, TV, off-site advertising, enewsletter, and other items to have an integrated UX strategy. (Yes, this does actually happen at times.)

UX evangelism strategy. Figure out how to get people thinking in user terms. At a highly numbers-driven social network, I introduced them to the concept of measuring not just user-generated content (UGC) but user-generated activity (UGA), lumping it all under user-generated experience (UGX). Product owners and others measured UGA on their own, which forced them to think from the user’s perspective.

Research-driven UX strategy. In the example in the second bullet, UGX became a strong driver of overall UX strategy – we consciously presented activities to users in a particular order, based on user research and testing, designed to both optimize their experience and increase the ROI on their activities. We also studied communication patterns of UGA and UGC, determining where the best user value and ROI lay there as well.

Road map strategy. As user advocates and researchers, UX strategists can contribute significantly to road map work. For example, putting on our analytic hats we can show product strategists how to objectively measure concepts they tend to consider intangibles, such as competitiveness. We can also show how UX focused strategies such as the ones above can be integrated into their road map for the benefit of both user and company.

Last but certainly not least, there is perspective-drive UX strategy. Here, the underlying narrative/perspective of the users on the site should drive UX strategy. For example, examining user personas recently to get the unifying “hook” behind a software app, I realized that while the users themselves were very different in many key ways, they were all concerned with the same ultimate goal. It’s actually not in the app itself, but putting that goal first in my design immediately became the underlying theme/narrative behind all my UX choices. If a design choice doesn’t further that goal, it’s probably the wrong choice, and it’s out.

These are some of the many aspects of UX strategy I’ve used, and I’m sure I’m not the only one. While which ones work for you depend on your role, good UX designers should probably consider all of them as much as possible in our work.

Thanks for the great conversation-starter.

Posted by alex on Aug 25, 2011 in design

Seen in the wild: infographic from National Geographic

An analysis of a lovely infographic from the July, 2011 issue of National Geographic (not my work). The subject is the average daily time spent sleeping by a variety of animals:
animal sleep infographic by National Geographic
Click for larger image.

Reasons to like it:

Shows both % of the day spent sleeping, as well as exact hours.
Adds iris/pupil patterns of the various eyes.
Evokes the concept of sleep with the “eyelid” sleep indicator.
Includes our species for context.
Provides information about the subjects used (all adults, all except humans in captivity).
Sorts from least to most to increase ease of comprehension. Of course, the issue here is not whether it’s done in descending or ascending order, just that order makes it more intuitive.

The only change I might make would be to combine the lines of text at the top and bottom, but this may be driven by a style standard. In any case, it’s a small issue, and doesn’t hurt the clarity of the graphic.

Posted by alex on Jul 13, 2011 in design, strategy

Google+ and evolutional UX

There’s an exchange in the film Little Voice which left a deep impression upon me as a designer.

In the pre-caller ID era, a woman has missed a call. She recently had new phones and service set up, and a phone technician visiting tells her to dial a code to get the number she missed. She dials the code, hears the number, and immediately says, “So you don’t get the name, then?” In other words, she’s just been told about a useful new service she didn’t even know existed, and already she’s disappointed and has an improvement.

This is one of the many reasons I don’t believe in pixel-perfect design. UX is about constantly reaching for perfection, not settling back and presuming you’ve accomplished it. The moment “perfect” UX encounters a user, the user and the environment change in response to it, and “perfect” needs to evolve.

Google gets this. Geek.com reports that Google+ is already responding to user critiques and feedback.

You may think Google could sit back and watch the Google+ network grow, but that would be a mistake. The search company has realized it can’t just watch what happens, it needs to respond to users quickly in order to keep them happy and the network growing.

Nice to see they’re not resting on their laurels. Intelligent designers evolve ;–)

P.S. Thanks to Shannon Brown for sharing the link—on Google+, of course!

Posted by alex on Jun 30, 2011 in design, psychology, strategy

Why Google+ works

I am thrilled to see Andy Herzfeld’s social circles concept implemented so beautifully in Google+. My semi-educated guess is that empowering users to define access to themselves according to their own purposes and needs—in context—will build engagement and strong loyalty. Why? Because it comes naturally.

Too many social media-based sites, including many social networks, provide only lip service to how users think about groups, let alone user privacy empowerment. A user is seen as one of their members, and the business creates a mental model in which the user is the center of a series of widening circles. “Empowerment” of user content privacy is typically limited to enabling permissions control within those circles.

Users don’t see themselves that way. People think of sharing information in terms of a constantly changing algorithm of need, purpose, and ability. We trust some friends more closely than others; we have acquaintances who know a great deal about us whom we barely know. It’s my belief that these clashing mental models are one of the primary reasons social media and social networks fail to engage.

Click for larger image.

Some examples of groups which don’t fit the standard business mold:

Trusted acquaintances. To get a job, we may need to share detailed background information with people we barely know but must trust out of necessity: human resources, drug testing representatives, recruiters. We also share a great deal with doctors, literally putting our lives and health in their hands, without knowing them very well.
Interest-based friends. We have friends with whom we choose to share everything, but we frequently have friends with whom we limit sharing to specific interests. Colleagues and fellow hobbyists are examples.
Family. These people know a great deal about us simply because of frequent close contact, which typically leads to close bonding and sharing. But as with interest-based friends, we may prefer to share some things, not all.
Unknown people. In a world in which job-hunting is becoming a lifestyle, people are sharing for an audience they don’t know yet. Potential employers, recruiters, customers, and business partners are often deliberately targeted by job-hunters.
Untrustworthy people. These may be ex-spouses, stalkers, etc. Some social networks allows you to block specific users, but many do not, and most sites which employ social media to enhance their business do not.

Natural grouping also allows sites to make the most of niche parts of their audience. Too many times I’ve seen sites imagine the majority of their users to be their primary audience, neglecting more highly focused and engaged groups. These long tail segments of the audience were typically grouped more narrowly, and interacted between themselves much more highly than the generic larger groups, but were neglected because of their size. My recommendation in this situation? Don’t neglect smaller active segments, learn from them. Enabling natural grouping allows the larger, generic audience to begin to sort itself into smaller, more actively engaged segments. In other words, don’t cut off your long tail to spite your site.

A few sites have allowed natural grouping, with great success. Back in 2003, before Facebook even existed, LiveJournal introduced easy-to-create custom friend groups to control content privacy. For example, my custom groups include writer friends, fellow techies, female friends, specific users, and more. LiveJournal also allows users to filter their friend content according to these groups. It’s more than a blog, it’s a social writing platform. This, along with a highly usable interface and solid branding, creates an experience that still commands a great deal of loyalty from a strong user base. It’s not Facebook, but it was never meant to be.

Google+ is likewise not Facebook. Nona Aronowitz at GOOD observes,

I see Google+ as serving a completely different function. Facebook and Twitter can mobilize, organize, and disseminate information. It can and will continue to help journalists, politicians, and activists do their work. But sometimes you just want to hang with your friends, and when that can’t happen in real life, something like Google+ could be the next best thing.

Users are constantly tweaking their output—what they say, what they share online, what they do—to optimize their personal experience of the world. Designing for this provides a more natural way of interacting with others online. Online social networking shouldn’t have to be the end of privacy, or limited to artificially preset circles; it can be an extension of our normal behavior. Herzfeld and Google+ get that.

P.S. Since late 2008 I’ve been advocating natural grouping, empowering users to control access to themselves by their own purposes and needs. Some of the above was shared in a 2009 presentation, Designing for purpose.

Aronowitz, N.W., 28 June 2011. Could Google’s new social network actually improve our social lives?, GOOD.

Dash, A. Blog. Twitter.

Ong, J., 28 June 2011. Google gave original Mac designer free rein on new Google+ UI, AppleInsider.

Posted by alex on Feb 27, 2011 in design, strategy

Designing an antifragile UX: Part one

Nobody wants a fragile user experience. The thoughts that come to mind when you imagine such a site are probably buggy, not very usable, difficult to navigate, limited compatibility, and most definitely not user-friendly.

Now imagine a robust web app. This site would work across most if not all browser and devices, “gracefully degrading” when necessary. It would be usable, useful, and user-friendly, fulfilling the promise of site for the user. Bugs would be a rare event.

After reading Nassim Taleb’s antifragility discussion on Edge’s World Question Center, I think we can do better. As Taleb envisions it, an antifragile system is one that is “beyond robustness,” one that not only withstands disorder and change, but loves those things. Taleb provides an example:

Just as a package sent by mail can bear a stamp “fragile”, “breakable” or “handle with care”, consider the exact opposite: a package that has stamped on it “please mishandle” or “please handle carelessly”. The contents of such package are not just unbreakable, impervious to shocks, but have something more than that, as they tend to benefit from shocks.

So let us coin the appellation “antifragile” for anything that, on average, …benefits from variability.

In this and following posts, I’m going to discuss what the characteristics of an anti-fragile web app might look like. These include (but are not necessarily limited to):

A self-refining interface. The more browsers, devices, and user preferences it’s exposed to, the better it can refine itself, and predict or suggest the ideal UI for a given user with a given browser or device.
Self-refining taxonomy. A content strategy that benefits from variety and size. I’m convinced that in the post-Google, post-UX, post-social media world, semantic information management in all forms will be the next big thing. (Note: by post-Google, post-UX, etc., I don’t mean a world existing without those things. Rather, I mean the world that has thoroughly incorporated these and similar game-changing concepts and is ready to grow from there.)
Simplicity of structure, allowing flexibility of response.
Loves change. Learns from being used for new and unexpected purposes, adapting the new ability or use to improve or expand existing features.
The broader and more varied the audience, the more information there is to develop targeted content and interfaces.

Self-refining interface

What on earth is a self-refining interface? A self-refining interface is one that adjusts itself to user needs, either at an aggregate or individual level. Ideally it would do both.

Today we have a plethora of interfaces with which to browse the web. Notepads, smart phones, PDAs, laptops, televisions and more are used to present online information. There are even a few awkward-looking wristwatches receiving online updates, heralding the arrival of the smart gadget. The Pew Internet & American Life Project reports a sharp increase in adults using mobile devices to access the internet, as well as other online activities. Cell phone ownership is stable, but using phones for purposes other than phone calls is going up, up, up.

This marks the beginning of the end of pixel-perfect web design. No longer is there a single fold, above which content cues should reside; no longer can a company focus solely on meeting their audience’s needs by designing for the top three browsers across the top two computer operating systems. Graceful degradation is going the way of the dodo. Instead, we need evolutionary designs, adaptable to a variety of niches.

Companies who have already focused on this typically seek to determine the device being used by a particular user, then serve them content optimized for that device. Unfortunately, with the broad variety of devices in use, it’s difficult to accommodate all of them. Alternatively, they offer a “mobile” or “text-only” link, optimized for users with low bandwidth or smaller mobile devices. Again, we have only a couple of optimizations, and as user trends change, the developers behind a given web application or site must run to keep up.

Built-in design adaptability might work in many cases. For example, a combination of incrementally sized, wrapping modules and liquid layout could flexibly accommodate both broader and shorter resolutions (the Xoom’s resolution, for example, is 1280 x 800). Navigation could be persistent, but fly out on mouseover. Tricky to do, but not impossible. There is no “graceful degradation” because all resolutions are intended to happen. But this is merely robust.

What if the web application itself took this optimization a step further? Imagine these scenarios:

A site that actively analyzes user system demographics and develops UI and navigation options for a variety of interfaces; users can select their preferred default. Depending on the intelligence of the system, these could be based on persona types, or actually customized on a user-by-user basis.

Proactively personalized interface preferences. Based on a user’s interaction behavior, the site infers their content and navigational preferences and presents or suggests an interface matching those. Do they like clicking on tags? Perhaps a tag cloud-driven navigation should be integrated into their UI.

To be honest, I’m not certain what a truly antifragile user experience would look like. But I know we’ll never get there if we don’t think about it; and thinking about it will bring us more robust UX along the way.

Smith, Aaron (7 July 2010). Mobile Access 2010. Pew Internet & American Life Project. http://www.pewinternet.org/Reports/2010/Mobile-Access-2010/Summary-of-Findings.aspx

Taleb, Nassim M. (2011). Antifragility—or—The Property Of Disorder-Loving Systems. The Edge Question 2011. Accessed 17 January 2011.

Posted by alex on Jan 13, 2011 in design

When designers are coders

In the ever-more-specialized web work world, UI (user interface) designers are frequently a “pure” career. They focus on the visual portion of UX, addressing issues such as branding and interaction design, but not taxonomy and coding. Design work can happen far in advance and apart from development, particularly in a waterfall development environment. It can happen in Agile, too, where a common solution to coordinating design and development is to have the creative work done a sprint or two ahead, a creative designer may find himself focused primarily on comps and web graphics, rather than prototyping or front-end coding. So long as both design and development are readily available to work through changes together once development kicks in, this can work quite well.

This specialization is a good work model, not least because it allows designers to be true experts in interaction, branding, etc. (Please note: I’m not arguing that either the specialist approach, or the shared roles—developer/UI/IA—approach, is better. Both have excellent advantages in different situations.) Such designers do not typically think of themselves as coders.

But they frequently are.

Many UI designers, particularly in the corporate world, work with a style guide. They frequently drive it, as style guides establish a visual language for the site. In the same way that someone flipping channels can frequently tell a CSI scene from a Law & Order scene without looking up the show title, the visual language of a site should set it apart as itself.

The style guide helps designers and coders do that. It’s a shared reference, in which the designers establish the visual and interaction requirements, and the developers create CSS styles to invoke those requirements on the page. This is where designers become coders.

Why does this matter? Because the tags a designer chooses become the code the developer uses, and the semantic impact of them goes beyond the visual interaction. Among other things, the semantic nature of code affects how it’s parsed by search bots, and how accessible it is to the visually impaired and other disabled users.

Designer-driven code happens in two ways:

specs

After designing interactions, creating comps, and obtaining buy-in from stakeholders or clients, there comes a point when a designer looks upon her work and knows that it is good. To ensure that it stays good when it gets translated into code, the designer then creates specs for the developers, frequently using a style guide to pick the appropriate tag or style for a given need.

It’s at this point that the designer becomes a de facto coder. Again, the tags a designer chooses become the code the developer uses. In this situation, designers must be careful to use the appropriate tag/style for the appropriate need. Header tags should be used for headers, and organized top to bottom—not used to create a visual distinction in non-header copy. If a designer chooses a header (H1-H6) tag for a visual style, the developer nests the copy within that tag, regardless of whether the content is a header or not.

So designers must be aware that when they use a header, or blockquote, or definition tag, they are telling the browser, bots, and other applications specific information about that content. Remembering this when creating specs helps considerably in producing semantic, searchable, accessible code. This should not be a burden to designers, particularly since organizational tags are limited but text styles are infinite.

creating the guide

Style guides are created in a variety of ways. Sometimes it’s a collaboration between development and design to create an entirely new brand from scratch, in which case it’s easy to develop a semantically sound guide. Sometimes it’s driven by design, and created by developers.

Sometimes it’s captured from an existing site, in which styles may or may not be semantically sound. For example, I worked in one place where header tags were viewed primarily as visual tools, and the same page might have five different H1 tags in five different styles, depending on the CSS-styled area of the page they were used. In such cases, developing a semantic style guide is more than simply changing a mindset, it’s a complex, large undertaking.

Semantically sound code makes sense. It’s easier to train new designers on it, easier to maintain as your site evolves, and sets your site apart to search bots as a more well-organized, user-friendly, likely-to-be-relevant source of content. Designers who are aware of the effect their styling instructions have on semantics will not only be better “coders,” they will be more valuable designers to their clients or employers—and most importantly, create better user experience for their audience.

« Older Entries