Adaptive Path Blog

Leisa Reichelt
For a long time, she had a traditional approach to product management. Discovery, documentation, functional specifications, sign off, and then go into production. This was a low-risk way of producing projects. It worked fairly well.

But then larger and larger projects, that methodology started to give way and not really work. Came to a fork in the road: another approach. Little changes over time that completely transform over time. The old process can take longer. Not exactly Agile, but similar. More iterative. Agile does have a lot of problems, definitely.

Waterfall = Bad
Scope > Design > Build >Test

Why is it bad? It does bad things to us as designers and to the human brain.

Assumes that you know what you are doing at the very beginning! You know in detail things like schedule, budget, timing, etc. But this isn’t really true. Half of the battle is often understanding the problem.

It also assumes that there comes a point in the process when the design stops. Designers walk away and the developers develop. Again, not true. Still design decisions happening: because of documentation ambiguity, because of technological constraints, because developer “helps out” and “fixes” the design for you.

Waterfall likes people in silos, in boxes. Creates a diminished working environment.

Waterfall doesn’t support the way we solve problems or how the brain works.

Washing Machine = Good
Iterative design. Obviously not a formal methodology. But has characteristics:

Iteration: start by designing, build, take what you’ve done and test with users, take back the design, refine, do it again.

Early and Rapid Release: don’t have to do the whole design process at one go. Break it up into chunks. Public or not, depending on the project. Incremental approach. Helps overcome design fatigue. Compare your first wireframes to your last!

Multi-Disciplinary: involves everybody who is involved in the project. No real stakeholders–everyone is involved (ideally) throughout the entire project. Maintain engagement with the project.

Collaborative: an ongoing engagement with all the different parties.

Involves End Users: real end users! Not just user advocates or usability people.

Agile vs. UCD
Sprints vs. Iterations
User Stories vs. Personas and Scenarios
Pair Design & Programming vs. Contextual Research
Close Proximity Teams vs. User Testing

Agile: weak on end user involvement
UCD: weak on early release and multi-disciplinary collaboration

We need to make Agile more like UCD or UCD more agile! Agile UCD? Can’t just do UCD in the beginning and Agile in development.

Cycle Zero
Happens at the beginning of the project before Agile happens. More upfront research, analysis, and strategy which is existing in UCD but needs to be added to Agile. Need to deliver something that “works” at the end of 2-6 weeks. Deliver: product goals, shared vision, contextual research, personas and scenarios.

But how much design can you do in one cycle? How much testing can you do in a cycle? (cycle=2-4 weeks!)

Mid-Project Cycle
While developers are working in a cycle, designers are involved but also looking to the next cycle.

Pick N’ Mix! Now is not the time for get purist re: methodology!

Share This

Sony has begun some heavy marketing around it’s Sony Reader, a device which reportedly can hold “hundreds of books” for you to “curl up with.” This echoes one of the great insights from Steve Jobs when he first introduced the iPod:

“How many times have you gone on the road with a CD player and said, ‘Oh god, I didn’t bring the CD I wanted to listen to.’ To have your whole music library with you at all times is a quantum leap in listening to music.”

Except that it differs in one respect… I’ve never said, “Oh god, I didn’t bring the Tolstoy I really wanted instead of Harry Potter.” People listen to music over and over and switch and mix it constantly. Books? Not so much.

Share This

Jess McMullin, of nForm, will present Smoothing the Way: Designer as Facilitator on Day 1 of UX Week 2007. I spoke with him to better understand his approach to facilitation.

Peter Merholz: What do you mean when you say The Designer as Facilitator?

Jess McMullin: In our practice, the thing that has become a barrier for us in delivering successful projects is how our clients and the different stakeholders on a project work together. In the last couple years we have focused on saying, “How can we better work with a business in order to understand what they really need and to deliver a successful project?” The things that derail projects are much more around different people having competing priorities, really different understandings of what the project is trying to accomplish, different visions for the project, and a general lack of alignment between decision makers and important internal constituents in the organization. So the session at UX Week is about working with internal teams to overcome that set of competing viewpoints and get people moving in the same direction.

PM: I find this interesting because for a long time I’ve felt that one of the most significant roles of the user experience practitioner is as the facilitator. Oftentimes people think of designers as being the creators, the genius with the spark and the person who comes up with the ideas. But with our design methods, the process is best done by a larger team and the role of the user experience person in that is to facilitate a team working together. My question for you is, why, of all the roles on project teams, has facilitation seemed to locate itself within design or user experience?

JM: The reason that a designer ends up being the facilitator is because all those same skills that we’ve cultivated – in empathy, in listening, in observation, in synthesis, in actually creating tangible artifacts that people can reference and discuss – all of those same skills that we would use in a user-centered perspective, if we pivot 180 degrees and then look at the business and look at the team, we can use that same skill set and many of the same methods to facilitate a consensus and get people talking from their different frames of reference so that they can actually articulate what’s important to them.

PM: Companies hire meeting facilitators to come in and address the issues you’re raising here. What is it that a designer brings to the discussion that is perhaps lacking from the typical meeting facilitation?

JM: A lot of the work that we do as facilitators is using particular design methods to help people communicate For example, a simple tool that we use is sketching; we have people sketch their ideas for what’s going to happen and then to share in the group why they drew what they drew. The point isn’t to actually draw the solution, but to help people articulate what is important to them about the project, and by doing several iterations of that, people come to a greater shared understanding, and that kind of design tool set is I think what sets the designer apart.

PM: How does the idea of tangibility fit within what you’re saying?

JM: When something’s concrete, then people are able to refer to it much easier. Human beings struggle with abstract concepts, and as we take abstract concepts that are ephemeral, like a vision or a mission statement, people struggle cognitively to relate to them. When we start to use concrete artifacts, tangible constructions, such as a sketch, or a fake product box, or a poster, or even press releases and newspaper articles describing some future state, that tangibility gives people something that acts as a shared reference, so that they can actually point to it and say, “Oh, I had this understanding about that.”

PM: So tangibility is important so that people can relate to it from their own personal viewpoint, but you mentioned something else there, too, when addressing the “future state.” What has your experience been with future states and what is important about imagining the future, as opposed to simply describing kind of the current state?

JM: We use a few different tools to think about the future. Some of them are very concrete, like creating the artifacts from the future, and some of them draw on more traditional planning techniques, like scenario planning and back-casting, and the thing that’s really critical about exploring the future and creating tangible instances of what that future might look like, you’re able to navigate towards something that’s much more interesting and much more compelling and innovative for your organization.

PM: What are some of the challenges you’ve faced in trying to help organizations with this kind of future state visioning and how have you kept people on the right path?

JM: There’s a couple important things. One of them is that we talk about outcomes as the core of the future, and we try to map the activities and the product into generating outcomes, and that results-based approach is something that’s valuable in managing future state vision. Also, we don’t look at necessarily just one future state –when we take an approach like scenario planning, we’re actually looking at alternative futures and we’re able to recognize that some activity might take us more towards this set of outcomes versus this set of outcomes.

I think that it’s well worth thinking of future state as a prototype of the future, but it’s definitely not our crystal ball that’s infallible.

PM: Do you have a story of how you’ve used your facilitation tools on a specific project?

JM: We we’re working with a large educational institution, who has a top-down mandate from the executives to do great new things with the web, and they’ve made some key strategic decisions, but there’s certainly not a clear understanding of what the web can do for that client.

They wanted to do great things, and they had great ideas, and they asked if we could help in developing a more concrete vision. In that work, we used two particular tools.

We used what we call experience maps, where we did some research and created a very large – as in put it up on the wall – picture of what a typical student or faculty member’s experience was like. Then we used that as the key focus in a series of workshops with the business about whether this is the right experience, and what kinds of things do you see happening in order to support the right experience in the future.

The other thing we’ve used with them is something called a results chain, where we identified four key success metrics and the outcomes we wanted to generate. Then we worked backwards from those outcomes into the kinds of activities the organization will need to undertake. As we work backwards, we look at the interim outcomes for each of those activities so that you can see how eventually you will get to this final set of outcomes. We’re able to demonstrate the value of the different activities that the web team there will be conducting, not only as a final set of outcomes but the interim benefits to the organization and to end-users, as well. So in working with them, we’re able to have a much clearer articulation of what needs to happen in order to achieve the great goals that they have there.

PM: We’ll end with that. Thanks for your time, and see you in August!

(For more on UX Week 2007, look at the program. Register today (July 13) to receive a discount. Use promotional code BLOG (at any time) for 10% off.)

Share This

I’ve been giving a particular presentation a lot of late, on the importance of an experienced-based approach to the design of products and services. Part of the talk deals with the evolution of product categories, which go through the phases of Technology, Features, and Experience.

So, for example, in 1976 or so, the first VCRs for home use came on the scene, and that was simply a function of a new technology. The technology allowed you to do something you couldn’t do before, and that was enough. It didn’t matter that the first VCRs were bulky, unattractive, and clunky to use — they allowed you to record television shows to be played back at your leisure, and that new capability was enough to make it exciting.

Then, in the 80s and into the 90s, VCRs entered into this features craze. In this middle tier, it’s typical for companies to compete on features, angling to get more bullet points on their product boxes in some demonstration of superiority. Such an approach lead to almost universal frustration with VCRs, and the blinking “12:00″ the icon of unusable home technology.

In this decade, we’ve entered the world of digital video recorders. And, largely thanks to Tivo, we’ve had a shift towards an experiential design. The Tivo’s designers could have simply taken their technological offering and housed it in the old trappings, offering an incremental improvement to the VCR experience. Instead, they realized that they could fundamentally reshape people’s relationship with television, and this experiential approach has given them amazing traction in the marketplace (though not domination, thanks to market forces in the world of premium television).

Now, when I give this talk, I make it a pretty clear and linear progression: Technology, Features, Experience, with the point being that, in this modern world, we can no longer compete or differentiate through features, but must often take an experiential approach.

The nuance that is lost, though, and which I’m exploring here, is that, in the case of Tivo, the experiential opportunity is enabled *because* of a technological shift — in this case, the recording to a digital medium and the delivery of the service on what is essentially a computer.

A similar thing happened in the 1880s with photography. George Eastman invented a new type of film, roll film, which was easier to handle than glass plates. In order to develop a market for this roll film, he invented a camera that housed it. He could have created a camera as complex as the ones that used plates, just smaller, but instead he redefined the photographic experience into one of great ease for the picture-taker, and the camera he created, Kodak, launched an entire new market.

Not every experiential awakening is borne of such technological innovation. Microsoft Office 2007 seems like a direct response to Microsoft’s earlier featuritis, recasting its functionality in a way that makes sense for users. The underlying technology is fundamentally the same — the bulk of the changes came from a reimagining and redesign.

Anyway, I don’t quite know what to make of this. I just wanted to put it out there. I find I can be dismissive of technological advances, but have to acknowledge that such advances are the underpinning of these seismic experience shifts.

Share This

At the end of her talk, Sara Ulius-Sabel asked all of us, “How do we sustainably get to WOW?” Her point being, we can get to developing products that deliver a delightful, transcendent experience occasionally, but often unpredictably. So how can we get there consistently?

Well, I tried to answer it by synthesizing the main themes I heard over the course of the event, and turning it into a couple of sentences. (Main themes are in ALL CAPS):

By achieving EMPATHY we realize an EXPERIENCE STRATEGY that gets us to DESIGN BEYOND PRODUCTS (and maintain focus when MAKING MISTAKES).

This requires SYSTEMS THINKING (which in return requires TEARING DOWN WALLS), that produces TRANSFORMATION for your MATRIXED(?) ADAPTIVE organization.

Commentary on the terms:

Empathy — Both Tim Brown and Todd Wilkens really stressed the importance of empathy in the design process, and how it’s the primary value of your research efforts.

Experience Strategy — Jesse kicked it off with a paean to experience strategy, and we heard it again from Adam Richardson, Caterina Fake, and Tim brown.

Design Beyond Products — Jesse talked about taking design beyond thinking about individual products and considering larger systems and services, which Lou echoed strongly, and was really brought home by Jennie Winhall’s discussion of her work with RED.

Making Mistakes — This was a primary theme from Scott Berkun, whose research on innovation showed that a primary contributor to innovative organizations is a willingness to make mistakes.

Systems thinking — Mentioned in Jesse’s discussion, Jennie Winhall also addressed this in her discussion of designing social services.

Tearing down walls — This was an explicit theme from Todd’s talk on research, where he stressed the importance of getting the entire organization involved in research activities, and the idea of multidisciplinary design teams was mentioned in many of the discussions.

Transformation — One of the more surprising themes that emerged was the discussion of transformation, and the importance of evolving organizations to better take advantage of research and design. Todd’s talk was titled “The Transformative Power of Research,” Jennie talked about transformation design (reinventing organizations to deliver new offerings), and, of course, IDEO has made waves with it’s transformation practice.

Matrixed — One open question was how design and experience groups should be organized within organizations. Should they be centralized, and “matrixed” into product teams, or decentralized, where designers work explicitly for product teams.

Adaptive — Caterina mentioned how her team had to be able transition from making an online social game to a photo sharing website, and Scott commented in his talk the importance of trying things, and if they don’t work, trying other things, and bobbing and weaving and adjusting as necessary.

Share This

Sara Ulius-Sabel

Whirlpool is probably bigger and more complex than you probably realize. We’re now the world’s largest manufacturer of home appliances. It makes us less complacent and more vigilant, knowing other company’s are gunning for us.

Have a huge portfolio of brands and are often competing against ourselves. Forces us to think about product development in a different way. Design locations in six locations around the world. Each region focuses on regional design, but we all have to share best practices and things that have global implications.

It’s not just about being usable. We also need to be useful and desirable. User needs for us have been fairly stable for many years. This made us pretty complacent. Why need to research how people wash their clothes? But we had to shake the organization up and say that there might be something better out there we could be offering.

The sea of white: commoditization of appliances. Starting to erode the paradigms of more features (27 cycles on a washing machine!). Consumers don’t need this.

How we approach usefulness: addressing unmet needs. Getting beyond the washing machine. How do you add utility without adding things like more cycles. We do it through research and ethnography. Environments, rituals, processes. What is missing? What are they doing now that is a strange behavior? We found loads of compensatory behaviors. What we did was make a series of products that are outside the machine and that is about the laundry process experience. Simple products, but a big step for us.

How we approach usability. Historically, usable always followed useful. It’s only recently that the usability team has been able to make recommendations to the engineering team. Lots around ergonomics and ease-of-use. Also taken on perceived quality. You need confidence in the appliance (the whooshing sound when you open the refrigerator door). Not only about can everyone use it, but what is the experience using it. Making sure people feel satisfied.

Help users understand the process. Help people build a mental model of what the machine is doing. People want to know what is available to them and the combinations they can create. Make it seamless and in the background–like it was meant to be there all along. Everyone can benefit from accessible design.

Desirable. Why would anyone lust after a washing machine? It’s not rational. It’s something about the product that makes you feel good. By owning the product you took on the characteristics of the products. Products–appliances!–can be desirable. We should seek this out.

Can desirability be added systematically? Contributed by the features, aesthetics (sigh, tough, smell). Not static–as new competitors and new technology comes on the market, it might not be desirable in the future. Want to make it less a fluke. Which is where my role comes in.

My title is design metrics manager. Metrics are a way to communicate design to the rest of the organization in a way they can understand. We use the metaphor of health: checking the health of products.

Each brand has to be something different for different people. How do you drive people to different products, sometimes on the same platform? The users all need a refrigerator, but which one? We need to find the dimensions that trigger an emotional response. Trying to drive different experiences with different brands. Point of the project is to make someone fall in love with products, not better engineering.

Pressure is about measuring vs. creating. Not only having to convince upper management, but also convince the designers that metrics are ok. Not grading their designs.

Question for everyone: how do we sustainably get to Wow? As the competition comes after us, we have to force ourselves to continue to move forward, where every product is capable of triggering wow.

Q: Can you tell us some of the design metrics?

A: They are proprietary, but they are all user facing. Asking multiple questions that help differentiate the products.

Share This

Adam Richardson, frog design

Ways of dealing with projects where you have to think really far out in the future (3-5 years), but you also have to be designing in the near-term. You have to be in two mindsets simultaneously.

Evolve: incremental innovation (~1 year of competitive advantage)
Expand: 2-5 years of competitive advantage. Growth innovation (into new markets)
Envision: Breakthrough innovations (5+ years)

Usually loads and loads of stuff in the evolving area, very little in envisioning. Most companies want pay-off from innovations within three years.

Four Easy Steps to Manage Schizophrenic Projects
1) Manage the dimensions. Dimensions (”constraints”) are enablers, not hindrances. Avoid designer’s block. Some dimensions are load-bearing (can’t change them), some are more decorative. Hard to tell which is which.

2) Manage the communications. In particular, communication around dimensions. Can’t manage long-term projects with the same metrics as the short-term. Have to manage up and down the chains of command. No surprises. Executives hate surprises. “One last thing…” is for the audience, not key stakeholders. Know what kind of organization you are in: Where does innovation come from: bottom-up or top-down? and How do they make decisions: faith-based or proof-based?

3) Manage the design factory. (read the book by Donald Reinertsen of the same name) Pay attention to the interfaces. Not the UI, but more about if you can break the experience you are designing into chunks, then figure out how information is passed between chunks. Do this early. Manage the queues. Large batch activities (can hold up everything else) vs. small-batch activities. Split up things and make them happen in parallel so that the big-batch stuff doesn’t hold everything up.

4) Deploy the scouts. There is a spectrum of scouts: illustration, prototype, partial market test, full market entry, fast follower. Try out different pieces of the system. Start with the simple, then move to the hard(er). All have different pros and cons. The product itself can be a scout.

Share This

Watch Steve Jobs’ iPhone keynote. Or watch Steve Jobs’ original introduction of iPod. Or read copy on Apple’s site about iMac. What’s missing? Why, English’s most common word.

What does that do for those products? It anthropomorphizes them. As this discussion of Segway demonstrates, anthropomorphization of objects is important to Steve.

Affixing a definite article relegates a device to simple object status. Without it, “iPod,” “iMac,” “iPhone” are not labels, but names, which provides familiarity, strengthening emotional connections between device and its owner.

Share This

Pete Mortenson’s post about Steve Ballmer’s reaction to to iPhone got me thinking about the intersection between user experience, quality and pricing. Ballmer’s negative response focused on pricing and the iPhone’s unsuitability for business customers. The business customer argument doesn’t hold much water, mainly because Apple isn’t targeting the business audience with this product. So much for that argument.

According to BallmerMicrosoft’s “strategy” in this case is pretty clear. Devices that run Windows Mobile like the Motorola Q are “very capable… it’ll do music, it’ll do Internet, it’ll do email, it’ll do instant messaging. So I look at that and I say I like our strategy, I like it a lot.” The only issue with this is that those aren’t strategies, those are features that are easily copied and improved upon.

The criticism of Apple’s iPhone pricing has gotten some traction though. Expensive? Certainly. But taken from the classic, Michael E. Porter perspective, the iPhone’s pricing, and the strategy behind it is dead on.

Here’s why:

Trade-offs are essential to strategy and price/quality is the granddaddy of trade-offs. Quality, in the iPhone’s case, is the phone’s user experience. A touch screen, motion sensors that tilt the display automatically, a fantastic form factor. How these features work together in concert is the difference. Great user experience doesn’t come cheap. It costs money for design, engineering, prototyping and testing, something that we know Apple does compulsively. And in doing so, they create products and software that deliver a great user experience. Apple’s Q1 numbers back that up.

Here we have the CEO of the world’s largest software company calling feature parity a strategy and making the most superficial of price/quality arguments. What Ballmer and much of Microsoft don’t understand, and what is borne out by many of their products, is that there is a legitimate trade-off between cost and user experience. Apple understands that although good user experiences are expensive, they deliver value. That’s why they can charge an arm and a leg for a phone. Consumers understand the value of a good user experience.

Too bad for Microsoft Steve Ballmer doesn’t.

Share This

In design and development, we’ve probably all had someone advocate that the new product/service, “has got to use some of that .” Please fill in with whatever hot new capability or technology you can think of: RSS, social networking, tag clouds — you know the usual suspects.

You often know at a gut level that the trendy addition is superfluous or even disastrous. But it’s always nice to have a few examples in your pocket when mounting your response…

NPR’s recent story on web-based viral marketing for ‘Snakes on a Plane’ versus ‘Borat’ makes a great case for examination. Despite all the hype and YouTube videos prior to ‘Snakes on a Plane’ (SoAP), the movie did no better than any other B-rated movie at the box office. The problem? The yuk-yuk fun that people were having with the concept of the movie had little to do with the actual content and genre of the movie. The experience of the buzz had nothing to do with the experience of the movie, and the people participating in the buzz weren’t the target market for the actual movie.

What should we learn from SoAP? Don’t engage in activities that don’t fit your core strategy and expect it to pay off. The marketers of SoAP executed perfectly on an (un?)anticipated opportunity for buzz marketing, but SoAP still fizzled at the box office.

In contrast the NPR piece points out that the Borat buzz might pay off because it’s all about yuk-yuk humor so the buzz might be tapping into the core target audience. Another example of effective buzz would be Blair Witch’s idea to, “use the Internet and suggest that the film was a real event” [The Blair Witch Project, Wikipedia]. The buzz fit the experience of the film and fit the target market.

So let’s hope Borat makes a good showing at the box office, so we can have another example of appropriate vs. inappropriate uses of trendy tactics.

Share This