According to a pair of articles on BusinessWeek.com, the social networking site Facebook.com attracted 11.5 million individual visitors over the age of 35 in June, more than double the number a year before. The growth of this segment is remarkable, given that the site was not open to all until late September 2006, and the increasing “graying” of Facebook is predicted to change the site’s character and content.
“I’m sick of users,” announced Josh Bernoff in
a recent blog entry, leading one to initially believe that he has joined the
ranks of indifferent (or outright hostile) developers, clients, and other uninterested
parties reluctantly associated with producing applications and websites. However,
Bernoff’s distaste is semantic, not social. He argues that the term “user”
emphasizes technology over relationships and encourages a flattened and skewed
view of the people interacting with the products. He challenges the readers to “try,
just for a day, to stop using this word. You’ll be amazed at how differently
you think about the world.”
Second
Story Interactive Studios, in its own words, “creates informative and
entertaining interactive experiences in the form of media-rich storytelling
presentations, online collections, interpretive installations, and
database-driven applications.” The company comprises a diverse team of creative artists,
writers, producers, animators and programmers who enjoy a work environment that
boasts both a screening room and a technology lab for experimentation,
prototyping and testing of their projects.
The Pathfinder User Experience Design team has written and published a whitepaper that was recently distributed at the annual Software 500 Conference in Boston, MA. The paper will show you how to combine Agile and UXD practices to get higher acceptance, fewer support calls, and return customers as well as define four key places in an agile development process where you can improve project success by integrating UXD practices into the Agile software development cycle. These techniques include the use of personas, taskflows, rapid prototyping, and iterative testing, among others, depending on the stage of development.
Continue reading "Integrating UXD with Agile--free whitepaper" »
Even in waterfall-based design and development projects, formal usability testing at the time the system is being finalized is essentially “too much, too late”: a time-consuming, labor-intensive activity yielding results that are frequently unactionable for the current release. Several iterative assessment techniques, however, can be employed throughout any process, providing timely insight and direction. These techniques are readily adaptable to the Agile methodology, and, with some minor adaptations, can in fact be regarded as “agile” usability testing methods. Low-fidelity testing, using paper prototypes (or even hand sketches) can provide a quick benchmarking, and can be incorporated into a scrum meeting.
Why is usability testing important in the Agile environment?
A crucial component of the Agile methodology is the practice of obtaining customer feedback after every iteration and then making functional changes accordingly. Introducing usability assessments at key points in the process can ensure that the users’ requirements will also be recognized and accommodated within the development process, at a point when any potentially off-course decisions can be corrected and improvements implemented.
The nature of Agile development is to focus on individual features and although the project “epic” attempts to preserve the big picture for the product, this view is nevertheless focused on the functional and business requirements, rather than on the holistic user experience. Usability testing can document and validate issues that may only be the opinions of the team.
Usability studies are experiencing a shift in geography. For some time now, there has been some consensus that a traditional, dedicated usability lab is an unnecessary expenditure for an individual organization. Of course, since we specialize in User Experience Design, including usability testing, it’s a moot point for us. But we’re not exempt from the cost factor, either.
The main driver for this movement is the availability of software such as Morae and Spectator. Even Mac users are getting into the game with a product called VisualMark. These products turn a couple of laptops into a portable usability lab at the fraction of the cost of a full, fixed installation.
Too often, usability testing is judged to be a “nice-to-have,” but dispensable within the time and budget constraints of a full design and development project.
This activity is often incorrectly perceived as being solely a formalized study that is time and labor intensive, with the potential to threaten the timeline and swell the budget. This is especially the case with the increasing dominance of Agile development methodologies, in which usability testing is thought to be a hindrance to the rapid iterative process.
However, there are many methods to elicit user feedback, both during development and pre-release. Here are the pros and cons of a few.
The growing partnership between user-centered design practices and the array of agile methodologies faces an impasse when it comes to usability testing. In a traditional waterfall approach, a formal usability assessment generally occurs close to release and is structured--and often perceived by clients--as a culminating Big Event. Consequently, the attempt to insert traditional usability testing events into the iterative agile process is viewed by developers as antithetical to their process.
Several interesting articles have been written that explore this topic. Uzanto's Jonathan Boutelle takes the novel approach that usability testing should be taken out of the hands of specialists, whom he feels filters the user insights and often fails to communicate them to the design team. His strategy is to solicit "a constant drip drip drip of insights" by recruiting a small number of participants from Craigslist and having them assess the system remotely. This, he feels, allows the developers to experience the insights first hand.
Continue reading "Usability testing in the agile environment: an overview" »
Leisa Reichelt has recently published a thought-provoking post on her site, disambiguity, titled "Yes, you should be using personas." She states that she's "come to the opinion that personas are incredibly valuable, but not for the reasons many people think they are."
Instead of functioning as a tool to justify design, she argues, personas should serve as the vehicle to communicate the user centered process to stakeholders. By involving the members of the project team in the creation of personas, as well as involving them in user research and testing, they will gain first-hand experience with the design process. And that is, I think, more compelling than having the UXD team create beautifully formatted artifacts in isolation and then present them with a flourish (and extended explanation).
The fundamental rationale that underlies the direct and observational techniques of user research is that a user’s actions speak louder than their words. As a matter of fact, as usability specialists we are trained to go beyond the surface of a comment and probe for the motivation that spurred the verbal reaction: if, for example, a user encounters an obstacle during a usability test, is the cause a design flaw or a unique characteristic of that individual? In my experience, many participants have an almost palpable desire to please the facilitator and avoid making “mistakes” during the assessment.
Similar to Amazon’s suggestive selling, e.g., “people who bought X also bought Y,” these sites group recommendations around a target book, band, or film. Liveplasma.com bills itself as a “discovery engine,” providing searches in multiple languages (English, French and German) as well as multiple English-speaking cultures (US, Canada, UK). The three English-language searches yield identical results; the distinction lies in the localized Amazon site that presents products associated with the search results.
After entering search criteria, consisting of keyword(s), category (artist/band, movie, director or actor), and country, liveplasma presents a detailed and visually compelling graphical “galaxy” of related products. The music search displays linked spheres, whose size indicate the relative popularity of the band or artist. Colors of the spheres link related bands. Movie maps display miniature images of the movies along with the titles.
Although liveplasma maintains that “data is grouped according to interest, style, epoch and other criteria that suggest somebody will like it,” I found the movie search disappointing: I selected a favorite film of a specific genre, and was presented with a tightly-related cluster whose commonality was that these highly disparate films had the same director. Peripheral links were akin to a six-degrees of separation connection, with the outer rings of the galaxy presenting some truly farfetched choices. I was hoping for a more three-dimensional group of recommendations that would also take genre into account. Clearly, the database is not nearly as extensive as that of the interactive movie database (imdb.com). The music search, as well, grouped bands and artists in self-evident and obvious relationships. I would find it difficult to discover new things I would like using liveplasma.
Usability of the site is compromised by the existence of a fixed search box/menu/product display that obscures part of the left side of the display. Although the user can zoom in and out, reducing the entire map to bypass the left panel leaves the data too small to be readable.
Next, the family of gnod: "A search engine to find things you don't know about."
Two days ago, Hitwise released statistics showing that Google accounted for 64% of all searches in March 2007. I would have assumed the percentage was higher, given the sheer ubiquity—and utility—of Google, whose name, like Xerox, has become synonymous with its function. The competition lagged far behind, with Yahoo search claiming 22%, MSN trailing with 9%, and Ask.com bringing up the rear with 3%. That’s 98% of all searches conducted during the period, and the significant factor is that all four of these search engines operate in essentially the same way, producing flat, one-dimensional lists of results.
Charles Knight, of Read/Write Web, writes a monthly article on the other 2%, offering his admittedly subjective lists of the Top 100 Alternative Search Engines. He’s careful to explain that these search engines are not to be considered head-to-head competitors to the multifunctional Google, but they make his list because they do perhaps a single aspect of search better than the behemoth. I decided to take a look at some of his picks.
The objectives of user and market research (should ideally) differ dramatically, the data combining to create a multifaceted profile of the audience as both customer and end-user of a website or application. User research traditionally begins with a discovery phase, in which existing market research is evaluated in order to determine high-level user groupings. This market research is traditionally quantitative, based on large-scale surveys and supplemented in some cases by focus group data, which is a richer source of information by virtue of providing actual verbatim, which is, in some cases, indirectly relevant to the usability specialist. However, user research is far less concerned with what a person says about a product than what they actually do with it. Thus, behavioral analysis—actual observation of the user, ideally in the authentic environment of use—is the most powerful research tool in designing an optimal user experience. A well-designed study, facilitated by a skilled usability specialist, yields layers of information that would be unavailable from a survey or group conversation.
Continue reading "The new market research is the old user research" »
Commenting on the debut of a recently redesigned metropolitan newspaper, blogger Steve Rhodes articulated a concern that certainly must strike a chord with many IAs:
. . .[T]he real problem is one that every redesign faces - that old lipstick on a pig thing. Unfortunately, nobody wants to improve the pig. It's not that hard to understand. Campbell's can change the label all they want, but if their soup still sucks, their soup still sucks. . .Redesigns always work around the edges.
My work at Pathfinder has been about evenly divided between working on new products and redesigns of existing sites and applications. The differences are considerable, both on the project level and in my individual approach and the tasks and challenges I face. Most clients seem to be under the impression that revising an existing product is a lesser undertaking: after all, they’ve got something built that hasn’t yet crumbled and collapsed. In discovery meetings, I’ve too often heard stakeholders say that “all we really needs is a facelift.” In other words, put some lipstick on this pig—slap a little look and feel on the GUI, maybe reposition a few buttons, and success is inevitable.
What they don’t realize is that bling therapy alone will probably damage the user experience more than it helps. Visual design is not simply creating concepts in Photoshop for the client to cherry-pick (“Oh, I like the navigation on Concept 1 with the color palette on Concept 3. Could you combine them?”). Visual design is as integral to usability as a solid, defensible, well-conceived architecture and flow: the two disciplines complement and strengthen each other. Invariably, an analysis of visual redesign brings deeper structural issues to the surface.
Fortunately, most clients understand—or can be persuaded—that a paint job, however skillful or artfully applied, does not in itself lead to a considerable improvement in usability. But colors and visual concepts are things that everyone can have an opinion on, and the appearance of a product makes the initial, most powerful impression to the stakeholders--especially the marketing department. It’s somewhat more of a challenge for us to engage them in taskflows and wireframes, but some of the most rewarding projects I’ve participated in were in the cases where the clients became true collaborators in the entire process. Understanding what makes their product or site better for users brings them closer to their audience and more sensitive to their needs. Ideally, everything we design should look good and work well, but if it doesn't work well, it really can't look good.
Although the concept of community has become an integral, high-profile component of the vision of Web 2.0, as an online system of communication and collaboration it is an elder statesman of the internet, preceding the birth of the World Wide Web. Message boards such as Usenet, created in 1980 (and now archived by Google), and electronic mailing lists such as Listserv, pioneered conventions that continue to thrive today, such as groups organized around specific topics and interests that promote spirited virtual dialogues. In fact, the popularity of flickr, YouTube and MySpace prove that communities can be centered around virtually any media. And while text-based innovations, such as blogs, RSS feeds, and collaboration tools such as wikis have expanded the options for participating in community, the basic principles for creating and maintaining successful communities remain relatively constant. Following are a couple of best practices for working on community features.
I’ve recently been working on a handful of websites whose philosophy is directly derived from Ralph Waldo Emerson’s observation that “a foolish consistency is the hobgoblin of little minds.” What these bedeviled sites have in common is a decentralized structure in which many content managers contribute information in many variations. Although this is generally a practice associated with corporate intranets, a recent project of mine involved a large consumer website.
Generally, the standard way to at least encourage—and hopefully, ensure—consistency is to develop a limited set of page templates and a detailed Style Guide that spells out the global and local guidelines. However (and this is especially true on intranets), these guidelines often become a challenge to the originality of the technically savvy, who with some knowledge of HTML or similar tools, can often subvert the norm to create their own, original layouts.
Intranets pose an interesting question regarding site-wide consistency, because in most cases, users probably will not be navigating across the entire site, focusing on their vertical (Marketing, IT, etc.) and a short list of general tools and resources, such as timesheets and travel arrangements. With that assumption, do the unique demands of the vertical trump the restrictions imposed by a design that carries through sitewide?
There are relatively harmless variations and those that not only make the “mini-site” hard for its core users, but cripple the usability of the site as a whole. In the former category, I would place some visual design decisions (e.g., use of images or not). But I’ve struggled with sites in which the navigation scheme changes from area to area, the disappearance and reappearance of global navigation, and shifts in terminology, where one concept can have several names. Individual content managers should design locally, but think globally.
Chicago graduate student Kristin Thomas has found a creative way to recycle her spam e-mail by constructing poems using only the subject lines of the unwanted correspondence. “I don’t like to get angry, and I was starting to get angry,” Thomas says. “One day I was looking at all of this stuff in my inbox—something like 2,000 pieces of e-mail, none of it from anyone I knew. When I was scanning the subject lines, something caught my eye, and it just sounded like slam poetry. And I wasn’t angry any more. It was a peaceful way to resolve the issue—because spam isn’t going away.”
While I’m still waiting for my share of fifty (50) million dollars from my investment partner in Nigeria, Thomas “repurposes” her email headers and posts them on her website. In an interview in the Chicago Sun-Times, she shared one of her favorites:
“it counts”
3 Chicks in one night
(25 mg did the trick.)
3 hand made silk ties
3 dollars, each
4 out of 5 doctors recommend
5 financial tips for grads
6 times the action
7 minutes in heaven!
15 minutes of waiting and then
36 hours of pleasure!
Numbers never lie my friend
Numbers never lie
The opportunity and options for online user interaction span a continuum from the tightly controlled, such as moderated message boards, to the organic, dynamic and unconstrained: think of sites that are almost completely comprised of user-generated content, like MySpace, flickr, and YouTube.
Sites in the latter genre grew and thrived in an environment of chaotic autonomy. However, their success has raised their profile and invited the attention of the corporate sensibility; the prominence of YouTube, amplified by Google’s acquisition of the site, has resulted in a trend toward censoring or restricting contributor content. Sites such as Facebook and MySpace are now routinely mined by corporate recruitment firms in an attempt to screen out prospective job seekers that may present themselves unfavorably in the context of their college lives. More seriously, MySpace has come under criticism as being a resource for predators and in response has subsequently had to tighten the rules for contributors who are minors.
Recently, YouTube became Big Brother (albeit wearing the white hat) for members of the Franklin, MA police department, who posted on the site a surveillance video of two men allegedly using stolen credit cards at a retail chain store. “You don’t have to be a technology wizard to figure out how to watch a video on YouTube,” commented one of the officers, an observation that demonstrates the low cost of admission to community and social networking sites.
One suspects that the Wild West days of the self-generating, self-maintaining social network sites are waning, ironically due to their appeal. Community has become a commodity—so much so that site owners are rushing to incorporate features such as blogging, commentary, content ranking and other interactive enhancements on their sites. USAToday’s recent conversion to a socialized environment has created a tidal wave of criticism from current users (92% of whom dislike the redesign) as well as a lively dialogue on the concept of social design. As Martin Neumann observes, “People seem to consider the social, but don’t realize the design is what makes people want to be social. . . If you want people to interact and use your site as a social web tool than you have to make it inviting enough for them to want to do so. . .” Communities originally grew and prospered organically, linking participants through common interests and impulses. The hundreds of Usenet groups that still exist today are living proof of this. Corporate-driven communities—because they are created to serve business, rather than genuinely social needs—must be nurtured carefully and must retain an element of user control. To paraphrase an old saw, you can bring a visitor online, but you can’t force them to rank your content.
Research is an integral component of Pathfinder’s UXD methodology, and we strive to incorporate research strategies throughout the design process and beyond, into post-development usability assessments. However, some clients are confused by—or worse, resistant to—the idea of front-end “user research.” How, they ask, do our activities and findings differ from the analyses and resultant charts, graphs and PowerPoint presentations provided to the firm by the Marketing department?
The first stumbling block is largely semantic: many business stakeholders regard their customer segments as their “users,” and fail to make the (sometimes subtle) distinction between buyers, the target of market research and end-users, the focus of UXD consideration. In lieu of the term “user research,” several firms have adopted the title “design research,” thus taking the emphasis off the subject and placing it on the ultimate goal. While this is a step forward in clarity, it may present a different semantic stumbling block for those who think of design strictly in terms of visual look-and-feel.
After some brainstorming, our team came up with the descriptor “Behavioral Analysis.” We feel this term gets to the heart of the essential difference between market and user research—our goals are to observe and explore what people actually do, as opposed to what they might say in the context of market research. We see Behavioral Analysis as an inclusive rubric that includes our various techniques, including site visits, contextual inquiry, ethnographic studies and interviews, as well as usability assessments.
Certainly, there is no hard line between market and UXD research. Initiatives such as “Voice of the Customer,” in which cross-functional teams pay site visits to their customers to see their environment first-hand, is essentially a business-oriented ethnographic study. Market segmentation studies are the first step in the creation of personas, providing UXD a valuable roadmap for focusing their attention on potential interviewees. However, market research, no matter how thorough, can never substitute for front-end user research, and we need to make the distinction clear to our clients and articulate the value of both.
Since the fifteenth century, when Gutenberg’s press enabled the production and distribution of printed materials to the masses, technology has influenced not only our means of communication, but often, the very medium itself: language. This year marks the twentieth anniversary of version 1.0 of Powerpoint (interestingly, initially designed for the Apple Macintosh). Still supporting an older technology, the early releases of Powerpoint simply created pages to be used for overhead transparencies. The first Windows-based version appeared in 1990, and, in the view of Edward Tufte, quickly grew into a ubiquitous and malevolent influence that formulated new cognitive and aesthetic models constructed of a decontextualized, sequential series of choppy phrases and an appetite for “smarmy, chaotic, incoherent chartjunk” graphics.
The Web has provided a potentially universal platform for communication—a virtual printing press—and has even more strongly shaped the way we think, communicate, and even think about communicating.
The explosion of community sites, blogs and message boards have inspired multitudes of nascent authors to reach out and express themselves. E-mails not only function as direct communication, but are forwarded large-scale as electronic entertainment. The easy entry into this environment has relaxed the standards of formal written communication, much to the annoyance of “grammar queens” who zealously police the online world, pouncing upon errors in spelling and syntax. (Full disclosure: Former English teacher here.)
A burgeoning glossary of acronyms and emoticons have been developed to accommodate technology, whether to speed up online chat to approach the speed of actual verbal conversation, or to accommodate the small canvas of the text message. To a degree, this is Powerpoint regimentation redux: do so many people really LOL at the slightest suggestion of humor?
A recent AP article notes that Web newspeak has extended into the naming of products (think flickr) and on to websites and products themselves, which are increasingly boasting names derived from newly invented words: ikbis, joost, Woomp!, to reference only a few.
To me, the most moving example of the power of technology to change communication for the better concerns Amanda Baggs, a severely autistic woman who found her voice in the digital world. Her eloquent writings express the intelligence and sense of humor that she is unable to convey in verbal communication. Read her blog and enter a world that was previously inaccessible to outsiders.
Influenced no doubt by his experience as a conceptual design leader at IDEO, branko Lucik has created the “non object idea/philosophy/point of view/[and soon-to-be published] book” in what is touted as “the new genre of Design Fiction.” Lucik asks us to take the leap into a design environment free not only of the constraints and boundaries of factual design processes, but even the techniques most of us have come to rely on for guidance and inspiration.
The book’s website features a preview application of Design Fiction, the CUin5 telephone. The philosophy and product are showcased in a slick, very-nearly-sincere presentation which incorporates virtually every content and visual cliché currently available to today’s marketers. The manifesto preceding the product’s glamour reveal is stark and faux-provocative. The phone itself, whose image is zoomed upon and examined from every angle as though it were an inanimate subject of the paparazzi, is simultaneously plausible and ridiculous in design.
This ambiguity of product concept is subtly underscored by the rationale offered in explanation for the CUin5. The product, explains Lucik, pushes a typical set of product specifications “to the level of absurdity.” The rectangular handset features a keypad, microphone and speakers on each of its six planes, enabling users to access the device from any side without first needing to orient it properly. Imagine grabbing it quickly, Lucik muses—from inside your bag, from off a shelf, from under a car seat –-and freely interacting with it without needing to turn it over or align it right side up?
The operative fiction here—which, unfortunately, is too often fact in the world of our practical work—is the unchallenged assumption that product specs drive design exclusively; that, in fact, users are clamoring for a grab-and-go phone that is patently unusable. It would appear that the worlds are inverted—that in real life, bowing to the influences of poorly conceived business and technical requirements, we create artifacts of fiction.
In a recent Adaptive Path e-newsletter, Jesse James Garrett made the following appeal:
I'm trying to get one or more photos of my Elements diagram "in the wild"--that is, pinned to cubicle walls. I could stage one, I guess, but I'd much rather have the real thing. Can anybody help me out?
I first noted Garrett's interesting--and possibly revealing--association of cubicles with the untamed and uncultivated badlands--as IAs, we are capable of wreaking havoc, but generally maintain a somewhat civilized environment, as minimum standards go.
But, as a group, I do believe that we are creators and collectors of the artifacts of our craft, and indeed, I often find myself a meta-architect of my work: the taskflows, wireframes, and visual designs of each project are constructed, iteration by iteration, level by level on the foundation we refer to as "The Wall." We trace backwards through the project lifecycle in a paper-based archaeological "dig," peeling away the finished product to re-discover the initial pencil sketches and Post-it notes.
As for my own current, cubicle-bound "wild kingdom," personal real estate prevents a personal reproduction of Garrett's (patently architectural) Elements diagram, but I have used it as a visual reference in earlier days. Now, in the space I have, I've built a small thatch of project ephemera, office procedures, and an ever-changing set of Guiding Principles scribbled on scraps of paper.
Sorry, Jesse.
In his long-range studies, Mihaly Csikszentmihalyi has described the condition of "optimal human experience" as "being in the flow," a state in which a person is fully engaged and in control of an activity. Although Csikszentmihalyi never specifically applied the concept of flow to user experience, several practitioners have enthusiastically bridged this gap, among them Benjamin B. Bederson and Andrew B. King.
However, much of the work on flow in HCI has been concentrated on the web experience. As a matter of fact, Csikszentmihalyi's concepts are even more relevant to the design of applications. King notes nine dimensions discerned by people who have experienced flow:
It is not at all difficult to correlate most of these nine end results with the standard list of usability heuristic goals. Flow, then, is a desirable design goal, especially for applications and other task-based systems, as researchers Hoffman and Novak note:
"Less experienced users tend to see the web in a hedonic, playful way, while more experienced users tend to view the web in a utilitarian way, or a means to accomplish a task. The authors found that telepresence/time distortion, exploratory behavior, focused attention, and challenge/arousal correlated with recreational web use, while skill/control, importance, and experience correlated with task-oriented activities, such as research, work, and shopping."
As application designers, we are of course concerned with user workflows and system taskflows: we need also concern ourselves with the aspect of "flow" that occurs within the users themselves.
In the Cubicle of the Unknown Consultant, there hangs a homily captured from a well-circulated e-mail:
You know you have a job in technology if you need a PowerPoint presentation to explain what you do for a living.
Generally, user experience designers try to maintain a slim but firm boundary between themselves and, well. . . you know. . . technogeeks. After all, we're there for the users, not the elegance of the code.
But the identity crisis--and the inability to describe our role concisely--is an issue we share in common. I used to be a college teacher. Little or no confusion there, and a limited questionnaire: What subject? Which college?
Then I became an Instructional Designer. That provoked a bit more conversation, but when I met other IDs, I felt that I knew, in general, what they did. And, after some preliminary explanations (no need for PowerPoint), so did clients.
Then I entered the world of user experience. My first job title was "Cognitive Engineer" (cue the Devo mix). The title sounded scientific, alluding back to UXD's evolution from physical ergonomics. Still, it gave folks virtually no idea of how I spent my working day, or what I could bring to the table. PowerPoint presentation v1 was born.
During the boom, user experience proliferated, drawing talented people from backgrounds related through tangential. In my experience, few colleagues came equipped with formal training in HCI; however, they did bring relevant skills. Some team members were wireframing virtuosos, some transitioned from a visual design background, and others could code as proficiently as they could design.
Client expectations therefore varied wildly: does a single person architect and provide visual design? Does a usability expert also do HTML? Titles began to proliferate, compounding the confusion: am I an IA? an Interaction Designer? a User Experience Designer? What's the difference? Or are they all the same? How do we define ourselves to each other, to our users, and to the people who may be interested in what we can do for their sites and applications?
We've evolved way beyond PowerPoint narratives--it's crucial for us to delineate roles and their core competencies while retaining the uniqueness and synergy of individual skill sets, or we will invent a (user-unfriendly) geekdom all our own.
For all the benefits face-to-face usability testing offers, no one can argue that planning and implementing the study is often a labor-intensive logistical challenge. Recruitment can be difficult--we're often at the mercy of the pool of locally available partcipants. Renting or creating the appropriate lab-like environment also consumes time and money.
More and more, virtual testing is being employed. The benefits? The opportunity to select from a global participant pool, schedule sessions more efficiently, and allow for a richer and more authentic experience for the users in the study (who are assessing the application or website in their own surroundings, outside of an unfamilar usability lab environment.) Applications like Morae or WebEx capture detailed data such as keystrokes or cursor movements that even the most eagle-eyed facilitator may miss in the real-time session. There's also the ability to capture video of the participant's face and expressions.
The downside? The difficulty in establishing the bond between facilitator and subject that creates the trust required in all good usability sessions. As often as we say "We're not testing you, we're testing the system," many participants inevitably feel that their performance is the focus. Ideally, I start my sessions with a pre-interview, both to capture participant demographics and to get a feel for the user's interaction style. That relationship is hard to create on a conference call.
As designers, we spend lots of time and thought on optimizing our users' experience. One common goal is to save the user's time and effort, to make tasks easy. But, as we all know, easy is hard. There's lots of grunt work and trial-and-error behind an elegant design.
And is ease-of-use always desirable, anyway? Surely, we expect challenges and roadblocks in a good game application. In this genre, "User Experience" arguably has a different set of standards. But a current client has illustrated the need for a judicious amount of user difficulty in the workplace as well.
Her company produces an application designed to create and manage vast amounts of data, with a crucial functionality designed to create reports. In two specific instances, she has advocated for making things a bit hard for the users (initially, at least). First, in the case of creating a report, she specifically cautioned against locating a "Submit" button near the area for selecting a report domain, and instead obliging the users to go through a short series of intermediary screens designed to filter down the selected data. The reason? Users have a tendency to select report criteria that may pull a majority of the database records, possibly resulting in reports that may run well over 10,000 pages. These screens serve as a cognitive intervention, causing a small amount of initial pain in exchange for the consequences of an unconscious and automatic reaction.
In the other instance, our client requested that we make the report function neither too easy nor too difficult, in order to provide clients with a variety of options in creating reports. Clearly, user control trumps a "one size fits all" model of speed.
Of course, gatekeeping should never be oppressive, awkward or frustrating for users. But neither should a taskflow or online process be so stripped down and streamlined that the user is propelled, unthinking, through the process windtunnel.
I've just completed the first of three days of usability testing for a new educational online subscription product. The multiple sessions are stacked consecutively; the 45-minute breaks I thought were ample in theory seemed to last as long as a single gasp today, as our team fought--not always successfully--an unfolding series of unfortunate technology events.
Still, I love the opportunity to do usability testing. I've been very fortunate in my career in UXD to have always worked in environments that did not create an unscalable wall between Information Architects and Usability Specialists.
If research, including usability testing, can be defined as "diagnosis," and creation, including wireframes, site maps, taskflows, and the like, comprise "design," these two complementary, yin-yang aspects support, validate and enrich each other. I love the opportunity to play both of these roles, to wear both hats. I think it's made me better in each, and takes me back to my early education in arithmetic, where we "proved" the accuracy of any single answer through the complementary operation--the division problem was proved through multiplication, the subtraction problem through addition.
Usability testing diagnoses design. It's the analysis of user reaction as opposed to the creation of user action. Diagnosis looks outward to the users, acting upon the design; design looks inward, to the designers acting in lieu of the users.
Sometimes, it seems that the role of User Experience Architect is 90% management and 10% actual design.
And there's lots to manage: user requirements, development schedules, business requirements, stakeholder expectations, schedules, timelines, and overall expectations. It's been frequently observed that the UXD is the liaison among all project participants. Truly, all roads to a given project lead through the focus of the user.
As a consequence, we mediators often become bargainers. I'm sure all of us have had to negotiate our design to conform with the myriad demands of the community of project stakeholders. We've given up the fight for a slick, appealing rich interaction for the sake of an overstressed timeline; have gone for the low-hanging, quick design hits in lieu of a more holistic and integrated design approach whose benefits may be more of an investment than an immediate showcase.
But some design recommendations are non-negotiable. Budget be spent, timelines be extended--we fail to justify our worth (and collaborate in our lack of ready acceptance) if we compromise on some critical practices.
Here are some of mine--I'm sure all of you can add to the list.
1. Coherent navigation: An astronomical percentage rate of abandonment is associated with poor navigation on a website. This directly, and concretely, correlates to lost revenue on an e-commerce site, and only inversely impacts response rates on lead generation sites (i.e., improve the nav, improve the response rate). With applications, though, where users are often captive users, the erosion of usability is less direct, but nonetheless actual. It's almost a karma thing: what goes around (or fails to), comes around (or fails to).
2. Knee-jerk rebellion. As designers, we shouldn't adopt the personas of sulky fifteen-year-olds. Conventions endure for a reason. Especially on sites and apps. They cut through clutter and noise, and allow users to focus in on the heart of their tasks. Sure, we could all make our buttons into links, and links into drop-downs, and display diagonal navigation, but that's design that serves the designer--not the users. An electric light switch is dowdy and plain, but I can rely on what it will look like and what it will do, from sea to shining sea.
Of course, if I'm in Vienna or Tokyo or Rio, that switch is likely to look very different (although it serves the same function), which leads me to. . .
3. Xenophobia and the Ugly American Compulsion. Face it, we're good at thinking we set the standards for the world, and the statistics regarding internet usage bear out--at least for now--US influence and dominance. But that's changing--quickly. China will soon ascend as the country with the largest percentage of the population online. But it's not a simple case of "majority rules." Cultural differences are sometimes subtle, sometimes glaring, but always meaningful. In designing a website or application nowadays, it's best to assume global, rather than local, standards. This filters down to the smallest IA aspects, such as forms: most of the world doesn't conform to the US convention of <city>, <state>, <ZIP>.
Qualified member of an elite class that includes the eternally regifted fruitcake of Christmases past, the Star Wars movie franchise, and the fervent hopes of the diehard Cubs fan for a Series sweep, the 800x600 resolution is truly one of those Things That Will Not Die.
We presume a dismissive, somewhat disparaging persona for the user with yesterday's browser: either very young, undeveloped in either manual dexterity or a sharpened sense of aesthetics, or, god forbid, over 45, eyesight failing, faltering in the doddering twilight of the wired lifespan. Conveniently, these two groups are usually of secondary importance--if at all--to the marketing folks targeting the high-profile general demographics.
Nevertheless, this user, who today represents barely 5 - 10% of all users (and dwindling all the time), maintains an extraordinary grip on website design even today. Our own website is currently optimized for 800x600, and I regularly design to these standards, often on projects that are likely to be of little interest to second-graders or their grandparents.
Of course, there's a catch. Designing for 800x600 in a world of 1024x768 and beyond is still a good practice. Indeed, with screen monitors achieving larger and larger footprints, a good many users have accustomed themselves to multiple, partially minimized windows, as Jennifer Kyrnin's ad hoc user research suggests. Also, widgets and navigation add-ons can subtract signficant real estate from even a fully maximized, higher-resolution browser. Finally, as several designers have observed, if a layout doesn't work for 800x600, it probably won't improve at double the resolution.
Luckily, formal usability testing offers us the opportunity of conducting a near-scientific study of stimulus and response. We're able to cull prospective users from a pool of particpants, and screen them against a carefully chosen list of attributes, including gender, age, computer literacy, and other specific qualifications--much more discrimination than the "real world" of users and links and happenstance allows.
When it comes to initial requirements gathering, though, we often (in the words of Tennessee Williams), "depend upon the kindness of strangers." There are at least three types of early user researh/requirements gathering whose success often depends upon the enthusiasm or engagement of the client. It follows that this pool of resources must be evaluated through the filter of operative agendas. Here are three examples of user research that can be potentially valuable if all factors are considered.
1. Subject matter experts - an incredibly valuable asset for building site or application content. Always keep in mind that the SME's time is constrained. Keep your questions open-ended, but focused on the task.
2. Stakeholder interviews - keep in mind that the client probably has an incentive to obtain "buy in" with these interviews. While much independent data can be garnered from these interviews, pay close attention to the client's needs and goals with these interviews.
3. "User" interviews - at an early stage in the project, these people are probably anticipated or target users. Don't lose track of capturing data to build personas and actual user scenarios.
The practice of user experience design frequently involves the invocation of rules, guidelines, tenets, and not a touch of folk wisdom. There are several plausible reasons for this. UXD derives from the cultures of many previous disciplines: architecture, physical ergonomics, psychology, to name a few--and each discipline comes equipped with its own doctrines. More importantly, we strive to focus on the science as well as the art of UXD, and as practitioners, I think we often bend over backwards to position our findings as objective and standards-based, and not as a collection of personal opinions emanating from a range of individual perspectives (not that there's necessarily anything too much wrong with that--after all, user experience is our expertise. Do we ask for a heuristic review of the beef brisket from our butchers?)
If any commandment is central to the spirit and philosophy of UXD, arguably it's Arnie Lund's enduring admonition--heck, it's even framed Biblically:
Know thy users, and thy users are not thyself
It's a good guideline, of course: as user experience designers, we often know far too much about design, and far too little about actual user experience. But I've often found that sufficient user research is the ideal rather than the reality, for numerous and varied reasons. Sometimes, stakeholders see user research as the one point of resistance in an otherwise acceptable project plan--they simply can't see the value. Or, potential users are unavailable. I've encountered two common reasons for this--confidentiality of the project prevents the inclusion of users in research because of speed-to-market or the need to keep aspects of the site or application completely confidential. Or, the product is being designed for a foreign or distant market, and the logistics (and budget) simply can't support field studies or task analyses.
But we've discovered workarounds for obtaining information in the absence of "warm bodies." Proxy users--often project stakeholders--can be successfully separated from their personal points-of-view, and their domain knowledge can be leveraged. Friends-and-family research is also a rewarding path--as a group of designers, one of us usually knows someone (who knows someone?) who can fill in to help supply the user persona.
And the idea of personas and scenarios is key in reinterpreting Arnie Lund's directive: after all, simple knowledge of the users is not sufficient--it's how you apply this information to the design strategy that's the important application.
To paraphrase Walt Kelly's Pogo, sometimes we've met the users and they are us.
Currently, I've been tasked with writing up our team's recent projects, for the immediate purpose of publishing these stories on our website to support our marketing efforts. Using case studies for this purpose is a recognized, and arguably successful, way for designers to document their successes and describe the ways a good design has contributed to a good software product or website.
But I always wrestle with the narrative. What is the story we want to tell? How design, detached from the larger context, was appropriate, optimal, on-target and on-budget? Shades, perhaps, of "the operation was successful, but the patient died"?
Classically, a case study provides an opportunity for providing "an exemplary or cautionary model." A good case study should equally document the mistakes and the milestones, the lessons learned as well as the goals achieved.
Does this alter the tenor of the corporate case study? Hopefully.
I confess to being an amateur quote-collector. While I don't immortalize these succinct and sage sayings on pillows or wall hangings, I find them useful and thought-stimulating appetizers in telling the story of user experience design. They can surprise us with their obvious common sense ("Easy is hard"), delight us with their elegance ("why couldn't I express it like that?") or reaffirm our own realities.
Here are some of my favorites. First, a pair of thoughts from Don Norman:
I prefer design by experts - by people who know what they are doing
The people who use your product are not usually amateur designers
Treasonous words from a recognized advocate of user-centered design? I don't think so, recalling a former client who punted signoff on several critical design issues by saying "Let's wait until user testing to make a decision." Design should be user-centered, not necessarily user-created. For as Margaret Meade, among others, has observed:
What people say, what people do, and what people say they do are entirely different things.
Or, John Meades:
You need to "listen deeply" - listen past what people say they want to hear what they need.
As designers, we must translate our perceptions of user requirements into efficient design and not merely act as clairvoyants for messages from the world of the users. That is the skill, the value we bring to user research.
To end this post, a quote I introduce into as many presentations as I can, because it's simultaneously a threat and a home truth of the olden days of design:
We will go into your houses and redesign them the same way your web sites are designed. The basement will be the first thing you see, the kitchen will be unreachable except through the bedroom and both bathrooms, the bedroom will be on six different floors, and the dog will be in every room at once. - Ann Feeny, Information Architect's Manifesto
What are your favorite words of wisdom?
"Flow" is an attribute we're talking about--and, hopefully, designing towards--here at Pathfinder. As application designers, we've been captive eyewitnesses to the proliferation of contradictory and unrelated features that consititues progress in IA and development.
Design theories of flow are derived, directly or indirectly, from the work of psychology professor Mihaly Csikszentmihalyi, who has dedicated over two decades to developing a theory of "optimal experience."
We've recently shared some of our thoughts on flow at the IA Summit and World Usability Day. Other perspectives include those of Kathy Sierra, the academically focused ACM, and designer/blogger Scott Berkun.
Plus, an interview with The Man Himself in Wired, titled (you guessed it) "Go with the Flow."
Back in the days of rigid gender stereotyping, Lily Tomlin observed that if we all grew up to be what we wanted to be, the world would be full of firemen and ballerinas.
I don’t recall aspiring to either of these vocations (too timid for the first, too tall for the other). More to the point, I never thought I’d eventually evolve into. . .ummm. . . whatever we’re being called today. Being WOTTI (Way Older Than The Internet), my education and professional expectations were defined in areas that seemed remote from technology, interface design, or usability. With degrees in English Literature and a late-blooming resistance to a life in academia, I began to accumulate the quixotic resume of the Liberal Arts graduate.
Eventually, I spent several years as an Instructional Designer (ID). As the internet boom gained increasing momentum, the small technology consulting company where I worked was acquired by a large technology consulting company, and our quirky New Media group was reinvented as the firm’s semi-quirky User Experience practice. Then, as now, we sought to crystallize our identity—and affirm our corporate value—by creating a clear, hopefully self-explanatory job title. I wince to remember that in the mid-90s we called ourselves (without irony) “Cognitive Engineers.” Now, “Information Architect” has gained currency, a title that retains the methodical and craft-like aspects of the role, while successfully distancing practitioners from the inevitably Devoesque connotations of spiky, mass-produced cogs and hand tools. To stay billable, “cognition” and “engineering” are two concepts that should not be paired on the same business card.
Actually, a background in ID is great preparation for a career in UXD. Both disciplines are solidly user-centric and require creativity as well as technique in planning and development. The two key goals of the Instructional Designer are to optimize content for organization and understanding and to determine learning goals and appropriate success metrics—both of which are important but often overlooked strategies in designing websites and applications.
The successful Instructional Designer has the ability to quickly understand and then effectively communicate information from complex knowledge domains. Although I’ve designed web-based training for neurosurgeons, you probably wouldn’t want me brandishing a scalpel in your OR. I may not be able to do—but I can teach. Our firm specializes in the design and development of complex applications, requiring a learning curve that approaches the perpendicular. This skill is valuable to me as a consultant as well as a designer.
I respect my colleagues who have had the benefit of formal training in HCI. I’ve had to create my own curriculum through reading, workshops, and work experience, and I wish I’d had the opportunity to study and experiment in a more cohesive and less project-driven way. But I admire—and have learned from—my peers who have come to UXD from more scenic routes. Certain disciplines have obvious synergies and commonalities—architecture, visual design, marketing, computer studies. But I know fantastic UXD practitioners from other backgrounds: quantum physics, music, healthcare. UXD is not an easy-entry profession, but it is one that welcomes the experienced traveler. I recently met an Information Architect with background and training in theatre, who feels that the persistent thread in her experience is the love of narrative—whether storytelling takes place on the stage or on the (computer) screen.
Maybe my friend and former colleague Jason lives in the best of all possible worlds: his undergraduate degree is in English, he has deep experience in development, and he’s recently completed his Master’s in HCI at DePaul. But who’s to say which of these experiences makes him an excellent User Experience Designer?
Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."
Here's an extract:
So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.
The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:
Something is usable if it behaves exactly as expected.
That's it! That's the whole story! As Hillel said, all the rest is commentary.
One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.
It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise, self-evident and facile. His use of the passive voice is revealing:
". . . if it behaves exactly as expected."
Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.
User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"
It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?
Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.
Wireframes and paper prototypes work well in documenting the standard page metaphor of the Web, as the functionality of each screen can be captured in a single wireframe. Rich interactions, though, pose the challenge of expressing a series of states that may occur on a single screen.
As technologies like AJAX gain greater popularity, designers face the challenge of exploring and developing new and innovative visual vocabularies and flexible tools for capturing the microflows of rich interactivity.
At Pathfinder, we are drawing inspiration from the discipline of storyboarding, which is, of course, closely related to wireframing. Storyboards express ideas in a sequence of "key frames," showing only the minimum number of frames to convey the idea. The richness of storyboards comes not from just the individual pictures, but from the change from picture to picture. It's possible, then, to embed a miniature storyboard into a wireframe, thus illustrating the quality of the rich interaction.
A second technique is to create a visual taskflow representation to the system. In this format, all screens are miniaturized to capture both the linear and non-linear flows within individual screens and from screen to screen.
Our fellow practitioners are tackling this challenge as well. Bill Scott considers several strategies for creating interactive wireframes, including the PowerPoint clickthroughs, the development of quick and easy RIA toolkits, and standardized notations to indicate interaction effects in traditional, static wireframes. His personal technique involves the creation of storyboards in Visio, which he then animates. The strategy is detailed in his blog entry, "Interactive Wireframes: Documenting RIAs."