Looking Forward and Back

Written by: Erin Malone

“I resolve to spend less time worrying about educating people about what I do, and more time doing what I do—designing websites people can use.”

—Brenda Janish

Reflections on 2003 and resolutions for 2004

Looking back

This time last year, Boxes and Arrows published a few predictions. We promised that at the end of 2003 we would take a look back and see how insightful these predictions were. As expected, many of these predictions were ahead of their time and I expect that it may a couple more years before these come to pass.

Here are a few of those predictions and their outcome:

Dan Brown predicted:

The number of books specifically on information architecture (a la Polar Bear and Blueprints, et al) will double.

B&A: Well, they didn’t exactly double. An Amazon search reveals 14 books with Information Architecture as a phrase in the title with only four coming out in 2003. On the other hand, we know that many usability, information design and design books that are relevant also came out in 2003 so collectively there are a lot of good resources available.

There will be at least one course on information architecture in every major university in the world.

B&A: Mmm, how to check this one out. There are a lot of new courses in IA showing up in universities around the world. However, finding consistency in curriculum or even in the type of department offering the class, cerificate, degree is hit or miss at best. We still have some work to do here.

Earl Morrough predicted:

I predict that in 2003 the subject of the emerging profession of information architecture will be picked up and reported on by at least one of the major television news networks. The report will include clips from an interview with either Christina Wodtke, Peter Morville, or Louis Rosenfeld.

B&A: Well, maybe this year.

Jeff Lash predicted:

2003 will be the year of wireless. Wireless networks in homes, businesses, and public and common spaces will be increasingly popular, and cheaper service plans for mobile phones and PDAs will drive the development of usable and useful wireless-based applications.

B&A: Close. We are getting there. I think 2004 will actually see the cheaper prices and free common spaces. Where folks dabbled in 2003, 2004 will see wireless become commonplace.

Christina Wodtke predicted:

“Findability” will begin to be part of the business vocabulary along with “usability” and “understandability,” but not until the end of 2003, where it will be mentioned in a magazine such as CIO or Fast Company.

B&A: Well, I couldn’t find, findability mentioned anywhere except here and Peter Morville’s site. But CIO has a couple of articles, from the latter half of the year, about using audience to drive website design. Sounds like UCD to me.

And Dan Saffer successfully predicted:

Several IAs will get drunk in Portland.

B&A: I think he hit the nail on the head there. Any predictions for Austin?

Here are the rest of last year’s predictions. Boxes and Arrows invites you to add more of your own and comment on the success or failure of these to come to pass.

Looking forward

To ring in the new year Boxes and Arrows asked our staff and members of the IA, UX, and Design community to share some of their professional resolutions. We have seen this community grow, fracture, and come together as we all share common goals. And I think our collective resolutions reflect our continued growth and search for excellence in our work.

Brenda Janish:

I resolve to spend less time worrying about educating people about what I do, and more time DOING what I do—designing websites people can use. And—if I’m lucky—designing websites that contribute to the general good.

Liz Danzico:

Whether inside or outside of work, I’ve fallen into an accidental pattern of using certain tools to avoid voice communication. I communicate with colleagues in the next cube via email. I keep up with family members through instant messenger. I have to depend on friends’ blogs to know where they are.

As an information architect, my job is to communicate ideas. Whether the communication takes place between my client and me or between my team and an outside vendor, how I communicate those ideas is important not only in content but in format. For 2004, I intend to communicate directly: I will use the telephone more and without hesitation; I will approach people’s desks unabashedly and without warning. I will depend on the typed word only when these more direct forms are not available.

Erin Malone:

Continue to practice work-life balance and put my external community efforts into initiatives that will really make a difference—like AIFIA and Boxes and Arrows.

Write more.

Nick Finck:

Well, I have made a new year resolution to start extending my efforts within and outside of my own publication.

Part of this is joining up with Boxes and Arrows as a web developer. The other part is going things streamlined in my publication internally so I can invest more time into writing and contributing to other sites and publications.

Another part of this is just getting more in-touch with other individuals within the web community as a whole. Individuals from various backgrounds such as IA, publishing, UX, usability, accessibility, web programming and more. These are people who I already know and talk with from time to time. I am hoping that this year I can get to know these people even better and build more open communication between all of us as professionals.

As far as IA techniques, I can say that I hope to implement a new taxonomy for my publication within the year. It’s actually something I have been meaning to do for a long time but haven’t been able to
gain enough momentum to make it really happen. Along with this I plan to implement several other IA related strategies that will help improve the findability, usability and user experience of my publication.

Marko Hurst:

My mantra in life is “balance in everything.” In my now 8 year career I’ve worked for nearly every sized company from myself—several thousand, worked on projects that have lasted a few days—2 1/2 years, worked with too many technologies to remember, and played the role of nearly every person in a web development cycle from designer-developer, PM-business owner, and of course an IA.

Other than for myself I have never been a “technical” architect. So, in keeping w/ my mantra I feel the one of the greatest assets I bring to projects as an IA is my well-rounded skill-set. I feel that having been in everyone’s shoes has allows me a special insight to their cares and concerns, which in turn I can take into account and “translate” to others. So, this year my resolution is to understand System Architecture & Design.

And let’s not get crazy now, I don’t plan on selling myself as a Technical Architect by any means. The same as I do not claim to be a Developer because I can code a few JSPs or create a JDBC connection. The point is to simply to become familiar enough with another integral part of the web development cycle.

Jenifer Tidwell:

In our next design cycle, I’m going to try to keep a “design notebook” for the project. It would be, in a sense, a collective memory for the design team. From the inception of the project through the final touches, I want to keep track of design decisions made, the reasons for those decisions, all design documents, and “paths not taken”—alternative designs, features we want to implement but don’t have time for, etc.

Why? First, our design documents tend to be scattered in different places. We’d like them pulled together into one place so we can all have easy access to them. Second, our product release cycles are long—over a year in many cases—and we always end up asking ourselves questions like, “Why did we decide to do X? Did we ever consider Y? There was a good reason not to do Z, but what on earth was it?” Third, it gives us something to look back over at the end of the project; we can use it to evaluate our process, and help decision-makers “connect the dots” between our high-level goals and the features our team actually delivers.

I’ve never done this before, and I’ve never heard of it being done. It just seems like a good solution to the problems our project teams have had!

Lou Rosenfeld:

My resolution is to write a book on enterprise IA. 🙂

Keith Instone:

I resolve to actually read B&A this year! “Too damn busy working” is not a valid excuse anymore.

[We like to hear that, Keith, and we’ll be checking our IP Address logs to see if you follow through…just kidding. —Editors]

Julianne Bowman:

Finding ways of using captology in interactive marketing that are useful and engaging to the user as well as smart for the marketer.

Convincing marketers to harvest customer profile data over the course of several user visits, thus creating several “value-exchanges” for the user instead of one big, alienating registration form.

To continue trying to focus my clients on the big usability changes that really matter. They are so focused on piddling quick wins it can be difficult to get them to see the wood for the trees.

To use Visio’s new XML output facility a lot.

And finally,

Cynthia Hoffa:

I think, like me, many IAs are still stranded on the lower end of Maslow’s pyramid of needs. Therefore my short list might look modest, but it encompasses the primary things we fight to conquer in our quest for “self-actualization.”

Don’t sweat the small stuff.

Demonstrate how I add value.

Extricate myself from crazy delivery cycles.

•••••

Good words to live by.

I invite you, dear readers, to add your resolutions to the list and wish everyone a prosperous and effective 2004.

Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.

Building a Vision of Design Success

Written by: Christina Wodtke

“Alone, the pain that triggers a redesign is not enough of a guide to build something useful to the company. You have to build a shared vision.”

Vision

In the last year I’ve been at Yahoo!, I’ve had the pleasure of participating in three redesigns. They have all gone rather well, though through conversations with colleagues, I’ve come to understand this is not always common. Redesigns are as often crucibles of group anguish as they are opportunities for invention and rebirth. In the entirety of my career, I’ve definitely seen both. So what is the difference that allows one redesign to work and another to turn into months of tail chasing? Fortunately I’ve been part of several post-mortems as well, and I think the key difference is vision.

A redesign has some built-in advantages over everyday maintenance; the most useful being focus. And focus is the loam that allows a shared vision to grow. A group chooses to redesign typically because the site is no longer working, and the pain of the site not working is greater than the pain of stopping business as usual and entering into an expensive and emotional project. But once committed, you have to move the project from reactive (something is broken) to proactive (we’re going to build something great). Alone, the pain that triggers a redesign is not enough of a guide to build something useful to the company. You have to build a shared vision.

Shared Vision

A common view of vision is that it’s something handed down by a leader to the troops. When a redesign goes awry, the troops complain, “There was no vision.” Sometimes there was a vision, but the leader didn’t communicate it, or more commonly, no one bought into it. Then the leader complains the troops didn’t obey. But the problem goes deeper than either scenario; the problem is that there was no shared vision. A shared vision is born of collaborative conversations, articulated in a form that is digestible and memorable, and then internalized and personalized by every member of the team. The power of the shared vision is that it is shared—it is held within every member of the team (or organization) and thus needs no leader to carry it forward; every action of the team helps make the vision real.

Success, all starts in the way the vision is birthed. A vision can come initially from one of two places: the leader can create it or recognize it. It’s another fallacy that folks think leaders must be the source of all ideas—they don’t. A great leader should be just as capable of recognizing an idea as well as dreaming one up—in fact, more the first, which is more scalable. So: a leader has either come up with an idea (the current site doesn’t allow us to realize a new business model; we need to redo it) or may recognize one (our usage numbers are in decline—marketing says people think we don’t have what they want; user research says it’s hard to find anything on the site, I just read this article on findability—hmm, I wonder if there is something there). This germ of a vision is the proto-vision. To get the proto-vision to a vision, the leader needs to feel comfortable shopping around the proto-vision. When you shop around the proto-vision, you have numerous one-on-one or small-group conversations about the proto-vision with as many people with different viewpoints as is feasible. Again, this is often hard for new leaders, who think they have to be the single resource of all wisdom. More seasoned leaders are eager to do this, as the act of shopping around the vision sets the foundation for a shared vision. It also makes the vision stronger, as it roots out biases arising from a single point of view.

Finally, the initial vocalized reason for the redesign is often not a good vision. Let’s say you redesign because your navigation system isn’t scalable. That’s the pain-point that kicks off the work, but is that a guiding force to lead you to a great product? You’ll need to deconstruct “our navigation isn’t scalable” into “we offer the greatest collection of independent movies in the world, easy to find, easy to watch, easy to share” (for example).

Look both ways

Let’s assume, for whatever reason, you will be shaping the shared vision. Maybe you are the leader, or maybe the leader hasn’t provided enough of a vision to make you confident in your project, and you are going to lend a hand shaping the vision. To shape the proto-vision into a vision, you’ll need to do some interviewing. I usually select the people who will help me shape a vision using a few criteria: domain expertise, intelligence, system thinkers and open-mindedness. I always do these in one-on-one discussions. This avoids group think, and I find I can help people speak more honestly if there isn’t any sort of audience. The conversation covers three topics: looking backward, looking forward, and finally, the protovision.

To look backward, I find it useful to use Peter Senge’s Five Why’s. This is a very simple technique in which you ask why, and when you get a response, you ask why again. It helps you move from specific issues to uncovering larger underlying problems.

For example, let’s say you are the head of user research:
Me: Why do you think we should do a redesign?
You: Because people can’t find anything.
Me: Why can’t they find anything?
You: The navigation isn’t intuitive.
Me: Why isn’t it intuitive?
You: We didn’t do any user research when we designed it, just usability after.
Me: Why is that?
You: Well, our budget was cut…
Me: Oh? (which is what I say when I’m tired of “why”…)
You: Well, the company doesn’t seem to value getting user feedback.

From this short conversation, I’ve learned several things. The user researcher thinks findability is a key problem, and he thinks research would help, and he feels we don’t invest in it. I can return to any of the places where I asked way, and take a different branch to find out more. I could ask “What makes you think the site isn’t intuitive” to learn more about the site problems, I could ask more about “Why you thought that usability wasn’t enough,” or could continue digging out why the company doesn’t think user research is important or I can spend another five whys finding out if user feedback is valuable and why. To be thorough, I’d probably dig through them all.

I’ll finish up the conversation by asking many of the classic pre-design questions, which allows me to look forward: why are we doing this design now? What are the opportunities? What will make this project a success? What would success look like?

Later, when I walk through my notes, I’ll be trying to find the concrete problems and positive aspirations. The concrete problems will go into my redesign plan, the positive aspirations are fuel for the vision. My sets of questions would probably lead me to moments of both: “Our site isn’t easy enough to use—our users say they want to be able to find and rent a movie quickly, because they are often doing it at work.” From here speed and ease arise. “Our users are sick of all the blockbusters they can get at the local store; they want to find movies they’ve never seen before.” From here comprehensiveness or unique collections arise as an aspiration.

As you get to your fifth and sixth conversations, you’ll find you start to have a more defined set of aspirations for your proto-vision which you can use as foil for your discussions:
Me: Do you think we need to offer access to every movie on the net?
You (business leader): No, I think we are positioning ourselves as an alternative to Netflix—it’s more critical to be comprehensive on independent movies.
Me: Hmm—can you tell me more? (another why alternative)
You: It’s an underserved market—we can build our strengths there before trying to get share from the big guys.
Me: What does it take to satisfy this market?
You: Better talk to Sally in research, if I recall right she said it’s going to take 500,000 films to appear useful.
Me: With so many films, how can anyone find anything?
You: Well, that’s your problem…
Me: But it needs solving? You think we need to make sure the site is easy to use?
You: You bet—we’ve got to satisfy this market; they influence others.

I’ve now gotten a more senior individual to voice his belief that a large selection that is easy to access, is a goal critical to the redesign. Even though his original kickoff to the redesign might have been about navigation, he has now revealed and/or bought into the larger vision to provide user satisfaction, built on ease of access and selection.

You may think this technique is a consultant’s tool, but even though I’m in-house, I still go forward asking these questions. Just because I think I know the answers doesn’t mean my answers are right. Let’s say I thought we planned to offer every movie ever made—I’d discover I was wrong. Moreover, these conversations tie us together in our inquiry, giving us an infrastructure of shared knowledge that will lead to shared vision.

These conversations can be quite delicate and require one to have a certain amount of skill in interviewing. It’s critical you do not lead the conversations with your ideas and that when you introduce elements of your proto-vision you are doing so in a way that tests the concepts and builds shared vision, rather than trying to get a quick buy-in (which will bite you in the patootie later). User researchers are excellent in subtle interviewing techniques; if you haven’t got the skills, you may want to go to a researcher for coaching, take a class or read a book (some resources listed below).

Digest, and articulate

At the end of each conversation, you have hopefully noticed some common themes. If you didn’t, you went through your notes and pulled them out. Then you took the themes to the next conversation, as you worked your way across disciplines and up and down the hierarchy. Maybe there have been three conversations, maybe there are ten, maybe they were all a tidy hour, maybe some of them were five minutes in the cafeteria…but you should now have what you need. You have a collection of critical aspirations for the site.

Now take a pass with your user base. In the past, I’ve successfully used a variation of an older technique which involves word-importance. You take a set of 100 words/two word phrases that represent qualities of products you offer and have a larger sample of users pick ten to fifteen of the ones that matter to a (mail, shopping, research) site. For each product, replace some of the words in your standard list with ones that are relevant to the product—in this case, your redesign. For example, a news site might need the word authoritative, a personals site might replace that with warm. Next you ask the users to rank them in order of importance. When you analyze this survey, you should see five words rise to the top—these will become touchstones for your work. You can also later use these words at the end of a usability evaluation (on a scale of 1-5 how authoritative was this site?) or to test visual comps in surveys. At Yahoo!, we print them and hang them in our war rooms to provide focus.

Once you have the words from users, and the interviews, you can see if they don’t match. God help you if they are completely different. Odds are good, though, there will be a fair amount of overlap, and a bit of nudging will ferret out a set of final qualities, valued by business thatusers also aim for. If time is an issue, you can do this at the same time you are still conducting interviews. If you don’t have access to large user numbers, I recommend skipping this exercise and using a different concept testing technique. And shocking as it may be, you may not get to have user input at all—in this case, hold as many interviews, with as many folks as you can, and include a few target users by going to the mall or asking questions on web bulletin boards. Honestly, you may even find you are forced to begin to design with the final vision unformed…it happens. But it doesn’t mean you shouldn’t continue to push toward a vision: a vision coalesced halfway through a redesign is still better than no vision.

Now take the time to articulate the complex vision made up of proto-vision and the user and business knowledge you are holding in your head into a simple vision—preferably one sentence. This will be hard, it’s almost like creating a mission statement. However, it’s not a vision for a whole company, so don’t kill yourself. Just get to a simple, clear sentence or phrase that is the essence of what you are striving to accomplish. I’ve seen redesigns driven by even the simplest set of words, provided they are the right words. What is critical, is that it captures the essence of what you hope to accomplish, collectively.

Market the vision

Now that you have your vision seed, you are going to do almost the opposite of what you have been doing. So far you’ve taken as many diverse elements as possible and boiled them down to the essence. Now you have to take that essence and make it accessible for the folks who will hear your vision. You have to articulate what that vision means—for example, if fast is a part of the vision, it’s worth it to clearly articulate that you mean, fast loading (for engineers to concentrate on optimizing on the server-side and designers to avoid graphics) , the illusion of fast downloading (for your web developers, so they can look into things like progressive rendering) and fast-to-scan (for your designers, to concentrate on clarity).

Next you need to market this eloquent vision. Some potential forms for this include:

  • PowerPoint presentations: The first sentence of the vision is the first slide, and then you go on to explain what the meaning of the vision is, what the aspects of the vision are, why this is the right vision and what it takes to get to it.
  • Posters: We’ve used posters as a great tool to keep the vision in front of our eyes as we work. The poster consists of a simple strong image capturing the essence of the vision, with words or phrases elaborating the vision around it.

    Simpler than a poster, you can print out the vision statement in a large font and hang it up in every cube, in every meeting room, and in the war room.

  • Memes: These are catchy phrases that hold a single key concept. You use them while reviewing work to hold the work accountable to the vision. If an aspect of the vision is speed, embodied in a fast download, then a meme might be “Every pixel has a job to do.” A catchy phrase is a godsend for keeping everyone focused…if you’ve got someone on your team with a talent for a turn of phrase, use them. If your memes are catchy enough, they’ll be internalized and every act of creation will be in context of these simple instantiations of the vision.

Not only do these techniques communicate the vision to those who did not help create it, but also act as a reminder of a shared vision to those who did. In the hectic day-to-day madness that accompanies any large project, reminders of a shared vision are invaluable.

In praise of vision

In a redesign, a vision can be the difference between a clear, cohesive design and a hodgepodge of various stakeholders’ urges. In the worst case, it can produce a work so inferior to the original that months are lost when the work is scrapped. Or it’s launched and customers flee in droves.

In our working life, there are many things we do without a vision. And we do the work like a zombie, without our heart, or we do it passionately, but at odds with the larger goals of the company. But if we incorporate vision into our work, our work is more targeted, more effective and more meaningful. A status report becomes a tale of getting closer to a dream; a banner ad becomes a promise of delight to a customer that is fulfilled upon a website visit.

This is just a simplified version of the techniques my colleagues and I have used to capture a vision to ensure a successful design process—you are welcome to expand, embellish, reduce and streamline it for your own purposes. Just remember: the vision must be clear, meaningful and shared. A top-down vision that is not owned and internalized by all members of the team is not a vision at all, but a wish.

And if wishes were horses…

The Devil’s in the Wireframes

Written by: Liz Danzico

Wireframes: At once a singular composition and a collaborative expression, communicating the vision of both an individual and a team. Their visual language must be detailed enough to be widely interpretable, yet particular to different audiences. As a result, wireframes can be stacked with an enormous amount of detail. Are we becoming victims of information pollution in our own wireframes?

Jakob Nielsen recently warned us about information pollution, commenting “excessive word count and worthless details are making it harder for people to extract useful information. The more you say, the more people tune out your message.” This resonated with me (perhaps not in the way Nielsen intended) because of an evolution I’ve seen in my own wireframes.

There seems to be a parallel relationship between level of detail and accepted-ness. As information architecture grows to be a defined step in my company’s process, my wireframes have grown more detailed; more departments must participate in and comment on them.

Once a calculated expression of gray boxes and greeked text, my wireframe has grown heavy with detail, chaotic even, sometimes communicating the desires and requirements of an entire project team. Each layer of detail (and there are many) is intended for a different audience: partial business rules for technologists; a page weight guideline for developers; an idea about a visual system for designers; a justification about “Phase One” features versus “Future Phase” features for stakeholders; even notes to myself sometimes creep into the sidebar.

How did this evolution come to be? And, more importantly, how can I stop it?

In Understanding Comics, Scott McCloud shows how a drawing of an ordinary smiley face can be a more effective representation of a man’s face than a photograph. Abstracting out a smiley face as such allows audiences to focus on the intended detail. Audiences are free to interpret the drawing, projecting their own past experience and meaning upon it. When faced with a photograph of Robert DeNiro’s face instead, the audience immediately makes judgments and assumptions simply because they recognize him.

My wireframes, unfortunately, have become almost photographic.

I’ve realized that it may be impossible to not see the semblance of a design in a wireframe with a lot of detail. A gray bar down the left side may show information grouping to the designer, but is immediately recognized as left navigation to the business owner. Levels of detail intended for audiences of every type are polluting my wireframes, forcing my audience to project their prior knowledge and experience upon them. This, I’ve found, leaves little room for innovation.

As information communicators, we must be conscious of how our information receivers are interpreting wireframes. As information managers, we must be conscious of how we position and take inventory over the data. As information designers, we have to regain control over the content included in our documents. Here are a few ways I now keep the clutter down:

  • Amplify through simplification.1
    Ensure that information is presented clearly and plainly. Use wireframes without color, without icons, and without layout recommendations. If there is a danger the audience will be distracted by multiple elements on a page, create separate pages, each illustrating a different point.
  • Cut out unnecessary details.
    Is your annotation covered in another document or on another page? Are you communicating something that is outside your area of expertise? Ensure that every item is critical to the wireframe at hand. If the navigation is the same on every page, for example, there is no need to repeat it.
  • Annotate thoroughly but relevantly.
    Does your wireframe have to stand on its own? Will you be there to present it? The details you include should match how and where the audience will digest it. If you are presenting to technologists, you might not include all the content strategy recommendations.

By stripping out these extras, I’ve been able to focus on the points I need to make to each audience. In meetings, I can focus on getting across relevant information. Over email, I can control interpretation by using general visual language. Everyone, including me, can remain focused on the page-level interface design itself. I’ve found that this not only improves my wireframe communication, but also improves communication of subsequent deliverables.

The most targeted information—not the most information—allows for an understanding of wireframes that is precise and accurate.

1 This phrase was coined by Scott McCloud in Understanding Comics.Liz Danzico, editor for Boxes and Arrows, started her IA career teaching English in Japan, forcing her to structure information into lesson plans and class activities. After more formal training, she’s been able to work on projects for clients from Charles Schwab to Columbia House to Barnes & Noble.com.

Liz is an information architect in New York City and teaches design history at The New School University. Liz has a B.A. in English from Penn State University and an M.A. in Professional Writing from Carnegie Mellon.

Her personal site can be found at bobulate.com.

The Power of Process, The Perils of Process

Written by: Erin Malone
“The power of a well-defined process is the creation of order amidst chaos. When it works, it can be like a fine-tuned machine, and our design work is better for it.”Traditionally, information architects and designers (UI, visual, ID) are creatures of process. We generally work in prescribed ways—discover, design, validate, repeat. We sketch first, then create rough flows and then finetuned detailed wireframes and mocks. This usually works well, once accepted, and most companies—whether in-house teams or consultancies—work along similar lines.

In my experience, I have found that creating and documenting process has been a good exercise to help institutionalize ways of working, to help educate new team members as well as to unveil the mysteries of what we do for executives, product folks, and development teams.

In my currrent situation, an agreed upon process has helped teams working in multiple time zones and across several locations to get their work done. The process — discovery and exploration, concept UI development, review, creation of wireframes and user interaction flows into a draft UI, review, finetuning into final UI and then creation and finetuning of a functional spec — is the same no matter who is working on the project or what country they sit in.

There is a lot of comfort in this shared way of working. There are fewer concessions that need to be made. Roles and responsibilities are clearly defined and everyone knows what they are going to receive at each point in the schedule. The framework within which we all work allows us to be creative, but also keeps teams on track.

The power of a well-defined process is the creation of order amidst chaos. When it works, it can be like a fine-tuned machine, and our design work is better for it.

On the flip side, problems happen when people get complacent about the structure they are working within. Expanding phases excessively, becoming rigid about the order or duration of each phase, or even over-documenting the elements within a phase can backfire on a team. There are also problems when one team decides to work in a totally different way than another within the same group. Suddenly, no one knows what to expect, what the level of thinking or quality of the product will be, and internal fighting over whose process is best ensues.

There can also be credibility issues surrounding process and how teams work with it and within it. No one wants the reputation of being so bound to a way of working that they lose sight of the reason they are working in the first place.

I was recently called out for rigidness about process by a client who went crazy over a proposed schedule. The client didn’t understand why some of the work couldn’t be done in parallel, and why certain phases of the project couldn’t be shortened. Ultimately, we were under a tight deadline to ship, and to make the deadline we all (design, product, and development teams) had to make compromises. I assured this client that we generally needed to “ask for the moon” at first, and then would pull back to something more realistic given the circumstances.

The conversation got me thinking though about how we work and how structure can overpower the actual needs of the project. If a group is not careful, the process can take on a life of its own and make demands that exceed the requirements of the situation.

For all the benefits a well-documented and richly detailed process has, it should also be a framework that is flexible, that can be adjusted at a moment’s notice to fit the situation at hand, and shouldn’t exist for its own sake.

I like to think of design process as a grand buffet. One that has discrete sections—discovery/early user research, exploration/concept, draft, final—and review checkpoints throughout. I generally like to think of each section as being collapsible or expandable depending on the needs of the project and the time allowed. Ideally, no section would be collapsed down to nothing, but sometimes it might feel that way. I also see each section as having a buffet of tools and techniques available to help solve problems, keeping in mind that just because a tool is available in a particular section doesn’t mean it must be used every time. That’s the beauty of the buffet: the framework and structure are there, but usage of the tools is flexible and can be fine-tuned for the needs of the team and the project.

Thinking about your work process in this way, getting your team or company to agree upon the framework and toolsets, and then remaining flexible within the overarching process structure will ultimately free you up to apply your skills to the tough problems—the design problems—and not the process.

Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.

DUX: Five Lessons Learned

Written by: Erin Malone
“Great things can happen when you move beyond the bullet point.”Normally I would write a traditional conference overview to inform people about the recent Designing for User Experiences conference (DUX) held in San Francisco, June 6-8. But the format of the sessions was set up in such a way that my overview would be even further distilled from the panels, which were 8-minute distillations of the papers. So, instead, I would like to impart a few of the impressions I came away with and recommend that everyone go to the AIGA Case Study Archive to read the papers that were accepted.

We are a like-minded community.
The attendees of DUX—members of AIGA, SIGCHI and SIGGRAPH—while having different professional emphases, are a rich and robust community with much more in common than we generally think. This blended community is curious and vibrant and surprisingly interested in sharing personal stories of our work. The conversations in the breaks and at the receptions were as rich and informative as the dialogue during the panels. There was no “us vs. them,” or academia vs. real world—research and practice blended well together. As a matter of fact, unless someone explicitly pointed out that they were from one space or another, the conversations were incredibly similar.

There is a positive undercurrent in the community as a whole.
My impressions, after three days at the IA Summit in Portland this past March and two days at DUX this past weekend, is that the atmoshpere of the field is looking up. Yes, I know many people are still out of work, but it seems to me that more folks are working and less are whining; people seem genuinely excited about their work. The challenges within organizations are still there, but the stories told show that design (this includes all the flavors—IA, visual, interaction, etc.) is engaging in productive partnerships with the other organizational disciplines. Engineering and marketing are collaborative partners. I heard less “They don’t take me seriously, how can we be heard and involved?” than “What else can we do to make improvements?” and “Where else can our skills be used in the process?” this time around. Maybe it’s just me, but I think there is definitely a shift happening.

Great things can happen when you move beyond the bullet point.
I was excited to see that many of the presenters moved beyond the traditional PowerPoint deck of bulleted items and actually spoke to the audience conversationally rather than reading their slides—which we can all do ourselves. It makes it harder to take notes, but as an attendee, I appreciated the effort and the conversational nature of it. Jess McMullin chaired a panel that focused on constraints. He challenged his panelists to create their presentations without any bullets and to include more images and fewer words. This challenge worked. For the most part, the presenters were more lively, the slides were illustrations of the points rather than lists of the points, and overall, the collection of presentations was more interesting and entertaining. I challenge the rest of us to try this at home — er… work. What if we began to give presentations at the office that followed this logic? Would it help elevate the status of design within the organization? It definitely makes the presentation more challenging to give, but it forces people to listen since they can’t take away a list of bulleted items to throw into the shredder bin. Try this and let us know how it worked. One presenter reminded us that while a “constraint is a factor identified as a barrier,” an “opportunity is a factor identified as a liberator.” Liberation within design. Liberation within an organization. Liberation from the bullet point. This is a pretty cool way of looking at things.

Design can have great impact, and shoulders great responsibility.
This community is having an impact. We “design” the products people are using every day. We create new behavior and change behavior. We have a responsibility to be smart about what we do and how we do it. One of the presenters reminded us that it is our responsibility to understand the communities of practice that already exist as we design products and experiences. These communities of practice contain deeply embedded structures and processes, and in understanding these, we can create more effective experiences. Several presenters reiterated this theme, and I think it’s good to continue to remind ourselves that it is more than the user that we need to understand; often it is a collection of people within a community that will give us the insight we need.

Mentors can be found in all sorts of places. You might even be one.
One of the closing plenary speakers on Saturday was a woman named Sara Little Turnbull. She is 85 and has worked for six decades in the realm of strategic design development. She is still working, currently at the Process of Change, Innovation, and Design Laboratory of the Stanford University Graduate School of Business. As I watched her converse with Richard Anderson and relate some of her experiences, I realized that I personally was in desperate need of mentors. I try to mentor my team at work, and am always open to answering questions from colleagues in the community via email. I hope that as I share my experiences I am mentoring those coming behind me, but I sense a lack of knowledge about those who have paved the way, of those who I can learn from. What this speaker reminded me of was that we have leaders in the field who may not be recognized, yet have much to offer. I believe there is a need for more formal mentoring structures to help get people together. There are many of us—particularly females over 35—who don’t necessarily have a lot of role models to learn from. We have a lot of great peers, but the women who have gone before us are unsung heroes, women who haven’t been recognized and are still trying to get by in a corporate culture that is predominately male. This speaker reminded me that mentors are out there, and we all should seek out one or two, as well as remembering to be one ourselves.

In conclusion, I enjoyed this conference, and for being a ”dot two” release (dot one was the Forum at SIGCHI last year) the organizers did a good job. The days were interesting, I feel like I learned a few things and, most importantly, I felt excited to be a part of this vibrant, rich, and curious community, particularly at this point in time. I would love to hear how others felt, and welcome your thoughts and feedback. I’m sure our feedback will be welcomed by the organizers as they plan the next version of DUX.

    AIGA Case Study Archive As of this posting, the DUX cases had yet to be posted but keep checking back.

Some other conference thoughts can be found from other attendees here:

There is also discussion going on at the AIGA Experience Design [http://groups.yahoo.com/group/AIGAExperienceDesign] list about the conference and other attendee’s thoughts as well as a few posts on SIGIA-L (archives) [http://www.info-arch.org/lists/sigia-l/0306/0077.html]Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.