If bringing along business stakeholders for user research is important for persona creation, co-creation exercises are an even more powerful set of tools to gain insight and to build buy-in. Co creation isn’t allowing the end user to design the product. Instead, it’s really a facilitation exercise that allows them to articulate their needs, goals, and desires. Creating a user experience journey map based on user research is a worthwhile effort in itself. But It’s possible to turn the user research into an activity that allows the users to essentially generate the journey map for the researcher through co-creation. Not only does it allow for a lot more to be done in less time/smaller budget, but you end up with a more accurate map in the process.
I’m not going to go into a detailed description or explanation of how to run one of these exercises. I still run into pitfalls and snares with the process from time to time, and perhaps my next post will get into the tactics of co-creating a journey map. But I find the exercise to be pretty amazing for clarifying business processes. Ever since I witnessed it in action, I have put it into place whenever the project requires it.

This exercise can be time consuming, though it doesn’t necessarily have to be. Ideally, you will need half of a day with your business stakeholders and SMEs if you are looking at redesigning a more complex process or series of processes that comprise a user experience. I’ve been able to walk a couple of participants through the process with satisfactory results in an hour, but I don’t recommend this approach unless it’s absolutely necessary and definitely not until you have gotten a couple under your belt.
At the end of the exercise you will have a journeyman that everyone has participated in creating. If you are defining the current state journey, it’s incredible to see how often the resulting map leads to the identification of a step or two in the current business process that can be eliminated almost immediately because it is redundant or otherwise unnecessary. Future state journey maps help everyone communicate what their vision is for the designed experience. Assumptions are made clear and pet projects/notions can begin being dismantled (or supported) immediately.
Back to the original story…

Through the co-creation of journey maps, stakeholders finally saw the screwed up processes they had intuited for so long. All of their assumptions were made visible. Eventually, word spread about the process itself and people within the organization were already imagining other potential uses for the exercise. In a simple visual language they could now point to and show people holding the levers of change exactly where the process could be improved.

The practical and strategic application of UX as a practice had been shown to provide real ROI. The UX team moved beyond being graphic designers in the eyes of their coworkers. UX itself had moved from a concept like “We should be more UX focused as an organization” via a tangible example that demonstrated what UX actually means. Improvement of processes had even demonstrated how UX tools can be applied to broader CX challenges.

UX for enterprise is about incremental wins that lead to cultural change. Having a vision for the end goal while being open to a change of direction is necessary to navigate any corporate landscape. The practice of UX can actually facilitate this.

It wasn’t long before I realized that there was an oversight vacuum on the project. Nobody seemed to be able to point me toward something that looked like an end goal. The best vision anyone seemed to have for what the new experience should be was based on the system they were desperately trying to abandon. There was no big picture available to guide decisions.

The best vision anyone seemed to have for what the new experience should be was based on the system they were desperately trying to abandon.

Most of the product owners were in a mode of simply port data fields and navigation models directly over to the new system without stopping to wonder why the legacy system was built the way that it was in the first place. It’s difficult to place any blame on their shoulders for this. Firstly, understanding and being advocates for the user’s experience isn’t entirely their job (This could be a topic of debate I’m sure). But most importantly, launching a CRM for a large multi-billion dollar organization is no trivial matter and the tight deadlines made the project seem overly ambitious to begin with. It seemed safer to do a port and clean up future iterations.

Yet here was an amazing opportunity to do things right. To make changes for the organization that could lead to significant efficiency gains, better data and tracking mechanisms, and better communication across the organization. They needed a change catalyst. They needed someone to come in and deconstruct the patterns and processes of their organization. They needed to be able to SEE the business processes before they could even understand that, perhaps, there may be a better way to go about things.

User Experience specialists aren’t uniquely equipped to provide product vision, but they usually are well equipped with a toolset that’s valuable to solve a surprising number of organizational challenges. Personas have been widely adopted as a better means to communicate end user behavior and goals than traditional requirements documents. When used well, they provide greater context to the way the product might be used and they help the project team build empathy with their end users.

Similarly, experience journey maps are beginning to replace traditional flow diagrams as a means to visualize process. UML diagrams are powerful, but they’re boring. Furthermore, where UML diagrams do a good job at showing process, they don’t show us where the process is “good” or “bad” form the user’s point of view. Instead of focusing on systems, journey maps show a process or sequence of events through the viewpoint of the humans involved. For those unfamiliar with journey maps, this UX Magazine article should provide a good introduction.

The teams were accustomed to seeing personas. It became clear that some of the teams hadn’t seen the personas for a while, so we refreshed and began recirculating them mostly in an effort to remind everyone that a good user experience matters. Personas don’t provide a lot of insight to processes though and the teams hadn’t seen a UX journey map yet.

It always seems that user research deliverables gain a lot more traction within an organization when there’s quite a bit of exposure to the research process itself. In persona creation, this often includes creating advocates and champions of the personas within the organization by bringing along business partners and product managers during user research. Most of the time you’ll have another user advocate in the room as the research observer recounts what they witnessed during research.

Continued in part 3.

Enterprise software is an exciting place to be for those of us involved in user experience. There is a sea change happening as users demand more from software. Many argue that exposure to well designed applications through new models of distribution, primarily via mobile devices, have paved the way for these changes. The ROI of good UX has become patently clear (pun intended) in the consumer space, and it seems that more and more organizations are realizing that it is also a good investment even when internal users have little choice in the software they must use. Good UX in software increases employee retention, decreases training time, and allows employees to concentrate and spend more time on their primary role which is probably never “systems user.”

The Enterprise 2.0 Conference is another example of this sea change. Each year, the conference topics show us that the focus within enterprise is finally shifting from systems and technology to people. The “humans” in human-computer interaction are the dominant catalysts for evolution in this sector. Sure, emergent devices are changing the way those humans engage, but industry visionaries in almost every vertical realize that technology will only take them so far. We are quickly approaching feature saturation. We’re probably already there.

But UX isn’t a magic pill either. All too often I see and hear about other examples where companies hire a UX practitioner or even try to build a UX team in what amounts to be another attempt at dominance mimicry. Most organizations want the unprecedented success that Apple has had and hope that they can achieve this by becoming more focused on UX. The truth of the matter is that most organizations simply aren’t ready to make the kind of changes necessary to reap the kind of benefits that an internal ux practice can achieve. Still, with careful execution, an internal UX team can begin to win the hearts and minds of an organization. It just takes time, patience, and some experience navigating the politics that are always present within the enterprise.

The truth of the matter is that most organizations simply aren’t ready to make the kind of changes necessary to reap the kind of benefits that an internal ux practice can achieve.

Over the next several weeks, I will tell the story of a recent experience within an enterprise as they pushed through a major transition in software. Most of the story will sound familiar to anyone who has been through the process. Hopefully there will be an insight or two that I can pass on. It would be even better if this generates discussion for more effective approaches than the ones I talk about. I hope you get something out of it, even if it’s just validation for what you are doing right now.

So here we go. Part 1…

I recently had the pleasure of working on a very large enterprise engagement focused on launching and integrating a new CRM platform for sales associates and support teams. As usual, there were multiple channels distributed across several business divisions that all had unique and specific requirements and business processes. In most ways this was a classic enterprise software development effort. And by that, I mean a fairly massive cluster **ck.

Much of the work focused on getting the new platform to a point of parity with the old Siebel based system that the sales and support teams were already familiar with. Some solid user research had already been conducted by one of the UX team members and several personas were established. Persona behaviors, needs, and goals were differentiated by the roles that individuals played within the organization, and these seemed to correspond to business titles more frequently than not.

Persona behaviors, needs, and goals were differentiated by the roles that individuals played within the organization, and these seemed to correspond to business titles more frequently than not.

There were four development teams and four product owners in charge of various sections of the platform or with additional software integration. There were two UX designers supporting those teams as well. So plenty of people were involved. Someone could argue that there were too many people to be really productive or at least efficient, and they would probably be correct.

The great news was that the developers were a part of some of the most highly functioning AGILE teams I’ve come across yet. They helped write solid stories and use cases. Scrums were efficient and the reviews at the end of each sprint demonstrated serious forward momentum. They totally knew what they were doing.

After coming onboard, I noticed something during the first review that seemed like a simple fix. Since two of the development teams were focused on two different business channels, there was a tremendous amount of overlap in terms of labeling and functionality in the interface, but the layout was strikingly different across these two channels. The terminology between the channels was similar enough that it seemed to me that they should pretty much be the same thing. I made some notes and talked with my teams and it seemed like things would be tidily cleaned up in a sprint or two at the most.

I started poking around the QA sandboxes and I realized that beneath that veneer was something actually troubling. Massive lists in drop down menus with options that weren’t obviously mutually exclusive seemed to be the rule rather than the exception. My gut told me that some of the workflows were suspect. They seemed unnecessarily difficult with multiple points of access yielding very different experiences. This was going to be a little more difficult than what I originally thought. Good. This was how I would demonstrate value…

Continued in Part 2.

I’ve been chosen as a finalist to speak at the SXSW Interactive conference and event. I still need to make it through a couple more rounds before it’s decided wether or not I get to go.

Vote for my topic on the 2011 SXSW Panel Picker

It’s a cultural phenomenon that most of us didn’t see coming: baby boomers are taking over Facebook, while the millenials are abandoning it like crazy because it is so last year. After all, what 20-something wants his mom to see his status update about last night’s party? This example signifies a trend in technology overall: the assumed late adopters are now joining early adopters as technology becomes increasingly easy and fun to use. Devices such as the Wii and the iPad have overwhelmingly been adopted by the older and less technologically savvy crowd. The trend has significant design implications. As we’re designing for emergent devices, we need to be very aware that we’re definitely not designing for ourselves. User research will become even more critical, with particular attention paid to the more mature crowd as they have different needs from other generations. Security, privacy and ease of use are key attributes for this audience that we may have overlooked, thinking we were designing for younger users. During this session, I’ll discuss specific case studies of companies that saw the benefits of conducting the necessary user research to understand the needs, goals and motivations of the boomer crowd as well as specific design techniques that appeal to a more mature audience. In addition, he’ll also explore whether there is one, common design language that speaks to the needs of multiple generations.

This is the app I’ve been waiting for a device to run.

Most of the work I do is at a whiteboard or with paper and pencil. I throw ideas out there and see if they stick. When I get something I like, I usually end up taking a grainy photo with my phone to send it off somewhere for feedback. I’ve always wanted something that will essentially let me do this low-fi approach to design directly into a digital format. Easier to keep, easier to share, easier to modify, easier to iterate upon.

Some of the folks at EffectiveUI showed me some early concept sketches of this app and I started getting excited about the possibilities. Now that I’m seeing it fleshed out, I’m thinking the iPad might be looking a lot more attractive again.

Check it out: http://www.ideateapp.com/

This subject seems to be the topic of conversation here at EUI over the last couple of days. Ther have been a few articles floating around.

Leah Culver, web designer, developer, and entrepreneur likes Amazon’s sign-up/login all-in-one approach and riffs on it a bit. Though the comments both on the blog and here at EUI seem to suggest that the Amazon approach is a little jarring. Several folks wonder if we are at the point where the system can decide wether or not you are a returning or new user and take the appropriate course of action automagically.

Luke Wroblewski takes a look at the Mad Libs approach. If you remember, Mad Libs created narratives where the reader could fill in the blank. So the approach is a narrative one. They did some A/B testing that suggests that this approach increased traffic 25-40%.

But the science bums me out just a little. He throws this statement out there:

“While it’s possible these adjustments also contributed to the increase, it’s unlikely they were solely responsible for it.”

Well, they have reduced the number of visible fields from 9 (A) to 6 (B), and the white space created by those fields has been cut by about two thirds. That alone might be solely responsible for the increased adoption. What if you took format A and simply reduced the fields without adding all the narrative text in format B? would there be an even larger increase?

I really think it’s about the impression/perception of how much info I’ll need to provide. Version B reduces the cognitive overhead and perception of work in terms of space comprised of form fields, but increases it again even more than A by forcing me to read. I’d love to see them run better tests on this. Still, great work and a 25-40% increase is pretty awesome.

Juan Sanchez just turned me on to a recent TED video where Blaise Aguera y Arcas demos some outrageously thought provoking video of Bing Maps, Seadragon, and Photosynth integration. This is a really excellent example of digital convergence.

The video gets extra special cool when, in real time, there is somebody creating an augmented reality experience where they are taking video at street level and it is being perfectly superimposed over the on-screen view of the “map”.

There was an Alternate Reality Game a while back that had photographs of locations that were supposed to be from the future. Most of the photos showed little change, but a few of them foreshadowed some major events to come. I feel like I’ve just looked at one of those photos.

When we meet new clients and begin discussing the goals of the software project, there’s often a bit of education that has to take place. A frequent mistake that I see is when people confuse usability and user experience. It’s an easy mistake, but there are important distinctions that effect the design.

From their book “Interaction Design”, Preece, Rogers, and Sharp define Usability as being a multifaceted concept. Usability goals can be memorability, learnability, efficiency, safety, utility, or a combination of those. Some of those goals might even conflict somewhat. Some of the old command prompt interfaces are extremely efficient and very usable for expert users, but are almost totally unusable by new users who need the application to be more learnable.

They go on to define a separate set of experience goals that include satisfying, enjoyable, fun, entertaining, helpful, motivating, aesthetically pleasing, and supportive of creativity. These are a little bit more difficult to measure; they are subjective in nature. These describe how the user connects with the product at an emotional level.

How about the example of Mr. Usability himself Jakob Nielsen’s website? I know that he’s an easy target, but it takes only one look at his site useit.com to clearly understand that it is very usable, but the experience totally sucks. People CAN use it, but few WANT to. There is little difference between Nielsen’s site and the very first public HTML sites. Even though user expectations and desires have evolved, his site hasn’t.

So usability is not user experience. It is as important, maybe even more important than experience, but if you ignore the experience and focus solely on usability you might end up with something that nobody WANTS to use. At the first opportunity of a real alternative with a good experience, people will abandon the usable but unsatisfying, laborious, boring, unhelpful, demotivating, ugly, and/or non-creative experience for the better one.

Elements that create solid usability are easier to imitate without screaming rip to most people. A lot of usability is predicated on existing patterns. It’s user experience that needs more attention in order to differentiate your product.

Update: another example of a bad, yet usable experience coming out of the Usability field: Usability Professional Organization. Do usability experts hate visual design? They must!

One of the things I’ve been very happy about in newer web interfaces is that I don’t have to use a “Save” button. Google docs and GMail are good examples of these. The system backs up the changes I make while I’m making them – or at least frequently enough that I don’t feel compelled to use the save button. I like this a lot. It frees me from worry and from an additional step. Apple has also been using this for a while in system settings. You make a change to your system preferences and those changes are simply made. No saving involved. You aren’t doing anything that can’t be undone, so why worry about the additional step?

That’s why I was really surprised when I went to change my connected sites in Google Buzz and, completely ignoring the save button (like banner ad blindness, I guess I’ve become blind to save buttons as well?) I got an alert that prompted me to either lose the changes I made or go back to the previous screen and hit the save button. WHAT?

The changes I’m making here are simple and certainly aren’t permanent. The task is simply moving a finite number of items from one bucket (not connected) to another (connected). And rather than closing the dialog after making changes, I am forced to use the save button.

It’s really strange for Google, being outside of their general UI metaphor, and kind of a backward step in online applications.

Go back! In time.

Armando Roggio interviewed me about the book on ECommerce Developer. The audio cuts out because I’m pacing back and forth while speaking on the phone and evidently there’s a dead spot in the office. Still, the interview went well and Armando was very gracious. Check it out for some further discussion about topics in the book.