Austin Mansu | Experience Architect in Sydney - Digital Experience Architect in Sydney

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

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

Step 1 – What’s your social object? Make sure there is a “there” there. Give users a reason to rally. Why would someone come to your site?

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

Step 2 – Give people a way to identify themselves and to be identified.

Attribution of a comment on flickr


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

Identity or Contact card as seen on FriendFeed


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

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

Relationship module shown from MyBlogLog


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

Step 3 – Give people something to do.

Thumbs up and down ratings for restaurants on GoodRec


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

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


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

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


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

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

Step 4 – Enable a bridge to real life (groups, mobile, meetings, face-to-face).

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.

Reputation labels on the intranet at Yahoo!


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

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



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


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

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

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

Go out and get started

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

Posted on 23 December 2009 | 12:54 am

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

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

Recruiting

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

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

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

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

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

Scheduling

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

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

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

Test Plan

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

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

Data Collection

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

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

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

Findings

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

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

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

Summary

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

Posted on 23 December 2009 | 12:54 am

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

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

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

How it all began

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

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

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

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

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

The problem

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

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

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

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

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

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

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

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

The technique—tree testing

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

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

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

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

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

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

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

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

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

So we built Treejack

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

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

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

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

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

Participating in an online tree test

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

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

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

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

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

Creating a tree test

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

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

Devising tasks

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

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

The results

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

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

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

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

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

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

Lessons learned

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

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

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

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

Conclusion

Tree testing 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.

References

Posted on 5 December 2009 | 12:02 am

Introduction

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

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

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

The same wireframe in sketchy and traditional representation.

The Traditional Wireframe Problem

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

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

Sketching to the rescue?

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

Why not sketch…

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

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

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


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

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

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

Enter the computer-generated sketch

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

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


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

Sketchy Wireframes in Action

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

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

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

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

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

The reaction to computer-based sketches

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

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

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

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

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

Computer-Based Sketchy Tools

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

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


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





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

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

   
   Some software automatically converts from sketchy to traditional lines.
   

   
   
   

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

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

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

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

   
   
   

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


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

Comparison of Computer Based Sketchy Tools

Key: = No Support = Partial Support = Full Support

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

Conclusion

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

Posted on 5 December 2009 | 12:02 am

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

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

Early bird registration ends Monday, November 30!

Pre-Conference Workshops

Keynotes include:

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

Interact Sessions

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

Local Challenge

Student Challenge

Art Exhibition

Posted on 26 November 2009 | 11:31 am

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

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

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


Day 1 @idea09 | Day 2 @idea09


Innovation Parkour – Matthew Milan

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

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

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

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

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

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

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

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

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

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

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

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

The Dawn of Perfect Products – Tim Queenan

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

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

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.

Posted on 19 November 2009 | 2:12 am

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Voice

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

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

Messaging

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

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

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

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

The Internet

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

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

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

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

Applications

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

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

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

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

Conclusion

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

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

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

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

Posted on 19 November 2009 | 2:11 am

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

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

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


Day 1 @idea09 | Day 2 @idea09

The Impact of Social Models – Luke Wroblewski

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

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

Social Spaces Online: Lessons from Radical Architects – Christina Wodtke

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Posted on 12 November 2009 | 11:59 pm

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

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

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

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

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

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

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

Application to Design Research

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

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

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

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

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

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

Learning from Negotiators

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

Building Rapport

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

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

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

Alliances

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

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

Team Approach

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

Training

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

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

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

Conclusion

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

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

Posted on 12 November 2009 | 11:59 pm

There’s an old adage among screenwriters that when a writer can sum up a story in a sentence or less, he has discovered what’s important about the story. He’ll know what the story is about and therefore have a strong sense of theme. And in knowing the theme, he’ll 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 wouldn’t 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, What’s 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 you’re 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? It’s 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 it’s 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 that’s 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: What’s 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. They’re 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. It’s 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. It’s an idea that should emerge organically from the raw material of one’s 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 wasn’t 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 Nixon’s life and a blog authored by Ms. Nixon herself. This wasn’t 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: “What’s 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 there’s 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 site’s 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 fan’s 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 you’re 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:

_Don’t 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 user’s 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

What’s 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 writer’s strategic choices. It’s 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 it’s 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 doesn’t line up with North, it might mean that it doesn’t 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:

1. 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 it’s put up against the core story of the site it really had no place. The site wasn’t 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 wasn’t contributing to the core experience we were hoping to deliver.



2. 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.
   
   
   
3. 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.
   
   



4. 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, we’ll pause and discuss the way we usually do, but we’ll 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 they’ve 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, they’ve 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.

Posted on 6 October 2009 | 1:25 am

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 here’s 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 fidelity

A prototype’s 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 what’s most important to UX designers, what it’s 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. Let’s 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 Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve 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 Fidelity

Very 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 user’s 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 Fidelity

In 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 they’d be in the developed system. These types of prototypes are effective in many situations:

• Evaluating the usability of proposed designs for new systems
• Exploring isolated interactions as a proof-of-concept
• Validating UX design direction with stakeholders
• Validating the implementation of requirements with stakeholders
• Supplementing printed documentation for development teams
• Performing remote testing

Remote 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.

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, I’ll know that and can release the design with confidence instead of with gritted teeth.

High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t 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 I’ve heard termed a “slap and map” test from within a browser.

High Visual and High Functional Fidelity

High 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 isn’t worth it. But there are a few situations where it is:

• Evaluating the usability of proposed UX designs for an existing system
• Performing usability tests with non-savvy user groups
• Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s 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 Process

What I’ve 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 you’d 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.

As you near completion of the prototype, make sure you walk through the prototype with the project’s 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 you’re 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, it’s 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 Practice

This 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 company’s 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 organization’s 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. Here’s how prototyping can help:

• High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
• These 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/Agency

When 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 they’re 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 user’s 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.

Posted on 22 September 2009 | 3:50 pm

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 Back
Bill 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 Program
For 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 10
Interested 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. Team
Along 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 Environment
Flow 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.


Sponsors
Interaction 10 will also introduce some new sponsorship programs. Bill explains what this means and how that helps both sponsors and conference attendees.


Test & Iterate
The 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/.

Posted on 31 August 2009 | 11:05 pm

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 uses—and those are far harder to anticipate and encourage through design.

 —

About Thomas Malaby

Thomas 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 Design

IDEA2009 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.

Posted on 22 August 2009 | 10:29 am

I thought I could not be out-geeked. With a background in radio, and having dabbled in the demo scene on the Commodore 64 and hung out on BBSes and IRC for a long time and all the other things normal kids don't quite get, I thought I was safe in this area.

Then I went to my first WhereCamp, an unconference dealing with geographical issues and how they relate to the world of Web development. Even my A-Levels in Astronomy did not help me there. I was out-geeked by the people who drive and tweak the things that we now consider normal about geo-location on the Web.

Pulling out your phone, find your location and getting directions to the nearest bar is easy, but a lot of work has gone into making that possible. The good news is that because of that effort, mere geo-mortals like you and me can now create geographically aware products using a few lines of code. So, let's give the geo-community a big hand.

Posted on 8 March 2010 | 3:56 pm

The design profession is full of happy folks, and understanding why so many designers enjoy their work is not hard. But not all are so happy. If you’re not careful, the joy of getting paid to pursue your passion can be tainted by the less joyous realities of the professional world. You see, no matter how skilled you are as a designer, unless you are equally prepared in professional matters, your prospects will be limited and your circumstances compromised. This is true whether you work freelance, for an agency or in-house with a company.

Every week I hear from designers who are struggling to come to terms with these realities. Unhappy with their current circumstances, they write to ask for advice on improving their lot. Usually, they either claim not to understand how things got so bad, or they lay the blame somewhere other than at their own feet. In every case, however, the sole cause is their poor choices and lack of professional acumen. It needn’t be so.

Posted on 8 March 2010 | 1:48 am

Posted on 6 March 2010 | 2:47 am

Although much valuable information for all sorts of web and print professionals can be found online, it is often difficult to weed through all the noise and find good quality content. I believe it's vital that professionals in different creative fields supplement their online learning and research through well-edited and high-quality print publications.

Print magazines, more often than not, are well-researched and are headed by top-notch editorial staff, usually containing information and resources on the cutting edge of their respective industries' trends and happenings. To that end, to help you fulfill part of your offline research needs, I've compiled a list of print magazines that are of interest to professionals in three different categories: Web Designers, Digital Artists, and Photographers. And be sure to comment so you can tell us your personal favourite print magazine, if you don't see it listed here.

Posted on 5 March 2010 | 5:32 am

Adobe Illustrator is a powerful software for illustrating that allows users to produce beautiful artwork, technical illustrations, and even graphics for both print and the web. Adobe Illustrator is a multipurpose vector illustration tool and its versatility makes it the most preferred choice among many professional artists and designers.

In the past, we've published a collection of Beautiful Photoshop Illustrations By Artists Around The World, and this is the latest post that will showcase the power of Adobe Illustrator. We present here hundreds of brilliant illustrations by artists from around the world that will surely mesmerize you and stir your imagination. Have a look, and feel the power of Illustrator!

We recognize that there are many more highly-talented illustrators that may not be mentioned here. We can't cover them all, but with your help we can try to showcase them in future posts. Please feel free to comment on this article and mention the name of your favorite artist.

Posted on 4 March 2010 | 3:10 am

App Store is a competitive environment. Against more than 140,000 apps, all screaming for attention, how do you make sure your app gets its time in the spotlight? What does it take to get good media coverage? How do you get people to talk about your app—and, ideally, how do you get them to buy it and show it to their friends?

Following the simple rules laid out below, you will increase your chances in the battle for fame and glory. These tips might seem rudimentary or in-your-face obvious, but they are so often neglected in the heat of the moment.

Posted on 3 March 2010 | 3:59 am

Web design is a relatively young field. It's youthful, growing and made up of people from all kinds of backgrounds, many of whom lack formal design training. We have learned, and still are learning, as we go. I came into my first job as a Web designer for Boeing back in the mid-1990s, with no formal design training. I was lucky to get some training on the job, and I would guess that my experience there was similar to that of many who are reading this article.

I had the opportunity to work with some very talented and highly experienced designers who all had made the jump from other design fields to the Web. It was there, as part of that training, that I learned about critiquing, both giving and receiving, through regular design reviews.

Posted on 2 March 2010 | 5:56 am

There has been an increasing and sincere interest in typography on the web over the last few years. Most websites rely on text to convey their messages, so it's not a surprise that text is treated with utmost care. In this article, we'll look at some useful techniques and clever effects that use the power of style sheets and some features of the upcoming CSS Text Level 3 specification, which should give Web designers finer control over text.

Keep in mind that these new properties and techniques are either new or still in the works, and some of the most popular browsers do not yet support them. But we feel it's important that you, as an informed and curious Web designer, know what's around the corner and be able to experiment in your projects.

Posted on 1 March 2010 | 2:20 am

Desktop wallpapers can serve as an excellent source of inspiration. However, if you use some specific wallpaper for a long period of time, it becomes harder to draw inspiration out of it. That’s why we have decided to supply you with smashing wallpapers over 12 months. And to make them a little bit more distinctive from the usual crowd, we’ve decided to embed calendars for the upcoming month. So if you need to look up some date, isn’t it better to show off a nice wallpaper with a nice calendar instead of launching some default time application?

This post features 50 free desktop wallpapers, created by designers across the globe. Both versions with a calendar and without a calendar can be downloaded for free.

Please notice:

• all images can be clicked and lead to the preview of the wallpaper;
• you can feature your work in our magazine by taking part in our desktop wallpaper calendar series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?

So what wallpapers have we received for March 2010?

Posted on 28 February 2010 | 2:43 am

Over the years designers have pushed themselves to create unique and inspiring designs. Companies have yearned to have websites which are innovative and make them stand out against their competitors. Yet charity websites have not progressed along with trends and expectations — they seem to have been designed for launch and then only updated with minor tweaks to suit the content.

It has become a recent trend for charities to look at their online identities and branding; spending money on creating user experiences which suit their user base, and over time getting people involved with their campaigns and messages.

Below we look at charity websites which have successfully developed their online brand using modern and creative ideas. We will also discuss how each charity website can be improved because, as we all know, not every website is perfect. There are always improvements to the design or usability that may have been overlooked by management, designers, or developers.

Posted on 26 February 2010 | 11:16 am

We will be at the SXSW Interactive festival in Austin March 12 -16

We will be posting updates on our SXSW activities at: 

http://uxmag.com/sxsw2010

UX Magazine's Managing Editor, Jonathan Anderson, and Contributing Editor, Whitney Hess, will be on the ground looking for interesting UX stories and professionals.

We're looking for suggestions of who we should talk to, what companies we should meet with, and what stories we should cover. There's also an overwhelming number of exciting parties, so we're trying to decide which ones to check out. If you have any suggestions for us, or if you're at SXSW and see something interesting we should capture on tape or video, please send us an email:

sxsw@uxmag.com

For occasional updates from UX Magazine, make sure you're following our Twitter feed @uxmag.

For more frequent on-the-ground updates, follow Jonathan (@first_day) and Whitney (@whitneyhess) on Twitter.

Jonathan will also be trying out Foursquare while at SXSW: http://foursquare.com/user/first_day

Want to contribute?

We're going to be stretched pretty thin, so if you're going to be at SXSW and want to help us cover the event, please email us at the above address.

Posted on 8 March 2010 | 12:40 pm

While I was doing research for a virtual user interface I was creating in 3D, I spent some time looking at some of the virtual UIs that have come out of Hollywood. A lot of money and thought goes into their development, so I figured they would make good reference material for my project. While you can’t take the virtual UIs in movies at face value, they do contain some nuggets of information on what the future might hold.

Complexity

I’ve noticed that UIs in feature films are continually getting more elaborate and complex. Meanwhile, though, real-world interfaces are getting more simple and intuitive. It seems an odd contradiction that the futuristic UIs we dream up for movies follow one path, while real world ones are heading down another path.

But the reason for this is simple. Complexity conveys the impression that a system is very robust and advanced, and a character’s mastery of a complex system is more impressive than it would be if the system were simple and intuitive. No matter how complex the system gets, the hero can always operate it expertly, leaving the audience dazzled by the UI and the character’s skill. In the real world, though, users are more often like Mr. Magoo than like Tony Stark or (as in the clip below) an MI5 agent. So while high-aptitude, heavily trained users might be the fantasy world for UX professionals, it’s not the world we live in. The trend toward complexity in movie UIs doesn’t give us much of a preview of the world to come.

Gestural UIs

The most notable use of gestural UIs that I can think of was in Minority Report. It’s impressive to see Tom Cruise moving his arms around to call up and manipulate video. But the large and intricate motions he makes wouldn’t work in actual practice. Our arms get tired, and it is hard to make such intricate motions with precision without any form of tactile feedback. Another issue with this method is that all of the commands Tom Cruise employs are completely memorized. Systems that don’t show commands rely completely on memorization and training. This is faster for an expert but takes a long time to master. Recalling commands, especially when stressed, can be very challenging.

Gestural UIs will be a part of our future. They are already present in several devices such as the iPhone and some video game systems, and they’re in development for televisions. In order to be successful these UIs will have to be supplemented with menus or be extremely intuitive. If they are to be a major part of the overall interface they will need to be driven by lazy or small motions that won’t tire out a user. The exception here would be something like the Wii where the gestures are more engaging and getting tired is part of the game.

The XBox Project Natal is a new gaming system that will be gesture driven. Unlike the Wii (which uses a remote with an accelerometer to capture movements), Natal will use a camera to detect motion. This may not go over well with users as it doesn’t provide any sort of feedback. Holding a prop steering wheel as you would with the Wii feels more engaging than an imaginary one as you would with Natal.

Eye Tracking UIs

This concept can be seen in the movie Iron Man. Tony Stark accesses various widgets just by looking at them. This concept is universal (cross-cultural)—just look at something to activate it. My concern is how the system knows the difference between someone glancing over an item and intentionally focusing on it. The idea of “hover intent” isn’t as applicable since the human eye doesn’t scan across a UI and come to rest on a particular spot like a mouse. Our eyes dart from spot to spot with temporary pauses as they pass over a screen. This could be worked out by having timer trigger based on the eye movements. Another issue would be temporary distractions that cause us to look away from the UI would potentially close applications we were working on. Interactive billboards will be a very likely candidate for this technology; in fact, a few of them already exist.

Voice Activated UIs

Probably the most famous incarnation of this is Star Trek. The ship’s crew can issue almost any command verbally and the ship complies. This technology is already present in most cell phones, some cars, and computer programs. If you own any of these systems you may already know some of the current technological pitfalls. The systems struggle when you speak fast or issue long commands. They also rely heavily on you speaking with the proper inflection (which is hard to do when you are panicked, distracted, or sick) and they user must have commands memorized. I often only use a couple commands in my car because they are the only ones I can recall while flying down an interstate full of cars. The only other alternative is asking for a list of commands that is lengthy and distracting.

Hacking Hollywood: The Star Trek Enterprise

On the other hand, these systems are extremely useful when you can’t use your hands or have a handicap that prevents you from interacting with the system normally. The key here in the future will be an easy method of retrieving commands and keeping voice commands short and simple.

Stereoscopy / Holographic UIs

Most recently, you can see these in the movie Avatar and District 9. In Avatar, human brains are projected in 3D allowing the doctor to look around at all parts for any abnormalities. In District 9, the alien ships are piloted with holographic UIs, something that is especially useful in navigation. These are a great idea as they help separate content from UI, and separates what is important at the moment and what isn’t. This can be faked in 2.5D systems as is done now, but with full dimensionality the effect is enhanced as well as allowing the user to create better groupings and spatial mappings. One trick to this system will be locating the right uses of this technology. Novelty will not be a good reason to make a UI 3D. Dealing with geography, multiple dimensions, and multiple axes will be good reasons.

While the keyboard and mouse work just fine as 2D inputs, these UIs will benefit greatly from other forms of 3D input such as multiple cameras comparing imagery to locate users in 3D space, manipulating a device in 3D that contains an accelerometer, or perhaps other current methods of 3D motion capture used in films and games today. In any of these methodologies, feedback will be important. Users will need to feel some sort of resistance to know they have pushed a holographic button. A simple visual indication won’t be satisfying enough. Perhaps a glove that provides feedback will be the solution.

Transparent UIs

Many of the movies that have come out lately feature transparent UIs. They are very visually stimulating and work for something like a HUD in a jet fighter since you need the UI laid on top of the elements behind it. However, it doesn’t work for a typical screen. It provides too many distractions when you add the elements on the screen with the complex visual scene and motions occurring behind it.

Large Fonts

Jakob Nielsen included the use of large fonts in his list of top 10 movie UI bloopers. I don’t agree with him on this one. His reasoning that fonts are unnecessarily large so that people in the audience can read them is sound. However, our culture of computer users is going from a “leaning forward” posture to a “laid-back” one. As we buy larger monitors and find more UIs on our television screens combined with wireless input devices, we’ll need those larger fonts to read the screens from farther away. Instead of sitting at a desk to interact with a computer, we are doing it more and more from our couches.

Adaptive UIs

The only really good adaptive UI I can think of is the Omega widget in Tony Stark’s final Iron Man suit. In the movie, the Omega widget is a single widget that contains all of the information from the previous widgets. However this one only shows information and options that are currently pertinent.

The easiest UIs are ones where each command has a unique button, but the number of buttons shown is limited to only the current options. This methodology allows for a tremendous amount of information and commands to be available, but without cluttering the user’s screen. Adobe is utilizing this currently in Catalyst and I’ve seen it in sneak previews of Adobe Rome.

Posted on 8 March 2010 | 10:41 am

Am I going to ditch my iPhone for a Puma phone? No. I am, however, really impressed by how Puma has chosen to enter a space that’s already way over-saturated. In an industry full of me-too-ing, they clearly recognized that the only chance they have to make any mark is to come to market with something genuinely different and from the looks of these demos and screenshots, they’ve done just that. This is evident from the memorable (and very well-branded) UI, the playfulness that permeates the OS and even some of the hardware additions:

That might be thanks to some of the silly stuff like a calculator that teases you when you try an operation it deems too trivial, a pet puma on the device called Dylan (who shows up on-screen when you leave your handset untouched for a while), and an audio player with a turntable you can actually scratch—but the real draw is probably the solar panel around back.

In a lot of ways, Puma is showing up manufacturers that have been making phones for years by demonstrating how even the little guy can make a splash if he’s willing to take a chance.

Read more about it over at engadget.

Posted on 5 March 2010 | 9:42 am

Facebook has updated its Communication Channels Best Practices. A must-read for any developers who want their apps to be "streamlined, clear, and less spammy."

http://wiki.developers.facebook.com/index.php/Communication_Channels_Best_Practices

Posted on 4 March 2010 | 10:42 am

Most user experience designers will have heard of the Product Reaction Cards (doc), a set of 118 words and phrases developed for Microsoft by Joey Benedek and Trish Miner in 2002 that can be deployed in a user testing workshop to help people articulate their emotional responses to a product.

The Product Reaction Cards are part of the Desirability Toolkit (doc) that suggests facilitators ask users to choose the cards that "best describe the product or how using the product made them feel" and then ask them to narrow their selection to just five cards. The cards selection process is then followed by an interview where the participant explains why they selected those five cards.

Whilst the 118 card deck seems to work for the creators of the PRC, some people think it's too much—I posted a question on UX Exchange a few months ago about and received responses like "unnecessarily fiddly" whilst another said they use a subset of the cards. Donna Spencer, author of Card Sorting, commented:

…at the end of the test the last thing a participant wants to do is go through this big pile of cards. It takes quite a lot of time, but I don't think the gain is worth the pain.

Whilst I support the goals of the cards to prompt people and provide a full vocabulary than might otherwise come to mind during workshop sessions I've been wondering if there might be a different approach.

For example, in the book People Skills, Robert Bolton talks about using adverbs to describe the level of intensity as well as grouping feeling words into "families":

By preceding feeling-word adjectives with appropriate adverbs, you can communicate with some accuracy the degree or intensity of feeling.

You could select adverbs appropriate to the adjective, as in the example Bolton uses:

• You feel a little sad because your dog died
• You feel quite sad over your dog's death
• You feel very sad that your dog died
• You feel deeply sad since your dog died

Or you could opt for a normalised Likert scale approach that could be applied to any adjective; although that would require participants to explicitly state their opinion of every feeling word, phrased as questions like, "This product makes me feel stressed: Strongly Disagree, Disagree, Neither Agree or Disagree, Agree or Strongly Agree."

It's intensive but it is a more analytical and thorough approach.

The "families" that Bolton refers to is a matrix of categories of feeling words grouped by levels of intensity for example in the category of emotional feeling words for "sadness":

Strong:

• Desolate
• Anguished
• Despondent
• Depressed

Mild:

• Glum
• Blue
• Sad
• Out of sorts

Weak:

• Below par
• Displeased
• Dissatisfied
• Low

This grouping of feeling words by level of intensity, the use of adverbs or a Likert scale, coupled with the Production Reaction Cards authors' recommendation to maintain a 60/40 ratio of positive to negative words should provide you with a better framework should you wish to alter or reduce the list of 118 words and phrases whilst ensuring you still cover the full range of emotional responses.

Think of it like a paint palette where the type of emotion is the hue and the intensity is the brightness. You might not need your 16.7 million colours but if you're going to cull your palette at least take a sensible and logical approach to it.

This is especially important if you want to follow a quantitative approach to reporting on research conducted using the PRC as mentioned in the book Measuring the User Experience by Thomas Tullis and Bill Albert.

What are your experiences with using the Product Reaction Cards—specifically if you culled the list of words and phrases or came up with your own? What technique did you use for developing your custom set of cards and how do you think your choices affected the quality and thoroughness of the emotional response inquiry?

Posted on 4 March 2010 | 10:17 am

Last year, I had the honor and pleasure of working on a project for the National Institute of Standards and Technology (NIST) to develop style guidelines for voting system documentation. Yawner, right? Not at all, it turns out. It made me think about where guidelines and heuristics come from for all kinds of design. Yes, if you live in the United States, you paid for me to find this out. Thank you.

What I learned in the process of developing style guidelines for voting system documentation (which, astonishingly, took about a year) is that most heuristics—accepted principles—used in evaluating user interfaces come from three sources: lore or folk wisdom, specialist experience, and research.

Though style guidelines for content are important, I’m going to talk about each of these sources of heuristics with various design examples. I’m sure you’ll see something that you’ve encountered before.

Lore or Folk Wisdom

First comes guidance from “They,” as in “They say…,” for which no one knows the true source. For example: “Feed a cold, starve a fever.” “Never end a sentence with a preposition.” “Limit the number of items in the main navigation to seven plus or minus two.”

Where do these come from? Someone’s belief that this is a good practice. They may have heard something or done something that they think supports the practice, but there’s really no basis in fact for any of these.

A New York Times article by Anahad O’Connor says that recent research about whether to eat a lot when you have a cold and fast when you have a fever is inconclusive. No one seems to know how this one started. It may just feel like there’s some inherent logic to it.

Not ending sentences with prepositions was encoded by a British guy named Henry Fowler in 1926. He was a crotchety, proscriptionist pedant, but his book was a best seller. People wanted guidance about how to speak and write “properly,” especially in class-conscious England. So a rule to not use words like “to,” “in,” “for,” “with,” or “on” as the last word in a sentence became wildly popular as a marker of a well-bred, well-educated person. But it was really just Fowler’s personal preference, and today the practice seems like an affectation.

My favorite example in the Web design world is a guideline about limiting the number of items in a navigation menu or list to five to seven items. Most people don’t know where this came from; if they did, they’d know that this isn’t the best use of that “rule” and imposing it actually won’t make the design usable. This one does originate in research, specifically an article published in 1956 by George Miller in the Psychological Review called “The magical number seven, plus or minus two: Some limits on our capacity for processing information.” The findings from the research Miller describes are about working memory. The lore passed down from that article is that humans can only hold about seven things in their short-term memory at a time. But Miller very heavily qualifies this as “suggestive” and an “estimate.” More importantly, what in the world does this have to do with designing website navigation? Nothing. Navigation is persistent. We’re not asking people to remember from section to section where they can go. It’s right there for them to see and use. The number of items in navigation should be determined by the data from research about the users and their task goals.

If you find yourself saying “they say” or “I’ve heard” when you make an observation about a design issue, you may be caught without a lot of support for your point. Basing an inspection on your own experiences observing users can hold more authority.

Specialist Experience

Older adults who use the Web need high contrast and large targets. If they are not expert Web users, they can be easily distracted, so to ensure that they’re successful, we should design in smooth task paths and clear labeling that doesn’t use jargon.

One of my special interests since about 2003 has been Web design for older adults. I’ve internalized the design principles above (as well as many others) after watching dozens of people who are age 55 or older use a variety of Web sites. I am confident that implementing a design that takes these design principles into account will make the design easier for older people to use than designs that use subtle colors layered on one another, small buttons and links, and cluttered page layout with trendoid headings and labels. Though I have observed many types of people using lots of different kinds of websites, I have specialist experience from watching one audience try to do typical tasks on a variety of websites.

Specialist experience means expertise in a particular domain or product. You get it only after hours and hours and hours of seeing the same kinds of things happen to the same types of users. Basing an inspection on specialist experience is definitely a step up from working from lore, but if you haven’t distilled what you have found in the many hours of observing a type of users using a site or type of site, then you may be working from hunches and opinion that could make it difficult for you to justify the evaluation recommendations.

Evidence From Research

Some things that experienced designers have internalized do have data to support them: eliminate horizontal scrolling, design for working memory limitations, facilitate scanning.

These all rate a 5 (out of 5) for strength of evidence in the guidelines on usability.gov (I’ll get to the rating thing in a minute). Usability.gov started as a project at the National Cancer Institute (NCI), which is part of the US Department of Health and Human Services. NCI needed guidance in designing usable cancer information websites—a simple goal.

On the way, the NCI team realized that not all guidelines were equal. Some guidelines were supported by a lot of data from multiple studies (like the high-scoring heuristics above). Some guidelines might come from only one study. Still, evidence was evidence, and NCI wanted to use “quantified, peer-reviewed Web site design guidelines,” which they found simply didn’t exist. And as far as I know, there’s nothing like the resource NCI created at usability.gov.

To reach their goal, NCI put together panels of experts to review research. The panelists then rated each guideline for strength of evidence that, among other considerations, needed to be “cumulative and compelling” for a 5 out of 5. The idea was that teams could use the ratings to help them make design decisions. But the guidelines were not meant to be a substitute for usability testing. Why not? The main reason was that the guidelines at usability.gov were developed for information-rich websites (versus e-commerce or transaction-based sites) with content about major illnesses. That’s fairly specialized. But when you read through the 500 guidelines that NCI identified, it is obvious that almost all could apply to many types of websites or many types of pages within sites. Your mileage may vary.

The Basis of the Heuristic Matter

As the folks at NCI learned in developing usability.gov and I learned in the work for NIST[*], the provenance of a heuristic is important. This is true of all implicit and explicit heuristics applied in design decisions.

Learning about where heuristics come from—lore or folk wisdom, specialist experience, or research—helped me understand better where some of the teams I’ve worked with were coming from as they developed design principles. Sometimes they based the principles on lore, sometimes on expertise. Rarely did they go to the research.

Expertise is good, but research is better. Research-based heuristics simply have more heft: credibility, specificity, and applicability.

Still, there’s no substitute for primary research. Firsthand observation of your users in their context reveals subtleties of behavior that even research-based heuristics can’t match. And if your research of your users in their context contradicts the known research, what do you do? (You don’t get two guesses to answer this question.) If you go with what your users do, then even the most deeply researched heuristics are at best a poor substitute for doing the right thing.

[*] I couldn't have made the discoveries I did on that project without Susan Becker, my project partner, who did most of the heavy lifting.

Related Links

You can pore through the evidence-based guidelines for usability developed by the National Cancer Institute (NCI) at usability.gov.

You might also want to check out other sets of research-based heuristics and guidelines. I've worked on a couple of them:

AARP commissioned Janice ("Ginny") Redish and me to do an expert review of websites in 2005 in order to develop a set of heuristics for designing websites for older adults (Google doc).

The final report from our review of 50 websites is here (also a Google doc).

The National Institute on Aging (NIA) also published guidelines for designing senior-friendly websites.

The voting section of the National Institute of Standards and Technology (NIST) website now links to style guidelines for voting system documentation, which are based on research in technical communication, information design, usability, and instructional design. Check out the site’s Publications section to download the PDF of the guidelines and to view other design research related to voting systems.

Oh, and you might want to read Miller's article to judge for yourself.

Posted on 3 March 2010 | 10:41 am

From Popular Science:

The future of touchscreen interfaces is: you? A project between a Carnegie Mellon researcher and a couple of creative thinkers over at Microsoft Research have created Skinput, a Bluetooth-enabled device that allows you to use your own skin as a peripheral input device for devices like cell phones, MP3 players or gaming consoles.

This is one of those things that's better shown than explained:

It's clearly a long way off from commercialization. But as they've demonstrated, this has a lot of potential for keeping devices in pockets and out of hands, allowing people to stay focused on their activity rather than on operating their devices. This also seems like one component of a potential future system that converts sign language communication to synthesized speech.

Posted on 3 March 2010 | 8:55 am

More than a year ago I very proudly announced that Boxee, the much-loved social media center software company, had hired me as the user experience designer for their beta. In the five months that I worked with them, I conducted user interviews and usability testing to identify people's needs, behaviors and frustrations, and redesigned the app's navigation and key screens.

Earlier this month the Boxee beta was released, and the consensus so far is that the overall experience is a huge improvement over the alpha. While I have not been formally engaged with Boxee since May (such is the life of an independent consultant), I am incredibly pleased to see that many of my ideas were implemented and made all the better by Boxee's small but outstanding team of visual designers and developers.

The Process

I conducted interviews with six prospective users (people who at the time had never used Boxee) and five existing users. I also performed usability testing with five existing users (three on their laptop and two on their home TV).

For the user research, I asked a boatload of questions about people's media consumption habits and attitudes. Of the 11 people I interviewed, two people subscribed to basic cable without DVR, five people subscribed to digital cable with DVR, and four people did not subscribe to cable at all.

Everyone I interviewed watches TV and movies using their computers, at least in part; approximately half had substantial personally-stored media collections and almost all used streaming media online. All interviewees also consumed digital music and photographs to some degree.

These individuals all considered themselves tech savvy, but represented both ends of the spectrum: from tinkerers to zealots. While some were programmers, others worked in technology only tangentially as business analysts, writers, designers, and sales representatives. They also had varying use of social networking websites, Web applications, blogs, and other websites.

The questions I asked during my interviews are below.

User Interview Questions

• Tell me a bit about yourself. Where do you live? Where are you from? What do you do?
• What kind of computer do you have?
• What kind of TV do you have? What stuff do you have hooked up to your TV?
• Tell me about your TV watching habits. Cable? Satellite? How often? Where?
• Who do you usually watch TV with? How do you decide what to watch?
• What kinds of shows do you watch? Are there shows that you watch regularly? How do you remember to watch them?
• What are your movie watching habits?
• Do you watch movies on your computer? How? Where? When?
• Do you watch videos, movies or TV shows online? How? How often? Where?
• Do you subscribe to Netflix or similar? How do you use it?
• Do you use Hulu, YouTube or other online video sites?
• What is your personal movie collection like?
• Are you using any media centers now? Which ones? Experience with them?
• What is your personal music collection like?
• What are your music listening habits? How and where do you listen?
• Where do you find music?
• Do you listen to music on the Internet? Where?
• Have you ever played music at a party you were hosting? How? Where?
• Have you ever played music through your TV? What do you use? How do you navigate? Keyboard/remote
• What is your personal photo collection like?
• Where are your photos stored?
• What photo applications do you use?
• What photo sites do you use?
• Have you ever displayed your photos on your TV? How? What do you use? How do you navigate? Keyboard/remote
• What websites or blogs do you frequent?
• Do you comment on blogs? Review sites?
• Do you use Facebook? How?
• Other social networking sites? Twitter?
• Other Web apps?

Usability Testing

Not only did we want to get to know prospective target users of the Boxee application, but it was also important that we receive input on how existing users are currently using the system. To measure the ease of use of several areas of the Boxee experience, I conducted usability tests with five existing users: three of whom most regularly use Boxee on their TVs, and two who primarily use Boxee on their laptops.

The usability tests started with each user simply walking me through their typical usage scenarios, from launching Boxee, to finding a movie or TV show to watch, to scanning through their music. Then after approximately 30 minutes of this natural navigation and discussion, I asked each participant to perform a series of tasks. This helped to identify breakdowns in user flow, usability flaws and bugs, or generally any problematic areas in the experience.

The tasks were as follows:

1. Start watching one of your favorite TV shows.
2. You just realized that you've already seen this episode. Switch to the next episode.
3. You're done watching this show for now. Switch to another favorite TV show.
4. Our friend is in an episode of Army Wives. Find it.
5. Now you're in the mood for some music. Play one of your favorite songs.
6. Check out the latest episode of This American Life on NPR.

These usability tests resulted in a wide array of findings, and several themes emerged across participants. I have collected the most pervasive and significant areas of difficulty and have provided my recommendations on how to resolve the problem. The issues are organized by content area.

Personas and Scenarios

To aid in the design and development of the beta, I developed three personas derived from insights I learned in my research to depict Boxee's target users; I called them a Practical Dad, a Techie Bachelor, and a Principled Fan. The personas do not reflect a single person, but rather are an amalgamation of various interviews. There is a lot of intellectual property captured in the personas so I will refrain from sharing them here.

I also developed a set of high-level scenarios to describe how each of the personas would interact with an ideal Boxee application. The scenarios helped us envision the right workflow, step-by-step, and allowed us to identify the key features necessary to meet users' needs. A selection of the scenarios we aimed to support are:

• I want to see if a movie is available online
• I want to subscribe to a current season of a TV show
• I want to pick up where I left off in a movie or TV show

Features

From the scenarios I was able to draw out an extensive list of features across multiple areas of the app that would need to be implemented in order to meet our target users' needs. Overall, we wanted to provide users with greater ability to discover content across sources, easier ways to sort and filter lists, and quick access to their favorite programming.

It was a long, long list, and not everything that ideally belongs in the app was realistic for our release schedule so we were forced to triage. We started first by prioritizing scenarios, and then marked each feature as Must Have, Should Have, Nice to Have, and Won't Have. This helped focus the team on what we needed to tackle immediately.

Flows and Wireframes

Now with the full set of features we were intending to implement, I set out to weave them together in an easy to use way that would make for a pleasurable experience. I drew flow diagrams to indicate how a user would navigate from screen to screen, and then created a series of wireframes of the key screens to recommend layout, prominence of features and content, necessary functionality and data display.

The Outcome

Take a look at some of the key screens of the app below, and see how my wireframes laid the groundwork for the beta's redesign.

Home Screen

Navigation

TV Shows

In the Press

Ars Technica 1/13/2010 "The program's user interface has undergone a significant transformation that simplifies navigation and makes Internet content easier to access."

TechCrunch 1/07/2010 "The new version is really a complete overhaul of the app — it's received a new, sexier UI that makes it easier to browse through the service's content (and anything you might have saved locally too)."

Mashable 1/07/2010 "The UI overhaul is significantly better…"

Wired 12/31/2009 "Yes, there are many methods for putting web video on your TV, but Boxee is the most elegant solution I've seen. For the beta release, the whole user experience has undergone a slick redesign."

CNET News 12/09/2009 "…new beta has a completely redone interface that is far superior to the alpha's."

Lifehacker 12/07/2009 "From the outset, it looks a whole lot more pretty and user friendly."

Gizmodo 12/07/2009 "What looked impressive during the demo was how cleanly it aggregated both local and online sources of video content."

Engadget 12/07/2009 "We're particularly fond of the new global menu for quick shuffling through the menu and to shortcuts."

What Do You Think?

If you're a Boxee user, I would love to hear your thoughts on the beta. Praise, criticisms, and questions are all welcome.

Posted on 2 March 2010 | 10:47 am

In his seminal pop-book, Mihaly Csikszentmihalyi argued that people are happiest when they can reach a state of "flow." He talks about performers and athletes who are in the height of their profession, the experience they feel as time passes by and everything just clicks. People reach a state where attention appears focused and, simultaneously, not in need of focus at the same time. The world is aligned and everything just feels right.

Consider what it means to be "in flow" in an information landscape defined by networked media, and you will see where Web 2.0 is taking us. The goal is not to be a passive consumer of information or to simply tune in when the time is right, but rather to live in a world where information is everywhere. To be peripherally aware of information as it flows by, grabbing it at the right moment when it is most relevant, valuable, entertaining, or insightful. Living with, in, and around information. Most of that information is social information, but some of it is entertainment information or news information or productive information. Being in flow with information is different than Csikszentmihalyi's sense, as it's not about perfect attention, but it is about a sense of alignment, of being aligned with information.

As of late, we've been talking a lot about content streams, streams of information. This metaphor is powerful. The idea is that you're living inside the stream: adding to it, consuming it, redirecting it. The stream metaphor is about reaching flow. It's also about restructuring the ways in which information flows in modern society.

Those who are most enamored with services like Twitter talk passionately about feeling as though they are living and breathing with the world around them, peripherally aware and in-tune, adding content to the stream and grabbing it when appropriate. This state is delicate, plagued by information overload and weighed down by frustrating tools.

For the longest time, we have focused on sites of information as a destination, of accessing information as a process, of producing information as a task. What happens when all of this changes? While things are certainly clunky at best, this is the promise land of the technologies we're creating. This is all happening because of how our information society is changing. But before we talk more about flow, we need to step back and talks about shifts in the media landscape.

From Broadcast to Networked

For the last few centuries, we have been living in an era of broadcast media, but we have been switching to an era of networked media. This fundamentally alters the structure by which information flows.

Those who believe in broadcast structures recognize the efficiency of a single, centralized source. There's some nostalgia here. The image is clear: 1950s nightly news, everyone tuning in to receive the same message at the same time. There are the newspapers, the radio stations, the magazines—all telling the same news-y story. Centralized sources of information are powerful because they control the means of distribution. There is also the town gossip, the church, and the pub. These too were centralized channels for disseminating information.

Broadcast media structures take one critical thing for granted: attention. There is an assumption that everyone will tune in and give their attention to the broadcast entity, even though that was never true in the first place. As TV channels and publishing brands proliferated, we've seen that attention can easily be fragmented. Over the last few decades, increasing numbers of entities have been fighting for a smaller and smaller portion of the pie. Even gossip rags started competing for attention.

The opportunities for media creation have been rising for decades, but the Internet provided new mechanisms through which people could make their own content available. From blogging to social network sites to media sharing sites to sites that provide social streams, we are seeing countless ways in which a motivated individual can make their personal content available. There were always folks willing to share their story but the Internet gave them a pulpit on which to stand.

Internet technologies are fundamentally dismantling and reworking the structures of distribution. Distribution is a process by which content creators find channels through which they can disseminate their creation. In effect, they're pushing out the content. Sure, people have to be there to receive it, but the idea is that there are limited channels for distribution and thus getting access to this limited resource is hard. That is no longer the case.

As networked technologies proliferate around the world, we can assume that there is a channel of distribution available to everyone and between everyone. In theory, anyone could get content to anyone else. With the barriers to distribution collapsing, what matters is not the act of distribution, but the act of consumption. Thus, the power is no longer in the hands of those who control the channels of distribution, but those who control the limited resource of attention. This is precisely why YOU were Time magazine’s the Person of the Year in 2006. Your attention is precious and valuable. It's no longer about push; it's about pull. And the “Law of Two Feet” is now culturally pervasive.

While we're dismantling traditional structures of distribution, we're also building out new forms of information dissemination. Content is no longer being hocked, but links are. People throughout the network are using the attention they receive to traffic in pointers to other content, serving as content mediators. Numerous people have become experts as information networkers.

To many people, this seems like old news. Isn't that the whole point of Web 2.0? Isn't that what we've been living? Sure, of course. But now that we're seeing Web 2.0 go mainstream, we're seeing all sorts of folks get into the game. What they're doing often looks different than what early adopters were doing. And the business folks are all trying to turn the Internet into a new broadcast channel (don't worry, they're failing). But we need to talk about these shifts so we can talk about what innovation needs to happen.

If folks are going to try to get in-flow with information, we need to understand how information flows differently today. Let me highlight four challenges, points where technological hope and reality collide.

Four Core Issues

1) Democratization. Switching from a model of distribution to a model of attention is disruptive, but it is not inherently democratizing. This is a mistake we often make when talking about this shift. We may be democratizing certain types of access, but we're not democratizing attention. Just because we're moving towards a state where anyone has the ability to get information into the stream does not mean that attention will be divided equally. Opening up access to the structures of distribution is not democratizing when distribution is no longer the organizing function.

Some people might immediately think, "Ah, but it's a meritocracy. People will give their attention to what is best!" This too is mistaken logic. What people give their attention to depends on a whole set of factors that have nothing to do with what's best. At the most basic level, consider the role of language. People will pay attention to content that is in their language, even if they can get access to content in any language. This means Chinese language content will soon get more attention than English content, let alone Dutch or Hebrew content.

2) Stimulation. People consume content that stimulates their mind and senses. That which angers, excites, energizes, entertains, or otherwise creates an emotional response. This is not always the "best" or most informative content, but that which triggers a reaction.

This isn't inherently a good thing. Consider the food equivalent. Our bodies are programmed to consume fat and sugars because they're rare in nature. Thus, when they come around, we should grab them. In the same way, we're biologically programmed to be attentive to things that stimulate: content that is gross, violent, or sexual and that gossip which is humiliating, embarrassing, or offensive. If we're not careful, we're going to develop the psychological equivalent of obesity. We'll find ourselves consuming content that is least beneficial for ourselves or society as a whole.

We are addicted to gossip for a reason. We want to know what's happening because such information brings us closer to people. When we know something about someone, there's a sense of connection. But the information ecology we live in today has twisted this whole thing upside down. Just because I can follow the details of Angelina Jolie's life doesn't mean she knows I exist. This is what scholars talk about as parasocial relations. With Facebook, you can turn your closest friends into celebrities, characters you gawk at and obsess over without actually gaining the benefits of social intimacy and bonding.

Stimulation creates cognitive connections. But it is possible for there to be too much stimulation. We don't want a disconnected, numb society, nor a society of unequal social connections. So driving towards greater and more intense stimulation may not be what we want.

Of course, there's money here and people will try to manipulate this dynamic for their own purposes. There are folks who put out highly stimulating content or spread gossip to get attention. And often they succeed, creating a pretty unhealthy cycle. So we have to start asking ourselves what balance looks like and how we can move towards an environment where there are incentives for consuming healthy content that benefit individuals and society as a whole. Or, at the very least, how not to feed the trolls.

3) Homophily. In a networked world, people connect to people like themselves. What flows across the network flows through edges of similarity. The ability to connect to others like us allows us to flow information across space and time in impressively new ways, but there's also a downside.

Prejudice, intolerance, bigotry, and power are all baked into our networks. In a world of networked media, it's easy to not get access to views from people who think from a different perspective. Information can and does flow in ways that create and reinforce social divides. Democratic philosophy depends on shared informational structures, but the combination of self-segmentation and networked information flow means that we lose the common rhetorical ground through which we can converse.

Throughout my studies of social media, I have been astonished by the people who think that XYZ site is for people like them. I interviewed gay men who thought Friendster was a gay dating site because all they saw were other gay men. I interviewed teens who believed that everyone on MySpace was Christian because all of the profiles they saw contained biblical quotes. We all live in our own worlds with people who share our values and, with networked media, it's often hard to see beyond that.

Ironically, the one place where I'm finding people are being forced to think outside their box is the Trending Topics on Twitter. Consider a topic that trended a while ago: #thingsdarkiessay. Started in South Africa, this topic is fundamentally about language and cultural diversity but, when read in a U.S.-context, it reads as fundamentally racist. Boy did this blow up, forcing a lot of folks to think about language and cultural differences. Why? Because Trending Topics brings a topic that gained traction in a segment of the network to broader awareness, often out of context. Unfortunately, it's hard to get meaningful dialogue going once a Trending Topic triggers reactions.

In an era of networked media, we need to recognize that networks are homophilous and operate accordingly. Technology does not inherently disintegrate social divisions. In fact, more often then not, in reinforces them. Only a small percentage of people are inclined to seek out opinions and ideas from cultures other than their own. These people are and should be highly valued in society, but just because people can be what Ethan Zuckerman calls “xenophiles” doesn’t mean they will be.

4) Power. When we think about centralized sources of information distribution, it's easy to understand that power is at stake. But networked structures of consumption are also configured by power and we cannot forget that or assume that access alone is power. Power is about being able to command attention, influence others' attention, and otherwise traffic in information. We give power to people when we give them our attention and people gain power when they bridge between different worlds and determine what information can and will flow across the network.

In a networked culture, there is also power in being the person spreading the content. When my colleagues and I were examining retweets in Twitter, we saw something fascinating: a tension between citationality and attribution. In short, should you give credit to the author of the content or acknowledge the person through whom you learned of the information? Instinctually, many might believe that the author is the most important person to credit. But, few ideas are truly the product of just one individual. So why not credit the messenger who is helping the content flow? We found that reasonable people disagreed about what was best.

In a broadcast model, those who control the distribution channels often profit more than the creators. Think: Clear Channel, record labels, TV producers, etc. Unfortunately, there's an assumption that if we get rid of limitations to the means of distribution, the power will revert to the creators. This is not what's happening. Distribution today is making people aware that they can come and get something, but those who get access to people's attention are still a small, privileged few.

Instead, what we're seeing a new type of information broker emerge. These folks get credit for their structural position. While the monetary benefits are indirect, countless consulting gigs have arisen for folks based on their power as information brokers. The old controllers of information are losing their stature (and are not happy about it). What's emerging is not inherently the power of the creators, but the power of the modern-day information brokers.

Making It Work

As our information ecosystem evolves, we will see some radical changes take place. First, I believe that information spaces will get more niche. We will see evidence of this in the ways people direct their attention, and also in what new enterprises are succeeding. Successful businesses will not be everything to everyone; that's the broadcast mentality. Instead, they will play a meaningful role to a cohort of committed consumers who give their attention to them because of their relevance.

To be relevant today requires understanding context, popularity, and reputation. In the broadcast era, we assumed the disseminator organized information because they were a destination. In a networked era, there will be no destination, but rather a network of content and people. We cannot assume that content will be organized around topics or that people will want to consume content organized as such. We're already seeing this in streams-based media consumption. When consuming information through social media tools, people consume social gossip alongside productive content, news alongside status updates. Right now, it's one big mess. But the key is not going to be to create distinct destinations organized around topics, but to find ways in which content can be surfaced in context, regardless of where it resides.

Making content work in a networked era is going to be about living in the streams, consuming and producing alongside "customers." Consuming to understand, producing to be relevant. Content creators are not going to get to dictate the cultural norms just because they can make their content available; they are still accountable to those who are trafficking content.

We need technological innovations. For example, tools that allow people to more easily contextualize relevant content regardless of where they are and what they are doing and tools that allow people to slice and dice content so as to not reach information overload. This is not simply about aggregating or curating content to create personalized destination sites. Frankly, I don't think this will work. Instead, the tools that consumers need are those that allow them to get into flow, that allow them to live inside information structures wherever they are, whatever they're doing. The tools that allow them to easily grab what they need and stay peripherally aware without feeling overwhelmed.

Finally, we need to rethink our business plans. I doubt this cultural shift will be paid for by better advertising models. Advertising is based on capturing attention, typically by interrupting the broadcast message or by being inserted into the content itself. Trying to reach information flow is not about being interrupted. Advertising does work when it's part of the flow itself. Ads are great when they provide a desirable answer to a search query or when they appear at the moment of purchase. But when the information being shared is social in nature, advertising is fundamentally a disruption.

Figuring out how to monetize sociality is a problem, and not one that’s new to the Internet. Think about how we monetize sociality in physical spaces. Typically, it involves second-order consumption of calories. Venues provide a space for social interaction to occur and we are expected to consume to pay rent. Restaurants, bars, cafes… they all survive on this model. But we have yet to find the digital equivalent of alcohol.

As we continue to move from a broadcast model of information to a networked one, we will continue to see reworking of the information landscape. Some of what is unfolding is exciting, some is terrifying. The key is not be all utopian or dystopian about it, but to recognize what changes and what stays the same. The future of Web 2.0 is about information flow and if you want to help people, help them reach that state.

This article is based on a talk I gave at O’Reilly’s Web 2.0 Expo last November. This could not have been written if it weren't for an inspiring conversation with Dan Gillmor.

Posted on 25 February 2010 | 11:34 am

Most interfaces are designed for use on a desktop, or more precisely, from behind a desk. They assume you're in a comfortable position, seated on a chair with screen and keyboard directly in front of you. Most times this assumption is appropriate because that's what 90% of all system setups look like. It's the standard home or office setup. But what if the setup is not standard?

Imagine a screen mounted to a wall in a hallway, displaying some general info like temperature, humidity, date and the likes. There's no keyboard and, more importantly, no seat to get you comfortably positioned at the right distance from the screen. That wouldn't help anyway, since the screen's mounted at eye-height. You'd be looking up.

This kind of thing is common. Walk into any kind of factory and you'll find lots of screens doing one thing only: displaying data for the technician (the user) to monitor. These technicians don't have time to sit comfortably behind a desk and use a mouse for pixel-precise clicking to find the data they need. When they use the UI, they do it fast—really fast—because they have to get on with their job. For this combination of user and type of data, there is one perfect type of user interface: the dashboard.

Dashboard UI's are designed to provide rapid contextual information regarding some higher task or goal, to which the majority of the user's attention is directed. This stands in high contrast with regular desktop applications, where the UI is (usually) designed to fulfill a specific task or goal in itself.

Dashboards are all too familiar. We've all driven a car and seen all the meters go up and down and then up again. A quick glance (mere milliseconds) is all it takes to see and understand the value it represents. Let's take my own car as an example. It's quite an old car with a dashboard of the same age, but that same dashboard is very usable. There's no ambiguity about what gauge represents what value. Learn it once, and you're done. View it once, and you've interpreted the data. It shouldn't be any other way. After all, you must attend to the higher goal of driving safely to the destination. Continuously looking down at the dashboard is a great way to cause an accident.

Dashboards live a lousy life, though. They never get any fair amount of attention—just a mere glance every now and then. When they do receive some hands-on interaction, it's only for a few moments and then they're abandoned again. This is all because of that higher goal the user has to keep his focus on. The best we can do is to make those few moments of interaction and quick glances as useful as possible.

Dashboards are often viewed from a considerable physical distance. This distance imposes some restrictions on the dashboard's appearance. Here's a little experiment: open up any text document. After that, walk away from your desk and get some coffee. When you return, keep five or six steps distance from the screen and locate the fifth word of the second paragraph. How long did that take you? And how hard was it to locate and read the word? From a distance, 12 pt type tends to blend into the background, becoming barely legible. This means dashboards can't feature small text, however pretty and aesthetically pleasing it may be. And the way text is displayed (font, weight, style, etc.) can only do so much. It all starts with the text itself. Repeat the experiment, but now try to read the second paragraph entirely. Chances are you have to put more effort into it than usual. Again. As old man Treebeard (yes, the one from Lord of the Rings) said, "You must understand, young Hobbit, it takes a long time to say anything in Old Entish. And we never say anything unless it is worth taking a long time to say."

This quote embodies the exact opposite of what is usable in any dashboard. Short labels or microcopy don't add simplicity: they remove complexity.

Maybe you don't even need to use text. An icon can often just as easily convey what you're trying to say. From a distance, icons are more easily distinguished than text. You've experienced this more than once already when looking for a restroom in a public area. You look around for signs showing the way until you see a symbol that resembles what you're expecting to see. It’s only after you've noticed the symbol that you read the text (if there is any). In this case, the text only confirms what you already knew by noticing the symbol: the restroom is that way.

A gentle color scheme with low contrast might very well work on a regular desktop app. But for dashboard apps, especially ones viewed from a considerable distance, strong contrast helps the user to quickly distinguish the relevant portions from the backdrop. This doesn’t mean that the UI should look like a lollipop. Both colors may very well share the same hue. Features like tone and saturation of a color impact contrast. Smashing Magazine recently featured a great article covering color-aspects.

According to Wikipedia, dashboard interfaces "are used to display management information in an easy to read mode like a speedometer or heat gauge." But why are these gauges easy to read? Showing your current speed in plain text is easy: it's a number followed by the unit of speed. It'd have to be BIG type, though. But is the current value really what the operator wants to see? More often than not, operators don't care what the current value is to the n-th decimal of accuracy. They want to know if it's still in the acceptable area or not, and how (or if) it's fluctuating. Analog gauges are versatile enough to show the actual value, trending, safe and unsafe ranges together in one glance. But text boxes…not so much. It's true that, unlike text boxes, analog gauges need some initial learning (like its beginning and ending value), but once that's learned and remembered, a quick glance is all that is needed to evaluate the value.

Dashboards consist of more than one gauge, meter, or graph, and they all need their own prominent spot on the page. Usually some are related, while others display some independent value. We could just place each item wherever there's still some room on the screen, but that would get unusable. Instead, we need to look at the data itself to determine how they can be best placed in relation to each other. Using the "prägnanz" laws of Gestalt psychology, we can design screens that help guide the user to the data he wants. These laws deal with cognition, and how we perceive individual elements as a group. Take, for example, the Law of Proximity: "spatial or temporal proximity of elements may induce the mind to perceive a collective or totality." In practice: adjacent elements in a dashboard are expected to share some common data source. The corollary to this is that we should avoid adjacencies or suggestions of visual relation between elements whose data is unrelated.

One of the advantages software dashboards have over hardware dashboards is the possibility to have multiple dashboard "pages" that change the data the gauges display. Using one screen, the operator can call one of many dashboards, each dedicated to a specific purpose. These can be awesome features with many uses, but as Uncle Ben so rightly pointed out, "with great power comes great responsibility." How can we, as UI designers, provide the option to interact with the dashboard in a without distracting the operator's attention to the higher goal?

Let's say driver of a car wants to swap the speedometer with the odometer (or any other kind of meter, for that matter). One approach would be to tap the gauge. This action that would cause the gauge to loop through the various options. This could work in a desktop environment but would be very dangerous while driving the car. Tapping a gauge demands the driver’s attention be taken off the road ahead and put on the gauge and his finger. This causes sloppy steering and reduced attention to the outside world with all its hazards. Tapping would also mean his hand would be blocking his view of the gauge, so he can't clearly see what he’s doing. One tap too many, and the driver has to go through the entire cycle again (and again, and again, and again…).

This example is about modifying a single gauge, but also applies to the multiple pages I referred to earlier. Looping through the available pages only requires on input, so you'd think practically no mistake can be made. But accidentally miss the screen you were looking for while looping, and you have to start all over again. This flaw can be solved by providing looping in two directions, but that comes with another problem: if the user does not know where in the loop he currently is, then how can he know which direction would be the shortest?

Navigation across multiple dashboard pages is a tough subject. There are lots of navigation controls available, but most of them are designed for desktop use. Tabs are an oft-used means of navigation, but they're only useful if there are few of them. More specifically: any more than seven (plus or minus two) are too many. When the amount of tabs reaches that number, the time needed to locate the desired tab takes too long for comfort.

Hotkeys are another option. They provide fast switching between pages, but only if the user remembers the key combinations by heart. Hotkeys also require a keyboard, which, in the case of dashboards, isn't always readily available. Even if a keyboard is available, there are only so many key combinations one can remember. Relying on a user's memory is never a good idea. People forget stuff.

I recently had to tackle this problem in designing an application that monitors and displays data coming from equipment on yachts. A dashboard UI is the ideal way of displaying such data. One catch though: there's a whole truckload of different data—too much for one page. So we had to devise a way for the app's navigation across multiple pages. We decided on a drop-down window with labeled icons, each linking to its own screen. It takes up a lot of screen real estate, but it does have the benefit that every screen can be reached with a mere two clicks.

Locating the correct icon may take a while at first (especially if it doesn't represent its target adequately), but adding the label provides a extra means of locating the desired target. And there's another benefit: we can, again, use the prägnanz laws. Icons symbolizing similar or related screens can be grouped together. Use the drop-down window a few times, and both the icon and the group's location in the window can be remembered. Note that we're not relying entirely on memory here; unlike hotkeys, the icons are quickly discoverable should memory fail.

Unfortunately, I can't show any actual screenshots (yet), but the mockup below show the general idea (the crossed boxes resemble the icons).

This solution isn’t perfect, as it requires some initial learning and remembering. However, once that’s mastered, the users are far less distracted by the UI while navigating the dashboard. The other options, tabs and hotkeys, would always impose a high degree of distraction, even after an extended period of using it.

Dashboard UIs are an interesting subset of interfaces, and there are some considerable differences between dashboards and desktops. The examples mentioned in this article show that principles that work in regular desktop interfaces don’t necessarily apply to all types of dashboards. As usual, knowledge of your user, her motivations, and her environment is vital when designing helpful dashboard interfaces. Sometimes an unconventional approach is required. After all, not everyone works behind a desk.

Theresa Neil recently wrote up a helpful article on screen layouts that includes dashboard layouts.

Posted on 23 February 2010 | 11:13 am