Lixlpixel RSS Newsreader / Boxes and Arrows

• Google, Stanford, and The Government Fight Swine Flu Bolt | Peters recently collaborated with Stanford Universitys 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 FixWith the recent outbreak of H1N1, Santa Clara Countys 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: Stanfords 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 wasnt 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 ProblemsBecause 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? organizationThe info wasnt grouped into meaningful categories?there wasnt 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 youre trying to learn about the tsunami headed your way.?3. It didnt anticipate the distinct needs of the most critical usersegments.? ?There was plenty of good info on the site, but it was never clear who a given piece of info was for?you couldnt scan the page headers and think, Yeah, theres what Im looking for. Instead it had a general audience feel to it; the info didnt 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 RecommendationsTo 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 wasnt pretty, but got our main info design recommendations across loud and clear.Our first stab at redesigning the H1N1 templateRedesign Goal #1: Prioritize information according to the urgencyof 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 Googles 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 didnt 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 listsand 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 couldnt be condensed in this way was moved to lower-level pages, and linked fromhigher-level pages. Users dont 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 addressuser 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 theiremergency 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 informationresources (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 RevisionAfter we sent over our recommendations and mockup, Bill sent us a nice note a day or two later:Youve convinced us that we have to completely rethink and redesign the site from scratch, soyour style guidelines come at a very good time. I cant thank you enough for opening our eyes tohow we can do this in a much better way. I think we can create a site that works much better thanthe 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 dont have permission to show you this revision yet (working on it), but it wasnt 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; its 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 agencys 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?) doesnt 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 theres 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 ResultsStanford 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 heres 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 heres 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 its great and you just want to use it yourself, heres the complete list of links: Google Sites Templates blog postPublic health sites:TemplateExample siteUser guideAll hazard sites:TemplateExampleUser guideStanford SIE site (were credited here!)Note: Nate and Tonys book on remote testing, Remote Research:http://www.rosenfeldmedia.com/books/remote-research/, will be published by Rosenfeld Media in 2010.
• Bringing User Centered Design to the Agile Environment 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 Developmentwho 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 theyd 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 Ive 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, Ive 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 cant 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, its 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 doesnt want. As such, it is a coping mechanism for a clients 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 customers 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 hasnt 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 MinefieldIn 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 doesnt 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 designIn the best cases of business approaching developers to build some software, some of those developers may have design skills. But thats 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 definedAgile 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 dont want to do any type of documentation that might outline a vision, even if in a rudimentary sense.Mine 3: Pressure to cut cornersImplementations 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, whats wrong with that? Well, nothing if youre 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 theyre right, but how will we know which best-practice interface works best in context with the users 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 peoples search results were poor at best. Then Google came along and realized what is now obvious. People just want to find what theyre looking for, not learn how to drive a search engine first. Im 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. Its 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 dont intend to release them on your poor, unsuspecting user without some usability testing. Just dont 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.4Mine 4: The temptation to call it good enoughInvariably when we have release-ready working code at the end of each cycle, even if its sub-optimal, theres 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 isnt right yet, its amendments get fed back into the requirements backlog where temptation strikes again. Should we spend time in our next iteration on a feature that weve 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 dont quite meet the bar.Mine 5: Insufficient risk-free conceptual exploration timeIteration 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, weve 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 DamageLets just say that design and research takes the same amount of time as development for arguments 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 were back to the same total duration after developing it a second time, but theres no guarantee well get the solution right the second time either. All the while weve 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 DesignUCD requires iteration  design, test with users, refine, test with users again, refine& repeat till its right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming youll need to change things, and thats a good thing when it comes to refinement.Uncovering requirements to form a strategyUser 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. Theyd 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? Thats a good question and one that Jared Spools Market Maturity Framework5 helps answer. Sometimes, just getting something off the ground, regardless of how precisely we meet users 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 Garrets Elements of User Experience3which underpins everything we do during the project. Do this well, and you really shouldnt come up with something thats fundamentally wrong. Agile doesnt 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, thats created through careful consideration of three things: Empathetic qualitative research that uncovers the users 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. 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). 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 doesnt preclude that kind of consideration, but it does not mandate it either.Concept DevelopmentIf 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 dont explicitly build this into our Agile methodology, we can miss that thinking time. The best of both worldsUCD 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 fundamentalsIn 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 well 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 weve 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 youre not wasting time and effort. Sometimes most of the product will be done this way and thats 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 isnt 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 thats not right yet. ConclusionIn 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
• 5 Steps to Building Social Experiences Nowadays everyone wants social in their sites and applications. Its become a basic requirement in consumer web software and is slowly infiltrating the enterprise as well. So whats 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. Its 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  Whats 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. Its the object around which conversations emerge and thrive. Remember that sometimes, the social object is a person  or the conversations between people. But dont 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 flickrIt 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 FriendFeedIts 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 MyBlogLogOnce 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 its 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 GoodRecAllow 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).Dont 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 startedThese 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 dont 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 dont have to have everything figured out. The people will create their own paths of interaction making their own meaning and experience.
• Research Logistics With more companies today putting a stronger emphasis on gaining a deeper understanding of their customer, its not unusual for us to be called in for a project to find that our clients dont have a lot of experience with research and dont 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 youre working with a good one. These are indicators, not standards, based on what weve found to be effective. There are many ways to do research and every research study is different so it doesnt mean that a researcher is incompetent if he or she doesnt 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.RecruitingOne 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 its 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 dont properly fit the target market segment, dont provide quality feedback, or just dont show up at all. All of these can have a negative impact on the data. Even if it is possible to get participants faster, its 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. SchedulingWhen creating a schedule for data collection, the researcher should know that you cannot run participants back to back. Its 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, theres forty-five minutes to an hour of buffer and setup time. Home visits can take much longer. Test PlanA 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, its 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 CollectionWhen the data collection starts, its 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, its important to try to minimize observer impact during the testing session. If you dont have a separate place to watch the session (e.g. behind a two-way mirror or through a video feed), dont make it obvious that you are paying close attention. Think about bringing in a laptop during the session to make it look like youre doing other work. One way of doing this is telling the participant that you are also a researcher but youre just going to be taking notes. When youre observing, remain objective and dont make judgments based on one or two participants. Its not uncommon to see a couple participants have a completely opposite reaction to a product compared to ten other participants. The researchers 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, its 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 youll notice by paying attention to the participant and seeing if they feel relaxed or nervous throughout testing.FindingsFrequently, stakeholders will want to make immediate changes to a design, product, or prototype and wont have the time to wait for the researchers final report. People have schedules that need to be met so its understandable that a project cant 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 arent 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. Theres 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. Its 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.SummaryIn 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, theres 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 dont 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.
• Tree Testing 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 hasnt found an effective, simple technique (or tool) to test site structures. The most common method usedclosed card sortingis 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 beganSome 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 sites 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. Weve 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 wasnt 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 werent 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 hadnt just contracted to deliver a different IA ? we had promised a better IA, and we needed a quantifiable way to prove it.The problemThis, 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 doesnt yield the final site structure  it just provides clues and ideas. And it certainly doesnt 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 doesnt necessarily model how users find information in a site. They dont start with a documentthey 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 didnt 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 dont 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 techniquetree testingLuckily, 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 wasnt 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 didnt find a topic that satisfied them, they could backtrack (go back up one or more levels). If they still couldnt 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 its true that this technique does not measure everything that determines a sites 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. Its like unit-testing a sites organisation and labeling. Or as my colleague Sam Ng says, Think of it as analytics for a website you havent built yet. So we built TreejackAs 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 didnt 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 testSo, what does online tree testing look like? Lets look at what a participant sees. Suppose weve 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 theyre welcomed and instructed in what to do. Once they start the test, theyll 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 (Id 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 theyve finished all the tasks, theyre done ? thats it. For a typical test of 10 tasks on a medium-sized tree, most participants take 5-10 minutes. As a bonus, weve found that participants usually find tree tests less taxing than card sorts, so we get lower drop-out rates.Creating a tree testThe 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 sites 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 tasksWe 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 weve 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 resultsSo weve 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, weve earned ourselves a beer. Often, though, well find ourselves looking at a 5 or 6, and realise that theres more work to be done. The good news is that our miserable overall score of 5/10 is often some 8s and 9s brought down by a few 2s and 3s. This is where tree testing really shinesseparating 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, weve 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 learnedWeve run several tree tests now for large clients, and were very pleased with the technique. Along the way, weve 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 weve 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, its 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. ConclusionTree 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.2References1. Dont Make Me Think:http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758, Steve Krug2. Full disclosure: As noted in his bio:http://boxesandarrows.com/person/35384-daveobrien, OBrien works with Optimal Workshop.
• Sketchy Wireframes IntroductionWhen 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 doesnt 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 ProblemThroughout 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 dont 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 dont 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 cant draw a straight line people to the cant put down their sketchbook people. This leaves a disparity in the quality of sketched deliverables produced by the team. Many organizations feel its 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 sketchTo 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 documentsWireframes can be re-purposed for interactive prototypingSketchy Wireframes in ActionI 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 couldnt 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 sketchesHaving used computer-based sketchy wireframes on a number of projects, Ive 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. Dont 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 isnt 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, Ive 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 dont like the font on those words, sketchy wireframes are more likely to elicit comments like I dont 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, Ive found that many of them are missing what I have identified as four essential capabilities necessary to be considered a complete sketchy wireframing tool: 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 arent 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. 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.Realistic Lines -Its 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 computers 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.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 ToolsSoftware 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 FlexibilityBalsamiq1DenimExpression Blend 3Fore UIFireworksIllustratorInDesignOmniGraffle PidocoVisio2Key: = No Support = Partial Support = Full SupportAssumes prototype flexibility using a 3rd party program called NapkeeAssumes use of custom line styles, as demonstrated in this tutorial ConclusionAs 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.
• Engaging Interaction iTunes     Del.icio.us     Podcast music generously provided by Bumper Tunes DownloadThis 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 WorkshopsThe 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 cant draw, designing for mobile, and prototyping with Arduino:http://www.arduino.cc/.Keynotes include:Paola Antonelli ? Senior Curator of Arch & Design at MOMABill Moggridge  IDEO founder and interaction design pioneerJon Kolko  Associate Creative Director at Frog DesignDan Hill  Designer and urbanist:http://www.cityofsound.com/blog/2002/01/about_cityofsou.html from SydneyEzio Manzini- Sustainability expert:http://www.sustainable-everyday.net/manzini/ and Professor of Industrial Design at Politecnico di MilanoNathan 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 SessionsJennifer 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 ChallengeSavannah 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 ChallengeStudents 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 ExhibitionExploring 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.
• IDEA 2009 - Day 2 IDEA2009 had the worlds foremost thinkers and practitioners converge on Torontos MaRS Convention Center to share the big ideas that inspire, along with practical solutions for the ways peoples 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 TunesDay 1 @idea09 | Day 2 @idea09Innovation Parkour  Matthew MilanInsight 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 AndersonRemember that percentage complete feature that LinkedIn implemented a few years ago, and how quickly this accelerated people filling out their profiles? It wasnt 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 whove 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 tomorrows deadline.. Download Seductive Interactions (Idea 09 Version)View more documents from Stephen Anderson. Social Design Patterns Mini-Workshop  Christian Crumlish & Erin MalonePrincipal 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. Ive 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 LuangrathMari 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: shes used Twitter, Facebook, and LinkedIn to build relationships with Chicagos 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 shes received since May 2009 can be tied directly to social media. While social media is constantly evolving from one medium to the next, its absolutely one of the most immediate ways to interact with potential consumers, influencers and connectors in your target market. Of course, theres 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 shes 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 dont 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 NYs 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.
• Four Key Principles of Mobile User Experience Design 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. VoiceVoice 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? MessagingFriedhelm 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 InternetThe 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. ApplicationsFrom 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. ConclusionSomeone 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.
• IDEA 2009 - Day 1 IDEA2009 had the worlds foremost thinkers and practitioners converge on Torontos MaRS Convention Center to share the big ideas that inspire, along with practical solutions for the ways peoples 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 TunesDay 1 @idea09 | Day 2 @idea09 The Impact of Social Models  Luke Wroblewski As Richard Farsons 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 products 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 Webs most popular social applications.. Download The Impact of Social ModelsView more presentations from Luke Wroblewski. Social Spaces Online: Lessons from Radical Architects  Christina WodtkeWhile 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 MalabyThe rise of virtual worlds (World of Warcraft, Everquest) has prompted new questions about the status of games in a digital age. Thomas Malabys 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. DownloadMaking 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 DachisEverything that can be digital will be. Why? Because its 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 dont get too comfortable, b/c the future is about to change?again!. DownloadSocial 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 ReicheltFor 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 KalmanWhat 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 well 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 years trends? And how have events and the art of event design changed now that social networking is part of almost everyones daily life.. Download The Information Superhighway: Urban Renewal or Neighborhood Destruction?  Mary NewsomAs a long-time practitioner of daily newspaper journalism who sees the economic model of the newspaper industry sinking (and broadcast journalism isnt 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.
• What design researchers can learn from hostage negotiators 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 ResearchThere are two types of behavior that we try to extract when conducting research:What the participant does (physical interaction with product)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 NegotiatorsDominick 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 RapportRapport 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:Go slow – Engage in small talk at first. If you dive right into business, the situation can become uncomfortable.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.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.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.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.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.AlliancesIn 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 ApproachHostage 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.TrainingFor 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: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.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.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.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.ConclusionThis 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.
• Experience Themes Theres an old adage among screenwriters that when a writer can sum up a story in a sentence or less, he has discovered whats important about the story. Hell know what the story is about and therefore have a strong sense of theme. And in knowing the theme, hell have a compass to use in the process of designing the damn thing (i.e. what to keep, what to lose, what actually happens at the end). The story will be all the better for it because it all hangs together with a central idea that will give it greater impact and meaning. Now wouldnt it be nice if we had something like that for user experience design? This article is about a method drawn from storytelling that can help us build a better story about our product, unify teams, inspire design concepts and get us closer to evoking the pleasure, emotion and meaning of the experience we intend to deliver to users through the products and services we design. So, Whats the Problem Anyway? As designers, we spend a lot of time examining design solutions against an array of information?business goals, user needs, design principles, best practices, the results of usability tests?but less often (if at all) against a definition of the core experience we hope to deliver. If youre not sure what I mean, think about this: We had a big problem at our company. The problem was that the websites we were designing and building were coming together like potluck meals made by a loose confederation of team members and stakeholders who were all working out their dishes independently, and on their own terms. You know the story: User experience brings the structural framework and behaviors of the interface; creative brings the visual design; client marketing brings the copy; business brings content; our engineering folks were sometimes bringing error messages. When each of these more tangible elements are cooked up in separate quarters without a shared vision or intent how can we possibly deliver an optimal experience, let alone agree on what that experience should be? Its not that the meal is bad?it often makes a lot of people very happy?it just seemed that we were missing out on a chance to serve up something better, something that would distinguish itself as a dining experience people would remember in a marketplace of potluck dinners. Coming from a filmmaking background where its a matter of course to see an army of people with specialized roles focus their efforts around bringing the story of the project to life, it often seemed as if our practice as UX designers neglected an important approach. On a film set, bringing a project to life involves having a very clear understanding of the experience the story is supposed to deliver to an audience. Everyone from the prop master to the camera person has a sense of this experience goal. If the story (or a particular scene) is supposed to make the audience fall over with laughter, the cameraperson, to be sure, will frame each shot in a way that maximizes that goal. Every scene, every moment, every tangible element of a film works together for a purpose: to make it easier for audiences to understand and engage with a story and to create an emotional response to walk away with. In the case of user-centered design, we do well at coming up with the right technology and features that perform in a way that meets the needs or behaviors we observe in our users. But we often neglect to consider the story thats told through the interactions people have with the things we make. For this story to be apparent to people, let alone meaningful, those involved with the design of a product should have a shared sense of the kind of experience they are trying to create. In the domain of digital products the story comes from asking the big questions: Whats the product or service about? What will it do for the customer? Where does it fit into their lives? In what ways might we create an emotional response the customer can walk away with? How does a good story get built? With a theme, of course. Writers and filmmakers have been using themes to build stories for a very long time. Theyre also not shy about designing explicitly for emotion and meaning. So why not designers? For us, a definition of the core value of experience can function as the theme that helps teams collectively build a more meaningful product. Its the thing that can serve as a coordinating force behind the design. When the tangible elements of a product are all working together for the same purpose the product has a stronger story to tell. The theme is merely the thing that helps us deliver that story in the form of an experience. From Theme to Story For a writer, a theme is not the thing one starts with, but the thing one finds or discovers at some point after the writing has begun. Its an idea that should emerge organically from the raw material of ones research, note-taking, plotting, scene-making, and character sketches that are produced during the story planning and early writing process. Typically, a story theme is expressed as a value (greed), an opposition (freedom vs. security), a value plus a cause (justice is restored when the truth is revealed), or simply a very strong gut feeling of what the story is ultimately about. The form can vary widely, and often depends on the bent of the writer or the type of story. An experience theme also emerges from the raw materials of our design process: the business goals, market considerations, user research and content analysis, among others. Yet while a story theme may express a topic or idea, an experience theme expresses the core value of the user experience. One such theme, for a project commissioned by Agnes Nixon, the renowned writer and creator of the soap _All My Children_, looked like this: _Reliving All My Children_ Agnes Nixon and her family had asked us to create a site that would leverage their tremendous library of content in a new, engaging interactive video-centric web property. That was their only requirement. So where to start? We started where one might expect. We immersed ourselves in the domain, read about soap operas, watched episodes, and spoke to fans until we got to the point where we felt like we finally understood what this rather obsessive world of fandom was all about.But when it came time to define functional requirements, it simply wasnt enough to take the business objectives and our user research and conclude that we should create a flexible video portable that would do x, y and z, include a really cool interactive timeline of Agnes Nixons life and a blog authored by Ms. Nixon herself. This wasnt a concept or an experience. It might be easy to use. It might perform well and look great. But to go that route would do no more than deliver a library of branded video content. What we needed to know was what this site was all ABOUT. What will it do for these fans? Where does it fit into their lives? In what ways might we create an emotional response the fans can walk away with? So in an attempt to break away from our customary ways of approaching design we started hunting for themes. We looked at what we had learned about prospective users and soap fans in general and considered our business objectives. With this information we then spent a long time brainstorming ideas that would answer two questions: Whats the site all about? and What kind of experience would be most compelling and meaningful to our users? _Reliving All My Children_ was just one of three possible themes. Our plan was to take these themes to the client to see if it would help them further articulate their vision. Each of these themes sprang directly from what we knew to be true about soap fans, and each evoked a different kind of experience. For each theme theres also an associated concept and story premise as well as an altogether different set of primary activities. If the site was to be about _Reliving All My Children_, then our design process would focus on creating an engagement that would tap into the memories of loyal soap fans who grew up watching the show. This theme evoked a product story about an immersive time machine where fans could engage with a story timeline of episodes, read blog posts about memorable moments, ask Agnes Nixon questions about what happened to certain characters.The idea was that one of these themes would drive the sites concept, functional requirements and our design strategy. The amazing thing: when the client saw these themes they were suddenly able to talk at great length about their vision for the fans experience of the site. We had, together, begun to form our product story. Go team, go! Once your team has an experience theme, they can begin to behave more like film crews. Everyone involved in the project will have a clear sense of what the site is about and their efforts can be focused around achieving that experience. When this happens all of the component parts of the product will begin to work together. If youre a consultant or designer working alone, you can think of the theme as the thing that will coordinate your inner team. But how does this happen? In our practice, the experience theme is packaged in a way that can be shared and internalized by all stakeholders. This usually takes the form of an _Experience Brief_ that outlines the purpose of the theme, the attributes upon which it was founded and the strategy it informs. And in a manner of speaking this document becomes another iteration of the product story. For another project we created a theme that was to capture the value of the experience of an entertainment alerts program: _Dont Miss Out. Discover something new. Get it first._ With this long-term client, comprised of stakeholders from separate interactive, business and marketing departments, we introduced the concept of a theme with an experience brief that looked like this: Our goal was to get this client to step away from discussions of pure functionality and to consider the value of using the product. As we were leading the research, we did the work of finding the theme that seemed to best reflect their business goals as well as their users expectations. We also appended a strategy, drawn from this theme that would connect it to more tangible, measurable goals. With this brief on the table in front of them, the concept of user experience no longer seemed so abstract. By expressing the value of that experience, it gave them a way to look at their program from the point of view of their users. It gave us, as their vendor, a way into their ideas of what they envisioned as well as a chance to validate our thinking behind what kind of experience the program could deliver. It led to a discussion about how the efforts of marketing could match up with what we were doing in the design of the online piece. The overall effect of this simple document was to synchronize our collective thinking about the project. In this way our product story was beginning to form. With this shared story, the copywriter from the marketing department and the interaction designer with our agency could now work toward the same experience goal. Designing with Themes in Mind Whats really interesting is how themes, once found, function in the creative process. In the words of Robert McKee, the author of Story and screenplay workshop guru, the theme (or, as he liked to call it, the Controlling Idea) is the thing that _shapes the writers strategic choices. Its yet another Creative Discipline to guide your aesthetic choices toward what is expressive of your Controlling Idea and may be kept versus what is irrelevant to it and must be cut._ A subplot, for example, may be constructed as a counterpoint to that controlling idea. A character might be designed to embody some aspect of theme. A scene might be cut because its simply not relevant to the theme. The best way to understand how this applies to design is to think of the theme as the geography as well as the compass. When generating concepts, the theme acts as the region within which our ideas circulate: this conceptual lay of the land gives us an area of focus and a space to create. When analyzing and reviewing solutions, a theme functions more like a compass: if a creative solution doesnt line up with North, it might mean that it doesnt quite chime with the theme. In this way theme can inspire solutions as well as help us make decisions during the design process. In another project, our team used the following theme to inspire solutions ranging from functional requirements to content strategy, site architecture and interaction design. _Where the Fight Never Ends_ This project was for Showtime Sports, a site delivering content and event information for fans of Boxing and Mixed Martial Arts. We felt this theme encapsulated the idea that the site could provide an online experience that seamlessly extended the kinds of real-world engagement found among fans of the sport. Not only could the fight live on in the context of the site, but fans would be able to engage, follow and learn about the full fight story. It was supported by our research, and potent enough to carry around as an idea that could inspire and inform anyone working on the project and at all phases. It was expressive of what differentiated the site as well as what would be compelling to users. It was good for business as well as design. Here are some examples of how the theme impacted our design:Functional Requirements  We used the theme as a compass when looking at our standard spreadsheet of features for determining scope. In addition to frequency of use, importance and level of technical difficulty, we looked at these items against theme. For example, someone had an idea for a really cool dynamic ranking tree. Fabulous, but when its put up against the core story of the site it really had no place. The site wasnt about seeing the sport in this way. It was about extending the experience of a fight. With the theme as an additional filter, it was easy to remove this from the list without prolonged discussion about its value. The idea simply wasnt contributing to the core experience we were hoping to deliver. Content Strategy ? As a basis for content strategy, we analyzed the available content against the theme and created suggestions for new content ideas. Showtime had a wealth of footage related to each event and some promo clips shot before the fight, but nothing about what happened well-before or after a fight was over. When thinking about content that could support our theme, we suggested creating short, cheaply produced segments of the fighters private struggles in preparation for an event. We also suggested in-depth interviews with the fighters after the fight?something that would give them a chance to reflect on what they needed to do in preparation for the next fight. In this way, the theme functioned as a space in which to generate ideas that would support our collective vision about what was most important about this site experience. Site Architecture ? The theme inspired ideas for the structure and user pathways. For this, we began thinking about how the users flow through content would reflect our theme. We created a concept model as a way of seeing these paths and their relationship to key content areas. To further explore this idea, we created an animated version of the model which added a dimension of time, where certain content elements appeared during specific phases of the fight (illustrated by the colored bands around the content buckets). Our hope was that this evolving structure would also support the theme.Interaction Design  When it came time to create solutions for the interface, our interaction designers sketched with the theme in mind as way to ideate concepts. This is the moment when the use of theme feels closest to writing. In this context theme is simultaneously our geography of play as well as our compass for analysis. We try not to be over-conscious of theme when generating ideas and sketching, but we do want to have it in the back of our minds.To this end, we usually have our theme written somewhere on the whiteboard. Then, while iterating on sketches, well pause and discuss the way we usually do, but well also reflect on whether or not the sketches are doing anything to support our theme. This process eventually led to the design of a flash component that stored all video content related to the fight in a carousel organized by time. The linear progression of videos would together create a fight story, from early pre-fight videos to post-fight interviews. Whether users wanted to catch up on something theyve missed, follow the fight online in absence of TV or revisit the fight at some future point the interaction design was supporting our experience goal of providing a place where the fight never ends.The lesson? Experience themes can inspire solutions, help teams make decisions and (perhaps most important) help us remember the quality and value of the experience we intend to deliver. Final thoughts As Robert McKee writes: The more beautifully you shape your work around one clear idea, the more meanings audiences will discover in your film as they take your idea and follow its implication into every aspect of their lives. Themes, used in the context of experience design, can function in a similar way. By aiming to capture the value and focus of experience, themes have guided us in the design process and, by extension have strengthened the impact and meaning of that experience. Equally important, theyve given us a path to holistic design. As user experience professionals we should be looking at all aspects of the product or service design, as well as the aesthetic potential of every element that comprises the experience. Themes can help us do that. They can be a potent tool for harmonizing otherwise distinct, tangible elements of a product or service in a way that will effectively distinguish it from competitors and offer a more pleasurable and meaningful experience on the part of the user. A theme can be applied to all stages of the experience design process, and it helps everyone involved in creating the whole of the product or service, no matter what their role. From the critical perspective of leaders and stakeholders, a theme will help unify the efforts of those who play a role in anything from the strategy to the design, development and delivery of the service. The ultimate beauty of a theme is that, in the product or service context, it can simultaneously inform the practical, tactical and aesthetic considerations of our work. It can be the coordinating force for an entire product, or a smaller component of a larger service. It is the organizing principle behind our product story. It can work for business as well as design. And in the end, it ultimately works for the benefit of customers.Special thanks to Steve Baty, my editor, as well as Joe Lamantia, Jared Spool and Andrew Hinton for their immensely helpful support and feedback for this article.
• Integrating Prototyping Into Your Design Process “ Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. ” Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But heres the thing& prototyping is not a silver bullet. There is no one right way to do it. However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered. The dimensions of fidelityA prototypes fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a high-fidelity prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out whats most important to UX designers, what its like to actually work with the prototype! Fidelity is multidimensional.Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity visual fidelity and functional fidelity. By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Lets take a look at some examples.A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations. That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations. After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:There is no such thing as high or low fidelity, only appropriate fidelity.Appropriate FidelityAppropriate fidelity refers to a level of prototype fidelity that allows you to achieve the goals youve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others. Low Visual and Low Functional FidelityVery low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:Does the system have all the features required to support the users goals?Does the workflow make sense at a high level?Which UX concept works best?Coming to consensus on a UX concept with stakeholders, e.g.Is this what you meant? Low Visual and High Functional FidelityIn my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes. Everything is black, white, and gray, but the interactions are extremely close to what theyd be in the developed system. These types of prototypes are effective in many situations:Evaluating the usability of proposed designs for new systemsExploring isolated interactions as a proof-of-conceptValidating UX design direction with stakeholdersValidating the implementation of requirements with stakeholdersSupplementing printed documentation for development teamsPerforming remote testingRemote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations. “ By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it&. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth. ” I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, Ill know that and can release the design with confidence instead of with gritted teeth. High Visual and Low Functional FidelityAt first thought, these prototypes may not make much sense. Why bother making something look nice if it doesnt work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what Ive heard termed a slap and map test from within a browser. High Visual and High Functional FidelityHigh visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isnt worth it. But there are a few situations where it is:Evaluating the usability of proposed UX designs for an existing systemPerforming usability tests with non-savvy user groupsSupplementing printed documentation for offshore development teamsPrototype testing is all about data, right? In the first two situations above, the prototypes high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.Integrating Prototyping Into Your Design ProcessWhat Ive talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process? First off, do what youd do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose. “ People like shiny things that move. The cool factor of prototyping will be difficult to resist. ” As you near completion of the prototype, make sure you walk through the prototype with the projects stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and youre soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, its very likely they will actually request a prototype as a result of their first experience with you. Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.Corporate, Agile, Mature UX PracticeThis situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your companys products. In this situation, there are three points in the design process that prototyping can be of benefit.Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system to build efficiencies into an Agile process.Corporate, Waterfall, New UX Practice In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organizations need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Heres how prototyping can help:High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your directionThese prototypes should also be used for user testing, if at all possible. Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.Consulting/AgencyWhen doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like theyre paying for the same thing twice.Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the users shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.
• A Wiser Interaction iTunes     Download    Del.icio.us     Boxes and Arrows theme music generously provided by Bumper Tunes Chris Baum speaks with Bill DeRouchey, co-chair for the 2010 Interaction Design Conference, about the upcoming conference and how the third annual conference will start to model the essence of Interaction Design. Looking BackBill talks about the first two years of the conference, the lessons learned from those experiences, and why Interaction 10 returns to Savannah.A Brand New ProgramFor 2010, the program is quite different. Bill explains the new approaches, in particular Discussions and Activities, and why they are changing things up. He also covers the Documentary and Art Exhibition, two new Interactions-related events.Submitting for Interaction 10Interested in submitting session proposals for Interaction10? Submissions are open:http://interaction.ixda.org/submissions.php until September 15. Documentary and Art submissions are open until November 1.IxD S.W.A.T. TeamAlong with Bill and Jennifer Bove, his co-chair, the conference team includes several well-known designers. Bill explains how each is bringing her/his talent to the conference preparations.IxD in a Physical EnvironmentFlow of people in a hotel is relatively easy. In Savannah, however, Interaction spans several buildings. Bill describes how that will affect the design of the conference proper.SponsorsInteraction 10 will also introduce some new sponsorship programs. Bill explains what this means and how that helps both sponsors and conference attendees.Test & IterateThe conversation closes with more reflection on what the IxDA has learned from the first two years of the conference, and how 2010 will reflects what has come before. For more information, visit interaction.ixda.org:http://interaction.ixda.org/.
• IDEA 2009: An Interview with Thomas Malaby As IDEA 2009 draws closer, the IA Institute is conducting a series of interviews with the speakers for the conference. As Director of Events and Marketing for the IAI, I fill a variety of roles and lead the charge for the IDEA Conference this year, as well as get to Interview the IDEA Presenters (which I proudly share with Greg Corrin in this case).For this interview, I was able to ask a few questions with Thomas Malaby. Malaby is an Associate Professor of Anthropology at the University of Wisconsin-Milwaukee and has a forthcoming book titled "Making Virtual Worlds: Linden Lab and Second Life" from Cornell University Press.You recently finished a book about Second Life and online communities titled “Making Virtual Worlds” (Cornell University Press). Can you describe how your research process was structured for this writing effort? How does one conduct ethnographic research in online communities effectively?The rise of digital technologies poses many challenges and opportunities for ethnographic research. Because this project centered on the makers of Second Life, Linden Lab in San Francisco, to a certain extent the familiar form of face-to-face ethnographic participant observation and interviewing was possible. But nonetheless even within the company an enormous amount of communication occurred through technologically mediated channels, including multiple email lists, wikis, an IRC channel, instant messaging, plus all of the tools for communication found within Second Life itself, wherein a great deal of Linden employees’ work was done.What are some of your key research findings about Second Life? How is this community progressing from a sociological perspective?My primary finding concerned the way in which the ostensibly “user-generated” world of Second Life was nonetheless shaped so deeply by the values and expectations that the makers at Linden Lab inscribed into it. What emerges is that while we may be tempted to think of the communities (and there are many) within Second Life as existing in a somewhat “natural” state, free to develop as they wish, in fact all users of Second Life are always already acting within an environment that makes assumptions about what kind of people they are. The inscription of property rights into the world is only the most obvious example of the ineradicable ideological assumptions that are part of SL.Do you have any advice for professional or other organizations as to how they could use Second Life to help foster increased activity amongst their members?Second Life’s advantage is the wide bandwidth for nuanced social action that it provides. That is, moving about as avatars within the environment broadens the scope for meaningful expression in ways that can form the foundation for powerful applications. From my point of view, the most promising of these are educational and therapeutic — uses that leverage the real human connections possible in an environment that allows people to express themselves so broadly.Did you find in your research that Second Life is evolving in a unique way compared to other communities?Certainly, but in a sense any given community changes historically in a unique fashion. We are always tempted to find some common sequence or pattern to how societies change, but overwhelmingly the evidence that anthropology and related fields have found about all communities is that they change historically, in contingent ways. There are some patterns we can observe that hold across some if not all cases, but no universal path. This is a facet of all change (even evolutionary change) that Charles Darwin deeply appreciated, but it is often forgotten in our desire to have universal answers.Do you care to make a prediction on the future of online communities? Will Second Life shape any primarily online social world going forward, or are other systems innovating in other more interesting ways?I think Second Life already has. Metaplace, the new virtual world by famous game designer Raph Koster, owes an enormous amount to Second Life in its conception of what users want (ideas that more deeply connect with longstanding assumptions about people, authority, and technology in postwar-U.S., especially the Bay Area).Do you spend much time actively participating in communities online or are you always wearing a researching hat? If so, in which communities do you spend your leisure time?I spend a great deal of time in virtual worlds, and almost all of it is in World of Warcraft, where I lead a guild of academics and their friends and family.There are many different online and mobile applications that allow people to find new methods of connecting with very little overhead.  How do you think SecondLife can compete—or work in conjunction—with these?With any networked technology (really, any technology) we must always be mindful of the specific experience of using it and the affordances it brings. There are things that Second Life and similar worlds are good at that mobile apps could never hope to achieve, and it is the same in the other direction. We don’t need killer apps, we need killer usesand those are far harder to anticipate and encourage through design. About Thomas MalabyThomas Malaby is Associate Professor in the Department of Anthropology at the University of Wisconsin-Milwaukee. He has published numerous works on virtual worlds, games, practice theory, and indeterminacy. His principal research interest is in the relationships among institutions, unpredictability, and technology, particularly as they are realized through games and game-like processes.You can learn more about Thomas on the Speakers Page and the Program Page of the IDEA Conference website.About IDEA (Information Design Experience Access) 2009: Social Experience DesignIDEA2009 brings together the world’s foremost thinkers and practitioners: sharing the big ideas that inspire, along with practical solutions for the ways people’s lives and systems are converging to affect society.These days, you can’t be socially engaging without considering the experience design. IDEA2009 brings together like-minded people who want to continue the exploration of Social Experience Design.

Feed cached for the next hour.

A List Apart: Web design news, info, and insights since 1995. CSS layout, XHTML, usability, accessibility. Designing with web standards. ISSN: 1534-0295. A List Apart
A.P.Lawrence Unix, Linux and Mac OS X Resources: Resources and information for Unix/Linux, Mac OS X, and other computer related topics. Thousands of articles, reviews, consultants listings, skills tests, opinion, how-to's, suggestions and more for Unix, Linux and Mac OS X, networking, web site maintenance and more.. A.P.Lawrence Unix, Linux and Mac OS X Resources
ABC News scitech ABC News scitech
About This Particular Macintosh: A Mac e-zine about the personal computing experience. About This Particular Macintosh
AccelerateYourMac News Headlines: Mac News, Reviews, Tips, Guides and More AccelerateYourMac News Headlines
ActiveMac: The Most Activated Windows Resource ActiveMac
Politics news and headlines from thousands of news sources worldwide, updated every 15 minutes. All Headline News
AlwaysOn Network News AlwaysOn Network
Apache Week: The essential resource for anyone running an Apache server, or anyone responsible for running Apache-based services. Apache Week
Apfelgeruechte.de: Nachrichten rund um den Macintosh Apfelgeruechte.de
Apple Computer Top Mac OS X Documents: Top Mac OS X Knowledge Base documents from Apple Computer, Inc. Apple Computer Top Mac OS X Documents
Apple Hot News: Hot News provided by Apple. Apple Hot News
Apple-X.net: Apple-X.net Backend Apple-X.net
AppleInsider: Hot News provided by Appleinsiders. AppleInsider
Ars Technica: The PC Enthusiast's Resource Ars Technica
Aufgelesen: Anmerkungen zu Allem. Von Ulrich van Stipriaan. Aufgelesen
base macintosh, design and photoshop tennis online hub: The latest active threads at baseboard base macintosh, design and photoshop tennis online hub
BBC News: Updated every minute of every day BBC News
Up to date news and information on the latest in cutting edge software. BetaNews
Blackhole News: Blackhole News
Boxes and Arrows Boxes and Arrows
citrusmoon: Free patterns, tiles, backgrounds and conversation citrusmoon
Cocoa Dev Central: Serving Cocoa Newbies since (++2000) Cocoa Dev Central
macscripter.net code exchange Code exchange @ Macscripter.net
codepoetry is a weblog-style site geared towards news, commentary, and satire of the technology industry. codepoetry
Computerworld Macintosh News: Computerworld.com connects the IT community with important news, business and technology information, as well as with their peers. The site complements and expands beyond the print edition of Computerworld with a continuous feed of technology news and analysis, as well as research and other services not available anywhere else. Computerworld Macintosh News
Cult of Mac: wiredblogs's Tripod blog Cult of Mac
Daring Fireball: Mac and web curmudgeonry/nerdery. By John Gruber. Daring Fireball
DealMac: find the best Prices on Macintosh Gear. DealMac
del.icio.us/tag/css various links from various users. del.icio.us css
del.icio.us/tag/php various links from various users. del.icio.us php
del.icio.us/tag/javascript various links from various users. del.icio.us javascript
Designtechnica Articles: Designtechnica Main channel has the 10 latest news articles, two latest reviews, and two latest Talk Back articles. Designtechnica Articles
Disturbing Search Requests: What's in your referrer logs? Disturbing Search Requests
dotmac.info: dotmac.info -- Recent News Headlines dotmac.info
DrunkenBlog: When all you have is a hammer, everything looks like a nail. DrunkenBlog
esa Science & Space News esa Science News
Fink Project Packages and more. Fink Project
freshmeat Newsletter: freshmeat.net maintains the Web's largest index of Unix and cross-platform open source software. Thousands of applications are meticulously cataloged in the freshmeat.net database, and links to new code are added daily. Freshmeat Newsletter
freshmeat OS X: freshmeat.net maintains the Web's largest index of Unix and cross-platform open source software. Thousands of applications are meticulously cataloged in the freshmeat.net database, and links to new code are added daily. Freshmeat OS X
Global Indymedia Newswire: Recent stories compiled by IMC editors worldwide Global Indymedia Newswire
Graphic Design: Graphic Design Graphic Design
Graphics.com: Graphics.com Graphics.com
Hack the Planet: News and views from Wes Felter. Hack the Planet
heise online news: Nachrichten aus der Welt des Computers heise online news
Insanely Great Mac: Insanely Great Mac publishes daily Mac news from Apple and the Macintosh industry. Site's content includes news, reviews, tips, and troubleshooting Insanely Great Mac
The Internet Archive Internet Archive
iTunes Top 25 Albums: iTunes Music Store: Today's Top 25 Albums iTunes Top 25 Albums
JavaScript Tip of the Day: Doc JavaScript's Tip of the Day Archive JavaScript Tip of the Day
Low End Mac: Resources for Mac users. Low End Mac
Mac Game Database: The ultimate Mac games finder. Mac Game Database
Mac Net Journal: Making the most of OS X on your Mac. Mac Net Journal
Mac OS X Apps: The Source For Mac OS X Software Mac OS X Apps
Mac OS X Downloads - Dashboard Widgets: Mac OS X downloads provided by Apple. Mac OS X Downloads - Dashboard Widgets
Mac OS X Downloads - Imaging & 3D: Mac OS X downloads provided by Apple. Mac OS X Downloads - Imaging & 3D
Mac OS X Downloads - Internet Utilities: Mac OS X downloads provided by Apple. Mac OS X Downloads - Internet Utilities
Mac OS X Downloads - Productivity Tools: Mac OS X downloads provided by Apple. Mac OS X Downloads - Productivity Tools
Mac OS X Downloads - System/Disk Utilities: Mac OS X downloads provided by Apple. Mac OS X Downloads - System & Disk Utilities
Mac OS X Downloads: Mac OS X downloads provided by Apple. Mac OS X Downloads
Mac OS X Hints: Get the most from X! Mac OS X Hints
MacCentral: MacCentral is the leading resource for Macintosh-related headline news. Continuously updated seven days a week, this site brings readers late-breaking news and product announcements from all over the industry. MacCentral also provides software updates, tips & tricks, forums, reader polls and more, all in a format that is engaging, fun and easy to use. MacCentral
Maccentric.com: The latest news from Maccentric.com. Maccentric.com
MacDailyNews: Your source for daily news about Apple, Mac OS and the Macintosh platform. MacDailyNews features news, links, tips, and opinions. MacDailyNews
MacFixIt: Troubleshooting Solution for the Macintosh MacFixIt
macgo: your #1 online mac community macgo
MacInTouch: The original Mac news and information site since 1994 MacInTouch
MacIT.org: Notes from a Macintosh systems administrator MacIT.org
MacMegasite: We will bring you the latest Macintosh news, tips, and rumors from a developer's point of view. MacMegasite
MacMerc: MacMerc
MacMinute: Mac news first. MacMinute
MacNewsworld - Mac Intelligence for the Enterprise MacNewsworld
MacNN: MacNN is the leading source for news about Apple and the Mac industry. It offers news, reviews, discussion, tips, troubleshooting, links, and reviews every day. The best place for Mac News. Period. MacNN
macosXrumors: Latest rumors on Mac OS X and related software. macosXrumors
MacRumors.com Page 2: more mac news and rumors MacRumors.com Page 2
MacRumors: the mac news you care about MacRumors
macscripter.net news: Your best source for all things AppleScript macscripter.net news
MacShareware.net: Shareware software reviews MacShareware.net
MacSlash: A daily dose of Macintosh News and Discussion MacSlash
MacsOnly: We don't do Windows MacsOnly
MacTechNews.de: News Tag und Nacht. Wissen was wichtig ist. MacTechNews.de
MacUpdate - Mac OS X: MacUpdate new releases for Mac OS X MacUpdate - Mac OS X
MacZealots.com - Articles: Articles MacZealots.com - Articles
MacZealots.com - Tutorials: Tutorials MacZealots.com - Tutorials
metamac.de - macs, menschen und mehr metamac
News headlines from more than 7,000 sources, harvested every 15 minutes... Moreover Science News
myapplemenu: Mac News for Mac Users myapplemenu
MyMac.com: publishing since 1995 MyMac
N24 - Werden Sie Augenzeuge.: N24 - Werden Sie Augenzeuge. Deutsche News rund um die Uhr. News in German. N24 - Werden Sie Augenzeuge.
National Geographic News: Scientific and Environmental News daily. National Geographic News
Newsticker - Hamburger Abendblatt: Newsticker Hamburger Abendblatt Newsticker - Hamburger Abendblatt
NPR News: NPR is an internationally acclaimed producer and distributor of noncommercial news, talk, and entertainment programming. NPR News: World
OSXFAQ: Technical News and Support for Mac OS X OSXFAQ
OSXGuide.com: OSXGuide.com Backend OSXGuide.com
PHP Everywhere: Daily news, articles and free source code on PHP, the popular web scripting language, and other Web technologies. PHP Everywhere
PHP: Hypertext Preprocessor: The PHP scripting language web site PHP: Hypertext Preprocessor
PHPBuilder.com Newest Help Forum Posts: Newest Help Forum Posts On PHPBuilder.com PHPBuilder.com Forum Posts - coding
PHPBuilder.com Newest Help Forum Posts: Newest Help Forum Posts On PHPBuilder.com PHPBuilder.com Forum Posts - general
PHPBuilder.com New Articles: Newest Articles and How-To's on PHPBuilder.com PHPBuilder.com New Articles
phpComplete: php, linux, open source, and stuff phpComplete
PHPDeveloper.org: Up-to-the Minute PHP News, views and community PHPDeveloper.org
PHPmac.com: The largest online resource totally dedicated to Mac users of PHP PHPmac.com
PhysOrg Team: The latest physics and technology news. PhysOrg Team
Reuters Science News Reuters Science
Reuters Technology News Reuters Technology
Reuters News Reuters
Salon: Salon makes you think. Salon
scriptbuilders @ macscripter.net: Your best place for everything AppleScript scriptbuilders @ macscripter.net
SecurityFocus is the most comprehensive and trusted source of security information on the Internet. We are a vendor-neutral site that provides objective, timely and comprehensive security information to all members of the security community, from end users, security hobbyists and network administrators to security consultants, IT Managers, CIOs and CSOs. SecurityFocus News
SecurityFocus is the most comprehensive and trusted source of security information on the Internet. We are a vendor-neutral site that provides objective, timely and comprehensive security information to all members of the security community, from end users, security hobbyists and network administrators to security consultants, IT Managers, CIOs and CSOs. SecurityFocus Vulnerabilities
Slashdot: News for nerds, stuff that matters Slashdot
Slate: the Internet's informed look at news, politics, and culture. Slate separates the facts from the spin with thought-provoking stories, irreverent humor, and delicious reads. Slate
SourceForge.net Project News: SourceForge.net Project News Highlights SourceForge.net Project News
spacetoday.net: Space news summaries and links to articles published around the web. Spacetoday.net
SPIEGEL ONLINE: Schneller wissen, was wichtig ist SPIEGEL ONLINE
Stoer-Signale: Information is a state between chaos and entropy Stoer-Signale
Surfin' Safari: Dave Hyatt's Weblog Surfin Safari
The Great News Network: Inspirational news headlines from around the world. The Great News Network
The Mac Observer: The Mac Observer: You'll Get Your Mac News Here From Now On... The Mac Observer
The Register: Biting the hand that feeds IT The Register
Think Secret: The latest news from Think Secret. Think Secret
VersionTracker: Mac OS X: The #1 source for software updates VersionTracker: Mac OS X
VersionTracker: Windows: The #1 source for software updates VersionTracker: Windows
Daily news, views, and how-tos on all aspects of web design and development. Features free web-based tools, open source scripts, and in-depth tutorials on DHTML, HTML, JavaScript, 3D, Graphics, XML, and Design for webmasters. Webreference
Wired News: Technology, and the way we do business, is changing the world we know. Wired News is a technology - and business-oriented news service feeding an intelligent, discerning audience. What role does technology play in the day-to-day living of your life? Wired News tells you. How has evolving technology changed the face of the international business world? Wired News puts you in the picture. Wired News
worldpress.org: Worldpress.org presents the best of the international press coverage. Worldpress Americas
worldpress.org: Worldpress.org presents the best of the international press coverage. Worldpress Europe
worldpress.org Topstories: Translations, analysis, and reporting from around the world. Draws on the greatest number of sources, updates irregularly throughout the day. Worldpress Topstories
Xicons.com: The premium source for Mac OS X icons. Xicons.com
Yahoo World News Yahoo World News
Latest technology news from Ziff Davis, featuring stories from eWEEK, ExtremeTech and PC Magazine Ziffdavis Technology News