I have never, ever, had an original song or melody pop into my head. I frankly think it would take me a lifetime to become a one-hit maker; let alone a one-hit wonder. I have however, had numerous occasions when I’ve heard a song and then imagined a movie scene play out. For me, the inspiration needs to first come in the way of a soundtrack. I can then fill in the blanks with a storyline.

In becoming mindful of my own personal nature, I’ve recently started paying more attention to how others around me think as well; and more specifically, how they approach design problems. It’s been my experience that many of my non-designer colleagues – typically stakeholders such as executives, product managers, and developers – don’t visualize like designers do. Their strengths generally lie elsewhere. That’s not to say that non-designers can’t be imaginative or creative, but chances are that their day-to-day responsibilities have shaped their thinking to be more matter-of-fact. Put another way, you’re generally better at what you do often; and to some degree, you also have to factor in how you are hard-wired neurologically. Some folks are just better suited to visualize stuff than others.

In thinking about the differences between these types of personal attributes, I’ve also started noticing that we designers sometimes leap from nascent ideas to interfaces far too quickly when faced with a design problem. By jumping right into our typical design process and favorite tools, we squander golden opportunities for enhancing experiences through more systemic thinking. When that happens, we deny ourselves a critical period for both incubation and ideation – which can potentially limit real innovation. In other words, once you show wireframes or mockups to stakeholders, you’ve already impressed upon them a specific direction, which is almost impossible to erase. And chances are that by showing design documents, you’re more than likely committed yourself. That’s just a natural position to take as you pitch your design rationale.

So what can we do to better communicate experience design vision during that window of opportunity between raw ideas and design deliverables? How can we use our abilities to visualize for the greater good? Enter experience modeling.

What? A means for communicating design vision.

What exactly is an experience model? I’ll define it as a vehicle for communicating systems-level experience design concepts. Granted, that’s a little abstract, so let’s break it down a bit.

Experience modeling should first and foremost be rooted in user research. This ensures that a designer has the necessary foundational knowledge to make educated design decisions. Upfront research should include an understanding of the current journeys a user goes through to accomplish their intended goals. Once you have an understanding of the steps involved in the process – ideally from observing and interviewing real users – you’re armed with invaluable information about the lifecycle and its stages.

To illustrate, let’s take the simple example of paying household bills online. The model should initially capture what the process of bill paying looks like from the point a user receives their bills to when they’re paid in full. You can’t improve an experience unless you fully understand its current flow and workarounds.

The next aspect of the model is actually rethinking the experience in the way of redesign. By having done the legwork with research and then breaking down an existing process, designers are in a position to uncover opportunity gaps and latent needs – in this case, ideas for streamlining and consolidating online bill paying options.

And so this is where representations of the new-and-improved experience needs to illustrate how a new model might work; and more importantly, how the proposed paradigm is better! It should convey big-picture design intent and serve as the roadmap for where you want to go; the design destination, if you will. It should also highlight how users will interact with a system and how the system will behave in return.

There are many ways to represent experience models, so more on that later. The key takeaway here is that this is essentially an intermediary step so you don’t get bogged-down in the details just yet – most notably around the actual interface and technological constraints. You simply want to frame your vision and gain alignment with your stakeholders.

In short, experience models serve to communicate design direction for getting team members to, at the very least, be talking about the same thing. (Whether they agree however, is something else entirely!) Having a stake in the ground early on is incredibly important to avoid confusion and divergent opinions when the user interface is being designed later on.

Why? People, *ahem* stakeholders, are strange.

Experience modeling is especially valuable early in a project when it is common to have a great deal of ambiguity. At this point in the process, designers should strive for alignment and buy-in on a general direction so as to begin working on the actual details.

To illustrate how this might come into play with the aforementioned stakeholders, let’s imagine our earlier scenario in which your product department has identified a market opportunity for consolidating online bill pay options. What generally happens next is that the business communicates the opportunity to the individuals who will be doing the actual work. At this point in the process, the evolution of a concept has already begun to take shape in people’s minds. The product folks are thinking about one thing, architects another, and the marketing team perhaps something else entirely different. The bottom line is that everyone is visualizing and the idea is inevitably taking on a life of its own.

In simply scratching the surface on some neurological research out there, it’s widely thought that the left brain is more rational, analytical, and requires sequential information, which means it has to first process bits of information in order to get a holistic view. The right brain, on the other hand, is more visual, intuitive, and able to see the bigger picture first – filling in details afterwards. I’d be willing to bet that most product folks are in the left brain camp and that designers tend to be slightly more right brain oriented.

And so our techniques for communicating design concepts should therefore adapt to meet these potential discrepancies much earlier. Far too often at this stage however, we tend to gravitate back to our comfort zones. By going directly to the design of screens, we may miss the proverbial forest for the trees. Early brainstorming input from stakeholders is stunted because it bypasses their own opportunity to do some systems-level thinking. Social scientists have also shown that abstract thinking can enhance creativity in all types of individuals. Again, what we need at this point is a direction for the team to agree upon (i.e., a model); not a precise solution (i.e., mockups of specific screens.)

In keeping with our imaginary product example, you wouldn’t want to show independent bill pay screens. That’s much too detailed. Instead, you’d want to focus on the benefits of having it all consolidated and displayed in one place. It’s that overarching value proposition of having everything integrated into one view that’s at the heart of the experience we should be championing at this stage in the game.

When? Well ahead of the typical design process.

There isn’t a whole lot to say with respect to timing. Whether you’re creating new products, or making significant changes to existing ones, getting in on those initial conversations with decision-makers is incredibly important. That’s when a designer can make the most significant contributions to the overall vision of a product.

Thankfully, getting user experience designers involved earlier in the product design lifecycle is happening much more often as companies are begin to recognize the value they deliver.

How? Make it your own.

There’s no one, optimal way to represent an experience model. What’s appropriate and relevant depends on your particular situation. You ultimately want the medium you choose to communicate your ideas in the most effective way possible.

I’ve seen models represented as paper drawings on poster-size paper, storyboards, videos, and even as a series of comic strips – which are a surprisingly powerful way to illustrate key interactions. (For some additional examples, check out an archived piece from AIGA’s Journal of Interaction Design).

I’ve also seen designers act out scenarios of how a system is intended to work. This is more common in the service design industry where interpersonal contact is remarkably important (e.g., checking into a hotel.) With digital product experiences, designers can of course play the role of users, but they can also anthropomorphically convey how a product responds. Acting out a few, important sequences is a fun way to communicate and it generally leaves a lasting impression on observers.

Whatever approach you choose, here are a few tips to keep in mind. Good experience models should:

1. Tell a story. You should, at the very least, have a point of view. Having a story also implies a beginning, middle, and an ending. As we’ve seen, you don’t want to leave important aspects of your vision at the mercy of stakeholders’ imaginations.
2. Showcase the talent wisely. You want to focus the spotlight on the most important aspects of your design vision. If a system is incredibly complex, consider chunking it into a series of sequential segments. Or, highlight the most critical paths a user might take. Whichever route you choose, always be sure that the key interactions stand out.
3. Avoid interfaces for now. Unless they are truly meaningful, focusing on the details at this stage can be a distraction. Again, what we’re after here is alignment on a general direction; not the color and placement of screen elements. If you do find yourself needing page-level design, keep it fairly conceptual and lightweight.
4. Use points of reference and metaphors. Providing context and background information is always a good idea. And think of creative ways to describe your offerings with references that your audience can identify with (e.g., “It’s like Mint.com for household bills.”)
5. Be engaging, sharable, and fun! Short videos are a fantastic medium for representing models and high-level interactions. Think about how a movie trailer needs to be all encompassing: it summarizes the plot, sets the tone, and generates some excitement. There’s nothing better than the buzz associated with a clip like this going viral within your company!

Scoring the ending

As the saying goes, knowing thy users is incredibly important; but so is knowing your stakeholders. Understanding how they view the world gives you insight on how to better craft a more compelling design argument. These opportunities also ultimately give us a chance to showcase our design thinking skills. And it’s generally at this stage of the process that real innovation gets a fighting chance.

In short, you need to know where you’re going before you decide how to get there. Experience models can make what you envision a little more real and help chart the course during that window of opportunity between ideas and interfaces.

And so with great powers to visualize comes great responsibility to communicate that vision. Use it wisely, folks.

Time to picture some closing credits… Cue the musical score, because I surely can’t come up with a tune.

As an interaction designer working in an Agile environment, I’ve recently been asked by several colleagues in non-Agile arenas – folks in agency settings, consultancies, or in-house software companies – what it’s really like in terms of design workflow and output. Their questions have touched on everything from the day-to-day differences to the quality of the designs coming out of the process, and their perspectives have ranged from casual-and-curious, to scared-and-skeptical (e.g., “Oh, it’s just a fad” and “There’s that vast Agile agenda again.”)

Well, that got me thinking. What were the real differences, anyway?

The Agile Agenda

Two years ago, I was brand new to Agile software development and pretty naive overall when it came to understanding competing development methodologies. These days however, I feel like I have some ground beneath my feet when talking about development processes and their underlying philosophies. In taking a step back to consider what it has really meant for me as a designer these last couple of years, I tried to tackle questions like:

• What am I doing now that’s different?
• Did my previous skills and user-centered design approach still apply?
• Did I need to learn anything new?

And, perhaps most importantly:

• What has the overall quality of the user experience really been like?

The following takeaways capture some of the things I’ve learned along the way. This is simply my perspective with a little insight on what the transition has been like. What it is not, is a guide for what you and/ or your team of designers should be doing. I’ll leave that to far more knowledgeable folks to chime in on. Besides, one of the major tenets of Scrum is to do what makes the most sense for you and your team.

one of the major tenets of Scrum is to do what makes the most sense for you and your team.

(Note: It’s probably helpful to at least have a rudimentary understanding of Agile Software Development at this point. Check out the Wikipedia entry to learn more.)

Designer as Design Facilitator

First, a little context. One thing that Agile newbies should understand is that the importance of the team and its dynamics are paramount. Scrum teams are small, self-organizing, and cross-functional. They should include representatives from design, development, and quality assurance. Work is committed to for a finite period of time – known as Sprints, which typically range from 1 to 4 weeks – and the team takes on a feature(s) that it feels it can deliver in that amount of time. And “deliver” does mean working code that is technically releasable to the masses.

I work very closely with the developers on my team and even co-locate occasionally. That in and of itself isn’t ground-breaking stuff. However, what I’ve found is that a large part of my job these days revolves around continually fostering communication within the team, as well as with peripheral stakeholders.

A large part of my job these days revolves around continually fostering communication within the team, as well as with peripheral stakeholders.

Since the focus of the team is to consistently work on items that deliver the most value to the customer, distinct roles within the team are sometimes blurred. Everyone contributes to the best of their abilities given the priorities, including providing input on design. This is especially true when it comes to new features with undefined requirements, but it really has to do with the intimacy of the team and the immediacy around the thing that we’re working on.

Let’s say a Product Manager gives the go-ahead on Feature X because she sees a glorious market opportunity. Once that is communicated to the team and prioritized within the backlog – basically a to-do list consisting of “user stories”, which are written in non-technical language to describe the value of a feature from a user’s perspective – it is up to the team to decide exactly what to create. The product team may still have the final say, but it’s up to the designer to lead the early efforts. That includes applying the tools of her trade in the way of user-centered design principles, coupled with a clear understanding of the business drivers and the technology behind it all. Although some of you reading this may be saying “Well, I’ve been doing that all along, anyway”, the difference here is that it is now being recognized. More on that later, though.

When we embark on a new user story, one of the first things I do is generate some ideas and hold early brainstorming sessions with my core team. This allows me to corral the different ideas and understand everything from technical feasibility, to ballpark estimates on the potential development work involved. Sometimes the conversations go astray or become focused on implementation details, so it’s my job to get them back on track by grounding everything in the end users’ goals and expectations. And everyone likes to be heard, so there’s a good deal of diplomacy required as well.

This ongoing dialog helps to ensure that we as a team are headed towards an appropriate solution and it’s these conversations that the designer needs to facilitate, time and again. (By the way, all of the above involves getting user feedback early and often, but as designers reading this article, you already knew that.)

Again, the headline here is that it’s all about the team. Designers don’t design in isolation and then simply hand-off a design, never to be heard from again. It’s a much more collaborative and tightly integrated effort between the designers, product management, developers, and of course, users.

Nimbleness Required

OK, so all of the above assumes that a Designer actually has the necessary time to conceptualize, validate, and then iterate accordingly. Unfortunately, that’s not always the case with Scrum and this is one of its downsides; which, by the way, is also frequently cited by its critics – especially in the way of shortcomings related to being truly innovative.

When done properly, a “Sprint Zero” is introduced to allow designers to do their upfront discovery ahead of any coding. However, given the flexibility inherent in a process that is beholden to shifting business needs, priorities for the team do sometimes change from Sprint to Sprint. That allowance is, of course, one of Scrum’s key value propositions. It’s also where being nimble on the part of the designer needs to come into play. The old-school way of having a rigid, stepwise process doesn’t apply terribly well any more for delivering complex software that is useful, usable, and ultimately timely. Design processes need to adapt to some degree as well.

All of the above however, doesn’t mean that design thinking isn’t valued; it’s just that designers need to be flexible and shift priorities in accordance with business objectives. If you’re a designer that finds themselves deeply committed to a design or unable to let go of a particular project, you’ll need to acclimate. Designing within Scrum means being able to shift as needed and handling ambiguity well. Really well.

Designing within Scrum means being able to shift as needed and handling ambiguity well. Really well.

(For more on the pros and cons of incorporating User-Centered Design within Agile, do read Anthony Colfelt’s incredibly insightful article).

The Lovely Bones

As mentioned earlier, Scrum understands that the needs of the business and its customers (i.e., requirements) will change and almost embraces that mantra. However, because Scrum also calls for working code as soon as possible, you may be thinking that those are opposing forces at work. However, the truth is that it can work. And once again, this is where our fearless designer comes in…

Remember Feature X and how the designer was brainstorming what it could ultimately become? Well, if we join our regularly-scheduled programming already in progress, it’s the designer (and potentially researchers) that are coming up with the building blocks for an incrementally feasible strategy.

What are the core features that users need? Which functionality can they live without (for now)? What could add some wow-factor? In other words, what’s the Minimum Viable Product (MVP)? Getting user feedback is crucial at this juncture to help determine what the bare bones will be – sometimes referred to as a “walking skeleton.” Designers help define what gets released in order to then get feedback on what’s working, what isn’t, and what’s next. To a large degree, releasing often tends to keep your designs and product honest.

Designers help define what gets released in order to then get feedback on what’s working, what isn’t, and what’s next.

As with any process, there are very real trade-offs involved. Given Scrum’s inherent proclivity to release something sooner than later, the big question often becomes “is it good enough?” This is why designers working in Agile need to be well-versed in communicating the business value of good design. Making business folks and developers understand why user experience matters is critical to the success of your product in this environment and it’s a never-ending crusade.

Incremental Design While Keeping Your Eye on the Prize

In working to define a Minimum Viable Product, the first challenge is thinking through what can be built in order to satisfy marketplace and user needs in the here and now. Again, we’re back to that notion of immediacy.

Because a designer goes from defining high-level requirements to specifying the very concrete steps of what to build and when, the trick is to keep your eye on the big-picture. I’ll have to admit that I’ve found this to be one of the most challenging aspects of designing in this environment. Once you determine what to build as bite-size pieces of functionality in order to get something out, it becomes increasingly difficult to keep a systems-level perspective on the holistic user experience – i.e., trying to avoid a Frankenstein-ish product – when priorities shift and you have to come back to a design at a later time.

Take any great iPhone app as an example. It doesn’t include everything-and-the-kitchen-sink, but instead distills the core set of features that users will need and then attempts to make that experience really good. This doesn’t mean that you can’t add or improve things at a later time; it’s just that you try and give customers the best you can with the bare essentials first. (One could even argue that the entire smart phone revolution is founded on this very principle. Otherwise, users would have surely dismissed the complexity inevitably inherent in designers lazily porting over a desktop experience into the mobile world.)

Welterweight Documentation

It’s probably no surprise at this point that design documentation is kept fairly minimal. The close working relationship among team members means a great deal is communicated face-to-face via sketches, whiteboards, and simple wireframes. The goal of design work (i.e., creating deliverables in the way of experience models, flow diagrams, and mockups) is really to communicate ideas to the team so as to jump-start the development process.

Once developers begin coding, I make sure to check-in early and often to offer advice and provide any additional documentation, repeating as necessary. Documentation still exists and is important, but it’s kept lightweight to capture the essence of an interaction and consumed in a just-in-time fashion.

For those designers coming from more traditional development backgrounds, you may be relieved that large documents with incredibly detailed specifications, footnotes, and obscure corner-cases, are a thing of the past. However, as indicated above, the time you have to think through a design is also compressed.

The big takeaway here is to use your design time wisely and create only as much documentation as is absolutely necessary to communicate your ideas effectively. It doesn’t need to be pixel-perfect, unless of course it needs to be pixel-perfect to get your concepts across.

create only as much documentation as is absolutely necessary to communicate your ideas effectively

Retrospective Introspection

When was the last time you really thought about what you and your team were doing? Did you ask questions like: How is this process going overall? What’s working and what isn’t? Should we be doing things any differently?

Well, with Scrum, facing yourself in the mirror is a standard option courtesy of “retrospectives” after each and every Sprint. They offer the team an opportunity to acknowledge strengths and weaknesses with unabashed transparency. I’ve found that the very nature of this exercise forces designers to focus more on what’s important by continually questioning their own process. This is especially beneficial when it’s coupled with customer feedback from designs that are live because the team is getting stuff out more often.

facing yourself in the mirror is a standard option courtesy of “retrospectives” after each and every Sprint.

Parting Shot

Hopefully you now have a little insight as to what to expect with Agile, as well as some awareness of the trade-offs involved. Upfront design and research are sometimes rushed and the ever-present threat of compromising user experience quality in favor of releasing something – which frankly feels like a gravitational pull sometimes! – are very real challenges. That said, not going astray and loosing your moral and/ or design compass by building unnecessary features and going down dead-ends is ultimately a good thing.

And rest assured designers, there’s still no shortcut to delivering a great user experience. The same, core user-centered design principles you know and love still apply and are highly valued. In the end, it’s not that drastic of a shift and designing within Agile just keeps you on your toes a little more.

My parting advice: be nimble, collaborate with your team as much as possible, and don’t take an uncompromising, hard-line approach to process guidelines. And most importantly, keep your eye on the prize.

This is the first of a two-part series. The second article, Designers as Product Owners, will focus on additional responsibilities designers can take on within an Agile organization.

As an Interaction Designer, I’m perpetually impressed with the continual design success inherent in most video games. We are taught to know our users by understanding their goals, leveraging mental models, and taking ourselves out of the equation in order to design useful and appropriate interfaces. And although a user-centered design approach is invaluable, I can’t help but wonder how game designers just seem to nail it time and again for what are large and diverse audiences.

Now, I have to confess that I’m not a hard-core gamer. I dabble on occasion, but mostly prefer to watch others play, as well as keep abreast of the industry. What is clear to me, is that the experiences are immersive, the storylines compelling, and the business itself, well, huge! So, just what is it about the domain-formerly-known-as interactive entertainment that makes it so engaging?

First, Knowing What We’re Up Against

Let’s be honest, doing your taxes using software as a service or completing a registration form isn’t exactly as enjoyable as a Halo LAN Party or rocking out in Guitar Hero. Gaming has a clear advantage here. This focus on the act of gaming is also very different than using traditional software, where the completion of a task leads one closer to a desired outcome or goal. Software is really just a means to an end; nothing more than a tool for most.

The game play journey on the other hand, can be as important to the user as achieving their goal of completing the game. A good experience needs to be rooted in an emotional dialog with a good story. One could even argue that the interactive component introduces another dimension altogether, thereby perhaps even making it more emotional as compared to a passive experience like watching a film or reading a book.

The sheer amount of time users invest in playing is also a major difference. Gamers can spend tens of hours practicing and honing their skills. That said, it also means that early stages are especially important because users won’t continue playing unless the experience is perceived as worthwhile.

New Media Culture, Meet Everyone Else

In the last few years, gaming has become much more widespread, having made tremendous inroads into Mainstreamville. You’d be hard-pressed not to find a console as the living room entertainment hub and the incredible success of the Nintendo Wii has contributed greatly.

The generation that grew up playing early video games is now also leading the way in designing experiences and their backgrounds have unmistakably influenced their work in the way of incorporating traditional gaming mechanisms. The gap between previously sovereign digital platforms has indeed converged, and they are now inextricably intertwined.

What that means, is that everyday users are now bringing mental models from what used to be segregated digital arenas to the interfaces we design. As Interaction Designers, it is our responsibility to understand that, so as to then be able to imagine and create designs users can intuit more easily. (I’d even go so far as to state that embracing this convergence actually makes our jobs that much more interesting, but more on that later).

OK, so gaming is popular and some really smart folks have begun to take the field seriously. Why should we care and what does all this mean? Well, there are interactions we can leverage (a kind of gamesmanship, if you will) in our day-to-day design work. Although we’ll need to set aside some of the advantages discussed earlier, there are still general principles we can learn from and borrow.

Everyday users are now bringing mental models from what used to be segregated digital arenas to the interfaces we design. As Interaction Designers, it is our responsibility to understand that.

Useful Game Design Techniques

In assessing some of the research out there and coupling it with my own experience, I’ve tried to corral some of the themes that emerged. Here is a collection of nine techniques with examples of how they might be applied.

The Edge and Back: Taking users to the very edge of their perceived comfort zones can have amazing affects. (Actually, this technique applies in all walks of life, but I digress). Video games tend to get harder as a user makes progress, meaning they’re also always getting better.

This technique can arguably be interpreted as being similar to what’s known within the user experience field as Progressive Disclosure. Exposing users to increasingly complex or advanced features as they gain familiarity with an application is powerful stuff.

Degree of Difficulty: Most games allow you to choose how challenging you want the experience to be. Some games even allow for practice tutorials and playable demos.

Complex systems that require a degree of mastery come to mind here; things like software for architects, which can do everything from actual 3D modeling, to budgeting for building materials. An embedded example project – much like the examples included within Adobe’s design products – also help users get started. (Can you imagine software that allows users to first choose their ability level; perhaps even incrementally increasing the level of complexity as they gain confidence?)

Power to the User: We all like to be in control and video games are empowering. As protagonists, gamers feel like they’re in command of their virtual world. This is actually pretty remarkable considering that most games are designed with a pre-determined outcome – albeit some more loosely than others. It’s that perception of being in control that is the real magic here.

On the web, examples can include giving users the freedom to come back to a registration process when they don’t have a specific piece of data available at that particular moment; or, allowing for partial completion of a profile (e.g., LinkedIn), potentially providing incentives to complete the process later.

You Are Here: Giving users constant status updates as to where they stand in their virtual world is something games do incredibly well. For example, being able to instantly access a level map at any time is very reassuring.

Translating this to web design can be as simple as using breadcrumb trails and status indicators during registrations or checkout flows. Bigger picture stuff can perhaps include encouraging exploration by showing users what percentage of an application’s features they have encountered up to that point (i.e., “Oh, I see that I’ve only been using this percent of the app; I wonder what else it can do?”)

“Tell Me What I Need to Know When I Really Need to Know It”: Providing users with information at the moment they need it most is something video games do a great job of. Games offer up useful tips that the user can dismiss or opt-out of entirely.

Having users learn through actual usage is key and inline links to contextual information/ help content is probably the most common application here. (see als: The iPhone is Not Easy to Use, by Fred Beecher)

Task Accomplishment and a Sense of Accomplishment: Traditional usability testing generally involves capturing metrics like: “Did the user accomplish Task A: Yes or No?” and the paths taken. However, when game developers test their wares, they also try to gauge the overall experience (i.e., Was it fun? Was it hard? Was it easy? Was it too easy? Would the user play again? Why or why not?) This focus on the large canvas logic – in addition to the usability of game play mechanics, of course – provides incredibly rich data that can be the difference between success and failure.

The takeaway here is to make sure stakeholders don’t become mired in the details around the success or failure of specific tasks and loose sight of whether the larger concept makes strategic sense.

Shared Experience: Capturing and then presenting issues that users encountered can be a wonderful way of educating the ones that come thereafter. The MMORPG EverQuest has a great deal of support available, but the game is designed to encourage “soloing” early on – meaning a user goes off to explore by themselves to gain experience. As the levels become more challenging however, “grouping” is encouraged so they can learn from one another in increasingly complex environments.

An interesting example of leveraging collective knowledge can be found within TurboTax, which uses their “Live Community” feature to bubble-up the most common questions during specific tax preparation steps. Answers from previous users and tax experts are displayed to the right of where users are working.

Sensory OptimumLoad: (Versus, of course, sensory overload, which is not a good thing). The highly interactive nature of gaming and the engagement of the senses is part of its allure. However, well-crafted games unfold their stimuli gracefully, allowing for a gradual period of acclimatization. Consistency is also a critical component because these interactions ultimately become a language the user relies upon. System feedback – in the way of visuals, sounds, and haptic controller vibrations – are an ongoing dialog.

As mentioned earlier, when users first encounter an interface, they bring their “baggage” in the way of existing knowledge from previous experience and conventions. They either expect things to behave a certain way; or, have to draw upon related experiences to try and make sense of them. This speaks to a need for standardization within a product, which hopefully also leverages established domain conventions.

FunNess: And lastly, having some fun is always good. Doing something that’s fun means it’s engaging, which in turn makes learning about it easier. Understandably, not every interaction can be a barrel of laughs, but there are plenty of ways to inject some creativity here and there.

Language and tone-of-voice is a simple way to make things a little more interesting. I recently encountered a mundane Terms & Conditions checkbox interaction that playfully stated: “Our lawyers make us do it.” That one sentence put a smile on my face and made me think a bit differently about the company. (see also JohnnyTV: Designing Humanity Into Your Products, by Bill DeRouchey)

Epilogue

As we have seen, convergence among what have historically been very siloed experiences has now expanded the universe of options Interaction Designers have to choose from. The challenge of course, is that the next-generation of experiences will not only need to be both useful and appropriate, they’ll also need to engage users more than ever before. My final words of advice in that case: choose wisely, be creative, and don’t be afraid to inject some fun. All in all, I’d say things just got a lot more interesting.

Top image: Wii promo photo