Adaptive Path Blog

Once, I only had ONE thing to do…not the onslaught I face in a typical day, but a single, solitary thing to wrap my brain around for an entire week.

I was attending a one-week video art residency at Arts Electronic. I had a cozy place to sleep, a private workspace with equipment, and someone nearby for help when needed. Because all of my basic needs were taken care of, I was able to surmount an unfathomable number of technical tasks in a short period of time. The result was draft one of a documentary. Prior to that week, I had never opened an editing program.

This experience of intense creative productivity is the basis for my project management style today. As an artist myself, I understand firsthand the importance of developing a nurturing environment in which to create. Keeping this in mind, when I start a new project with a team, I do a few simple things to enable the same singular focus and heightened productivity that I experienced at the residency:

Keep it simple
Part of my job is to take care of the team’s basic needs, so they can focus on creating. Practitioners don’t need to be thinking about meetings, finances, client relations, or buying supplies and tools. If they are, the creative process isn’t getting that attention and the work suffers. At Adaptive Path, we also limit practitioners to one project at a time so that their focus is not split in multiple directions.

Make the physical workspace inspirational
The team needs to feel good enough in their physical workspace to spend hours there brainstorming and making. Grey cubicles and blank walls kill creativity. At our company, each team has a dedicated room for their project. I make sure those rooms are filled with the tools needed to create. The walls are then quickly covered with drawings, doodles and illustrations.

Take care of the team
The director of the Arts Electronic residency, Annie Langan, was like my guardian angel. She cared immensely about my experience and took care of my needs before I was even aware of them. My goal as a project manager is to be that guardian angel. I pay close attention to the health, mental wellbeing, and dynamic within my team. Sometimes practitioners get so deeply entrenched in their work, they need to be reminded to take care of themselves. To produce dynamic projects, their brains, bodies and spirits need to be nourished, not exhausted. When team members feel cared about, they also become more deeply invested in the success of the project.

There are, of course, many other aspects like budgeting, scheduling, and client relations that make project managers successful. But when project managers also develop an environment that encourages focused creativity within their team, they set the foundation for exceptional ideas. At the core of projects is the work itself and, most importantly, the people that create it; foster those two things and you have the recipe for a dynamic project worth talking about.

For a recent project, we analyzed strategies used by sites that thrive on user engagement to encourage people to sign up and get established. We presented our findings, including design and usage guidelines, in this visually-rich report. I’m excited to be able to share it with you, for reference and inspiration!

You can enjoy the preview below (click it for larger version) and download the full report here (FREE to Newsletter subscribers).

Alexa, Teresa and I recently finished a project that, from the beginning, had all the signs of trouble: a busy client team working weekends on other projects, an aggressive schedule, a tight budget and my own pre-planned vacation during the critical architecture phase. While this project had a lot of challenges, and was quite intense at times, we had fun and came up with some really well executed designs that we all love. The project ended with a very satisfied client team, too.

I was happily surprised when our client made a point of commending my team for our client management skills. At first I politely tried to diminish our part in making it such a great experience “Well you’re a great client!” and “That’s why you hire outside consultants!”, but he pursued his point by illustrating how his other vendors’ relationships hadn’t been handled the same way and more importantly, what we did right. His feedback seemed worth sharing; here’s a bit of a summary:

1. We rethought the design problem rather than simply executing their requirements. We took their ideas and vision into consideration and then took a step back and rethought the problem. The result was a refreshing and unexpected approach that they liked much better than their own initial ideas.
2. We scoped the project according to the budget and timeline allowed. The client needed a lot of work done in a short amount of time. So much work that there was no way it could all be done in the time allotted. The approach we took was to work closely with the client engineers and UX team to reveal only the essential design elements needed. We delivered only primary screens, a few key scenarios and prototyped interactions that needed more clarification. We also delivered design principles to enable the client team to stay focused on what’s important once we’re no longer there. What we didn’t do, which they appreciated, was deliver a big, fat document of every permutation possible. Instead we delivered high-level design guidelines.

The Team’s Approach — There were a number of client relations techniques we used in making the project a success. Here are just a few:

Trust — We kept our eye on building and maintaining trust with the client throughout the project. We did this initially with a full day hands-on workshop that included key members from the Product Management, Engineering and UX teams. This built rapport, inclusion and unified our vision of the product and our goals for the project. We maintained the trust through frequent review periods and showing our thinking along the way (even half-baked ideas were shared).

Listening — We listened to the client’s ideas and vision, but didn’t limit our designs to how they thought that vision should be executed. We took their vision and added in our understanding of user needs, consumer behavior and context of use as the launching point for our designs.

Setting Expectations — We had an extremely aggressive schedule for this project. We set a schedule with reviews and milestone deliverables, but we communicated heavily on the idea that “things may change” and we would “see what we can get done by x date”. This prepared the client for when we delivered sketches and rough ideas instead of polished designs.

Flexibility — When the client called and asked for a redesign a few days before our last big deliverable, I didn’t let it phase me. I welcomed his need to get the designs right. I didn’t even mention the impact to the schedule/scope, I focused on simply listening to his needs. What was missing in the current designs? We immediately set a face-to-face meeting with the client and his Director to better understand their concerns. It was a hands-on design session, where we sketched through ideas on the markerboard. After that meeting, we talked about schedule impact. The question I asked was if we could slip the schedule and if not, where would we need to cut scope?

Under-promise, Over-deliver — This is a technique I try to employ with all of my projects if I can. Of course my clients reading this will now know, but hopefully they won’t hold it against me! I try to scope a project that is realistic in what my team is capable of in the time allotted, but I pad in a little time for unplanned client meetings, idea gestation periods, wait time and general unknowns. In most cases, that padding time gets used up by unforeseen circumstances, but that’s OK because we don’t go over the budget or beyond the schedule. Sometimes there are extra hours to which I try to over deliver: more screens, more scenarios, more concepts, more interaction explorations, more annotations - what ever might be needed to wow the client.

Since the schedule was so aggressive with this project, I was honest with the client and explained that I wasn’t sure how much we could deliver, but I promised a minimum amount (which was safely low). Not surprisingly, he figured out this technique mid-project and luckily he saw the value in it and we had a good laugh about it. He appreciated how flexible we were throughout the project and the only reason we were able to be so flexible was because of the extra hours I had included.

Desire for Success — Philosophically we all have to remember that everyone involved in a project truly has the best interest of the project at hand. They may not be approaching the project in the way we’d like, or they may have bad ideas, but their intentions are for a successful project. Rarely do clients or colleagues knowingly and willfully undermine a project. We need to always remember that their intentions are good.

Last but certainly not least is in how to be a good client. Dan Saffer composed a great essay on how to be a good client, but I thought I’d share a few specific traits our client possessed that enabled us to take the approach we did. These traits allowed us to deliver the best possible designs:

1. We had a client who set a vision and was open to the possibilities of where that vision might be taken.
2. The client gave us access to all the right people. Their program manager did an astounding job of getting the right people in the room with us each and every time.
3. They also had a system for decisions by proxy. If a decision maker was unable to attend, they identified a proxy who would speak on the behalf of the decision maker.
4. The UX, Engineering, and Product Management teams all have a deep respect and regard for one another. Yes they disagreed (lots of heated debates!), but they did so respectfully and with humor.
5. They leveraged our time together as efficiently as possible. Issues that didn’t pertain directly to our design problem were tabled for later discussions (without us).

In the newest issue of Interactions magazine, Steve Portigal laments the use of personas. His point essentially is that personas “invite misuse” and therefore they should be avoided. Peter has responded, pointing out that Steve has thrown a baby or two out with the bath water by conflating personas with poorly conceived personas. To some degree it becomes a war of analogies, with Steve saying personas are like guns (i.e. inviting misuse and dire consequences) and Peter saying they are like movies (i.e. just because most are bad doesn’t mean that we should dismiss the activity of movie-making).

But neither of them addresses the underlying issue that is at the heart of all this fear and loathing, use and misuse. The power and danger of personas is their realism. Good personas use this realism to drive authentic understanding deep into the heart of an organization. As humans, we are highly attuned to observing, interpreting, and relating to other people. Good personas take advantage of this tendency and focus it on “people” that are highly relevant to a design, business, or engineering task. I have seen this have profound positive effects on organizations.

The issue is that personas are not real. They are realistic but, in the end, fictional. Knowing Steve, I can say that he is very uncomfortable with that element of fiction because of how it can affect the people creating and using personas. When handled poorly, organizations can begin (or continue) to talk about real people as characters or stereotypes. And that, as he would probably say, “freaks him out.” As it should. We all hate to see organizations misunderstanding the people they are trying to serve.

But does this potential really outweigh the benefits? In my experience, personas have always improved an organizations understanding of their customers because, if nothing else, they become a tangible and explicit artifact for focusing and catalyzing discussion about customers. While this may not always be inspiring, it moves things forward. Incremental change is better than no change at all.

Of course, Steve’s essay also raises an important question, what is the alternative to personas? (Peter makes this same point.) If we agree that qualitative, contextual, and in-depth research is important and necessary, how do we capture and communicate the things we learn in the field beyond giving people a mountain of raw video and audio to go through for themselves? (Assuming that video and audio actually substitutes for being in the field…). Steve says that we should “tell stories.” But every story told is an approximation. Details are left out or reordered to support a larger theme or message. This is true in journalism as much as in romance or sci-fi. In the same way, some level of fiction is necessary when it comes to personas. Personas are meant to represent archetypical customers or users of a product or service. Representing archetypes requires a certain level of aggregation and synthesis.

In my whole career, I have seen few things that inspire strong reactions like personas. Enthusiasm & excitement as well as fear and loathing. So, I can’t fault Steve for his strong reaction. Personas blur the line between truth and fiction, which can be disconcerting. But this all highlights the fact that personas are more a medium of communication than a tool. So, Steve’s gun analogy isn’t really appropriate. Peter’s movie analogy is better. Or consider painting, which actually had/has a movement called Realism. I think it’s a mistake to throw out the idea of painting or of Realism just because someone’s first attempt looks more like a toddler’s scrawl than a Rembrandt.

P.S. Congrats to Steve for such a provocative first column!

Leah and I have been piloting some new approaches to get around some of our frustrations with the limitations of wireframes:

• they can focus time and attention on all the wrong details and activities
• they constrain creativity
• they split up designers and teams to work alone

We call our approach “sketchboards,” a technique that allows designers and teams to explore and evaluate a range of concepts, getting to better UX solutions faster. We’ve found that this approach:

• allows us to iterate faster towards more creative solutions
• better supports the design of flows and highly interactive experiences
• incorporates the input of the entire team; our clients and partners love it
• defines what we need to document in wireframes, or just skip ahead and begin prototyping

The video below takes you quickly through the sketchboard technique, but be sure to read the essay that contains more details, templates, and examples.

Leah and I will be sharing this as an agile-friendly approach in a workshop titled “Good Design Faster” at UXWeek 2008. Come join us!

I was cleaning out my desk (= hard drive) this week and found a research artifact we created for the Charmr project that was never fleshed out in time for the release. So I took some time to touch it up.

Before proceeding, keep in mind that:

• Diabetics’ motivation ebbs over time because diabetes is incurable.

The diagram tells a story of different people that we interviewed. The widening/splitting of the line represents different groups of people going their separate ways (so to speak).

The visual style was inspired by C.J. Minard’s Napoleon’s march map.

Last weekend at the Dwell on Design conference I had a minor revelation when I passed by a collection of sample boards and wondered to myself, why don’t we make deliverables like that?

For those of you who aren’t frustrated DIY decorator types like me, sample boards are used in interior design to convey the general feeling of a space while showing proposed materials, colors, finishes, furniture, etc. They’re a bit like mood boards, except that instead of a general visual design direction, sample boards focus on the real thing - real materials, real layout. Imagine a big poster board covered with floor plans and fabric samples and little tile cutaways and sketches and product images - basically a gestalt of structure, texture, feeling, and visual richness.

There are a lot of deliverables that interior design and experience design do have in common, but as far as I know, there is no equivalent for this type of holistic view in the work that we do. This is a real shortcoming.

At Adaptive Path we talk a lot about how to communicate the feeling and, well, experience in experience design. And yet our deliverables are often focused on very specific aspects of a project - a site architecture, a set of wireframes, a content inventory. These are surely all important things, but rather narrow in purpose. This often puts a burden on our clients to do some mental synthesis to imagine the resulting experience. Sometimes they get it, sometimes they don’t.

Perhaps we could alleviate some of this burden with a sample-board-like deliverable (experience boards, anyone?) that blends structure, design principles, core behaviors, characteristic interactions, and even, maybe, a little bit of feeling. Preferably involving poster board.

I actually think Adaptive Path’s recent movie for Charmr is a good example of a deliverable that brings together feeling, specifications, and experience, but movies like this take some effort to put together. Are there simpler ways to accomplish the same thing with less overhead? Is anybody out there producing deliverables that communicate the gestalt? If so, please share.

A thread on an internal mailing list addressing non-standard interaction design methods lead to a discussion of video prototypes. Some of our favorite examples:

ThingM’s technology sketch for a wine rack.

Sun’s Starfire video, produced by Bruce Tognazzini.

Apple’s Knowledge Navigator.

Philip’s Vision of The Future films.

And perhaps my personal favorite, Design for Dreaming, which involves a ballerina prancing around a kitchen… from the future!

For the longest time, I was skeptical of the value of personas in the user-centered design process. They felt too narrow, too constricted, too idiosyncratic for me to design for.

That’s changed of late. User research is primarily about empathy — getting designers and developers to have empathy for their users, and be able to deliver products and services that really appreciate the users’ needs and goals. And personas are perhaps the best tool in the user-centered design toolbox for communicating empathy — they feel like real people with real concerns, and when crafted well, can transfer insights realized through research to other members of the project team.

Because, for me, personas are all about empathy, I get riled up when I see persona deliverables that diminish the reader’s capacity for empathy. And perhaps the most pernicious element that I keep seeing cropping up in personas is the “user type.”

Here’s a persona chart developed for Kivio, a diagramming tool similar to Visio. (I found it here.) There are many qualities I appreciate about this chart, such as just enough information to understand who these folks are (more detail if you click the link), specific characteristics about how they would engage with this product, good images to help us believe in these as individuals. All of these are great at creating empathy for them, and helping designers better understand how to serve them.

But there’s one thing that keeps them at arm’s length: “The researcher,” “The Sysadmin,” “The OSS Developer,” “The CS Student.” It is common practice for personas to be given these kinds of user type labels but that practice diminishes our ability to empathize.

It might seem like a small thing, but the moment these folks are typed they become members of a class, and their identities are now of being in those groups — and you start referring to that persona as “the Sysadmin” and not “Donald.” It doesn’t take much to go from typing to stereotyping–”Sysadmins want these kinds of features”–and once that happens, empathy is lost.

THIS is our baby.

Originally uploaded by b-may.

Hank Mason, newborn son of AP COO Bryan Mason and Maggie Mason, Mighty Girl and sometime AP Copywriter. Born today! Mazeltov to all!