Friday March 27, 2009 / 3 Comments

For some time, I’ve described the design of experiences with this potent little phrase: 

It’s all about People, their Activities, and the Context of those activities.

That’s it, really. Whether we are designing a Web app or new office building, simply ask: Who are the people we are designing for? What is the activity (or activities) they are trying to do? And what are the contexts in which they are trying to operate? And ‘people’ can be an individual or group. It’s that simple. On the surface…

Behind every explicit piece of information, we can dive much deeper for a richer understanding of the space in which we are designing. People are much more than users (or markets, prospects, players, stakeholders, or…). An exploration of activities yields more insights than simple task or use case definition. And context is so much more than a device or platform— from the environment we as information architects define to the environmental and economic context in which we work.

It’s these ideas that form the basis of my “Fundamentals of Experience Design” Model, which I had the pleasure of unveiling at the recent IA Summit 2009 conference . Think of this as my “grand, unified model” of experience design. Or something like that!

Download The Fundamentals of Experience Design model
(10M print quality pdf file!)

Download The Fundamentals of Experience Design model
(not quite so large 2M png file)

The origins:
This model/poster, as with previous Summit posters, is a personal attempt to resolve a number of different threads and conversations, this time around “designing for experiences”— any kind of experience, from shopping online to going out for dinner to checking out a book from the library.

The model covers the basic UX stuff like moving from a focus on tasks to a focus on activities, as well as more theoretical discussions like activity centered design vs user centered design. I also wanted this model to represent where I’m moving professionally: As evident in my seductive interactions presentation, I’ve become more focused on subjects like psychology, social design, game mechanics and other “deeper” human considerations when designing for experiences.

The elements:
For years I’ve been discussing experience design in terms of people, activities and the context of those activities. These are the core elements of this model. FYI, the poster you see is actually the third iteration— for several years, I’ve been exploring (1) how these elements relate to each other, and (2) whether there should be any other core elements added (I wrestled with things like “objects,” “tools” and/or “content”). Along with the considerations listed below, I’m comfortable with this particular representation of the ideas:

This is a simplified explanation (the poster explains all this much better!):

• Experiences should focus on individuals and groups as people first, followed by our various roles as users, consumers, segments, stakeholders, employees, etc.

• Activities can be anything you do, and aren’t necessarily task-focused (this is a problem I have with many of the UCD and Agile discussions). Consider passive experiences like reading The Onion, or entertainment experiences like iSteam. There’s a motivation for these activities, but there isn’t always an explicit task involved.

• Context contains people and activities. Context for activities is fairly straightforward — environments, cultures, devices, etc. For people, there is a personal, implicit context that may affect an activity — having a bad day or finding out someone is in the hospital for example may have nothing directly to do with the activity (say, buying a pizza) but will affect the experience of that activity. Context also extends out further to consider the business, technological, cultural and social contexts that enable or affect the activity in some way. An easy example of this deeper cultural context is the editing out of the Twin Towers from the original Spider Man movie following 9/11— this editing decision recognized the emotions outside of the film itself that would have affected the movie enjoyment experience.

• With the resulting peanut shape, I draw horizontal a line between explicit considerations (tasks, users, business goals) and deeper considerations— the insights, motivations, behaviors and other “softer” focus areas that separate good experiences from the great ones.

Here’s a “Cliffs Notes” version of all this, using first person callouts:

Some things I learned making this:

• The importance of context.
  I’ll probably have to write a whole separate post on this. Needless to say, context is SO MUCH more than screen resolution and browser size! One theme that kept surfacing at the Summit was “context shapes behavior.” This is so true. On one hand, you do need to consider things like device constraints. On the other hand, you have to step back and look at the business context that is enabling (or standing in the way of) an experience.

• These fundamentals are largely input considerations.
  In describing how different UX tools and activities might map to this model, I realized it was best suited for those things that provide input and insights. The output will vary base on your discipline (interaction design, industrial design, etc.)

• Distinguishing between internal (personal, for people) and external (related to the activity) contexts. Basically, this is how something like “having a bad day” may affect an unrelated activity. How often do we factor in these personal contexts into our designs? This could be especially useful for contexts such as hiring sites, where a personal, emotional state might vary widely from individual to individual.

Feedback from the IA Summit:
During the reception and poster presentation, I got some great feedback from a ton of different folks. Here are some of the highlights:

• “Aren’t motivations specific to people, not activities?”
  I got this feedback from about 3 people, two of whom work at the same company. This was clearly a semantic issue, not an issue with meaning or intent. For me, motivation is specific to an activity— why you do something. I’d call those abstract motivations that get us up in the morning (to be happy, to change the world, to avoid conflict) “goals” or “desires.”

• “What about the cultural context for people?”
  Behind activities is a deeper cultural context, why not the same for people? I’ve been thinking about this, and I’m thinking this is part of the internal context specific to a person. But, something to consider…

• “Why are people separate from activities?”
  This has been the most challenging question, as there are good reasons to join people and activities within context (think two halves of a circle inside a larger circle). I’ve been sketching this, and while there is cause for this, it would also introduce new discrepancies — for example, business context is specific to an activity and not a person. I exist outside of a given activity until I choose to do whatever that is. This would introduce a problem not currently in the model.

• “Should behaviors be a core element?”
  I’ve also been thinking a lot about behaviors, specifically the idea that “context shapes behavior.” I think the model supports this just fine. We design for activities, and we design or consider the context. The behaviors are how the activities occur within a given context for a particular person or group of people.

• One final comment— people really connected with the floating chunk of earth! Apparently this a powerful visual metaphor for these ideas. Several people described this as a better iceberg model. I’ll go with that! When I chose this, I was thinking about tumbleweeds, and how badly designed experiences have no roots in natural human behaviors, desires or motivations. I like the idea that the deeper your roots go (more human insights and applied behavioral economics), the better the experience being designed will be… And I like the analogy that roots aren’t readily visible.

What’s next?
So, that’s some of the thinking behind my Fundamentals of Experience Design model. What are your thoughts? Does this help you in some way? In the poster, I list some ways this might be useful with clients or with practitioners. But, I’d like hear more about how you might be able to use this in your work…

Friday April 18, 2008 / 2 Comments

If you’re managing (or part of) a team inside of a large corporate organization, then you’re familiar with the difficulties of juggling strategic and tactical concerns. This was the focus of my poster for the this year’s IA Summit. So, for all you ‘innies’ running a strategic User Experience Design group, here’s a model for you:

Download the Managing A Strategic UX Team Poster (pdf file)

[CLARIFICATION: Since creating this, I’ve joined Viewzi — I no longer work in the corporate environment in which this was produced…]

The Problem that led to this model
In my experience, we’re frequently asked “what are you working on?” Many times this is just a conversation starter. And other times, if it’s a project owner, that person really only want to hear you say “yes, we’re working on your project.” But at the executive level, the question is a strategic one: what is it that you are working on that is either going to make me look good and/or benefit the business. In these circumstances, we’ve two challenges:

1. address their concerns, but also
2. communicate how the things about the UX practice that they may not understand but are linked to top level strategic goals.

This is a communication problem. And a difficult question for UX groups to answer succinctly, given the breadth of activities that we are working on at any given moment—from ‘order taking’ on interface efforts to design research, internal presentations, technology experiments, or perfecting our ping pong skills.

But more than a communication problem, this is a strategic planning challenge: As a leader in a company, I have to be able to defend how every bit of our time fits into the overall strategic direction. This is especially the case where resources are tight and you have to make trade-off and priority decisions that don’t sit well with some.

3 Boxes Model
I’m a big fan of models—especially models that ‘get it right’, making simple the complex and providing a platform on which people can map their activities.

So when I came across the 3 Boxes Model from Vijay Govindarajan, I found it to be one those rare occasions where someone has framed the strategic conversation in a way that is easy (very easy!) to understand and can be built upon by almost any group inside an organization.

The ’3 Boxes’ are:

• Manage the present
• Selectively Abandon the Past
• Create the Future

...which are then rolled into these into 2 groups:

• competing for the present
• competing for the future

Brilliant. The 3 Boxes apply to all business units, project teams or disciplines. The resulting groups— competing for the present / competing for the future— are the perfect frame by which to evaluate where you’re time is being spent. Which leads me to…

Proactive and reactive work
When I arrived at my corporate gig, it was agreed that to be successful (truly successful), the UX group would need to split our time between ‘proactive’ and ‘reactive’ work. Different words, same idea.

Reactive work consists of funded projects for this year— enhancements, incremental changes, new projects building upon existing structures. It’s this kind of work that most folks expect from a tactical UX group (aka ‘order takers’). And this is the work that demonstrates short-term value. Of course to a good design team this is the work that can be immensely frustrating—like straightening deck chairs on the Titanic. But, to quote Thomas Dolby: “A few years in the music business taught me that you don’t invest ahead of the revenue curve.”

Proactive work consists of those future ideas we have around how things should be (and could be, given a reframing of the problem to be solved). This could simply be the ‘ideal’ version of the reactive projects we’re working on. Or, these ‘future ideas’ could be a radically different take on what’s possible and valuable given our understanding of business and customer goals. Of course, these solutions might potentially poke at the business model or challenge the technology infrastructure—which is to be expected as one leg of the 3-legged stool.

One problem with this language— proactive and reactive — is that they only suggest user interface or project related work—which is only the end result of a bigger process. Between ‘proactive’ and ‘reactive’ efforts, there are a score of other initiatives that have nothing to do directly with any particular project or product design—training, brown bag lunches, design research, persona creation, guidelines and standards, etc.

There was another big problem. Not surprisingly, this language didn’t stick. ‘Proactive’ work began to be associated with the ‘fun, sexy stuff’ that was keeping us from doing the real work. Of course, this perspective is flawed— there’s a world of difference between work and progress. And anyone spending more than a few days with us quickly recognized the strategic value our UX group offered. We would never be satisfied with ‘putting lipstick on a pig’.

Putting it all together
So, a simple change in language sent me down the path that led to this model. I had already listed the many different activities we were or would need to be engaged in, and thinking in terms of competing for the present or the future proved to be the perfect base to layer these activities to… End result, this was a great framework for me to explain all of our efforts to my peers and upper management in a way that is strategic and not tactical.

And now…?
What I’m most curious about is whether this framework would work elsewhere, or is this only applicable to the culture in which it was created? I’m curious to see how these generalized activities translate into other companies and other UX Design groups with different cultures and roles within the organization.

So, now it’s your turn, innies. How does this work (or not work) for you?

Monday June 18, 2007 / 1 Comments

In preparation for several research projects, I’ve been digging up what I can around experience modeling, a practice pioneered by E-Labs during the mid to late 90s. Experience Modeling (or Xmod as it was later called at Sapient) can be used to distill and visually communicate key experiential elements gathered from ethnographic observations. Something like this:

This model shows how one type of user evolves from viewing a cellular phone as a single-function appliance to experiencing it as an essential life tool.

Rick Robinson (CoFounder of E-Labs) discusses these as “models of thought” which become “things to think with”. While reading some presentation notes from 2003, I encountered a curious thought in which Rick seems to have stated:

The model doesn’t have to be perfect, it just has to be right.

I wasn’t exactly sure what this meant until I read another interview with him, in which he recounts the development of the now famous stairwell model of DNA:

Now think about how profound the changes in Western medicine, science, biology, have been, not to mention how much money has been made from this thing that was clamped together out of old chemistry clamps and sticks and balls in a stairwell behind their offices. Their genius was to represent not the precise detail, but the underlying structure of how protein molecules combine to create a DNA sequence. That notion of a model was something that was both a model of the underlying structure and a model for how people could think about what’s going on in genetic material.

Robinson goes on to quote Jacob Getzels, saying:

Good theory gives you something to think about, a but a great theory gives you something to think with.

This makes wonderful sense. As I’ve been preparing for some large-scale research efforts, my priorities are focusing on aligning the various diverse and competing interests. Key to this effort is a proper framework or model by which we can structure our conversations.

Not Just Experience Models…
Along similar lines, Gene Smith and Michael Milan presented at the IA Summit on the topic of Systems Thinking, Rich Mapping and Soft Systems Methodology, describing a

holistic problem solving framework that can be used to design and model interactions between organizations, people, environments, products and services.

Where experience modeling is rooted in a person’s total experience (across products and environments), Systems Thinking proposes a model (CATWHOE) for understanding the broader context in which a solution is developed. This includes all factors affecting a system- including such things as organizational, relational, or political concerns well outside of any actual product design and development. This would be quite useful for understanding how to push a good idea throughout an organization, preparing (upfront!) for possible resistance, or understanding why a good idea might never have made (or make) it out the door.

Two different models with similar goals—understanding and insight around the real problem to be solved. I particularly like how Gene and Michael described why they like Systems Thinking:

• Illuminates the structures behind the structure
• Helps to engage us in thinking about problem solving beyond just “requirements”
• Helps us understand the context(s) in which we are delivering the appropriate IA to the client

This stuff is gold. As I’ve matured professionally, my concerns are broadening, with less day to day focus on products (thought I still have much to say on that subject!) and more focus around the business and technology context in which we are designing—which is interesting in a different sort of way. While I have nearly a decade of experience with Design, in one form or another, I don’t have that same deep expertise in finance, strategy, technology, or other topic areas that would certainly come in handy! Which leads to my next topic…

Shared Problem Framing
Jess McMullin (also at the IA Summit) discussed a related theme in his presentation Project Touchstones. There exists a tendency to create deliverables that define solutions as opposed to creating deliverables that define problems— together. Jess made this point quite effectively, before presenting six ways to work together with clients (or other departments) to create a shared definition of the problem to be solved. One of his slides references Arias and Fischer (2000) who write,

Fundamental challenges facing communities of interest are found in building a shared understanding of the task at hand…

Hmm… A shared understanding. Sounds like problem framing. Sounds like a shared model. Or A shared definition of the problem. Or an experience framework. Or a shared vision of the ‘future state’. Or…

The common theme here is eerily similar and not at all surprising: let’s come together to frame the real problem to solved. And models seem to be a good way to do just that.

The trick of course is to get the model right.

Friday March 30, 2007 / 2 Comments

Getting from Tasks to Experiences: What’s Next in Interface Design

Download the Tasks to Experiences Poster (pdf file)

Description
If we look to established fields such as product or environmental design, we can draw some interesting parallels to the still maturing field of UI design. An initial focus on function gives way to better performance, usability testing and eventually differentiation on more visceral and reflective attributes. Of course, this latter focus is far less tangible and certainly subjective— it’s easier to perform a heuristic evaluation than it is to measure a product’s emotional appeal.

With rich interactions, the Social Web, and other recent web application advancements, we are reaching the point where it’s finally appropriate to discuss things like ‘joy of use’ and ‘pleasure’ in interface design. This is also the point at which we must stop designing only to support tasks and begin designing to support experiences. Unfortunately, this transition is a difficult one to get companies to invest in, except where the product is consumer facing and needs to remain competitive. I dub this difficult transition the UX grand Canyon. This is the chasm between designing to support tasks (with a focus on products and features) and designing to support experiences (focusing on people, their activities, and the context of those activities).

As a consultant, I found that Usability, Information Architecture— disciplines that help people accomplish their tasks— were relatively easy to justify. But how do business owners justify desirable experiences, especially where the application is an internal application, a portal for example?

To communicate that this is a critical next step in interface design — and and not a luxury to be marginalized — I developed two, complementary models:

The first visual takes a speculative view of how things have evolved and might evolve, tracing the evolution UI design from the early days of text only functional apps to a not so distant future where people define themselves by the software they use (as with products) and software can personalized, and assembled for use by individuals.

The second model comes at this idea from a slightly different angle, communicating the relative priority of UX . This model is a variant of Maslow’s Hierarchy of Needs, tailored for UX, with six levels ranging from useful/functional up to meaningful (the highest level a product can achieve)

In various conversations and presentations, I have found early drafts of the models to be invaluable tools for identifying where exactly a product is in its maturity, and where it should go next. This has also been useful to illustrate that while many of the new ‘Web 2.0’ application are succeeding at creating emotional experiences, Enterprise software is still struggling with usability issues.

Tuesday November 21, 2006 / 7 Comments

I’ve spent the last several weeks preparing for and presenting my thoughts on pleasurable interfaces – first at Refresh Dallas and then at the Refresh06 conference in Florida.

A special thanks to everyone who made it out to either of these events. As was probably evident, this is a topic I’m somewhat passionate about. And, as is true of any subject dealing with emotions, beauty or pleasure, this is a rich and somewhat subjective discussion.

My User Experience Hierarchy of Needs model forms the skeleton of my presentation. Think of it as ‘Maslow’s Hierarchy of Needs’ except for interfaces.

The slides for the ‘Creating Pleasurable Interfaces’ (12M pdf file… right click and ‘save as…’) go along with the one pager, offering practical examples of what the model describes.

What I’ve tried to do here is bridge a lot of really fascinating academic ideas with practical examples or application ideas. The model is something I’ve created to make sense of the conversations and ideas already in existence. I’m planning to post more on this—and some of the specific slides—as time permits.

Until then… Enjoy!

Sunday August 13, 2006

A few of us at Geniant have been working on a career growth plan. This is for the User Experience Design (or “Enterprise Gateway”) practice, and should not only benefit individuals (“how do I get to the next payband?”) but also lend some structure to a pretty diverse range of skills and disciplines.

Had we not merged with Geniant, this formality might have emerged (to some extent) from the company culture, the type of projects sold or pursued, and the natural growth curve along which a company matures. However by pushing the fast forward button on our company, it’s been necessary to take a more proactive role in defining this internal structure. One, because we’re plying our trade in a different arena – enterprise service offerings. And two, because we have to figure how our expertise complements or integrates with existing focus areas we didn’t spend a lot of time pursuing – portal configurations for example.

Specific things we wanted this framework to define are:

• what types of people we want to hire

• what skills we value

• what skills we lack (for both the work we are doing and what we want to do)

• what types of growth opportunities there are within the company (for new and legacy employees)

• how this practice and different roles within this practice work together

• and so on…

That, and we needed some hiring structure in place to insure we’re hiring the right people for long term growth (and not just staffing short term needs).

The Presentation:
You can jump into where we’ve arrived, here:

…or continue reading below about some of the challenges we’ve faced, other models we tried that didn’t work, and what is revealed by framing our practice this way.

Challenges we’re facing:

• Technology for Geniant includes both web based apps and desktop based applications (e.g. WinForms). Having focused primarily on web-based applications at Bright Corner, we’ve had to rethink what skills are expected from a Front-End Developer. A really good—and valuable—WinForms developer may know very little about DOM Scripting or valid markup, for example.

• Along those same lines, we’ve wrestled with how to value people who are prized for the expertise in a specific Enterprise technology package or platform, but know very about things like semantic markup or valid CSS. How do you compare a Front-End Architect to someone who knows a package really well? They’re both making the UI a reality from a programmatic perspective, but it’s comparing apples and oranges. There goes a linear growth track.

• Not all IAs are created the same. This is true anywhere, but in our case we’ve had some fairly unique flavors of information architecture, resulting in some different processes and deliverables based on who was delivering on a particular project. Garrett and I are both IAs, but we can approach the same project very differently with very different priorities—and that is a good thing. What we’ve never had is a homogenized brand of IA.

• Not all IAs are created the same (II). While we were rather loose about our definition of “Information Architecture” at Bright Corner, at a larger scale we’ve needed to be more particular (mostly for hiring purposes) about the distinctions between interaction designer and information architect.

• Not all IAs are created the same (III). Defining IA for an organization is further complicated by the fact that no one in the field can actually agree on what IA is. Just when you think you’ve got a handle on it, along comes ‘Cross-Channel IA’ and ‘designing shared information spaces’ (other than just the virtual). Peter Merholz’s closing plenary at the 2006 IA Summit was a great recap of what IA has been and is about. Though I might quibble over the semantics…

• Not all IAs are created the same (IV). Let’s just say, for where Geniant wants to go, we’ve needed to start looking at Enterprise Information Architecture a bit closer…

• Content Sites and Applications are very different, each requiring as different a set of skills.

• Custom Applications and packaged implementations require different sets of skills.

• One of our strengths is the ‘deep generalist’ mindset, where we each have a broad set of very deep skills across many user experience disciplines. So how do we maintain this differentiator, but also support hiring highly specialized employees who do not have a broad set of skills?

• Whether it’s labeled as “Cross-Channel IA” or “Designing for Experiences,” adding these services can be… challenging. For a group that is so wholly focused on interfaces, how do you plug in the design of environmental spaces or processes? More importantly, try explaining to an IT company how these services are a logical extension of the interactions being designed for in the UI.

• We also recognize that younger hires we are able to mentor will probably grow along a different trajectory than that of most senior hires who have grown up inside other organizations. Developing a plan that works for and rewards both types of employees is also important.

Some of the approaches we took:
So, with all those challenges in mind, taking a historical look at the company, assessing present needs, and trying to anticipate the future, here are some of the initial approaches we took to structuring our practice:

“The Baseball Diamond”
This model is based in the idea that we all start with a similar (if not the same) set of skills and as we mature in our careers we move farther out into more specialized directions.

Pros: It was a nice, early start at articulating the ‘deep generalist’ nature of many of our employees; what’s represented here is the idea that if we all share a common base, then we’ll be ably to work more fluently together as we move into our specialized areas (contrast this with traditional organizations where disciplines are very siloed, with little to no understanding of what other people on the team contribute).

Cons: While sharing the same base set of skills was true for many, this is not true for most. Also, what are the specialized skills people move to? Are these proportionate across the board?

“The ‘Slider’ Approach”
Imagine a mixing board. Or an equalizer. Or for those familiar with the user experience tracks in Peter Boersma’s T-model post, imagine each of those tracks as a slider, where you can mix the skill levels of an individual across nine categories, with the goal to be somewhat experienced across most of these disciplines. Something like this:

Pros: Encourages a deep generalist mindset; recognizes a wide mix of skills; easy to assess your talent level across a range of skills, resulting in a quantifiable numeric value.

Cons: Which disciplines get picked? How do you get a fair mix of disciplines that doesn’t favor a design group over say a programming group? Also, this approach flattened and equalized some really disparate skills. And, without introducing some hacks and complexity, this didn’t support dependent disciplines (e.g. IA leads to EIA). Likewise, highly specialized people (who’ve reached the highest level of only one track) weren’t compensated fairly under this model. And again, who decides what the sliders are, and for how long?

“3 Most Popular Titles (with a 4th variable slider)”
Since the roles of Front-End Developer, Information Architect, and Visual Designer are so commonly bandied around—why not just turn these into three tracks, each with its’ own growth levels? And to support the specializations people have (mobile devices for example) add a 4th slider which is unique per individual

Pros: Around the office, these are the only three user experience titles most people recognize; from this the idea of ‘grades’ originated. As you see in our final model, maybe there was something to these 3 tracks…

Cons: Unfortunately, these tracks are grossly disproportional. Also, is a front-end developer the only kind of technology position we recognize? What about usability testing—where would this go? What about visual designers who are now doing UI design? And (rattle off a dozen other focus areas not covered by Visual Designer, Front-End Developer, or Information Architect)...

So…
There were other variations of these models, and other models discussed or proposed. But in the end, the things listed above gave way to…

“The 3×3 Model” (the final)
While the ‘3 tracks’ were way too narrowly defined and not remotely equal in scale, simply relabeling and broadening the focus of these tracks altered things considerably:

• Visual Design becomes Design

• Information Architecture becomes Human Sciences

• Front-End Developer becomes Technology/Development

While this might seem like a slight change, it changes things profoundly. Where before there were specific roles, you now you have focus areas — which could include a number of different roles and span a longer period of time.

Some explanation:

This model supports people from different tracks playing the same role on a project, a very real situation for small and growing companies where multidisciplinary skills are highly valued. In our case it’s common to have designers and developers doing information architecture. This model starts to explain how these disciplines can respond so differently when faced with the same problem. Designers favor elegant solutions. Developers want a system working as intended. And ‘Human Sciences’ people love concepts and mental models. Gross stereotypes, I know. But there is a grain of truth in here.

Coincidentally, as we started exploring these 3 tracks, I started encountering validation from other places. The most striking similarity came from MAYA Design, where they are fond of saying ‘Mayans come in threes,’ referring to the three broad disciplines represented on every project: Designer, Engineer, and Human Sciences specialist. Of course their scope of focus is broader than ours, where design also includes industrial design and engineering is about more than software. But, the idea is sound:

Every project needs…

• someone focused on what can or can’t be done with technology

• someone focused on how people think, feel, and interact

• someone who can create innovative solutions, whatever form that solution takes

While Geniant is not exactly cross-channel focused (yet), we do look beyond just screen interactions. In several instances, our information architecture work has resulted in organizations modifying offline process flows. By abstracting these tracks to the underlying discipline, I also didn’t need to go off and create a second model (outside of this one) for higher-order strategic offerings that moved beyond interface-based interactions. Where earlier models suffered from being entirely user experience focus (limited to screen or interface interactions), this model supports moving off of the screen and into cross-channel experiences or organizational assessments. Example: a simple ‘design’ track can support a “design-minded” person through 10 years of growth – from visual designer to interface/interaction designer to someone managing strategic innovations. Where the roles and duties might change, one thing remains—a person’s motivation for doing their work (even if that actual work produced changes from year to year).

Beyond the tracks, this model presents ‘grades’ – levels of advancement in a position. This was a carried over from an earlier model and stretched to span over 7-10 years of maturation—and several role changes. Where before the three grades represented career growth within a specific role, grades now took on a larger meaning, representing an invidual’s growing awareness of their contribution to the overall organization. Where someone may start off with a narrow focus at the screen level, at the highest levels of maturity that same person may look across multiple applications, technology stacks, and the corporate strategy, to make decisions rooted in a much deeper understanding of the business context.

There are a lot of nuances I’m glossing over here, and a lot that is probably very fuzzy without looking at the visual. So go ahead and download the framework. Let me know what thoughts you have…

Tuesday April 18, 2006

Okay, so here’s an odd thing I’d like to share.

Last week at work, we were having a discussion around “How to Improve our Quarterly Partner Meetings” (yes, the same meeting mentioned in a previous post). While the initial discussion was quite fruitful, it was also all over the map. That being said, several key conversation points did rise to the top, such as…

“What topics should be presented (or not presented)?”

“What kinds of activities could we have?”

“Where else could we meet?”

and so on…

Under normal circumstances, I might be content to list these out as discussion points to structure the next conversation, when more people are involved. But, the relationships between these topics areas merited more than a simple list. That and I’m naturally a visual thinker… And a bit obsessive.

Combine all that and you get a basic concept model for discussing meetings. Or at least a meeting that exhibits the characteristics of the meeting in question.

I haven’t really ‘tested this with anything other than our quarterly partner meetings (which are off-site, have multiple speakers, activities, etc.). But… let me know if this could be useful anywhere else.

Wednesday February 22, 2006 / 8 Comments

I’m excited to announce that I’ll be presenting at the 2006 IA Summit in Vancouver Canada. While it’s not a formal lecture style presentation (maybe next year?), I’m very grateful to have been asked to convert my proposal into a poster presentation (you can view the 2005 presentations here). In hindsight, my model is certainly more suited to this format. And, I’ll have a chance to get feedback from some of the really smart people in the IA community.

So, the topic?

“Sorting, Classifying, and Labeling Experiences”

First, some background that led to this…

From ‘user experiences’ to ‘The Experience Economy’ to ‘designing for experiences,” not to mention “brand experiences,” “customer experience management,” and “experiential marketing”— experiences are definitely the topic du jour. But with so many different perspectives, each with substantial merit, I found myself asking what creates a great experience…?

For example:

• Is an experience defined solely by how easily one accomplishes a task (as with Google or Craig’s List)? Is all else just nonsense?

• What about the “entertainment experience” that Pine and Gilmore describe, when they say we’ve moved beyond a services economy into a new experience economy?

• What about advertising? While companies can no longer rely on image alone to sell products, there is an undeniably powerful role that advertising can—and does—play in affecting our emotions and possibly even our perceptions of a thing.

• Packaging—is it or isn’t it part of the experience Is it even possible to separate the ‘packaging’ from the product when evaluating a person’s satisfaction with a given thing.

• And what of our backgrounds and perceptions. We can have a great product that suffers due to personal issues, such as buyer’s remorse. Or conversely, a merely ‘good’ product where people tolerate faults because of cognitive “confirmation bias”. Or even great products that are generally ill-received due to unfavorable branding.

Intent on resolving these various perspectives, I began exploring how it is that these different elements work together to complement each other. The resulting framework structures all the elements that contribute to a good (or bad!) experience, and provides a context for the various activities (both internal and external to an organization) that play a role in defining a person’s perception of a product or service.

Check it out! Let me know what you think:

Sorting, Classifying, and Labeling Experiences poster (pdf, 3 megs)

One caveat: This IS a poster. A very large poster. So while it is viewable on a monitor, it won’t exactly print very well.

UPDATE: As promised, here is the much smaller, printable version of the ‘Classifying Experiences’ model:

Sorting, Classifying, and Labeling Experiences letter sized (pdf, 450k)

Unlike the poster, this version builds narratively offering a more detailed explanation of the model.