Bolt | Peters recently collaborated with Stanford University’s Bill Behrman on designing the Google Sites template for local governments to use as a backup to deliver information on the H1N1 outbreak, and also disasters and emergencies in general. The goal was to create a template that was well laid-out, easy for non-techie local governments to edit and update with content, and conveyed the most important information to different audiences.

How It Started: The Quick Fix
With the recent outbreak of H1N1, Santa Clara County’s official public flu information site was taken down by the surge in web traffic. To help relieve the demand, the Stanford SIE Program, a Stanford University group that develops technology for social change, stepped in literally within hours of the interruption to create an ad hoc backup site using Google sites, so people could still access the critical info.

This is the version of the site they originally posted, using Google Sites’ standard WYSIWYG editing tools:

Stanford’s original stopgap design

After the site went live, Stanford trained the Santa Clara County maintain it and add their own information. Santa Clara County needed to have site that could handle the traffic and get the information out as quickly as possible—which is to say that there wasn’t a whole lot of time to think about design.

This experience made it clear that it would be valuable to create a well-designed, easy-to-edit template for local governments to distribute information in case of emergencies—not just H1N1, but any public hazard, including floods, earthquakes, wildfires, and so on.

Bill contacted us in late October with the original draft of the website. Since it was important to make the site available as soon as possible to deal with the ongoing H1N1 outbreak, so the timeline we had for design recommendations was really brief—just a few days. With that in mind, we got to work.


Spotting the Problems
Because of the layout restrictions, our design evaluation focused primarily on information design. We had two main issues with the early design, along with a handful of usability tweaks here and there.

1. Lack of visual hierarchy.

With two columns of equal width and mostly indistinguishable boxes filled with text, it was hard to tell at a glance what information was urgent, time-sensitive, or recently added.



2.
Big chunks of info, no
 organization
The info wasn’t grouped into meaningful categories—there wasn’t much visual or spatial distinction between contact info, prevention info, calls to action, and so on, making it difficult to zero in on information even if you know what you were looking for. Also, the info came in big blocks of unscannable prose, and deep reading is the last thing you want to do when you’re trying to learn about the tsunami headed your way.



3. It didn’t anticipate the distinct needs of the most critical user
segments.
 

There was plenty of good info on the site, but it was never clear who a given piece of info was for—you couldn’t scan the page headers and think, “Yeah, there’s what I’m looking for”. Instead it had a “general audience” feel to it; the info didn’t take into account that different groups might have different needs and different levels of urgency.


4. Buried info.

Vital info on vaccines, symptoms, and SMS / Twitter updates was absent from the front page entirely, lurking deep in the navigation.


Our Recommendations
To keep editing simple for the local government end-users who would be using the template, we had to stick to using the WYSIWYG Google Sites editor, which meant no custom CSS and very little control over layout. We also had literally a single day to make our recommendations and synthesize them into a first-draft mockup—the result wasn’t pretty, but got our main info design recommendations across loud and clear.




Our first stab at redesigning the H1N1 template


Redesign Goal #1: Prioritize information according to the urgency
of visitor need.
Our design takes into account that there are different “general public” user segments with different goals, and that there are tiers of urgency and priority. From most-to-least urgent, we identified these segments: * People infected with the flu: Immediate help / contact info * People worried that they might have the flu: Self-diagnosis * People concerned about catching and/or spreading the flu: Preventative measures and vaccine info) * People just curious, staying informed: Information about travel restrictions, public response, news updates, deep flu info

The structure of the site was altered to serve each of these segments: # We added a page-width alert box that would be displayed to convey urgent, time-sensitive info—this is a common feature on many of Google’s sites, as well as CNN.com. # A yellow-shaded box to give the highest priority group, currently affected individuals, clear instructions on what to do. # The left-column contains info on self-diagnostic and preventative measures for at-risk or concerned individuals. # The top-right contains info on vaccines; below is links to deep info, research, and update notifications. Though the Google Sites template didn’t allow us to resize the right column, we noted that it should be made smaller than the left column. # The left sidebar navigation was reserved for redundant quick links to most important info, as well as links to pages for specially affected individuals and organizations.

Redesign Goal #2: Reduce block text down to easy-to-scan lists
and chunks.
Cut the bureaucratic BS.
We broke down the block text to keep from overwhelming users with too much difficult-to-scan information upfront. Lists were kept to under 8 items long, unless they broken down into categorized sub-lists; text was kept under five lines. All information that couldn’t be condensed in this way was moved to lower-level pages, and linked from
higher-level pages.

Users don’t need to know what the mission statement and goals of the organization are; they just want to know if and how they are personally affected, and what they can do in case they are affected.


Redesign Goal #3: Use informative headers that directly address
user goals, and which give all users clear next steps.
All types of visitor (e.g. directly affected, at risk, concerned, just curious, administrative, medical, etc.) should be able to tell by the header if that information is “for them”. We tweaked the headers to make it clear what kind of info you could find in each section. We also made it clear what, if anything, each user segment needed to do: * Immediately affected individuals are given step-by-step instructions on how to deal with their
emergency situation(s). * At-risk individuals are given step-by-step information on preventative, precautionary, and self-
diagnostic measures. * Individuals seeking non-urgent information can be given supplementary external information
resources (by phone, online, and downloadable / printable) and means to stay updated (by email,
text, RSS, Twitter). * Urgent contact info is immediately visible in the right sidebar.

The First Revision
After we sent over our recommendations and mockup, Bill sent us a nice note a day or two later:
You’ve convinced us that we have to completely rethink and redesign the site from scratch, so
your style guidelines come at a very good time. I can’t thank you enough for opening our eyes to
how we can do this in a much better way. I think we can create a site that works much better than
the original site.

…and then a few days after that, Stanford sent a revised version over to Google, who worked with the design firm OTT Enterprises to create two new designs with some added visual design flourishes.

Unfortunately we don’t have permission to show you this revision yet (working on it), but it wasn’t bad—certainly cleaner and better organized, easier to scan, less dense. There was, however, a large distracting green gradient background, some empty space in the sidebar columns, a few stock photos, and a muddled color palette (green, blue, yellow, and gray).

Our second batch of suggestions focused mostly on visual design and layout. Just a few of them:

Visual Design

* Get rid of the gradient background; it’s distracting and confuses the emphasis on different parts of the site, since it runs behind multiple different elements. * Get rid of the green coloring, which is tertiary to the blue and yellow. Instead, use several shades of blue as the primary color and a little light beige or light grey as a secondary trim. Blue signifies authority, calmness, trustworthiness, etc., which are of course appropriate here. Notice how almost every major government agency’s website (including the CDC) uses dark blue and gray as the main colors. * Remove the stock images, including the CDC and Flu.gov widget images, which look like ads. The phone and email icons are fine, however. * Rather than images, make the content headers stand out with size and strong typography—”make the content the focus” is an old web design adage, and the content, in this case, is the flu information. Here are a bunch of sites that use typography, font size, whitespace, and bold layout to create emphasis, using few images [list of a bunch of websites].

Layout

* Header and upper-page content takes up way too much space—note that the important info (“If you or your child…”) doesn’t begin until more than halfway down the screen. Compress. * I like how Design #2 places the alert and contact info in the sidebar; in Design #1 the sidebar is wasted space. This frees up space to move important info (Vaccine and How to Care for Someone With The Flu) up to the right side. * This design consists mostly of links to deeper pages, but there’s definitely room to put more specific, useful info right on the homepage: symptoms, preventative measures, vaccine info (see our original design) * Get rid of the Contents box.

The Results
Stanford started over once again, aided by our style guide and input from OTT Enterprises. After further iterations in Google Sites, they handed it over to the Google visual designers, and here’s the before-and-after:

Google Sites template, super rush draft

Google Sites Public Health Template 1.0

Can you do better?
As with all things on the web, the template is a design-in-progress, and will be improved as time goes on. Stanford SIE is looking for feedback on the design, so here’s where you can send feedback for the Public Health template and the All Hazards template. Since these Google Sites templates are available to everyone, you can even make your own design edits and mock up improvements.

Or if you just think it’s great and you just want to use it yourself, here’s the complete list of links:

Google Sites Templates blog post


Public health sites:
Template
Example site
User guide


All hazard sites:
Template
Example
User guide
Stanford SIE site (we’re credited here!)


Note: Nate and Tony’s book on remote testing, “Remote Research”:http://www.rosenfeldmedia.com/books/remote-research/, will be published by Rosenfeld Media in 2010.

When the exciting opportunity to work in a post-bubble dot.com startup arose, I jumped to take it. I had the luxury of doing things exactly as I thought right, and for a while it was truly fantastic. I built a team with a dedicated user researcher; information architect; interaction and visual designers and we even made a guerilla usability lab and had regular test sessions.

Unfortunately, the enthusiasm I had for my new job waned after six months when an executive was appointed Head of Product Development—who insisted he knew SCRUM1 better than anybody. As the Creative Director, I deferred authority to him to develop the product as he saw fit. I had worked with SCRUM before, done training with Ken Schwaber (author1 and co-founder of the Agile Alliance) and knew a few things from experience about how to achieve some success integrating a design team within SCRUM. This required the design team to work a “Sprint” (month long iteration) ahead of the development team. But the new executive insisted that SCRUM had to be done by-the-book. Which meant, all activities had to be included within the same sprint, including design.

Requirements came from the imagination of the Head of Product Development; design was rushed and ill-conceived as a result of time pressure; development was equally rushed and hacked together, or worse, unfinished. The end of Sprint debriefing meetings reliably consisted of a dressing down of the entire team by the executives (since nobody had delivered what they’d committed to i.e. they had tried to do too much, or had not done enough). Each Sprint consisted of trying to fix the mess from the Sprint before or brushing it under the carpet and developing something unstable atop the code-garbage. Morale languished, the product stank, good staff began to leave… it was horrible.

This is an extreme example of where SCRUM went bad. I am not anti-Agile although I’ve been bitten a few times and feel trepidation when I hear someone singing its praises without having much experience with it. Over the last eight years, I’ve seen Agile badly implemented far more often than well (and yes, it can be done well, too). The result of this is mediocre product released in as much time as it would have taken a good team to release great product using a waterfall approach. In this article, I will describe Agile and attempt to illuminate a potential minefield for those who are swept up in the fervor of this development trend and want to jump in headlong. Then I will present how practices within User Centred Design (UCD) can mitigate the inherent risks of Agile and how these may be integrated within Agile development approaches.


Where did Agile come from?
Envisioned by a group of developers, Agile is an iterative development approach that takes small steps toward defining a product or service. At the end of each step, we have something built that we could release to the market if we choose to and therefore it can assure some speed to market where waterfall methods usually fail. Agile prefers to work out how to build something as we go, rather than do a waterfall style deep dive into specification and then finding out we can’t build parts of the spec for some reason e.g. a misjudgment of feasibility, misjudgment of time to build, or changing requirements.

A group of developers such as Kent Beck, Martin Fowler and Ken Schwaber got together to come up with a way to synthesize what they had discovered was the most effective ways to develop software – The Agile Alliance was born. It released a manifesto2 to describe its tenets and how it differs from waterfall methods.

Agile can be thought of as a risk-management strategy. Often developers are approached directly by a client who does not know what a user experience designer, information architect or user interface designer is. Roles such as these usually interpret what clients want and translate it to some kind of specification for developers. Without this role, it’s down to the developer to work out and build what the customer wants. Because Agile requires a lot of engagement with the client (i.e. at the end of every iteration, which can be as little as a week) it mitigates the risk of going too far toward creating something the client doesn’t want. As such, it is a coping mechanism for a client’s shifting requirements during development as they begin to articulate what they want. To quote the Agile Manifesto’s principles “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.


Why do people rave about it?
At the heart of what makes Agile attractive is the possibility of quicker return on investment for development effort, because we can release software earlier than we would have otherwise. In the short term, this is typically borne out. In the long term it can be too, though only when the team hasn’t fallen victim to temptation (more on that later).  Agile is also good at generating momentum because the iterations act as a drumbeat to which the team marches toward manageable deadlines. The regular "push" to finish a sprint ensures that things move along swiftly. Agile is also good at avoiding feature bloat by encouraging developers to do only what is necessary to meet requirements.

Because it emphasizes face to face contact for a multidisciplinary team, Agile tends to encourage contribution from different perspectives. This is generally a positive influence on, pragmatism, innovation and speed of issue resolution. The team is empowered to make decisions as to how requirements should best be met.


The Minefield
In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.


Mine 1: An unclear role for design
In the best cases of business approaching developers to build some software, some of those developers may have design skills. But that’s not a particularly common scenario. Many developers have also had bad experiences with designers who don’t know what they’re doing. It took a long time for the design profession to come to grips with designing for complex systems and there is still a deficit of expertise in this field. “Business people and developers must work together daily throughout the project” is another principle of Agile. Where does the designer fit into the frame?


Mine 2: The requirements gathering process is not defined
Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.


According to Ken Schwaber, SCRUM intends to be a holistic management methodology and leaves space for activities other than programming to occur within the framework of iterative cycles. But when organizations adopt SCRUM, too often the good parts of a waterfall process like research and forming a high-level blueprint for the overall design become the proverbial baby thrown out with the documentation bathwater. As the Agile Manifesto says, “Working software over comprehensive documentation.”2 Many latch onto this and don’t want to do any type of documentation that might outline a vision, even if in a rudimentary sense.


Mine 3: Pressure to cut corners
Implementations of Agile that put design activities within the same iteration as they must be developed, ensure designs are achievable in code. But they also put tremendous pressure on the experience design team to ‘feed the development machine’ in time enough for them to implement their vision. This can and does lead to impulsive design. So, what’s wrong with that? Well, nothing if you’re not adhering to user centric principles which suggest you should test ideas with end users before committing them to code.

Some assert that there are plenty of examples of best-practice interfaces to copy out there. So, why reinvent the wheel? Surely we can save time that way? Sometimes they’re right, but how will we know which best-practice interface works best in context with the user’s goals, with no time to test with the user? How can we innovate by copying what already exists? Before Google reinvented internet search, other search engines assumed a status quo which behooved the user to learn how to form proper search queries. It was institutional knowledge among the other search engines that this is how searching was done and customers simply had to learn to use it. Most people’s search results were poor at best. Then Google came along and realized what is now obvious. People just want to find what they’re looking for, not learn how to drive a search engine first. I’m not suggesting the other search engines could not have done what Google did sooner, but I am pointing the finger at a mentality which meant they missed the opportunity. Interestingly, Google is not known for its designers. It’s mainly a development house, but lots of those developers can clearly put a design hat on too.

There is absolutely nothing wrong with using Agile to produce results quickly; that is, if you don’t intend to release them on your poor, unsuspecting user without some usability testing. Just don’t be fooled that this is going to save you a lot of time if you want your new product to be right, because you will have to iterate to arrive at an appropriate solution. Alan Cooper has argued that this creates a kind of ‘scar tissue’ where code that has to be changed or modified leaves a ‘scar’ that makes the foundations of the program unsound.4


Mine 4: The temptation to call it “good enough”
Invariably when we have release-ready working code at the end of each cycle, even if it’s sub-optimal, there’s a strong temptation to release it because we can. Agile condones releasing whatever we have so long as it works. Sometimes, that means doing what we can get away with, not what is ultimately best for the user. Equally, if we do decide that a feature isn’t right yet, it’s amendments get fed back into the requirements backlog where temptation strikes again. Should we spend time in our next iteration on a feature that we’ve already got a version of? Or shall we develop something new instead? Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.



Mine 5: Insufficient risk-free conceptual exploration time
Iteration “zero” (i.e. a planning and design iteration prior to the first development iteration) can be used to do this and other planning activities. However, depending on how long this iteration is, the level of rigor applied to exploration may be insufficient. An argument used by some Agile practitioners asserts that a working example of a solution is the best way to validate whether it is the right one through exposure to the market. This ‘suck it and see’ approach bypasses an activity called “concepting.” Concept activities dedicate time to sketching different solutions at a high level and validating them in the rough with users before digging into detailed design or code. “Suck it and see” would have us just build it, launch it and see if it flies. This way, we’ve wasted time building something we will probably have to take apart or rebuild. The counter argument is: if it took as long to build as it would have to research and design before laying a line of code, then we break even. This statement is a stretch in practice because development itself usually does take longer than well-managed design research and conceptual exploration. Also, there has to be some level of design regardless  of which methodology is used, and this adds days to the timeline.


Mine 6: Brand Damage

Let’s just say that design and research takes the same amount of time as development for argument’s sake. In the worst case, we completely miss the mark with the non-researched and designed solution and we have to start all over again. Then we’re back to the same total duration after developing it a second time, but there’s no guarantee we’ll get the solution right the second time either. All the while we’ve repeatedly foisted a botched product design on our users and adversely affected our brand. Many companies succeed on the back of their reputation for producing consistently appropriate products and services. When a company releases a flawed product or service, then their image in the customers mind (i.e. brand) is tarnished. Brand damage takes far longer to mend than it does to make. Software creators that fall victim to the temptation of "good enough" and fail to innovate through conceptual exploration put their companies revenues at risk. In a competitive market, repeated failure to meet user needs well leads to serious brand and subsequently financial repercussions, as other companies who do get it right take the business.


Agile is good for refining, not defining.
If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.

But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.


User Centered Design
UCD requires iteration – design, test with users, refine, test with users again, refine… repeat till it’s right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming you’ll need to change things, and that’s a good thing when it comes to refinement.


Uncovering requirements to form a strategy
User Centered Design (UCD) is not about answering requirements alone, but also includes defining requirements. When we practice UCD end-to-end, we pretend we know little. Little about what the solution to a problem should be; little about what the problem actually is because assumptions close us off to new possibilities. We prefer to allow some design research to create a viewpoint and then form a hypothesis as to what we might build. In this regard, we cross into the realm of product managers, producers, program managers, business analysts and the like, trampling toes with gay abandon and meeting resistance all around. Facing confinement to defining the boring old business need (distinct from the user or customer need), these folks would prefer we constrain our UCD work to usability testing on designs meeting the requirements they set out. They’d prefer we stick to just helping with development… and if we can do that quicker using Agile? Wahey!

Is it always appropriate to do extensive research before starting design? That’s a good question and one that Jared Spool’s Market Maturity Framework5 helps answer. Sometimes, just getting something off the ground, regardless of how precisely we meet user’s needs with it is all we can afford to do. Once we graduate out of this "Raw Iron" stage into "Checklist Battles" focused on getting the right features and then beyond, research is a core ingredient to putting our feet in the right place.

After researching what the user and business requires, we can make the “Strategy” tier of Jesse James Garret’s Elements of User Experience3which underpins everything we do during the project. Do this well, and you really shouldn’t come up with something that’s fundamentally wrong. Agile doesn’t account for this beyond a planning phase (i.e. iteration zero), which may well define a strategy of sorts. But does it really define the correct strategy? Surely, that’s created through careful consideration of three things:

1. Empathetic qualitative research that uncovers the user’s context, needs, goals and attitudes i.e. user requirements. Cooper suggests that the customer doesn’t know what they want and advocates a role of interaction designer as requirements planner.4 This would avert building to the wrong requirements in the first place, but the time to do this must come into the development lifecycle somewhere. It involves talking to users, preferably visiting with them in their environments to create experience models and user personas.
2. A thorough appreciation of what else in the big wide world exists in terms of products, features and technology that can be emulated somehow (not necessarily addressing a similar situation to ours).
3. A clear articulation of the business problem, objectives, success measures and constraints. Business people sat in a room discussing what they think should be done must be informed by all these things if the right strategy is to emerge. Agile doesn’t preclude that kind of consideration, but it does not mandate it either.

Concept Development
If we manage to built something usable and reasonably intuitive without research or strategy, did we succeed? Most MP3 players fit this bill but none took off like the Apple iPod. Leaving interface usability aside, the iPod had a service concept behind it which included digitizing, replenishing and managing your entire music library with iTunes. This was part of the iPod concept from the outset and in combination with good marketing and design, continues to eclipse the competition over seven years later. But that concept needed to be sketched and iterated at some point. If we don’t explicitly build this into our Agile methodology, we can miss that thinking time.




The best of both worlds
UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go. 





A shared vision of the interaction fundamentals
In good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms, i.e. not each and every navigation label, task or tool but rather the interface and interaction patterns that will persist. This produces something rudimentary to test with users to see if we got the big picture right. Following this roadmap sketched on the back of research and concepting prior to development activity, ensures consistency and cohesiveness when each component is coded separately to each other later. In many cases, the concept will need iterating to accommodate lessons from the journey. But we’ll at least have some indication of direction at a macro scale. Then, when in the midst of Agile iterations working out the details alongside our developer brethren, a level of expertise and experience is required of the designer because what we design will be built before we’ve had a chance to second-guess ourselves. Domain knowledge and an understanding of interface paradigms that work is also a big help. But to build new projects from scratch without a shared vision is a mistake.

Risky interfaces that are new or significant improvements on what has been seen before, are best tackled as design-only activities in a sprint prior to when they will be developed (i.e. do involve developers, don’t try to produce code). This circumvents the pressure to deliver something before proper thought, reflection and user testing, which ensures you’re not wasting time and effort. Sometimes most of the product will be done this way and that’s fine so long as developers and designers are still working together and talking every day. The first development iterations are an important time for the developers to lay the architectural foundations based on the vision. Designers should use this time to get a jump on any high-priority tricky interfaces so the development team isn’t waiting for something meaty to start on when it comes time to build features.

Most important to success, the business needs to accept that some things won’t be right the first time around and commit to iterating them prior to release i.e. not be led into the temptation to release something that’s not right yet.

Conclusion
In summary, dogmatic attitudes about each of these approaches should be avoided if they are to be combined. Remember, Agile does not mandate how to define concepts or overall design direction, but it is a great way to execute on solid design research and well laid plans. UCD needs to be flexible enough to respond to the reality on the ground when the implementation team encounters issues that mandate a different design solution. Document only what is needed to get the message across and co-locate if at all possible, because cross-disciplinary collaboration and face to face communication are vital. Working a sprint ahead of the development team is helpful in allowing the design team enough time to test and iterate. If these rules of engagement are followed, the two approaches can work very well together.

Notes:
1. Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle

2. Manifesto for Agile Software Development

3. The Elements of User Experience by Jesse James Garrett

4. Extreme Programming Vs. Interaction Design. Interview with Kent Beck and Alan Cooper

5. The Market Maturity Framework is Still Important – Jared Spool

Nowadays everyone wants social in their sites and applications. It’s become a basic requirement in consumer web software and is slowly infiltrating the enterprise as well. So what’s a designer to do when confronted with the requirements to “add social”? Designing social interfaces is more than just slapping on Twitter-like or Facebook-like features onto your site. Not all features are created equal and sometimes a little bit can go a long way. It’s important to consider your audience, your product—what your users will be rallying around and why they would want to become engaged with it and each other, and that you can approach this in a systematic way, a little bit at a time.

These concepts derive from a book I wrote recently with Christian Crumlish, “Designing Social Interfaces”:http://www.designingsocialinterfaces.com/. They are quick and easy things to remember when infusing social into your site. Each points offers some simple suggestions and points to consider when designing. Potential design patterns are recommended (and linked to) as examples for what could be done in your interface as you design and grow your service. Keep in mind that your context will dictate different specific solutions but the questions and concepts to think about will still be applicable.


Step 1 – What’s your social object? Make sure there is a “there” there. Give users a reason to rally. Why would someone come to your site?
Most people are drawn to a site based on their particular interests, in hopes of learning more or meeting others like themselves. They may be looking for information or they may have information to share. They have a passion—such as making handcrafted jewelry or taking landscape photographs—and at some point, they will want to share that with other people. That passion, that thing that people rally around is often referred to as the social object. It’s the object around which conversations emerge and thrive.

Remember that sometimes, the social object is a person – or the conversations between people. But don’t forget history (remember Friendster? or SixDegrees?), if the only thing to do is build a profile, people will eventually go somewhere else to have conversations or to do things around objects of interest.


Step 2 – Give people a way to identify themselves and to be identified.
This can be as simple as an “attribution”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Attribution line when contributing and signing content.

Attribution of a comment on flickr


It could be an “identity card”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Identity_Cards that shows a little bit about the person and is attached to every thing they do or can be as robust and complex as a “full profile”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Profile that is linked from all their contributions. The method can start out simple and grow over time.

Identity or Contact card as seen on FriendFeed


It’s important to give people credit for their words and contributions. It helps others recognize their friends and disambiguate them from other people with the same name and builds a “reputation of quality”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Reputation or lack thereof for their participation on your service.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing.

Relationship module shown from MyBlogLog


Once you have given people the ability to identify themselves, allow them to “find each other”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Find_People and claim their tribe. “Relationships”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Relationship_terminology_%28friend%2C_family%2C_fan%2C_follower%2C_contact%2C_colleague%2C_connection%2C_cohort%29 make the world go round and online it’s no different.


Step 3 – Give people something to do.
Provide a path for participation so lurkers as well as early adopters can be engaged at the level of effort that is appropriate for them. Things like ratings (“1-5”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Ratings or “thumbs up”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Thumbs_Up/Down_Style_Ratings) are easy ways to get low participation people involved by letting them quickly register their opinion with little effort.

Thumbs up and down ratings for restaurants on GoodRec


Allow them to “share items”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Share_This they find interesting with their friends or family and “curate and collect their favorites”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Favorites. The latter requires a little bit more effort, but lets your users have ownership over what they find meaningful.

Flickr allows users to “favorite” images they like and collect them for display to others.


At the other end of the spectrum is full authorship of content with “reviews”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Reviews, “comments”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Comments, “blog postings”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Blogs_-_Ownership, and “wiki entries”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=The_Wiki_Way all the way through to participation as a moderator or guide in your service.

Wikimedia allows collaborative editing of content on sites built with the software.


Start simple, with light features, and gradually add more complexity if it is really needed. Keep the structure flexible enough for your users to mold and adapt to their needs. In the book, we discuss several principles related to this including “Deliberately Leave Things Incomplete”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Deliberately_Leave_Things_Incomplete, which reminds designers to allow features to emerge from the community behavior rather than forcing behavior to fit the UI and “Strict vs. Fluid Taxonomies”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Strict_vs._Fluid_Taxonomies which merges a strict taxonomy like your site navigation with user generated groupings and organization with features like Groups, Message Boards, Tagging, etc.

Allowing behavior to guide your features and giving your users ownership of the structure make the site much more personal for them which in turn encourages repeat and longer term usage.


Step 4 – Enable a bridge to real life (groups, mobile, meetings, face-to-face).
Don’t be afraid to build in tools that allow your users to bring their community into the real world. In many online groups, a majority of people know each other personally.

Upcoming shows local events and allows people to add events to their calendar and view events their friends are interested in.


Providing tools to help plan face-to-face meetings and then archive those happenings will strengthen your site and the community. Consider incorporating “geo” features like “GeoMapping”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Geo-Mapping, and “GeoMashups”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Geo-Mashing.

Additional features might entail creating “subspaces (groups)”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Groups and coordinating real time “face-to-face meetings”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Face-to-Face_Meeting and gatherings among users of your service.


Meetup lets people affiliate with groups of interest and the site helps coordinate real life – in person meetings and gatherings between members.


Step 5 – Gently Moderate. Let the community elevate people and content they value.
This can be through simple things like ratings or “reputation labels”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Labels.

Reputation labels on the intranet at Yahoo!


The community can help you surface contributions of quality which in turn should help attract future participants and will help keep the interactions lively. This process also helps push bad quality content down and out of sight.

Keep an eye on the community, participate yourself, welcome people as they join, set yourself up as a role model.



Hunch founder, Catarina Fake, acts as a role model for the community being built on the site.


Notice who is passionate and who is potentially causing trouble. Conversations should run their course. Let the “community moderate itself”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Group_Moderation and provide tools to allow them to do that, like allowing them to mark content as spam or block trolls or “report abuse”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Report_Abuse. Step in only when necessary.

Report Abuse is available on every comment in Yahoo! Answers and allows users to moderate the content quality.

Make sure people are aware of the “terms of service”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Terms_of_Service and “license”:http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=Licensing implications of content they create – both as it relates to your site as well as what they can permit others to do with their content.

Go out and get started
These are a few of the things to consider when building a social application or when adding social features to an existing site. There are a lot more features and concepts available within the social ecosystem but these should get you started and will build a good foundation from which more robust and complex features can be added to.

It is important to remember that you don’t have to do it all at once. You can apply features sparingly and let the community tell you when you need to expand. Consider the bare minimum while fleshing out your infrastructure. Add complexity as your community grows and scales. Remember that you are building a container for activity and conversation and that you don’t have to have everything figured out. The people will create their own paths of interaction making their own meaning and experience.

With more companies today putting a stronger emphasis on gaining a deeper understanding of their customer, it’s not unusual for us to be called in for a project to find that our clients don’t have a lot of experience with research and don’t know what to expect. This article is for every designer, architect, manager, engineer, and stakeholder who wants to know more about research and is intended to provide you with the most critical tools for interacting with researchers and understanding how the work that we do can make your job easier.

This article will also outline what to expect from researchers and some ways to recognize when you’re working with a good one. These are indicators, not standards, based on what we’ve found to be effective. There are many ways to do research and every research study is different so it doesn’t mean that a researcher is incompetent if he or she doesn’t conform to these indicators. One sign of a strong researcher is that he or she will educate you throughout the process so that you know what to expect. With that in mind this article is ultimately intended to provide a useful starting point.


Recruiting
One of the most critical and time-consuming elements of test preparation is defining the right target audience and recruiting participants. Participant recruiting is usually conducted by professional recruiters who typically consult databases of potential participants. Sometimes researchers will do the recruiting themselves, but it’s usually more cost effective to use a specialist.

Recruiting will almost always take two weeks or more depending on the number of participants and the type of research, so make sure that you get started early enough for the recruiter to have enough time to find the appropriate participants for the study. Recruiting for phone interviews may take slightly less time and any kind of home visit will likely take longer (ethnography or contextual interview). Your researcher should be able to provide you with an estimate at the time of initial engagement.

A week for recruiting tends to be difficult and any less than that is pretty much unthinkable. Short-changing the recruiting could result in participants that don’t properly fit the target market segment, don’t provide quality feedback, or just don’t show up at all. All of these can have a negative impact on the data. Even if it is possible to get participants faster, it’s usually better to take the time to ensure that you are getting the right people. Your researcher should know all of this and recruiting participants is where he or she will start after getting a basic understanding of your product and schedule.

A recruiter will need a screener to get started. A screener is a description of the target user with open and close-ended questions about the participant that will help the recruiter to select the right people. What you can do to smooth the process along is to have a prepared concept of your target user. This does not need to be a full market research report—just an outline of the types of users that will use your product.

Your researcher should dig deep with questions that include more than demographic information by asking behavioral questions. Behavioral questions can include such topics as TV watching behavior, purchasing behavior, internet use, etc. Typically behavioral questions will give you a stronger understanding of those who are being recruited than demographics alone. These are important elements of market segmentation that are sometimes organized into profiles called personas.

Personas are useful because they create a consistent concept of the intended market segment that can guide the design process through multiple iterations. Personas can also be adjusted following deeper discovery research, such as in-depth interviews, as more information about the intended user comes to light. Within a few days, the researcher should present a screener that includes behavioral questions as well as demographics.


Scheduling
When creating a schedule for data collection, the researcher should know that you cannot run participants back to back. It’s generally not feasible to squeeze in 8 one-hour sessions in a single day, because of all of the activity that must occur between sessions. In an eight hour day, a researcher can perform four (maybe five) one-hour sessions but any more than that will take more time. Here are the reasons why:

One-hour sessions rarely go exactly one hour, some are shorter and quite a few will run longer. This can be due to a variety of reasons such as the product malfunctioning, the participant arriving late, or the participant providing lots of feedback. My rule of thumb is to allocate 50% of the session length as a buffer between sessions to allow for overrun, not including time needed to set up for the next session.

For sessions at an office or lab, some participants will arrive 10-20 minutes early, at which time they will need to use the restroom, sign NDAs and consent forms, and generally get comfortable. Comfortable participants give useful feedback, while uncomfortable participants tend to clam up and provide short, unemotional responses.
The researcher needs to set up and get ready. For usability or experience testing, the test will need to be reset, notes and documents need to be filed and new ones prepared. For any kind of home or location visit, the researcher will need to pack up all equipment and travel to the new location and set up equipment again.

Thus for every one-hour usability or experience testing session, there’s forty-five minutes to an hour of buffer and setup time. Home visits can take much longer.


Test Plan
A test plan should take no more than a week to develop and the researcher should give it to you for review and approval before being finalized. The test plan should specify the research and business goals associated with the project. During this period the researcher will need a significant amount of time with the product, either with a prototype or available concepts, while writing and checking the test plan. The better the researcher understands the intended final product, the more valuable the information he or she can get from the participant.

For usability or experience testing, the researcher will test the tasks with the product prior to a pilot test. He or she will need to make sure that there are no glitches, no unexpected areas under construction, and nothing giving away future tasks when performing each of the tasks with the product. With that in mind, it’s important to give the researcher a stable product or prototype and avoid drastic changes to the product prior to the test.

You should receive a well-written and organized test plan that details each research question and how it will be addressed. For usability testing this will include a list of tasks, what each task is intended to examine, approximate wording for the task (avoiding leading language), and detail on how each task will be scored or evaluated. For discovery research, it will include a list of topics to be addressed such as processes, environment and context, and expected pain points and needs.


Data Collection
When the data collection starts, it’s important to let the moderator work. During this time, the participant should feel comfortable enough to open up and provide honest feedback. In order to do this, it’s important to try to minimize observer impact during the testing session.

If you don’t have a separate place to watch the session (e.g. behind a two-way mirror or through a video feed), don’t make it obvious that you are paying close attention. Think about bringing in a laptop during the session to make it look like you’re doing other work. One way of doing this is telling the participant that you are also a researcher but you’re just going to be taking notes.

When you’re observing, remain objective and don’t make judgments based on one or two participants. It’s not uncommon to see a couple participants have a completely opposite reaction to a product compared to ten other participants. The researcher’s job is to sort through all the noise and report the real trends in the research. Take what you see with a grain of salt and listen to your researcher.

At the same time, it’s important to try to observe as many sessions as possible and give your researcher feedback between sessions if there are certain aspects of the user experience you want to know more about. The researcher should put the participant at ease and extract a great deal of information, including details that might have been overlooked or emotions that the person experiences. Different researchers will tend to achieve this in different ways as everyone has their own style, but you’ll notice by paying attention to the participant and seeing if they feel relaxed or nervous throughout testing.


Findings
Frequently, stakeholders will want to make immediate changes to a design, product, or prototype and won’t have the time to wait for the researcher’s final report. People have schedules that need to be met so it’s understandable that a project can’t always wait for the final report but the researcher should be able to provide you with quick findings within 24 hours of the last session.

For usability research, these quick findings should consist of a couple of short paragraphs including problems in the interface, possible solutions to these problems, and participants’ general reactions to the product, its look and feel, and expected usage. For ethnography or other forms of discovery research quick findings will tend to consist of expected usage of the product, expected value, high and low value features, and general trends about the intended user. Quick findings aren’t comprehensive and come before the researcher can get a complete look at the data, but it will provide you with the overall themes from the study.

When you do get the final report, make sure you take a look at it. It will tell you two things: * Detailed findings regarding the interface, product, features, and intended user * The quality and clarity of the report will tell you quite a bit about the quality of your researcher.

There’s one other thing to keep in mind when you are processing the findings from a usability test. The participants will tend to focus on the more obvious problems with a product or interface. There could be other, smaller or more abstract problems that are not identified in the first pass of usability testing. It’s usually a good idea to perform another test on the product after making changes to ensure that the changes you made were effective and identify any additional issues.


Summary
In summary, here are the most important points for non-researchers to know about the research process: * Recruiting will almost always take two weeks or more. * For every one-hour usability or experience testing session, there’s forty-five minutes to an hour of buffer and setup time, home visits can take much longer. * The researcher will need a significant amount of time with the product (prototypes or concepts) while writing and checking the test plan. * Try to minimize your impact during the testing session. * Remain objective and don’t make judgments based on one or two participants. * Ask your researcher to provide you with quick findings within 24 hours of the last session.

Any comments, feedback, or suggestions are very much appreciated.

A big part of information architecture is organisation – creating the structure of a site. For most sites – particularly large ones – this means creating a hierarchical “tree” of topics.

But to date, the IA community hasn’t found an effective, simple technique (or tool) to test site structures. The most common method used—closed card sorting—is neither widespread nor particularly suited to this task.

Some years ago, Donna Spencer pioneered a simple paper-based technique to test trees of topics. Recent refinements to that method, some made possible by online experimentation, have now made “tree testing” more effective and agile.

How it all began
Some time ago, we were working on an information-architecture project for a large government client here in New Zealand. It was a classic IA situation – their current site’s structure (the hierarchical “tree” of topics) was a mess, they knew they had outgrown it, and they wanted to start fresh.

We jumped in and did some research, including card-sorting exercises with various user groups. We’ve always found card sorts (in person or online) to be a great way to generate ideas for a new IA.

Brainstorming sessions followed, and we worked with the client to come up with several possible new site trees. But were they better than the old one? And which new one was best? After a certain amount of debate, it became clear that debate wasn’t the way to decide. We needed some real data – data from users. And, like all projects, we needed it quickly.

What kind of data? At this early stage, we weren’t concerned with visual design or navigation methods; we just wanted to test organisation – specifically, findability and labeling. We wanted to know: * Could users successfully find particular items in the tree? * Could they find those items directly, without having to backtrack? * Could they choose between topics quickly, without having to think too much (the Krug Test)1? * Overall, which parts of the tree worked well, and which fell down?

Not only did we want to test each proposed tree, we wanted to test them against each other, so we could pick the best ideas from each.

And finally, we needed to test the proposed trees against the existing tree. After all, we hadn’t just contracted to deliver a different IA – we had promised a better IA, and we needed a quantifiable way to prove it.


The problem
This, then, was our IA challenge: * getting objective data on the relative effectiveness of several tree structures * getting it done quickly, without having to build the actual site first.

As mentioned earlier, we had already used open card sorting to generate ideas for the new site structure. We had done in-person sorts (to get some of the “why” behind our users’ mental models) as well as online sorts (to get a larger sample from a wider range of users).

But while open card sorting is a good “detective” technique, it doesn’t yield the final site structure – it just provides clues and ideas. And it certainly doesn’t help in evaluating structures.

For that, information architects have traditionally turned to closed card sorting, where the user is provided with predefined category “buckets” and ask to sort a pile of content cards into those buckets. The thinking goes that if there is general agreement about which cards go in which buckets, then the buckets (the categories) should perform well in the delivered IA.

The problem here is that, while closed card sorting mimics how users may file a particular item of content (e.g. where they might store a new document in a document-management system), it doesn’t necessarily model how users find information in a site. They don’t start with a document—they start with a task, just as they do in a usability test.

What we wanted was a technique that more closely simulates how users browse sites when looking for something specific. Yes, closed card sorting was better than nothing, but it just didn’t feel like the right approach.

Other information architects have grappled with this same problem. We know some who wait until they are far enough along in the wireframing process that they can include some IA testing in the first rounds of usability testing. That piggybacking saves effort, but it also means that we don’t get to evaluate the IA until later in the design process, which means more risk.

We know others who have thrown together quick-and-dirty HTML with a proposed site structure and placeholder content. This lets them run early usability tests that focus on how easily participants can find various sublevels of the site. While that gets results sooner, it also means creating a throw-away set of pages and running an extra round of user testing.

With these needs in mind, we looked for a new technique – one that could: * Test topic trees for effective organisation * Provide a way to compare alternative trees * Be set up and run with minimal time and effort * Give clear results that could be acted on quickly

The technique—tree testing
Luckily, the technique we were looking for already existed. Even luckier was that we got to hear about it firsthand from its inventor, Donna Spencer, the well-regarded information architect out of Australia, and author of the recently released book “Card Sorting”:http://rosenfeldmedia.com/books/cardsorting/.

During an IA course that Donna was teaching, she was asked how she tested the site structures she created for clients. She mentioned closed card sorting, but like us, she wasn’t satisfied with it.

She then went on to describe a technique she called “card-based classification”:http://www.boxesandarrows.com/view/card_based_classification_evaluation, which she had used on some of her IA projects. Basically, it involved modeling the site structure on index cards, then giving participants a “find-it” task and asking them to navigate through the index cards until they found what they were looking for.

To test a shopping site, for example, she might give them a task like “Your 9-year-old son asks for a new belt with a cowboy buckle”. She would then show them an index card with the top-level categories of the site:

The participant would choose a topic from that card, leading to another index card with the subtopics under that topic.

The participant would continue choosing topics, moving down the tree, until they found their answer. If they didn’t find a topic that satisfied them, they could backtrack (go back up one or more levels). If they still couldn’t find what they were looking for, they could give up and move on to the next task.

During the task, the moderator would record: * the path taken through the tree (using the reference numbers on the cards) * whether the participant found the correct topic * where the participant hesitated or backtracked

By choosing a small number of representative tasks to try on participants, Donna found that she could quickly determine which parts of the tree performed well and which were letting the side down. And she could do this without building the site itself – all that was needed was a textual structure, some tasks, and a bunch of index cards.

Donna was careful to point out that this technique only tests the top-down organisation of a site and the labeling of its topics. It does not try to include other factors that affect findability, such as: * the visual design and layout of the site * other navigation routes (e.g. cross links) * search

While it’s true that this technique does not measure everything that determines a site’s ease of browsing, that can also be a strength. By isolating the site structure – by removing other variables at this early stage of design – we can more clearly see how the tree itself performs, and revise until we have a solid structure. We can then move on in the design process with confidence. It’s like unit-testing a site’s organisation and labeling. Or as my colleague Sam Ng says, “Think of it as analytics for a website you haven’t built yet.”

So we built Treejack
As we started experimenting with “card-based classification” on paper, it became clear that, while the technique was simple, it was tedious to create the cards on paper, recruit participants, record the results manually, and enter the data into a spreadsheet for analysis. The steps were easy enough, but they were time eaters.

It didn’t take too much to imagine all this turned into a web app – both for the information architect running the study and the participant browsing the tree. Card sorting had gone online with good results, so why not card-based classification?

Ah yes, that was the other thing that needed work – the name. During the paper exercises, it got called “tree testing”, and because that seemed to stick with participants and clients, it stuck with us. And it sure is a lot easier to type.

To create a good web app, we knew we had to be absolutely clear about what it was supposed to do. For online tree testing, we aimed for something that was: * Quick for an information architect to learn and get going on * Simple for participants to do the test * Able to handle a large sample of users * Able to present clear results

We created a rudimentary application as a proof of concept, running a few client pilots to see how well tree testing worked online. After working with the results in Excel, it became very clear which parts of the trees were failing users, and how they were failing. The technique worked.

However, it also became obvious that a wall of spreadsheet data did not qualify as “clear results”. So when we sat down to design the next version of the tool – the version that information architects could use to run their own tree tests – reworking the results was our number-one priority.

Participating in an online tree test
So, what does online tree testing look like? Let’s look at what a participant sees.

Suppose we’ve emailed an invitation to a list of possible participants. (We recommend at least 30 to get reasonable results – more is good, especially if you have different types of users.) Clicking a link in that email takes them to the Treejack site, where they’re welcomed and instructed in what to do.

Once they start the test, they’ll see a task to perform. The tree is presented as a simple list of top-level topics:

They click down the tree one topic at a time. Each click shows them the next level of the tree:

Once they click to the end of a branch, they have 3 choices: * Choose the current topic as their answer (“I’d find it here”). * Go back up the tree and try a different path (by clicking a higher-level topic). * Give up on this task and move to the next one (“Skip this task”).

Once they’ve finished all the tasks, they’re done – that’s it. For a typical test of 10 tasks on a medium-sized tree, most participants take 5-10 minutes. As a bonus, we’ve found that participants usually find tree tests less taxing than card sorts, so we get lower drop-out rates.

Creating a tree test
The heart of a tree test is…um…the tree, modeled as a list of text topics.

One lesson that we learned early was to build the tree based on the content of the site, not simply its page structure. Any implicit in-page content should be turned into explicit topics in the tree, so that participants can “see” and select those topics.

Also, because we want to measure the effectiveness of the site’s topic structure, we typically omit “helper” topics such as Search, Site Map, Help, and Contact Us. If we leave them in, it makes it too easy for users to choose them as alternatives to browsing the tree.

Devising tasks
We test the tree by getting participants to look for specific things – to perform “find it” tasks. Just as in a usability test, a good task is clear, specific, and representative of the tasks that actual users will do on the real site.

How many tasks? You might think that more is better, but we’ve found a sizable learning effect in tree tests. After a participant has browsed through the tree several times looking for various items, they start to remember where things are, and that can skew later tasks. For that reason, we recommend about 10 tasks per test, presented in a random sequence.

Finally, for each task, we select the correct answers – 1 or more tree topics that satisfy that task.


The results
So we’ve run a tree test. How did the tree fare?

At a high level, we look at: * Success – % of participants who found the correct answer. This is the single most important metric, and is weighted highest in the overall score. * Speed – how fast participants clicked through the tree. In general, confident choices are made quickly (i.e. a high Speed score), while hesitation suggests that the topics are either not clear enough or not distinguishable enough. * Directness – how directly participants made it to the answer. Ideally, they reach their destination without wandering or backtracking.

For each task, we see a percentage score on each of these measures, along with an aggregate score (out of 10):

If we see an overall score of 8/10 for the entire test, we’ve earned ourselves a beer. Often, though, we’ll find ourselves looking at a 5 or 6, and realise that there’s more work to be done.

The good news is that our miserable overall score of 5/10 is often some 8’s and 9’s brought down by a few 2’s and 3’s. This is where tree testing really shines—separating the good parts of the tree from the bad, so we can spend our time and effort fixing the latter.

To do more detailed analysis on the low scores, we can download the data as a spreadsheet, showing destinations for each task, first clicks, full click paths, and so on.

In general, we’ve found that tree-testing results are much easier to analyse than card-sorting results. The high-level results pinpoint where the problems are, and the detailed results usually make the reason plain. In cases where a result has us scratching our heads, we do a few in-person tree tests, prompting the participant to think aloud and asking them about the reasons behind their choices.


Lessons learned
We’ve run several tree tests now for large clients, and we’re very pleased with the technique. Along the way, we’ve learned a few things too: * Test a few different alternatives. Because tree tests are quick to do, we can take several proposed structures and test them against each other. This is a quick way of resolving opinion-based debates over which is better. For the government web project we discussed earlier, one proposed structure had much lower success rates than the others, so we were able to discard it without regrets or doubts.

* Test new against old. Remember how we promised that government agency that we would deliver a better IA, not just a different one? Tree testing proved to be a great way to demonstrate this. In our baseline test, the original structure notched a 31% success rate. Using the same tasks, the new structure scored 67% – a solid quantitative improvement.

* Do iterations. Everyone talks about developing designs iteratively, but schedules and budgets often quash that ideal. Tree testing, on the other hand, has proved quick enough that we’ve been able to do two or three revision cycles for a given tree, using each set of results to progressively tweak and improve it.

* Identify critical areas to test, and tailor your tasks to exercise them. Normally we try to cover all parts of the tree with our tasks. If, however, there are certain sections that are especially critical, it’s a good idea to run more tasks that involve those sections. That can reveal subtleties that you may have missed with a “vanilla” test. For example, in another study we did, the client was considering renaming an important top-level section, but was worried that the new term (while more accurate) was less clear. Tree testing showed both terms to be equally effective, so the client was free to choose based on other criteria.

* Crack the toughest nuts with “live” testing. Online tree tests suffer from the same basic limitation as most other online studies – they give us loads of useful data, but not always the “why” behind it. Moderated testing (either in person or by remote session) can fill in this gap when it occurs.

Conclusion
Tree testing has given us the IA method we were after – a quick, clear, quantitative way to test site structures. Like user testing, it shows us (and our clients) where we need to focus our efforts, and injects some user-based data into our IA design process. The simplicity of the technique lets us do variations and iterations until we get a really good result.

Tree testing also makes our clients happy. They quickly “get” the concept, the high-level results are easy for them to understand, and they love having data to show their management and to measure their progress against.

You can sign up for a free Treejack account at “Optimal Workshop”:http://www.optimalworkshop.com/treejack.htm.2


References
1. “Don’t Make Me Think”:http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758, Steve Krug
2. Full disclosure: As noted in his “bio”:http://boxesandarrows.com/person/35384-daveobrien, O’Brien works with Optimal Workshop.

Introduction

When it comes to user interface documentation, wireframes have long been the tool of choice. However, using traditional diagramming tools like Visio, OmniGraffle, and InDesign, most wireframes today look the same as their ancestors did from a decade ago – assembled with rigid, computer-drawn boxes, lines and text. While these artifacts have served us well, they can also be slow to produce, burdened with unnecessary detail and give a false impression of “completion.”

To compensate for the drawbacks of traditional wireframes, many practitioners put aside the computer in favor of simple pencil sketches or whiteboard drawings. This speeds up the ideation process, but doesn’t always produce presentable or maintainable documentation.

#tableHeader {
color: #FFF;
}
#tableHighlight {
background-color: #E5E5E5;
}
.superscript {
font-size: .5em;
vertical-align: top;
}
.indent {
text-indent: 10px;
}
—>

There is a growing popularity toward something in the middle: Computer-based sketchy wireframes. These allow computer wireframes to look more like quick, hand-drawn sketches while retaining the reusability and polish that we expect from digital artifacts.

The same wireframe in sketchy and traditional representation.

The Traditional Wireframe Problem

Throughout a project lifecycle, wireframes can be used for different purposes depending on the stage. In the early stage, wireframes act as a tool for exploration and concept development, when sweeping changes are expected and encouraged. As the project continues, parts of the wireframe begin to be “locked down” as functionality is reviewed and “signed-off.” During this process, wireframes can become a confusing hybrid of conceptual ideas and finalized functionality. By the end of the process, wireframes can turn into a highly detailed functional specifications document.

The problem here is that traditional computer wireframing tools, like Visio, OmniGraffle or InDesign, lay out drawings as hard-lined boxes, lines and fonts. As a result, wireframes look the same regardless of which stage of completion the wireframe is representing. Early-stage, conceptual wireframes look identical to late-stage, functional specifications. This differentiation becomes especially murky in the middle of the project, where conceptual and final elements are comingled on the same page.

Sketching to the rescue?

To compensate for the drawbacks of traditional wireframing, some designers ditch the computer in favor of hand sketching. An informal poll by Konigi.com (as of 8/24/09) showed 22% of respondents identifying sketching as their primary tool for wireframing. Hand-sketching of wireframes, proponents argue, allows for faster expression of ideas and freedom from artificial confines of diagramming software. Sketches don’t require the same level of detail, and can be produced faster than traditional computer-based wireframes, allowing for a more iterative design process.

Why not sketch…

If hand-sketching has so many advantages over computer-based tools, why don’t we all ditch our mouse pads for sketch pads? There are four major reasons:

• Drawing ability – Wireframes are essentially presentation tools, and not everyone may feel that their drawing skills are “presentable.” In team environments, there can be a wide range of drawing skill levels… from the “can’t draw a straight line” people to the “can’t put down their sketchbook” people. This leaves a disparity in the quality of sketched deliverables produced by the team. Many organizations feel it’s best to standardize their deliverables by forcing everyone to use the same tool.

• Perception – When people become accustomed to seeing fully fleshed-out wireframes, introducing sketchy may be a challenge. Some may see the architect as suddenly becoming “sloppy” or “lazy.” In these cases, it is critical to sell the benefits of sketchy wireframes to stakeholders and opinion leaders.


In situations where wireframes are intended to live past the initial concept stage and turn into functional specifications documents or user guides, hand-sketching is not the most appropriate method. Hand-drawn sketches give the wrong impression of flexibility at later stages of development when the interface has already been “locked down.”

• Reusability – Hand drawing is great for getting ideas down quickly. However, when wireframe documentation is lengthier than a couple of pages or when the documents must be re-worked over a long period, sketching loses its speed advantage and becomes a burden. In an electronic medium, changes can be made across pages and documents very quickly.

• Prototype flexibility -Many practitioners prefer to go directly from hand-drawn wireframes to interactive prototypes, bypassing the more traditional wireframe process. However, in many situations, wireframes are used to generate interactive prototypes for proof of concept and/or usability testing. Hand-sketched wireframes are excellent for paper prototyping, but the amount of work involved increases quickly if they need to be scanned into the computer and converted into interactive prototypes. For on-screen prototypes, it is much easier to start with wireframes that are already in an electronic format.

Enter the computer-generated sketch

To compensate for the problems of both traditional and hand-sketched wireframes, certain programs allow you to create the look of hand-sketching with no drawing ability required, while retaining all of the benefits of a digital tool:

• The style gives the impression of a work-in-progress, yet still retains a “polished” feeling that aids in acceptance by the workplace


• Components are easily reusable for longer documents
• Wireframes can be re-purposed for interactive prototyping

Sketchy Wireframes in Action

I discovered the need for computer-based sketchy wireframes while working on the website redesign of a well-known print media brand. I found myself presenting wireframes to executives, who would critique them in the same manner that they would a print-spread: with a heavy focus on fonts, text placements and graphic treatments. Despite frequent disclaimers that the wireframes were for high-level discussion purposes only, each presentation would drift into fixations of irrelevant details. To accommodate them, I found myself spending countless hours polishing the wireframes to look beautiful, when I should have been spending time on concept development and user testing.

To make matters worse, as we removed features from the wireframes that were determined to be “out of scope,” we continued to receive requests to bring them back, right up until the end of the project. Clearly, the wireframes were not helping to convey the right message.

On the next project, I generated the conceptual-stage wireframes using sketchy Visio stencils created by Niklas Wolkert. I began all of my wireframe presentations with an explanation of why the wireframes looked like sketches: they were intended to be malleable, rough outlines. I also prepared the executives for the next phase by telling them that the sketchy look of the wireframes would be removed as decisions became “finalized.”

Caption: Comparison of the sketchy wireframe stencils by Niklas Wolkert (right) and traditional ones by Henrik Olsen (left) at guuui.com. Image credit: Henrik Olsen.

The improvement in the executives’ perception of the process was immediate. The boxes and lines of the wireframe no longer had to look perfect, and the hand-drawn fonts couldn’t possibly have been mistaken for an intentional design. The executives, feeling less compelled to fix the visuals, were free to talk at a high-level about architecture and strategy. As the project transitioned from concept to execution, I removed out-of-scope features and converted the style from sketchy to traditional. This virtually eliminated later-stage requests for functionality that had previously been removed.

The reaction to computer-based sketches

Having used computer-based sketchy wireframes on a number of projects, I’ve found many ways that they can decrease confusion with teams and stakeholders:

• Clients and Executives - People in this group typically want to push projects forward as quickly as possible. Consequently, the more “finished” the wireframes look, the faster they will expect to see the finished product. You can do yourself a disservice by making your wireframes look more complete than they are. To quote Kathy Sierra, “How ‘done’ something looks should match how ‘done’ something is.”

• Programmers - Programmers who see traditional wireframes too early in the process may misinterpret their functionality as “signed-off.” Don’t be shocked if you hear frantic questions like “Did we agree to this?” Programming requires meticulous attention to detail, so programmers read wireframes with an eagle eye. Consequently, they may expect a level of specification from wireframes that isn’t appropriate in the early stages.

• Designers - Designers make their living with their visual creativity, and they resist anything that could constrain it. Consequently, in situations where designers must work with wireframes created by someone else, designers can perceive them as a creative straightjacket, or worse, as a threat. A sketchy representation can help reduce friction by removing unnecessary details and adding a certain amount of “fuzziness” to the wireframes, thereby giving designers more leeway in interpreting the look and feel of the interface.

• Users - In my research, I’ve found that users who are asked to comment on traditional wireframes can be intimidated by an overly finished look and feel. This is mirrored by a general consensus in the usability industry that the “less done” a demo looks, the more comfortable users feel with giving feedback. Where traditional wireframes can elicit comments like “I don’t like the font on those words,” sketchy wireframes are more likely to elicit comments like “I don’t know what those words mean.”

Computer-Based Sketchy Tools

There are now a number of programs that are capable of generating computer-based sketchy wireframes. However, in working with them, I’ve found that many of them are missing what I have identified as four essential capabilities necessary to be considered a “complete” sketchy wireframing tool:

1. Ability to Draw New Sketchy Shapes -
   These days, many components of user interfaces are standardized into stencils that can be dropped onto wireframes to build them out quickly. While this can be a real time saver, not all UI problems can be solved with prepackaged stencils. In fact, one could argue that the best use of wireframes is to illustrate new concepts that have not become standardized. Many tools use pre-built, sketchy-looking stencils to allow designers to create sketchy wireframes. However, at some point you will need to create new shapes that aren’t available in your set, and a true sketchy tool must enable you to create new ones in the same sketchy style.


A sketchy tool should allow you to draw. These were created in Visio using custom line styles. This tutorial tells you how.





2. Easy Conversion from Sketchy to Traditional Style -
   Sketchy wireframes are a great tool for encouraging creativity, exploration, and collaboration. However, at some point, your blue-sky, creative ideas fall away and you are left with what you are actually going to build. In environments where wireframes morph into spec documents and user guides, those rough lines and hand drawn fonts must be converted to a more finished, traditional style to avoid the impression that your technical documentation is still changeable.
   

   Does this mean you have to go back and re-draw all of your sketchy wireframes with straight lines? Not if you can avoid it. Fortunately, certain programs allow you to convert your existing sketchy lines and fonts to traditional style without having to recreate them.

   
   Some software automatically converts from sketchy to traditional lines.
   

   
   
   

3. Realistic Lines -
   It’s always been difficult to approximate the look and feel of true hand-drawings using software tools, but some do it better than others. The quality of drawings generated by a computer-based sketchy tool could have an impact on whether the wireframes are perceived as “conceptual” or just plain “sloppy.” These are the 3 major components needed to completely represent hand-drawn styles in wireframes:
   

   • Wavy Lines – No human can match the rigidity of a computer’s lines. Adding waviness and movement to lines humanizes them.
   • Varying Line Weights – When drawing conceptual wireframes, there are often areas of the screen that have yet to be explored. One way to represent this is to fade out lines as they enter these areas.
   • Smudging and smearing – These effects help to reduce focus on unimportant areas of the wireframe.
   
   
   
   

   
   These lines, created in Fireworks with a graphite line texture, could hardly be mistaken for true hand-sketches.

   
   These lines, created in Illustrator, are much closer approximations of true sketching.

   
   
   

4. Prototype Flexibility – For those who prototype their products, speed and efficiency of workflow is a critical issue. In this case, the benefits of creating a sketchy look and feel will become irrelevant if doing so increases the time needed to create prototypes. Fortunately, some tools allow themselves to slip naturally into the process by generating interactive prototypes that maintain the sketchy look and feel.


In interactive sketchy prototype created in Visio and imported into Axure.

Comparison of Computer Based Sketchy Tools
Software developers are starting to recognize the importance of computer-based sketchy wireframes, and there is a growing assortment of tools to create them. This is a quick breakdown of how each of the major tools matches our criteria for a complete computer-based sketchy tool:

ToolDraw ShapesEasy Conversion Realistic LinesPrototype FlexibilityBalsamiq1

Denim

Expression Blend 3

Fore UI

Fireworks

Illustrator

InDesign

OmniGraffle

Pidoco

Visio2

Key:

= No Support

= Partial Support

= Full Support

1. Assumes prototype flexibility using a 3rd party program called Napkee
2. Assumes use of custom line styles, as demonstrated in this tutorial

Conclusion

As the industry evolves, there is a growing trend toward hand-drawn styles, as evidenced by an expanding amount of literature and workshops on the subject. This is a positive step in the evolution of our field. Sketchy wireframes allow practitioners to guide creativity and problem solving in the early stages of projects, rather than getting lost in a sea of documentation. Hopefully, this trend will continue as software manufacturers focus on enhancing their tools for creating computer-based sketchy wireframes.

iTunes     Del.icio.us     Podcast music generously provided by Bumper Tunes

Download


This evening I had the pleasure of speaking with Principal of Interaction Design at Kicker Studio Jennifer Bove. Jennifer is co-chairing Interaction10 the third annual Interaction Design Association conference taking place February 4-7th at the Savannah College of Art and Design in Georgia.

She shares many details for the upcoming conference including speakers, workshops, and several unique experiences that attendees can expect during their time at the event. You can also follow the conference on Twitter @IxD10.

Early bird registration ends Monday, November 30!

Pre-Conference Workshops
The day before the conference, interaction designers can add core skills to their repertoire with hands-on workshops covering a range of topics. They include basic user experience skills like user research, mental models, brainstorming, and wireframing, but also mix in other topics like visual skills for folks who can’t draw, designing for mobile, and prototyping with “Arduino”:http://www.arduino.cc/.

Keynotes include:
Paola Antonelli – Senior Curator of Arch & Design at MOMA
Bill Moggridge – IDEO founder and interaction design pioneer
Jon Kolko – Associate Creative Director at Frog Design
Dan Hill – “Designer and urbanist”:http://www.cityofsound.com/blog/2002/01/about_cityofsou.html from Sydney
Ezio Manzini- “Sustainability expert”:http://www.sustainable-everyday.net/manzini/ and Professor of Industrial Design at Politecnico di Milano
Nathan Shedroff – Author & Chair of the “Design MBA”:http://www.designmba.org/ at California College of the Arts

Also invited speakers to speak about core topics like storytelling, service design, copy writing, networked objects, open source hardware & software. People like Liz Danzico, Shelley Evenson, Timo Arnal from Oslo, Denise Wilton from Moo in the UK.

Interact Sessions
Jennifer and the team for Interaction 10 are trying something new this year with the community sessions they used to call lightening rounds. They want to encourage more interaction among attendees. All folks who know each other online from around the world will finally have a chance to meet face to face, and give the younger and more experienced folks a reason to mix.

The IxDA received over 250 submissions from the community, opened it up for comments the topics the community was interested in; from which they chose about 30. The effort in selection was based on a mix of topics and formats including discussions, activities, and games, and the UX bookclub.

Local Challenge
Savannah was the first design city, and organizers wanted to do something to give back. They designed a Local Challenge structured to give participants an opportunity to put interaction design principles and methods to work, engage with the rich history of Savannah, and address an issue that affects the lives of their local peers.

Student Challenge
Students can submit process books, juried by an international panel of educators, where 5 finalists will be invited to the conference for an on-site design challenge to compete for prizes and peer recognition.

Art Exhibition
Exploring the concept of interaction. Organizers of the conference have invited designers and artists to submit work that explores the concept of interacting with people, tools, technology, and answering the questions about what it all means.

IDEA2009 had the world’s foremost thinkers and practitioners converge on Toronto’s MaRS Convention Center to share the big ideas that inspire, along with practical solutions for the ways people’s lives and systems are converging to affect society. Listen and learn from experts in a variety of fields as we all continue the exploration of Social Experience Design.

Subscribe to the Boxes and Arrows Podcast in iTunes or add this page to your Del.icio.us account:

iTunes     Del.icio.us     IDEA Conference theme music generously provided by Bumper Tunes


Day 1 @idea09 | Day 2 @idea09


Innovation Parkour – Matthew Milan

Insight is one of the most widely used and poorly understood concepts in the creative process. Insight is what drives the big idea, validates the crazy hunch, and frames both problem and solution in one fell swoop. Without the right perspective, knowledge, and grounding, generating insight can be unpredictable, wildly unreliable, and completely inconsistent in application.

Matthew Milan, Principal and Design Director with Normative, helps us understand how to generate, identify, frame and use insight effectively. This poorly understood practice is an increasingly a critical skill to have when working on solving complex problems. As an information architect, insight is one of the best tools you can use to unpack difficult challenges and turn them into effective solutions.

Social experiences online might benefit from an alternative venue, but standard human dynamics, modes of kinship/friendship, etc. still apply. Furthermore, we have a rich history of examination to mine, and a range of metaphors to apply that allow us to shift our perspective and enjoy more innovative thinking. The techo-geeky thing is old news, Lisa applies some human thinking.

.









Download
Innovation Parkour – IDEA 2009View more documents from Normative.


The Art and Science of Seductive Interactions – Stephen Anderson

Remember that “percentage complete” feature that LinkedIn implemented a few years ago, and how quickly this accelerated people filling out their profiles? It wasn’t a clever interface, IA, or technical prowess that made this a successful feature—it was basic human psychology. To be good UX professionals we need to crack open some psych 101 textbooks, learn what motivates people, and then bake these ideas into our designs.

Independent consultant Stephen P. Anderson looks at specific examples of sites who’ve designed serendipity, arousal, rewards and other seductive elements into their application, especially during the post sign-up process when it is so easy to lose people. Regardless of your current project, the principles behind these examples (from disciplines like social sciences, psychology, neuroscience and cognitive science) can be applied universally. Best of all, attendees will receive a special gift that makes it easy to bridge theory with tomorrow’s deadline.

.









Download
Seductive Interactions (Idea 09 Version)View more documents from Stephen Anderson.

Social Design Patterns Mini-Workshop – Christian Crumlish & Erin Malone

Principal at Tangible UX Erin Malone, and Curator at Yahoo! Design Patter Library Christian Crumlish present a family of social web design principles and interaction patterns to help user experience designers and strategists grapple with the social dimensions of their products and services. The family of patterns, principles, and practices provides a framework and starting point for the conceptual modeling of any interactive digital social experience.

Erin and Christian have observed and codified 96 patterns thus far, capturing user-experience best practices and emerging social web customs for practitioners; introducing the conceptual clusters of patterns, delve deeply into some of the most interesting patterns, and share fundamental principles and deceptively appealing anti-patterns in context through discussion of illustrative scenarios.

Editors Note: The second half of their presentation involved participants playing the Social Mania card game. I’ve included a few pictures of attendees learning the game the evening before to assist Erin and Christian during their presentation. Thanks to Denise Philipsen (@theguigirl) for posting these and other photos from the conference up on Flickr.

Download
Designing Social Interfaces: 5 steps, 5 principles, 5 anti-patternsView more presentations from erin malone.

If You Build It (Using Social Media), They Will Come – Mari Luangrath

Mari Luangrath is currently starting up her third entrepreneurial venture, Foiled Cupcakes. Without a traditional “cupcakery” storefront but choosing instead to focus on online order and personal delivery, Mari has gone completely non-traditional: she’s used Twitter, Facebook, and LinkedIn to build relationships with Chicago’s most active and vocal influencers and more than double sales targets in month 1 and 2. As a result, 90 percent of the word-of-mouth business she’s received since May 2009 can be tied directly to social media.

While social media is constantly evolving from one medium to the next, it’s absolutely one of the most immediate ways to interact with potential consumers, influencers and connectors in your target market. Of course, there’s no one “right way” to do things in this dynamic environment. Mari shares insightful information regarding the real-time challenges she has faced to stay present in the lives of potential consumers amid all of the fluidity. She also discusses her targeted marketing action plan (what worked, what flopped, and how she’s used roadblocks to her advantage); suggest ways to identify which social media applications will work best for the results you desire; how to develop a plan to connect with targeted consumers; and ways to continue that relationship to provide consumers with an enhanced experience, leading to conversion and sales.

Download
Idea09View more presentations from Foiled Inc..

The Dawn of Perfect Products – Tim Queenan

There is a potential upside in social media besides encouraging more dynamic communications and facilitating human networks: the end of bad products. Sure, “bad” is subjective but so is why we buy or don’t buy certain products. Could one of the effects of social media be that we see fewer and fewer inferior products existing in market?

Executive Director of Draftfcb NY’s Digital Practice Tim Queenan, explores what happens when a commodity driven market is regulated by the “crowd” and what types of products and experience start to emerge.

Download


These podcasts are sponsored by:

Information Architecture Institute: Through education, advocacy, services and social networking, the IAI has 1400 members from 80 countries demonstrating the value of Information Architecture to the world at large.





IDEA brings together the worlds foremost thinkers and practitioners. Sharing the big ideas that inspire, along with practical solutions for the ways peoples lives and systems are converging to affect society.





Visit boxesandarrows.com/about/participate to be a part of your peer written journal.



Axure RP is the leading tool for rapidly creating wireframes, prototypes and specifications for applications and web sites.



Morae is the premier software for deeply understanding customer experiences…and sharing those insights clearly and powerfully.

iRise enterprise visualization solutions give companies a powerful way to fully experience application before development.

Prior to becoming a senior UX designer at Popular Front Interactive, I spent two years as a mobile UX researcher within the Georgia Institute of Technology’s Mobile Technologies Group – a lab tasked with both future-casting and then rapidly prototyping innovative mobile experiences.

As I transitioned from academia to industry, I discovered that while mobile UX was discussed, it wasn’t discussed from the same broad frame of reference that I was used to within the confines of a research-based institution. Although more recent mobile UX conversations I have found myself in have undoubtedly benefited from the ongoing smart phone revolution, overall I still find these conversations to be needlessly driven by tactical adoration and lacking a conscious consensus regarding the fundamental principles of the mobile-user experience.

I do not presume these following principles to be all-inclusive or ultimately authoritative; rather, it is my hope that they are received as an anecdotal summation of my findings that might then spark and contribute to the larger conversation and consensus-building process.

 

PRINCIPLE #1: There is an intimate relationship between a user and their mobile device.

While an intimate relationship between an individual and their mobile device may seem like a given, the depth of that relationship probably goes deeper than most initially realize. In fact, I argue that the relationship extends to a physical level and the exchange of bodily fluids.

Imagine that it is a hot summer day and someone asks if they may borrow your mobile device to make a call. You hand it over. What level of trust does this simple act portray? Consider those around you right now: How many of them would you loan your mobile device to without hesitation? In your social circles, is it acceptable to decline such a request? How does context influence this scenario? What if you are at work? At a bar? How about a family reunion?

Let’s assume that this person is noticeably respectful of your device and the personal data it contains while making their call. At the call’s completion, the individual immediately and graciously returns it, whereupon you notice that it has accumulated an amount of … goo (perspiration, humidity, etc.) that is typical of mobile device use on a hot, sticky summer day…but then again, it isn’t your goo.

From a gooey physical level to a level of data privacy and security, there is an intimate bond between an individual and their mobile device, the strength of which often elevates the mobile device to the status of iconic personification. I am my phone. My phone is I.

In order to meet user expectations, mobile experiences should assume a semi-guarded state of primary usership; however, we must also responsibly protect our users. As the trend of embedding ourselves into our mobile devices increases, so does the cost of our devices being compromised. Assume primary ownership, allow for secondary usership, and plan for what might happen should we lose ourselves.

In a worst-case scenario, a compromised mobile device containing a significant amount of personal data would become the networked equivalent of a voodoo doll, where actions performed via the mobile device could cause actual harm to the individual personified by the device. In cases such as this, a remote wiping of all data on the device may be a user’s only recourse. 

 

PRINCIPLE #2: Screen size implies a user’s state. The user’s state infers their commitment to what is on the screen.

Imagine that you have been looking forward to seeing a particular blockbuster movie since the day it was green lit, and now that the day of its release has finally come you are going to get the most out of the experience by going to see the movie on the largest IMAX screen in the tri-state area.

Let’s say that when you finally take your seat in the sold-out theatre, you notice the person sitting next to you has a very annoying laugh. There is nowhere else to sit in the theatre, and you’ve been dying to see this movie for more than a year. What are the chances you abandon the experience and walk out? Probably fairly slim to none.

Now let’s say that you were backpacking through Europe when the above blockbuster was released, and that you have been equally anticipating the movie’s Blu-Ray release. To celebrate the release, you and your friends are gathering at the home of the friend who has an impressive home theater featuring a 52-inch HD screen, and again you find yourself seated next to the guy with the annoying laugh. Now how likely are you to abandon the experience? Probably more so than above, but still not likely.

What if this scenario played out in a college dorm room and the movie was being viewed on a 22-inch computer monitor? What if you were sitting next to the guy with the annoying laugh? The chances that you might abandon the experience are probably increasing.

What about a mobile device’s 3.5-inch screen? Is there any way you would sit next to some random person with an annoying laugh for 90 minutes to watch that movie? Probably not.

Although there are any number of social and environmental factors that would affect the user abandonment rate in the experiences described above, it is consistently possible to estimate a user’s level of commitment to an experience based upon the size of the screen through which they are engaging it.

Since mobile devices are likely to be the smallest screens in a user’s experience, the design of mobile experiences must accommodate the user’s varying commitment and distributed attention. How an experience accommodates these conditions will change depending on experience type — game, banking application, or the like — but the underlying impetus remains the same.

 

PRINCIPLE #3: Mobile interfaces are truncated. Other interfaces are not.

A dreaded task that usually accompanies getting a new mobile device is the act of transferring your data from the old device to the new. In years past, this meant arduously re-entering all of your contacts via the device’s, most likely E.161 (12 key), keypad.

There were a few early, notable attempts to ease this burden. GSM service providers pushed device manufacturers to save all user data to the devices SIM card by default, but the card’s limited storage capacity produced a poor user experience. On the other hand, CDMA service providers began automatically transferring address books between devices as a customer service. Even early on it was widely acknowledged that although an individual wanted to use information on their mobile device, they would go to great lengths to avoid having to manually enter that information.

Palm, and later Research in Motion, sought to improve this fact of mobile user experience by introducing and then proliferating the practice of syncing. This concept paired the truncated mobile interface with a full-sized desktop interface, allowing the user to easily and reasonably efficiently enter their address book data via a familiar QUERTY keyboard. Although this feature was initially limited to smart phones, it has since been incorporated into a wide swatch of consumer-grade devices. In fact, the notion of syncing has become so ubiquitous in mobile computing that the syncing of one’s entire networked identity is a core plank of Google’s Android operating system.

Even as miniaturized QUERTY became and becomes a more standard feature for all mobile devices, the truth remains that mobile interfaces are truncated and better used for manipulating data rather than entering it. One might conclude that as mobile devices continue to incorporate increasingly impressive sensor arrays, even standard, consumer-grade devices will provide powerful data collection capabilities. Regardless, data collection is not data entry, and data entry is not likely to become a mobile-appropriate activity. 

 

PRINCIPLE #4: Design for mobile platforms — the real ones.

There is a prevailing tendency is to discuss mobile platforms in terms of device manufacturers and service providers. This is understandable. It is fun and easy to get caught up in the moment of the latest tech demo, press release, or rumor. However, in needlessly binding the dialogue to the news of the day, we create unnecessary segmentation across an already complex landscape. The overall conversation is better served by focusing on the mobile platforms that have emerged as constants over time. Those four platforms are voice, messaging, the internet, and applications.

 

Voice

Voice was the original mobile platform, but it is also the platform with the most nebulous future. Don’t get me wrong: People will always need to make an occasional phone call. However, the frequency with which we are doing so is declining. Why? Mobility is as much about efficiency as anything else, and telephony (vocal communication and vocal response interfaces) has proven more difficult to optimize compared to other methods of interactivity.

For example, let’s say that you wanted to verify that your paycheck had been deposited. Most banks offer both tele-banking and online account access. Which interface are you likely to use, and why? How about if you wanted to order a pizza? Would you rather call, be placed on hold for five minutes, and then dictate your order to a multi-tasking teenager, or would you rather just use a GUI to do it?

 

Messaging

Friedhelm Hillebrand, the architect of the messaging (SMS) specification, described the platform’s limit of 160 characters as “perfectly sufficient.” The question we must ask ourselves in considering this mobile platform is, “Perfectly sufficient for what?” Although Hillebrand can provide several reasons for how he arrived at the 160-character limit, the one that I have always found the most interesting is that his team discovered that most postcards typically contain 150 characters or fewer.

Have you received or sent any postcards recently? If you have, they were likely either brief social communications (“Having a great time. Wish you were here!”) or they were simply task-oriented such as RSVP-ing for a wedding or canceling a subscription.

Messaging trends today continue to affirm Hillebrand’s postcard comparison. The vast majority of SMS traffic consists of social interactions within small groups of individuals. The second tier of usage is comprised of simple task-based transactions such as voting, entering contests, and receiving notifications.

In both cases, SMS and postcards, content-heavy experiences are a minority occurrence as the media is not designed to accommodate such a level of engagement. Furthermore one could argue that due to the designed efficiency of the messaging platform, that a content-heavy experience would be far from appropriate. 

 

The Internet

The Internet is the most awkward of the mobile platforms in that it is the one that is the least natively mobile. Currently almost 95% of all Internet users experience the web via displays with resolutions of 1024×768 or greater. As such, 1024×768 is observed as a fairly universal standard and is what a significant portion of Internet-based experiences are designed to. Given that mobile displays typically range between resolutions of 60×120 and 480×320, it is fairly obvious that most Internet-based experiences aren’t designed with mobile users as a primary consideration.

As a means of making Internet-based experiences more accessible to mobile users, most mobile web browsers have been designed to include adaptive methodologies for displaying larger experiences on smaller screens. While these adaptive tactics, which typically employ pan and zoom-esque interactions, have undoubtedly made more of the Internet accessible to mobile user, one could hardly argue that it has resulted in a desirable user experience. In fact, if browsing the Internet from a desktop is regarded as a scanning activity, than browsing the Internet through the adaptive lens of a mobile browser might best be described as a squinting activity.

As mobile web usage has continued to emerge as a somewhat common activity, the assumption that Internet-based experiences are to be automatically adapted for mobile users has given way to the design of alternative experiences specifically for mobile users. While this trend has provided mobile users with more efficient and scannable web experiences, it also has the potential of overplaying the users’ expectations for Internet-based mobile experiences.

As Internet-based mobile experiences have become more device-centric and sophisticated, they have begun to resemble mobile applications, thus creating a scenario where users might expect the Internet-based experience to function as a mobile application would. The distinction between desktop applications and Internet-based experiences may be rapidly evaporating, but it remains germane in the mobile experience. Although there are several differences between the platforms, the primary point of contrast I will draw here is that applications are able to use device-level services such as sensors, ad-hoc networking, and optics, whereas Internet-based experiences cannot. While mobile browsers are beginning to make some of these services available to Internet-based experiences, each platform will always have affordances the other doesn’t. As such, and to manage user expectations, if an experience looks like an application and attempts to behave as an application would, then it should be an application — and vice-versa.

 

Applications

From a technical standpoint, applications represent executables that are native to a specific mobile environment, have been selectively installed, and have access to the device’s full array of available functionality. However from a UX standpoint, they represent a specialized interaction design that caters to an affluent, sophisticated, and targeted mobile user base.

As few as 24 months ago, the seemingly basic task of locating and installing an application on a mobile device required a fairly developed skill set. With the recent proliferation of “app stores,” this task has become more user friendly; however the percentage of users who are able to install an application on their mobile device nowhere near approaches that of those who know how to make a phone call or send a text message. So, regardless of recent improvements to the overall process of acquiring and installing a mobile application, the user who can perform this task would still be considered sophisticated compared to the overall segment.

All things considered, mobile applications might best be described as the boutique mobile platform. As is the case with most boutique experiences, a comparatively small audience will compensate for itself through fervor and zealotry. However, since the success of an application-based mobile experience is based almost entirely upon acceptance within that small audience, extraordinary attention must be paid to the particulars of the target audience’s needs and behaviors. What existing need is the application attempting to mobilize? What efficiencies can a focused interface bring to that workflow? How can the specific affordances of a mobile device augment and improve upon that experience in contrast to using one of the other mobile platforms?

Mobile applications are powerful tools…for a relatively small segment of individuals who want them and know how to use them.

 

Conclusion

Someone tweeting on behalf of Punchcut once wrote, “In mobile UX, don’t confuse precedence with standard.” I couldn’t agree more, but as I hope that I’ve successfully illustrated, this statement is well ahead of where the conversation should be. Both standards and precedence are both tactical perspectives. Within our context, they both represent distinct libraries of interactions and are either redefined as the landscape evolves or simply replaced as more elegant solutions are brought to market.

The variable nature of each of these categorizations only further demonstrates why it is best for the current mobile UX conversation to focus on higher-level principles rather than tactical particulars.

As mobile UX designers, we have both opportunity and choice in front of us. The opportunity is to establish the foundation principles of a stable, yet still emerging, experiential space. The choice lies between getting caught up in the excitement of the fad du jour or asking ourselves the difficult question of what foundational principles am I following, or establishing, with the work that I am currently doing.

The only unfortunate part is that the time we have to make this decision is quickly running out.

IDEA2009 had the world’s foremost thinkers and practitioners converge on Toronto’s MaRS Convention Center to share the big ideas that inspire, along with practical solutions for the ways people’s lives and systems are converging to affect society. Listen and learn from experts in a variety of fields as we all continue the exploration of Social Experience Design.

Subscribe to the Boxes and Arrows Podcast in iTunes or add this page to your Del.icio.us account:

iTunes     Del.icio.us     IDEA Conference theme music generously provided by Bumper Tunes


Day 1 @idea09 | Day 2 @idea09

The Impact of Social Models – Luke Wroblewski

As Richard Farson’s truism “no one smokes in church no matter how addicted” points out, context informs almost everything that happens in an environment. Online social experiences are no exception.

How a product’s social model is set up can impact not only who contributes, but how much, and why. From permission-based subscriptions to one-click follows, Luke will discuss the attributes and implications of several popular social models by looking at data and behavior in the Web’s most popular social applications.

.









Download
The Impact of Social ModelsView more presentations from Luke Wroblewski.

Social Spaces Online: Lessons from Radical Architects – Christina Wodtke

While Information Architecture took its name from architecture, it took very little else. This is not surprising, as the early days of the web were about making sites that supported the interaction between people and data. The obvious model back then was a library; a library is a space for humans to receive knowledge. But with the rise of social networks, and the integration of community into almost all online experiences, more architecture practices are directly transferable to design. Online spaces are no longer just about findability, but about falling in love, getting your work done, goofing around, reconnecting with old friends, staving off loneliness… humans doing human things.

Download
Social Spaces: Lessons from Radical ArchitectsView more presentations from cwodtke.

Making Virtual Worlds: Games and the Human for a Digital Age – Thomas Malaby

The rise of virtual worlds (World of Warcraft, Everquest) has prompted new questions about the status of games in a digital age. Thomas Malaby’s research at Linden Lab, makers of Second Life, suggests that game design and game development practice are becoming a key part of how some high tech companies operate. Instead of relying on top-down and procedural decision-making, these organizations contrive complex and game-like systems that promise to generate legitimate decisions from the ground up.

Download
Making Virtual Worlds: Games and the Human for a Digital Age (IDEA 2009 Presentation)View more documents from tmmalaby.

User Experience as a Crucial Driver of Social Business Design – Jeff Dachis

Everything that can be digital will be. Why? Because it’s faster, better, and cheaper. UX in the digital world will be the key definer of value. UX design now means to embrace a whole new set of behaviors and characteristics. Social Business Design is a framework to understand and think about the multi-faceted users and the way they participates inside a business ecosystem in meaningful ways.

Co-founder of Razorfish, Inc., and current CEO of the Dachis Group, Jeff Dachis suggests that Experience design has started to evolve into Business Design – a fully connected ecosystem of suppliers, shareholders, employees, products, and supply chains. But don’t get too comfortable, b/c the future is about to change…again!

.









Download
Social Business Design Embracing Change In Key Drivers Advancing User Experience For A Networked EconomyView more documents from Jeffreydachis.

Bare Naked Design: Reflections on Designing with an Open Source Community – Leisa Reichelt

For the past 12 months Leisa has been working, with Mark Boulton on a series of projects with the Drupal community – firstly to redesign Drupal.org, and then following the success of that project, to work with the Drupal community to try to address some significant user experience issues in the interface of Drupal itself.

In this presentation, Leisa shares war wounds and learnings from their work with the Drupal community as well as some questions and challenges for both designers and open source communities. She examines what it is like to design openly with communities and whether good design can ever flourish in a meritocracy like the Drupal community.

.









Download

Does Designing a Social Experience Affect How We Party? Of Course It Does! – Maya Kalman

What makes an event whether social or corporate a true success? What makes you want to go to a party or networking event? And what makes you want to stay!

That premise, of what should or could have been done to make that event a success is the core of the concept behind “Social Experience Design” and what we’ll be discussing in this session. Maya will explore what goes into planning the perfect event. How do we approach the task at hand? How do we insure success? What has changed in the last year and what are next year’s trends? And how have events and the art of event design changed now that “social networking” is part of almost everyone’s daily life.

.









Download

The Information Superhighway: Urban Renewal or Neighborhood Destruction? – Mary Newsom

As a long-time practitioner of daily newspaper journalism who sees the economic model of the newspaper industry sinking (and broadcast journalism isn’t in much better shape), Mary looks into what will happen to cities if/when the mass media splinter.

With all of the “new media” journalism: the emerging trends of crowd-sourcing, blogging, YouTube, Twitter and the general explosion of information available to people, this makes virtually anyone, a potential journalist. What are the implications for information, and for the dependability of that information?

.









Download


These podcasts are sponsored by:

Information Architecture Institute: Through education, advocacy, services, and social networking, the IAI has 1400 members from 80 countries demonstrating the value of Information Architecture to the world at large.





IDEA brings together the worlds foremost thinkers and practitioners. Sharing the big ideas that inspire, along with practical solutions for the ways peoples lives and systems are converging to affect society.





Visit boxesandarrows.com/about/participate to be a part of your peer written journal.



Axure RP is the leading tool for rapidly creating wireframes, prototypes and specifications for applications and web sites.



Morae is the premier software for deeply understanding customer experiences…and sharing those insights clearly and powerfully.

iRise enterprise visualization solutions give companies a powerful way to fully experience application before development.

It’s 2 a.m., and a call comes across the radio that a young man with a gun has barricaded himself and his mother in his home. No shots have been fired, and little communication has been established between the man and police officers outside. The officers on the scene report that the young man has been struggling with the loss of his job and feels like there’s no reason to live. The crisis response team has been called, and hostage negotiators are en route. It’s the negotiator’s job to ensure that the young man does not harm himself or others during this crisis.

What would you do? How would you handle this situation?

Throughout the past six years, the founders of ActiveComm Labs have not only been performing design research but also assisting the law enforcement community by conducting research on the communication patterns of hostage negotiators. Specifically, we have been analyzing the communication between the hostage negotiator and hostage taker to locate patterns that could introduce new strategies to help resolve crisis situations peacefully.

We’ve come to realize that the techniques used by hostage negotiators to resolve crises are also extremely valuable to user experience researchers. In essence, both parties are attempting to establish a relationship, both are trying to keep the communication flowing, and most importantly, both are trying to extract valuable data.

There are certain myths about hostage takers. Most of them are not bank robbers or terrorists demanding millions of dollars and a plane to Cuba. The vast majority of hostage situations are a result of domestic violence, psychological disorder, or barricade situations in which a person is threatening to commit suicide, possibly with a child in the next room. Hostage takers are usually confused, upset, and very scared. It’s also pretty rare for them to be outright hostile toward the negotiator. Hostage negotiators are trained to gather important data about the situation. Who’s in there? Is anyone hurt? What kind of weapons does the hostage taker have? How much ammo does he have? To do this, negotiators have to master a variety of communication techniques.

Have you ever worked with a research participant who will only give you “yes and no” answers? How about a participant who tells you exactly what you want to hear? These situations can be frustrating, especially when you invest so much time and energy in recruiting candidates. But these experiences don’t necessarily mean that these people can’t provide valuable data, it means that you need a different approach to extract that information.

A research session isn’t usually an emotionally charged situation and research participants aren’t typically in crisis, but the fundamentals of communication tend to hold true across different types of people and contexts. Our negotiation instructor told us that we should approach a hostage negotiation in much the same way as going on a first date; it’s important to bring a certain level of calm into the situation and put the hostage taker at ease. It is also extremely important to connect with the hostage taker on a personal level. Negotiation provides a great example of how to perform this kind of communication because it demonstrates these fundamental communication elements under the most difficult of conditions. Ultimately, negotiation is about two strangers coming together to work toward a common goal built on an understanding of each other, much like design research.

Application to Design Research

There are two types of behavior that we try to extract when conducting research:

1. What the participant does (physical interaction with product)
2. What he or she says (communication about the product)

Our goal is then to study the interaction between these behaviors in order to tell a story about the user’s experience of the product.

One of the most difficult parts of research is getting the participants to tell us their story about the product. Some researchers only focus on physical interaction data, but we think too much valuable content is lost. We’ve found that the communication piece of the equation provides the emotional and logical connection that participants make with products and how it relates to their lives.

With that said, one of the most common issues with communication-related data is how to gather accurate information. What a participant says is not always what he or she believes, and what a participant does is not always what the participant reports.

Much like a hostage negotiator, who must build trust in order to successfully resolve the crisis, a user experience researcher must establish a relationship with the participant in order to extract useful and accurate information. So, the fundamental element of becoming a better communicator, and also researcher, is to establish a relationship. Hostage negotiators focus on establishing relationships in order to save lives, there’s much we can learn from the methods that they have established.

Learning from Negotiators

Dominick J. Misino is a retired NYPD crisis negotiator who has been involved in more than 200 hostage and barricade incidents. He is recognized for his successful resolution of the Lufthansa hijacking in 1993 and numerous other successful negotiations. When it comes to communicating, Dominick knows what he’s doing. Since retiring, Dominick began training other hostage negotiators. To date, he’s trained thousands of negotiators across the country and around the world. A few years ago, we had the privilege to attend all three phases of Dominick’s negotiator training and certification program, which included hands-on practice as a negotiator and hostage taker. We learned communication techniques that we currently employ when interacting with research participants. These techniques include building rapport, building alliances, and using a team approach.

Building Rapport

Rapport is established through trust, open communication and empathy. Negotiators know that rapport is essential in their job. They use rapport to influence the hostage taker and gather information. If you can effectively build rapport with the participant, there is a higher likelihood he or she will trust you and disclose more information.

The following techniques used by hostage negotiators can help you build rapport with research participants:

1. Go slow – Engage in small talk at first. If you dive right into business, the situation can become uncomfortable.
2. Communicate openly – While you can’t disclose everything, it’s important to encourage an atmosphere of open communication. Tell the participant that there are certain aspects of the study that you can’t reveal, but he or she shouldn’t feel that you’re hiding something.
3. Actively listen – When you are listening to a participant’s story, listen for the emotions behind the words. Ask open-ended questions that dig for the source of those emotions.
4. Discuss personal topics – In a hostage situation, some of the most valuable topics that lead to a peaceful resolution are personal ones. The more a person feels that you accept them, the more comfortable they will feel with you.
5. Share your experiences – Building rapport is as much about sharing your experiences as it is about listening to the other person’s. Negotiators know that the more you reveal about yourself, the more the participant feels like he or she knows you and therefore trusts you.
6. Show you care – Hostage negotiators build rapport through empathy. Empathy is extremely important because it shows that you care about the other person and that you have their best interests in mind. As a researcher, you should do this also. If you show that you care, the participant will appreciate it and respond with more openness.

Alliances

In a hostage situation, the negotiator works for the police department but he has to show the hostage taker that he’s on his side. In order to do this, the negotiator can never be the one in charge; it cripples his or her ability to negotiate. Anytime the negotiator has to tell the hostage taker “no” it’s because his boss is being a jerk. Anytime the negotiator says “yes,” whether it’s a pack of cigarettes or just some extra time, it’s because the negotiator fought hard to get it for him. The negotiator intentionally shifts the blame for anything negative and takes credit for anything positive. It convinces the hostage taker that the negotiator is on his side.

In user experience research, the researcher is on the side of the user. In our work, we establish this by telling the participant that we are not the people who designed the product and that their comments, whether good or bad, will not offend us. This establishes objectivity and allows a certain freedom in the research session. In most cases, participants open up when they hear that you have nothing at stake. Also, if the participant can see that you share his or her common goal of improving the product, the participant is more likely to be truthful in his or her evaluation.

Team Approach

Hostage negotiators always work in teams, and so should you. In the event of a hostage situation, a negotiation team is called to manage the situation. Each person in that team holds a different but critical role in the event. One of the most important positions on that team is the coach. As the negotiator acts as the primary point of contact with the hostage taker, the coach sits with the negotiator and functions as another pair of ears. The communication can move very quickly during a negotiation, and the negotiator can have a hard time catching all of it. The coach specializes in listening, controlling access to the negotiator, generating questions and helping guide the communication process by passing notes to the hostage negotiator. Through crisis negotiation training, my partner and I have learned that the ability to gather useful and accurate information dramatically increases when you work in teams. For example, when conducting an expert interview we have one person ask the questions and another person as a secondary moderator. Like the coach in negotiation, the secondary moderator listens closely, takes detailed notes and chimes in when he feels that something is being missed. This type of setup will reap maximum data in the shortest amount of time. We can’t always work in teams for logistic or financial reasons, but it is our preferred method.

Training

For hostage negotiators, training is a crucial part of the job and they understand that the more you train, the more comfortable you will feel in the situation and in turn the better the outcome.

From what I have seen in the user experience community, little or no time is spent training on the best practices of communicating with participants. Every so often a workshop is attended but that only happens a few times a year. If we take a page from the book of negotiating, we would learn that just a little bit of training on a regular basis will take us to a whole new level of success. Here are some modified exercises that we can use to polish our communication skills as researchers:

1. Communicate with new people all the time – every time you have a chance to meet someone new and learn about their life, do it. Ask questions about who they are, where they come from and what they’re like. When you start to feel more comfortable doing this, start pushing yourself and asking more intimate questions about their life such as “What keeps you up at night?” Play a little game with yourself where you try to learn as much as you can about a person in a short amount of time. Three things will happen when you do this. First, you will learn about boundaries and what you can ask and you should not ask. This doesn’t mean that you’ll necessarily insult people and then learn not to do it; it means that you will see what topics are challenging to people and how to pull that information out of them without upsetting them. You’ll also learn more about people in general and how they function in the world. You’ll get a better sense of behavior and start to see trends in people. Finally, you will make more friends in the process and that is always a nice outcome.
2. Learn to listen – A well-known question asks, “When someone is speaking to you, do you think about what they are saying or do you think about what you are going to say next?” This is a very important question when learning to communicate more effectively with others. When you are communicating with participants or friends, really listen to what they are saying. Listen to the emotions behind the words, look at body language, and ask questions about their responses if they are unclear. There are sometimes differences between what a user will answer and what they believe. Ask yourself what those statements say about the speaker as a person; it will enable you to discover the areas where people are most passionate.
3. Learn how to disclose – When talking with friends and new people, start disclosing about your life and observe how people respond. Most people will feel more comfortable sharing information if you share information also. You’ll be amazed at how quickly people will open up.
4. Learn to trust your gut – When working with a participant or talking with a friend, learn to listen to your instincts. There are times when you need to speak up, times when you need to bring the communication back on track and times when you need to let the other person just open up and talk about whatever they feel is important. Different types of communication are needed for different situations. If you train frequently, you will notice that your gut tells you what you need to do.

Conclusion

This article began with a scenario of a hostage situation. After the first 30 minutes, the hostage taker and negotiator were talking like old friends about food, sports, and pets. At two hours, the hostage taker confided in the negotiator about his relationship problems and issues that led to him losing his job. At two and a half hours, the young man sent his mother out of the house, despite her protests that she wanted to stay with her son. At four hours, the young man placed his empty gun in a bucket attached to a rope outside an open window, where it was retrieved by the police tactical team. At 7:50am, after five hours and fifty minutes of negotiation, the young man peacefully exited his home and surrendered to police. The negotiator followed up on all of his promises. He rode with the young man to the police station, allowed his mother to visit so that he could apologize and even made a statement on the young man’s behalf at his trial, resulting in a reduced sentence.

This process should be mirrored in a research session in a condensed period of time. After the first ten or fifteen minutes, the participant should feel like you know each other and feel pretty comfortable talking with you about your product or service. After about twenty minutes, the participant should understand the product and its goals. After thirty minutes, the participant should be discussing how the product would fit into his or her life. In order to achieve this, some form of communication training should be implemented. Researchers typically receive a great deal of training in research methods, statistics, human factors and elements of design, but little training on advanced communication. Researchers who really want to invest into their skills as a researcher should think about spending time and energy to learn effective communication methods.