Author: Jess McMullin

Jess is a consultant who helps the public sector improve policy design and service delivery. Through value-centered design, Jess works to maximize return on investment for his clients and return on experience for their users. His new venture, the Centre for Citizen Experience, works to promote design innovation in the public sector.

Using Design Games

by:   |  Posted on

If you’ve ever sat through a requirements workshop thinking it was wasted time, maybe you’re ready to take on some new tools to get what people really need out of their heads, and into the world. One tool that I started to use in 2002 is design games: game-like activities that help my team gain insight, understanding, and clarity while avoiding dry and often unproductive meetings.

I’m a passionate proponent of ethnographic field studies and other ways of gaining human-centered insight. At the end of the day, that work needs to dovetail with organizational realities and requirements—and understanding business vision and drivers is where we often use design games.

In this article, I’m going to talk about four things: why we use games, core game principles, how to apply games, and how to sell design games to your organization or client.

Why Games?

First, games create conceptual touchstones—shared references that bridge different points of view and provide a common platform for conversation. That’s what most design deliverables try to do, with varying degrees of success. That brings us to the second reason: games are participatory. Instead of the design team holing up to produce some artifact for approval, games can involve a broad spectrum of players, and that creates buy-in as well as common ground for conversations. The accessibility of gameplay means that it’s not just a team of specialists involved, and the diversity of viewpoints from a broader group makes for better insight and innovation.

Finally, games tap into different ways of articulating ideas that help bring tacit knowledge to the surface. Tacit knowledge is often the key to successful requirements, and yet design teams often miss the implicit assumptions and elements that people can’t articulate on demand: asking people what they really need is likely to give anything but. Games can help surface this missing understanding.

Three Game Examples

The IA Slam

Part roleplaying, part case study, The Information Architecture Slam is an ongoing session at the annual IA Summit. Other design slams have emerged as well, but the IA Slam is the gold standard. The facilitators role play various client characters, often an executive, a marketing manager, a product manager, and a project manager. Each character comes with a distinct set of quirks, priorities, and misinformation that teams have to digest as they are assigned a design brief for a product or service.

Teams spend time brainstorming and coming up with solutions, and then present to the whole group. Sometimes the solutions make sense, and other times they just offer comic relief; the important thing is that people work together collaboratively and stretch their imagination, empathy, and innovation skills.

Design the Box

The Design the Box concept (which I learned about from the JoelOnSoftware blog) is a way to puzzle out a vision statement.

In this game, individuals or teams create a box, as if the project is going to be sold at retail. Small groups work together to answer key packaging questions: What’s the tone? The name, the tagline, the short hook on the front to entice a consumer to pick it up? What are the features and functions, the details that connect this product to some real need? Those go on the back of the box. What about system requirements?

box_render_sm.jpgThe output can be a digital rendering or an honest-to-goodness physical box. The key is that this artifact creates a touchstone for the project—a concise expression of what the project is really about. Designing a box constrains and focuses teams to discuss what’s really important, and for who.

Not only is the output playful, but you can create teams to work together on generating box ideas. Whether the group with the most ideas gets cookies, or the team that creates the best idea for customers gets to pick lunch, or if the team with the key positioning statement that reframes the product gets to have a go at the boss in a dunk tank, keeping box generation playful fits with the playful nature of the artifact itself.

Even though it’s a playful output, it’s highly practical; one client kept a box on his shelf for six months, and would toss it over anytime someone asked what his team was doing with the new intranet. People understood the core of the product immediately, and enjoyed the break from reading yet another document describing an initiative.

Variations of this game include creating the product press release, movie poster, movie trailer, magazine or newspaper article. The keys are 1) constraining the form so that the participants are forced to prioritize the many (conflicting) ideas they have about the product, and 2) producing a concrete touchstone that bridges competing viewpoints and perspectives.

MetaMemes

metamemes_photo.jpgMetaMemes is a hilarious brainstorming card game developed by creativity consultant Kes Sampanthar. (Where else do you get to combine the Heisenberg Uncertainty Principle, Grossout Humor, and banking for tweens?) There are 214 cards, which illustrate ideas, words, and objects. Players combine cards in their hands with cards from other players to create new ideas. After several rounds, each player has an opportunity to collect their best ideas, and the players vote to pick the winning idea from the group.

Unlike some other design games, MetaMemes is a commercial product designed to support creativity. The polish of a commercial product means that it can have more credibility than a homegrown solution. However, being completely finished and packaged can make it harder to adapt a commercial product to fit your specific situation. When a commercial product does fit your needs, it can save a lot of time and headache.

MetaMemes has recently launched a new version, called ThinkCube, that’s geared even more to the needs of teams brainstorming ideas. I haven’t seen it yet, but I’m eager to check it out.

Luke Hohmann’s “Innovation Games” Book

Luke Hohmann has collected 12 design games in his book “Innovation Games: Creating Breakthrough Products with Collaborative Play,” well worth checking out for more formats and examples.

Design Game Principles

While it’s great to talk about different design games, the real power comes from understanding the underlying principles at work so that you can successfully adapt and adopt for your own specific situation. Design games share six core principles with all games that help us recognize opportunities to bring games into play.

  • Objectives: There needs to be some kind of goal or outcome that people can work towards. The more concrete and defined these are, the easier it is for people to participate. However, fuzzy objectives can be more rewarding, since they model real situations better. Consider more ambiguous objectives for teams that are already gelled and accept the ideas for design games.
  • Constraints: There needs to be some limits on what players can or can’t do when achieving those objectives. Constraints should be relevant, related to each other, and present a coherent whole.
  • Success criteria: There needs to be some way of knowing when the objectives are met. Clear success criteria help establish expectations and buy-in for game participation. Some games are more unstructured, with less well defined criteria. Classic role-playing games like Dungeons & Dragons don’t have a clear overall objective. That ambiguity can make such games better able to model some scenarios, but harder to sell inside an organization because they don’t have a set ending.
  • Reward: Incentives that reward success can be intrinsic outcomes of the game (good results, recognition), embedded in the game itself (getting more Monopoly money), or external recognition or prizes (the winner gets dinner at a nice restaurant). Balancing rewards between players can be a challenge, and needs to be considered when adopting games.
  • Play: The most important reward needs to be a sense of fun, encouraging interaction and intrinsic value for the game. That sense of play can be elusive—playtesting a design game in your own team is important to get a sense of what is fun, and what isn’t before you roll it out with a larger group. Play operates in the area of flow—balance the challenges of the game with the abilities of the players.
  • Competition (sometimes): Sometimes, but not always, design games can involve individuals or teams competing to achieve those game objectives. While competition can be an easy game mechanic to introduce, it can also create the wrong dynamic depending on organizational culture and individual participants. Does competition make things fun, or turn people into raving lunatics bent on winning at all costs? If it’s the latter, you might look for more cooperative alternatives, including setting competition against previous performances, like beating your old record for ideas generated, instead of against other teams or individuals.

Design game organizers also need to consider whether the game should try to model the current situation (prototyping for example), or teach mindset and universals that support the participants’ needs such as roleplaying to encourage teamwork skills.

By keeping these principles in mind, opportunities for design games can emerge from the normal rhythm and flow of typical projects in your organization.

To learn more about game principles, check out “Rules of Play: Game Design Fundamentals.”

Applying Games

Taking advantage of those opportunities can involve three approaches to applying games:

  • Modifying current activities: Find existing, accepted activities, like brainstorming or workshops, and look for entry points to introduce game principles. For a brainstorming session, this might include setting the outcomes (generate as many ideas as possible), constraints (time limit, ideas need to address a particular customer group), success criteria (simply counting the number of ideas), rewards, play (etc etc), competition (working in teams or individually, see who has the most ideas, who creates ideas that combine different disciplines or areas).
  • Using existing game formats: You can use games that other people have developed—from Designing the Box to Metamemes to the IA Slam. Luke Hohmann lists 12 games in Innovation Games that can work for various situations.
  • Creating new game formats: If you’re dealing with a situation that other game formats don’t support, you can create a new game. Before you make that effort, consider whether a game will give you better results, and if the extra effort is worthwhile. Creating a game from scratch can be rewarding, but takes a lot of time. This makes sense for activities that are frequent or are large enough that the extra effort is going to pay off.

Selling Games

Of course, all of this talk about design games is just talk until you can apply it on a project. The challenge is getting buy-in for using games. Sometimes the novelty of design games is a selling point, but the secret for us is that we don’t sell design games. In fact, I hardly ever talk about games with clients. Instead, I talk about design games in terms of what the activity is or what it does. Using language to reframe games puts them on an equal footing with other discovery and requirements activities. Some of the terms I use to talk about design games include:

  • Innovation tools for structured brainstorming and increased creativity (MetaMemes)
  • Team building exercises (Improv)
  • Participatory requirements gathering (Design the Box)
  • Live case study exercises (IA Slam)
  • Facilitation tools
  • Simulations
  • Facilitated system modeling
  • Artifact collection exercise (scavenger hunt)

No matter how you talk about them, design games can add vitality, energy, and fun to your work and change the game of requirements gathering with your team.

Searching for the center of design

by:   |  Posted on
“In the user experience community, we’re valiantly fighting against the infection of chooser-centered design, and the antidote we prescribe is user involvement.”Design is driven by many considerations. But on each project I’ve worked on, there seems to be a consistent center—a driver that determines priorities, direction, and the metrics used to measure success.

The most common driver I’ve encountered is “chooser-centered” design: Whoever runs the show sets the agenda. That doesn’t always mean the VP is in charge–the “chooser” might be a gung-ho lead developer. As Cooper illustrates in The Inmates are Running the Asylum, techies who are focused on the latest whizzy server platform can be just as unbalanced as a CEO obsessed over expressing the corporate mission, or a creative director who prizes aesthetics to the detriment of all else.

The key isn’t to point fingers at the culprits—it’s to find solutions. I know I’m preaching to the converted when I point out that client-centric, portfolio-centric, technology-centric, marketing-centric, and business-centric approaches abound, and all are flawed. We see the symptoms across the Web with CEO mug shots and vision statements on the homepage, or edgy visual design that wins awards but not customers. So what’s the answer?

In my mind, I hear your response: “We know better. We have the answers!” In the user experience community, we’re valiantly fighting against the infection of chooser-centered design, and the antidote we prescribe is user involvement. It’s the common rallying cry of the UX community: “Put the user in the process! Embrace user-centered design!”

Unfortunately, it’s the wrong answer.

Let me rephrase that—it’s only a partially right answer, and not the key consideration either. User-centered design (UCD) suffers from three significant drawbacks that disqualify it as the ultimate candidate for the center of design.

  1. In placing the user at the center of the process, UCD often ignores other aspects and the process and projects become unbalanced. In reacting to the prevalence of chooser-centric decisions, we grasp UCD with such zeal that we lose sight of the bigger picture. Kent Dahlgren’s CHI-WEB post Usability Contributed to My Layoff vividly illustrates the consequences of extreme user focus.
  2. Putting the user at the center of the process and setting the metrics for project success implies that user-centered design is the “right” approach. Assuming UCD is THE right approach suggests that there is a sort of moral imperative to pursue a user-centered methodology. This has a number of detriments. For people who tacitly adopt the moral imperative position, attempted evangelism can come off with a preachy “I told you so” attitude. When others don’t buy into doing things the “right” way, they are often dismissed as unenlightened luddites who don’t understand the importance of what we do. Thus, some practitioners develop a UCD inferiority complex–a resentful feeling that we’re not appreciated or understood. Often this results in the practitioner’s return to more comfortable territory–conversations within the UX community about methods or tools, or how engineers or marketing just don’t get it. And that leads us to what might be the biggest drawback of UCD.
  3. UCD information is rarely put in terms that resonate with others outside the field–the reality is that user-centered design evangelists often aren’t user-centered at all. We might address ROI, but in the same sentence we use jargon like contextual inquiry, controlled vocabulary, or experience map. While jargon is useful inside the community, and business decision makers are smart enough to pick up our vocabulary, it points to a deeper problem. We naively expect our audiences to learn our lingo, rather than understanding their needs and addressing executives and other decision makers with language and messages tailored for them. We don’t practice what we preach.

None of this means that user-centered design is wrong or worthless. But it’s only part of the picture–necessary, but not sufficient. To see the complete picture requires stepping back and developing a balanced perspective. Individually, practitioners often recognize the other factors at play, but collectively we don’t express the recognition very well.

To connect with decision makers and the people who influence them, we should treat them as “users” of the user experience message. And in this case, being user-centered means not blurting out “User-centered design is the answer!” at the first available opportunity.

While there are a number of alternatives for approaching user experience evangelism, I’m going to share one perspective that has worked for me to begin conversations with decision makers. I call it value-centered design.

(Before we go further, a caveat: Value-centered design isn’t the ultimate answer either, but I hope it helps in your own efforts to connect to decision makers).

mcmullin_090803.gifThe basic premise of value-centered design is that shared value is the center of design. This value comes from the intersection of:

  • Business Goals and Context
  • Individual Goals and Context
  • The Offering (While it sounds like the title of a low-budget horror flick, “offering” is general enough for a wide variety of situations. For a particular project, this might be a product offering, service offering, or content offering)
  • Delivery (How do we get it from the business to the individual?)

Consideration of these goals leads to a particular offering from the business to the individual, delivered through a specific channel. Together, the offering and delivery method create a solution that drives return on investment for the business, and “return on experience” for the individual—return where she gains some benefit for the time, attention, or money invested in the experience. Both parties are satisfied, and this satisfaction establishes the foundation for sustainable initiatives and an ongoing relationship. Meeting business and individual goals creates value, and that’s largely what design is about.

When value is explicitly placed at the center of design, we no longer have to explain what we mean by user-centered design. Our user experience toolbox merely becomes part of the complete picture, working to produce a great solution that meets individual and business goals. User needs are set on equal footing with business needs, and the solution is explicitly a means to achieving those ends, instead of an end itself.

While space doesn’t permit great exposition on the implications of value-centered design, I want to address some key questions I get from my peers in the user experience community.

  1. Isn’t VCD incredibly generic? Isn’t everything about creating value?

    Well, the generality of value is what lets VCD speak to a wide variety of people and situations. However, it’s important to remember that VCD isn’t just about value as a platitude or ideal; value explicitly comes from meeting business and individual goals. The meeting of goals puts individual user goals on the same plane as business goals, which tremendously changes the conversation with business decision makers. In fact, when value is defined this way, everything isn’t about creating value. All those different centers we touched on–award-centric, technology-centric, self-centric approaches–all fail to generate value because they don’t satisfy both individual and business goals (and sometimes neither).

  2. Isn’t VCD just a reframing of current ideas?

    The quick answer is yes. But it’s not “just” a reframing. It’s a reframing that does two key things: puts the user into a business context as an equal player with business goals, and uses language tailored to business decision makers. It also helps me get over my personal “I told you so but nobody listens to me” complex that I seem to share with many in the user experience community. Most importantly, “value” provides a common platform for taking current ideas and introducing them to a much broader audience in a way that “user” can’t.

  3. For something so broad, what real concrete tools come from value-centered design? How can I apply this in my daily work?

Well, I hope B&A will let me talk some more about this at a later date, but for now, here are three ways I apply VCD day to day:

  1. Building buy-in for user experience;
  2. Applying user experience tools to the business side of the equation (ask me sometime about business personas); and
  3. Creating a framework for looking at projects and the tools that they need to generate value.

Of course there are more questions about value-centered design. It’s not perfect, and it’s still evolving within my own practice.

Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction. How that story ends is still being decided with every new project we pursue. I hope that VCD will spark the first chapter in some great success stories about using a balanced approach to create lasting, sustainable value for businesses and the individuals they work with.

Jess McMullin is a user experience consultant who helps companies innovate products and services. Through value-centered design, Jess works to maximize return on investment for his clients and return on experience for their users. A founder of the Asilomar Institute for Information Architecture, he runs the popular IA news site iaslash. He is based in Edmonton, Alberta, Canada. Jess can be reached at banda(at)interactionary(dot)com.

Usability Heuristics for Rich Internet Applications

by:   |  Posted on
“The key difference between a typical Flash site and an RIA is that RIAs possess the functionality to interact with and manipulate data, rather than simply visualize or present it.”Heuristics, or “rules of thumb,” can be useful in both usability evaluations and as guidelines during design. Jakob Nielsen’s 1994 set of usability heuristics were developed with a focus on desktop applications. In 1997, Keith Instone shared his thoughts on how these heuristics apply to what was a relatively new area: websites. Today, in 2003, with Flash-enabled Rich Internet Applications (RIAs) becoming more popular, Nielsen’s heuristics still offer valuable guidelines for RIA designers and developers.

In this article, we focus on Flash because it currently dominates the RIA landscape. However, many of the lessons for Flash apply to other technologies as well.

Rich Internet Applications offer the benefits of distributed, server-based Internet applications with the rich interface and interaction capabilities of desktop applications. The key difference between a typical Flash site and an RIA is that RIAs possess the functionality to interact with and manipulate data, rather than simply visualize or present it. While RIAs hold significant promise, many in the Flash community don’t have the opportunity to work with interaction designers, information architects, or other user experience professionals. As well, user experience professionals often decry Flash or other rich technologies as “bells and whistles” that detract from user goals. We hope this article provides some common ground for discussion between the two communities.

The list below includes Nielsen’s heuristics in bold; our comments about how they apply to RIAs follow each heuristic. Since RIAs cover a broad range of applications, we know we haven’t covered everything. We’d love to hear your own thoughts and experiences in the comments.

1. Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
RIAs should leverage the rich display capabilities to provide real-time status indicators whenever background processing requires the user to wait. While progress indicators are frequently used during an extensive preload when launching an application, they should also be used throughout a user’s interaction with data. This may be monitoring backend data processing time or preloading time.

When dealing with sequential task steps, RIAs should indicate progress through the task (e.g., “Step 4 of 6”). This helps users understand the investment required to complete the activity and helps them stay oriented during the activity. Labeling task steps will provide a clearer understanding of system status than simply using numbers to indicate progress. RIAs’ ability to store client-side data can be used to allow the user to skip optional steps or to return to a previous step.

System status should relate to the user’s goals, and not to the technical status of the application, which brings us to our next heuristic.

2. Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
Understanding the user’s vocabulary, context and expectations is key to presenting a system that matches their world. While RIAs are made possible by the functionality of Flash and other technologies, users are usually not familiar with terms like rollover, timeline, actionscript, remoting, or CFCs – such technology-based terms should be avoided in the application. (See our sidebar for definitions if you’re not sure of them yourself).

While RIAs can offer novel metaphors, novelty often slows usefulness and usability. When using metaphors, ensure that they act consistently with their real-world counterparts. If application functions cause the metaphor to behave in ways that don’t match the real world, the metaphor has lost its usefulness and should be discarded in favor of a different concept.

Both information and functionality should be organized to reflect the user’s primary goals and tasks supported by the application. This supports a user’s feeling of competence and confidence in the task – a key need that is also supported by letting the user stay in control.

3. User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Users are familiar with browser-based controls, including the Back button and Location field. However, using browser commands within an RIA may result in data loss.

The RIA should include code that is aware and responsive to browser history. For applications that contain complex functionality that is the focus of user attention, creating a full-screen version that hides the browser controls can be appropriate as long as there is a clearly marked exit to return to the browser.

While “undo” and “redo” are not yet well-developed in the Flash toolkit, changes to data can be stored as separate copies, allowing the application to revert to a previous version of the data. However, this becomes quite complex in multi-user environments and requires strong data modeling to support.

Many Flash projects include splash screens or other scripted presentations. These non-interactive exhibitions of technical prowess reduce the user’s feeling of control. The ubiquitous “Skip Intro” link offers little help – instead, consider how any scripted presentation benefits the user. If a scripted sequence doesn’t support user goals, skip the development time in favor of something that does. One area that may be a better investment is working to ensure consistency in the application.

4. Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
All applications require consistency within their features, including terminology, layout, color, and behavior. Complying with interface standards can help maintain consistency. However, since RIAs are a new category of applications, standards are still being developed. The Microsoft Windows User Experience guidelines, Apple Human Interface guidelines, and Macromedia’s developing guidelines provide some alternatives starting points for RIA standards.

Branding guidelines also often require consistency that RIA teams need to consider. RIAs are often deployed as branded solutions for a variety of customers. The application needs to be flexible in implementing custom copy, color, and logos. However, branding should not compromise good design. RIA teams may need to show that the brand will gain equity through applying useful and usable standards as well as beautiful visual design. A gorgeous, cutting edge, award-winning presentation won’t help the brand if it’s easy for users to make disastrous mistakes that prevent them from reaching their goals.

5. Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
In forms, indicate required fields and formats with examples. Design the system so that it recognizes various input options (780.555.1212 vs. 780-555-1212) rather than requiring the user to comply with an arbitrary format. Also consider limiting the amount of data entry required and reducing input errors by saving repetitious data and auto-filling fields throughout the application.

Avoid system functions with disastrous potential, such as “Delete All Records.” When functions with significant impact are necessary, isolate them from regular controls. Consider an “Advanced Options” area only accessible to administrators or superusers, rather than exposing dangerous functionality to all users.

With RIAs, when problems do occur, network connectivity allows for the capture and transmission of error details. Similarly, the distributed model of RIAs empowers developers to provide minor updates that are nearly immediately available to the user. These immediate updates can provide correction to issues that repeatedly cause user errors. Beyond the technology, another way to prevent errors is to make currently needed information available to the user instead of making them remember things from previous screens.

6. Recognition rather than recall

Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Too often, the rich presentation possibilities of Flash are used to play hide-and-seek with important interface elements. Don’t hide controls that are key to user tasks. Revealing application controls on rollover or with a click can create exciting visual transitions, but will slow user tasks and create significant frustration.

Since people who are engaged in a task decide where to click based on what they see, rollovers or other revealed elements can only provide secondary cues about what actions are appropriate. The interface should provide visible primary cues to guide user expectations and help users predict which controls will help them achieve their goals. While some of these cues will be basic functionality, cues should also be available for frequent users to show functions that save them time or let them work more flexibly.

7. Flexibility and efficiency of use

Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
RIAs can leverage the advanced functionality of the platform to provide accelerators such as keyboard shortcuts, type-ahead auto-completion, and automatic population of fields based on previously entered data or popularity of response.

Less technically sophisticated accelerators should also be available—particularly bookmarks—either by allowing bookmarking in the browser, or creating a bookmark utility within the application itself. Another option for giving quick access to a specific screen is assigning each screen a code which a user can enter in a text field to immediately access the screen without navigating to it.

RIAs also offer the opportunity allow for personalization of the application through dynamic response to popularity or frequency of use, or through user customization of functionality.

Established usability metrics, such as time spent carrying out various tasks and sub-tasks, as well as the popularity of certain actions, can be logged automatically, analyzed, and acted on in a nearly real-time fashion. For example, if a user repeatedly carries out a task without using accelerators, the application could provide the option of creating a shortcut or highlight existing accelerated options for completing the same task. However, providing these options should be an exercise in elegance, instead of a display of technical prowess.

8. Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
For any given feature, style, or branding element, ask two key questions: “What is the return on investment for the business?” and “What is the return on experience for the user?” What value does the element contribute? If a feature can be removed without seriously impacting ROI or ROE, the application will be better without it.

RIA design is often a balancing act between application functionality and brand awareness for the business. Limit user frustration by reducing branding emphasis in favor of functionality. While branding can and often should play an important role, the brand will best be supported by a positive user experience. Rather than creating a complicated visual style with an excess of interface “chrome,” work for simplicity and elegance.

Animation and transitions should also be used sparingly. While animation and transition can make a great demo in the boardroom, gratuitous animation will provoke user frustration. The time to animate an element interrupts a user’s concentration and engagement in their task. Disrupting task flow significantly impacts usability and user satisfaction.

Sound can also disrupt task flow – use subtle audio cues for system actions, rather than gratuitous soundtracks that are irrelevant to the task at hand.

A further advantage of maintaining clean, minimalist design is that it generally results in decreased file size, and lessened load times, which is essential given the limited patience of many internet users. Another advantage is that a clean interface makes it easier for the user to recognize when things are going right, and when things are going wrong.

9. Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Rollover
Changing the visual appearance of an interface element when the mouse “rolls over” it. A rollover may also trigger changes to other interface elements.

Timeline
The Flash development environment shows a timeline to organize screen elements and their interaction over time, and along with ActionScript is the primary way of creating interactivity in Flash applications.

ActionScript
A JavaScript-based scripting language built into Flash. Used to program interface actions and behaviors.

Remoting
Server technology called Flash Remoting allows the Flash client to interact with software components on a server that can contain business logic or other code. Flash Remoting can allow connections between Flash and server programming environments like ColdFusion, .NET, Java, and PHP. This provides for a cleaner division of labor and better security, with the server-side components doing the heavy computational lifting and the Flash client focusing on user interaction.

CFCs
Acronym for ColdFusion Components – server-based software components written in Macromedia’s ColdFusion language. CFCs natively support remoting.

Error messages should hide technical information in favor of explaining in everyday language that an error occurred. References to “missing objects” or other development jargon will only frustrate users.

RIA error messages can explain complicated interactions using animation. However, animation should be used sparingly in favor of clear textual explanations. Explanations should focus on solutions as much as causes of error. Display error messages along with the appropriate application controls or entry field sot that the user can take appropriate corrective action when reading the message. The ability to overlay help messages or illustrations directly over the interface can be useful in explaining task flow between related screen elements.

When errors are not easily diagnosed, make solution suggestions based on probability – ask what things is the user most likely to want to accomplish right now, and present those options.

RIAs also provide the opportunity to immediately connect a user experiencing major difficulties with support personnel who can guide them to a solution through text chat, video chat, or remote manipulation. These live support channels are just some of the help options available to RIA teams.

10. Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
RIAs should contain simple and concise instructions, prompts, and cues embedded in the application itself. More extensive help should be available from within the RIA.
Using animation or video tutorials with concise narration can often guide a user through complex tasks, while engaging individuals who learn better from visual or audio instruction rather than text. Showing the required steps is often easier for the user to understand than mentally translating a text description of the steps to the appropriate interface elements. Providing immediate contextual help through the use of tool tips and contextual help buttons allows the user to complete their tasks without having to shift focus to a help system.

Conclusion
This take on how Jakob Nielsen’s heuristics apply to RIAs are far from definitive. Rather than accepting these examples as unquestioned rules, we hope it sparks your own thinking about how to apply the heuristics in your work, whether you’re a Flash developer or an interaction designer (or both). RIAs hold considerable promise for both Flash developers and user experience practitioners. Usability best practices like Nielsen’s heuristics are essential for realizing that promise.

The key takeaway for the Flash community: RIAs aren’t about grabbing attention, they’re about getting things done. This is a different mindset than many marketing-driven Flash sites, where bells and whistles are often encouraged in an effort to hold short attention spans. With RIAs, there’s no need to shout – the user is already engaged in accomplishing a goal. The best way to rise above the crowd is to cultivate a deep understanding of who your users are, what their goals are, and then design to meet those goals as quickly and elegantly as possible.

The key takeaway for the user experience community: Flash has matured beyond bells and whistles to provide a platform that enables a far better user experience for complex interactions than regular browser technology. While it isn’t perfect, it can open new possibilities for you as a user advocate. You’ll hear less “we can’t do that” from engineering teams, and be able to create interfaces and interactions closer to your vision. Getting to know the potential of Flash and other RIA platforms will help user experience professionals take advantage of the rich interaction available.

Over the coming months and years, RIAs will move from cutting edge to mainstream. That transformation will accelerate with the Flash and user experience communities working together to understand and develop best practices and shared knowledge. We’re looking forward to great new things— if you’re already doing them, drop us a line in the comments.

Jess McMullin is a user experience consultant who helps companies innovate products and services. Through value-centered design, Jess works to maximize return on investment for his clients and return on experience for their users. A founder of the Asilomar Institute for Information Architecture, he runs the popular IA news site iaslash. He is based in Edmonton, Alberta, Canada.

Grant Skinner On the cutting edge of Rich Internet Application conceptualization and development, Grant fuses coding prowess with interface design, marketing and business logic. Grant is internationally recognized for his work on gskinner.com, FlashOS2 and gModeler. As a freelance consultant, Grant works with corporate clients and leading web agencies to deliver online solutions that generate value. A frequent conference speaker, he will be speaking on usability issues specific to RIAs in SIGGRAPH at the end of July. Grant is based in Edmonton, Alberta, Canada.

Getting into Government Consulting

by:   |  Posted on

From Washington, D.C. to Olympia, Washington, there’s a rich potential for user experience (UX) consultants of all flavors to provide services to government. In this article I’ll share some thoughts directed toward you, the independent consultant or small firm that would like to work with government. I’ve tried to imagine what I’d tell you if we sat down for a drink together and you wanted to get into government consulting. Here it is.

On safari in deepest, darkest bureaucracy: Understanding government culture is crucial for ongoing engagement.

Developing a consulting relationship with government can be quite different from your previous experience consulting for business. To help you get started, I’ll outline some lessons I’ve learned in my work with government, in three key areas:

  • Appreciating the differences
  • Understanding the culture
  • Finding your niche

These strategies promote a customer-centric consulting practice—after all, your clients are your customers, and many of the same user-centric principles used in design apply to your business operations. That’s not too different than consulting anywhere else. But your niche in government culture is likely to be something other than what you’re used to in business.

Dorothy, we’re not in Silicon Valley anymore
Assuming that government works just like business will cost you the contract. Appreciating the differences allows you to target your efforts effectively.

For consultants engaging government, focusing on the different levels of jurisdiction is a critical first step in targeting your potential clients. Do you want to work with local, state or federal government? While the federal government makes headlines with “$700 million in new IT spending,” local and state governments are often more accessible and can provide valuable opportunities.

Deciding which segment to serve is largely a factor of access—state and local governments often prefer “hometown” consultants who are sensitive to local issues. Federal contract opportunities exist across the country, but may be too large for independents to tackle alone.

Political ROI trumps all
Once you’ve decided where to focus your attention, someone has to buy in to what you’re offering. In business, return on investment (ROI) drives those kinds of decisions, and the same goes for government. But ROI is so much more than money. In government (and often in business), financial ROI is secondary to political ROI. What do I mean by political ROI? Just that the cost-benefit ratio measures risks and rewards in political terms: how does any given action fit with the current elected policy? What are the ramifications for re-election? Negative media coverage? Public perception? How does it benefit the government, the department, a politician or senior executive? Does it make the job easier? What’s the worst-case scenario?

In the end, you may have a brilliant proposal with significant financial benefits that gets torpedoed because of politics. Selling your services requires you to position yourself as a political solution first—your services need to acknowledge the party line and make bureaucrats, politicians, internal teams and departments look good.

Beware the Ides of November
Even when you’ve covered your political bases, in an election year, all bets are off. This is true at any level of government, not just in presidential elections. A new administration can (and will) extinguish initiatives started by the ousted party. And even in the case of re-election, the focus isn’t on your precious UX proposal—it’s on the election aftermath. Budget announcements, major policy initiatives, departmental shuffles and other shifts in government will interrupt projects, too.

The bottom line is that you need to be patient during upheaval, and even more than being patient, you need to understand the culture of the departments you’re approaching.

On safari in deepest, darkest bureaucracy: Understanding government culture is crucial for ongoing engagement.

Learn the language
Like any foreign land, government has its own language. When traveling abroad abroad, knowing the local lingo—even a bit—goes a long way in building relationships. Without some advance effort on your part, departmental acronyms, official program names, building locations, internal traditions and initiatives can create a maze of jargon that keeps you from making the connections you need to sell your services.

Alongside this idiosyncratic vocabulary that defines your clients’ “national borders,” there is an additional set of buzzwords that can be aligned with UX goals and objectives. The language of eGovernment is full of things like “citizen-centric,” “G2C” (government to citizen), “C2G” (citizen to government), “service-centric,” etc. The actual selection “eGov” buzzwords will vary, but knowing what they mean can let you frame UX issues in terms that mesh well with existing eGovernment projects.

Know the people—top down and bottom up
While you’re learning the language, get to know the people. Consulting relationships are largely about people relationships—assuming you do good work, the difference between business success and failure is often who you know. In government there are two kinds of people who you’ll get to know: “top down” people are the people in charge. While this includes elected politicians, senior civil servants endure between elections and have more to do with strategic policy than many “backbench” politicians.

“Bottom up” people are people in the trenches actually doing the work—the internal web teams, the middle managers. If you can start talking right away with senior people, that’s great; but the grassroots civil servants will sink or float a project with their acceptance (or lack thereof). Use your personal network to make both kinds of contacts when you’re looking for government work. Even if the people you meet don’t have work for you immediately, you will learn more about government culture, establish longer-term relationships, and find leads on work in other departments.

Big picture, little picture
Even if you’re perfectly fluent in local jargon and know heaps of people, you still need to understand the political landscape. Two flavors of politics inform that landscape: the “big picture” of government initiatives and policy (particularly eGovernment or citizen-centric initiatives) and the “little picture” daily reality of how your client fits into those initiatives.

The “big picture” is usually public—take the time to get to know more than the sound bites from the 6 o’clock news by reading policy documents, studying up on current initiatives, and talking with your contacts to get the word on the street. Those same contacts can help you see the “little picture,” which is no less important. Understanding how your clients fit into the big picture—and where they’d like to fit into the big picture—goes a long way to in tailoring your offering.

Symbiosis is reality: Finding your niche means working with others
So you’ve learned the language, know the people and the landscape, understand the power of political ROI… now what?

While there may be small projects you can tackle on your own, many of the contracts considered in government are beyond the means of an independent or small consulting firm, particularly since the contracts are often package deals (there is the expectation that you will scope the project, create the spec and design, and then build it, maintain it and support it).

Think about working with existing development teams—this routes around the limitations of a smaller shop. This approach can take the form of supporting in-house efforts or working alongside a larger contractor (right now I’m working with an in-house government team; over the summer I did the UI design for a $1.2 million government extranet application that a large contractor is building). Since you can’t compete with larger firms, cooperate with them or change the field on which you compete by doing things they don’t do.

Go get ’em, Tiger 😉
That’s all there is to it. Well, not really. There’s more to consulting with government than this article can cover. But if you appreciate the differences, build connections and cultural understanding and pursue good partnerships, things are off to a good start. Drop me a line and let me know how it goes. Maybe we can go out for a drink.

For more information:

  • California eGovernment Plan
    http://www.ss.ca.gov/executive/bj_tech_plan.htm
    Most governments have a similar public policy document that you can find on their website. It’s required reading before any pitch.
  • Six Ways eGovernment Can Alienate Citizens
    http://infocentre.frontend.com/servlet/Infocentre?access=no&page=article&rows=5&id=265
    Sometimes good ideas get taken too far—in usability testing with over 40 participants, the life events model didn’t scale well to meet a wide variety of information needs.
  • Building Better eGovernment: Tools for Transformation
    http://www.nga.org/center/egovernment/
    Knowing current trends in eGovernment means that you’re being customer-centric in developing your own practice—after all we should practice what we preach.
Jess McMullin is active in the online UX community. He is on the CHI-WEB moderation team, is a User Experience Architect and serves on the info-arch.org advisory board. In his spare time he’s a family man. His personal site is www.interactionary.com