It Seemed Like The Thing To Do At The Time

by:   |  Posted on

This is Part One of our “Lessons From Failure”:http://www.boxesandarrows.com/view/lessons-from-failure Series.

“Failure is instructive. The person who really thinks learns quite as much from his failures as from his successes.” JOHN DEWEY

Several years ago, I changed careers, moving from designer to entrepreneur starting a dot com company. The experience taught me many lessons in the basics of how—and how not—to successfully build an Internet business. But the most valuable lesson I learned—one applicable to any business model, design challenge, technology, or industry—was in the powerful links connecting state of mind, self-definition, and failure. Startlingly, these same links appear no matter what size the group of people or the venture: from design projects and startup teams, to cultures seeding colonies abroad, state of mind and self definition are closely connected to how well a group responds to failure.

In the midst of the exuberant rush to (re)create communities on the Internet for a dizzying array of peoples and purposes, we should understand and respect this underlying pattern, whatever our role: founder, designer, or member. For though the growing wave of technosocial media may change how we conceive of and relate to the Internet by offering abundant opportunities to create and join new societies, these societies will remain driven by fundamental elements of state of mind and self definition.

To illustrate these ideas, I’ll briefly discuss three examples of new societies—the entrepreneurial ventures of their respective cultures—that faced failure: first, the small Internet company I founded, then two cultures facing environmental challenges. Two of these societies failed, and one succeeded.

It Seemed Like the Thing To Do at the Time

In the winter of 1999, I decided to start a business with two partners. I was working as an Internet strategy and design consultant at the time, so moving from designing online businesses for clients to designing one for myself felt like a natural step. We had a talented group of founders with the right mix of experience, and we had a good idea. We needed money in order to build substantial business and technology infrastructure, but capital for a good idea was easy to obtain in early 2000. Becoming an entrepreneur genuinely seemed like the thing to do at the time, since it offered a good opportunity to apply my skills and experience at a new level, and to my own vision.

We worked diligently to build the company for the next twelve months. Our team grew from 3 people to 10 people in the U.S. and China. We recruited a (bad) CEO. We recruited a (good) CTO. We assembled an impressive roster of critical business partners and advisors on both continents. We were fortunate—given the terrible business climate for online companies after the dot com crash—to receive several funding offers from the very beginning. But none of them were sufficient, and some were downright shady (I met a number of “unusual” people during this time 1).

In March of 2001, after a year of unpaid overtime, I left my regular full-time position to dedicate all of my time to the new company. In this, I was joined by several other team members. Based on our previous successes, we believed proper funding was literally around the corner. Our business plan was exquisite, our financial projections were meticulous, we had customers and staff in place, and our execution strategy was finely honed. Like a Broadway production awaiting the audience on opening night, we were ready to go. All we needed was capital.

By the summer of 2001, despite considerable success during difficult times, we were at a financial breaking point. Lacking strong revenue, we could not continue without help from outside in the form of legitimate funding. The attacks of September 11th, 2001 shut down the New York capital markets, closing the door on any hope of venture funding shortly afterward. We closed up shop, my partners went their various ways, and I took another full-time position.

A Moment for Reflection

After the team disbanded, I reflected on the experience to understand why we had failed.

Vizzini’s Advice

In retrospect, as Vizzini from the Princess Bride would say, we made a series of classic blunders:

  • We had a complex concept
  • We sought too much money during a difficult funding climate
  • We hired the wrong CEO (beware of business men who dress like Cuban drug smugglers)
  • We were not willing to compromise or modify our plans
  • We grew the team too quickly
  • We relied on unrealistic financial projections
  • We underestimated the operational challenges

As a once and future entrepreneur, I interpreted these as straightforward lessons for my next venture: begin with an idea that is easy to understand, be flexible, don’t fear change, involve only trustworthy and talented people, make realistic financial assumptions about revenue and income etc.

In summary, I understood that our failure was driven by the fact that we focused too much effort on securing external funding, and not enough on growing essential day to day operations. Vizzini would say our true blunder was that we did not get involved on the ground in Asia!

The Power of State of Mind

“I have not failed. I’ve just found 10,000 ways that won’t work.” THOMAS ALVA EDISON

Staying the Course…

People often ask why we made the decisions that took us from our first to our final steps. Why didn’t we change our plans? Why didn’t we put more effort into other ways to build infrastructure? I always answer, “It seemed like the thing to do at the time.” Meaning because of our state of mind and the progress we’d made, this course of action seemed the best way to reach our goal. We certainly didn’t intend to fail!

State of mind is an umbrella term for the common outlooks and framing assumptions that define the ways people perceive and think about situations and themselves. State of mind also sets boundaries for what people can and cannot consider. In practice, individuals and groups interpret the world through a state of mind that defines their understanding of:

  • Cultural concepts and ideas
  • Their needs and goals
  • The situations and environments around them
  • Their roles and the roles of others (both groups and individuals)
  • Available choices and actions
  • The results of those choices and actions

In retrospect, it is clear our team shared a common state of mind that we were unwilling or unable to change. In this state of mind, underlying all the decisions we made from beginning to end was a single goal: seeking external funding was the best thing to do for the business. Based on our shared understanding, we pursued this goal far past the point when a heavily venture-funded model became invalid, because the environmental conditions that sustained it had collapsed.

A glance at the headlines provides abundant examples of similar responses to failure driven by state of mind, such as the heated debate between the U.S. Congress and the Bush administration over different approaches to the ongoing U.S. involvement in Iraq. President Bush’s state of mind is epitomized by his dictum to “stay the course,” a view that substantially determines the choices considered possible by his administration.

Waiting for Rescue: Self vs. Other

Some time ago, I came upon a quotation from an 8th century Buddhist philosopher named Shantideva that changed my perspective on my experience as an entrepreneur. In “Entering the Path of Enlightenment,” 2 Shantideva writes, “Whoever longs to rescue quickly both himself and others should practice the supreme mystery: exchange of self and other.” When Shantideva says, “exchange of self and other,” he is advising us to change our self-definition, one of the most basic components underlying state of mind.

Shantideva, or Manjushri

So I came to see that my team of entrepreneurs had set out on the wrong path from the beginning, and never wavered, because our state of mind rested on defining ourselves as venture funded entrepreneurs. We never considered changing our self-definition. Obtaining funding became part of our identity, rather than a pragmatic business activity. There is a second parallel with Shantideva’s words: we were unable to consider other courses of action even after we recognized that we were in danger of failing, because we were waiting for rescue from outside. We believed outside funding would save us.

We never considered how our self-definition was leading us to failure. Nor did we consider that we might find another way to succeed if we changed our self-definition. President Bush would be proud: we managed to stay the course!

Easter Island: A Machine for Making Statues

My experience as an entrepreneur shows the power of state of mind in societies on the small scale of a closely focused startup team. The Easter Island society that collapsed in the 18th century clearly demonstrates the strong connections between self-definition and failure on the much larger scale of a complex society of approximately 15,000 people. (The discussion that follows draws upon the work of Jared Diamond in Collapse. 3)

Easter Island

Easter Island was settled approximately 1200 A.D. by Polynesians from islands further to the west. 4 The small (64 miles square) island remained essentially self-contained due to its remote location in the Pacific Ocean. 5 The population increased quickly as settlers rapidly cleared forests for farming. Based on common Polynesian religious practices, the Easter Islanders began carving the immense volcanic stone statues (Moai) that make the island famous, mysterious, and photogenic.

Easter’s Statues

Over the next 500 years, in a remarkable demonstration of the power of a common state of mind and self-definition, Easter Island’s religious and ceremonial practices effectively turned the entire society into a machine for the construction of statues. 6 The Easter Islanders built their social and political system around the creation of statues. Reward mechanisms offered prestige and power to chiefs who competed to carve and erect ever larger statues, on ever larger platforms. Driven by this institutionalized self-definition, the population collectively invested massive effort into carving and transporting thousands of tons of stone for each burial platform and for the hundreds of giant Moai placed upon them. 7

Wood from the island’s forests was literally the fuel that kept this statue-making machine running. Farming to produce the food needed to feed large groups of workers required ever increasing amounts of cleared land. Moving statues required large wooden carriers and hundreds of miles of rope. Funerary rites mandated cremation and burial in the gigantic stone platforms. As Easter Island’s human and statue populations grew rapidly, estimates of the island’s forest coverage declined precipitously, as this comparison chart shows.

Figure 1: Forest Cover vs. Population 8

This self-reinforcing cycle of statue creation, deforestation, and population growth created a recipe for environmental collapse that lead to comprehensive social failure. 9 Conservationist Rhett A. Butler summarizes the findings of Terry Hunt, an anthropologist who studied Easter Island’s history of habitation:

“With the loss of their forest, the quality of life for Islanders plummeted. Streams and drinking water supplies dried up. Crop yields declined as wind, rain, and sunlight eroded topsoil. Fires became a luxury since no wood could be found on the island, and grasses had to be used for fuel. No longer could rope by [sic] manufactured to move the stone statues and they were abandoned. The Easter Islanders began to starve, lacking their access to porpoise meat and having depleted the island of birds. As life worsened, the orderly society disappeared and chaos and disarray prevailed. Survivors formed bands and bitter fighting erupted. By the arrival of Europeans in 1722, there was almost no sign of the great civilization that once ruled the island other than the legacy of the strange statues. However, soon these too fell victim to the bands who desecrated the statues of rivals.” 10

Lessons from Easter Island

Easter Island Today, Deforested

The tragic pattern is clear to see: though institutionalized practices and goals based on a narrow self-definition were leading to comprehensive failure, the Easter Islanders refused (or were unable) to change their state of mind and goals, and their entire society collapsed. To this day, Easter Island is almost totally deforested, with the exception of small patches of trees from recent plantings, and the ~400 stone statues that remain. In a potent instance of irony, the Easter Islanders succeeded in constructing dramatic and enduring stone testaments to those things their society valued, even as the act of constructing those monuments consumed their society. President Bush would be proud of the Easter Islanders, too—they stayed the course.

A Tikopial Paradise

It is on our failures that we base a new and different and better success.HAVELOCK ELLIS

Tikopia Today

The Pacific island society of Tikopia is a good example of a culture that successfully responded to failure, by changing how its members define themselves. Tikopia differs from Easter Island in ways that make the challenges its inhabitants faced more pressing. Tikopia has been inhabited far longer (since ~900 B.C.), is much smaller (only 1.8 miles square), has fewer natural resources, and supports a much higher population density than Easter Island. 11 Yet photographs of Tikopia today show a lush, green landscape that is well-forested, while the island is populated by closely spaced communities of villages, supported by well-tended gardens and farm fields.

Over the history of human habitation on Tikopia, three different economic and social models governed the production of food and management of the island’s environment. For the first 100 years of habitation, the Tikopians relied on a slash and burn style agricultural model that severely damaged their environment through deforestation. They also mined the nearby shellfish and bird colonies for needed protein.

Recognizing that this model was unsustainable on a tiny island, the Tikopians changed agriculture and food production practices to a mix of forest orchards and pig farming, wherein livestock made up ~50% of their protein sources. This new model retained a two-tiered social structure, allocating scarce protein to a ruling class of chiefs. Under the forest garden model, Tikopia’s environment continued to degrade, albeit more slowly than before.

Such a quick and comprehensive shift in economic and agricultural approaches across a whole culture—even a small one—is rare. By around 1600 A.D., the Tikopians again faced environmental and social breakdown driven by resource use. They again deliberately changed all aspects of their sustenance model and social structure in a single, closely coordinated effort:

  • Switched from unsustainable agriculture to a sustainable permaculture model 12
  • Completely eliminated expensive and inefficient livestock (pigs)
  • Substituted fish for large land animals
  • Removed social and economic distinctions—no more chiefs
  • Adopted stringent population management practices

Lessons from Tikopia

The dramatic changes in Tikopia’s social and economic model dating from ~1600 equate to a concerted shift of identity (self-definition) and state of mind for all of Tikopian society, a moment they commemorate to this day through oral storytelling. Unlike Easter Island, Tikopia’s society makes no distinction between the resources allocated to leaders and to the populace. Tikopian society does not reward environmentally destructive activity. The result is a stable population, kept carefully in balance for approximately 400 years by a range of practices that limit growth. All of these decisions were driven by a state of mind based on matching human impact with the island’s limited resources for the entire society.

Shantideva would surely say the Tikopians are remarkably flexible and resilient: instead of waiting for rescue, they averted failure (through environmental and social collapse) by redefining themselves not once, but twice.

Heed Shantideva

As an entrepreneur, I was one member of a small group making decisions about a single business venture which affected only our own lives. But as designers, architects, technologists, business owners, or anyone involved in building the new virtual societies emerging under the banner of social media, we have the power to affect many lives, by shaping self-definition and state of mind in a community from the very beginning.

We can’t predict every situation a starting society will face. But we can assume that potential failure is one challenge that may arise. And so—based on these three examples of societies facing failure—it seems wise to heed Shantideva’s advice about the exchange of self and other, thereby making our efforts now a part of the solution to future unknown problems. We can do this by allowing for changes to self definition, and by encouraging awareness of, and reflection on, state of mind, whether in our own venture or when we design a society for others.

Footnotes and References

1 They ran the gamut from debased expatriate executives, to corrupt former politicians (with gout), to alcoholic ex-CIA operatives, to the founder of a major mainframe computer maker, to veterans of anti-communist coups in Africa during the 70’s. Or so they said…

2 Bodhicaryavatara, ch. 8, v. 120

3 Diamond, Jared. Collapse: How Societies Choose to Fail or Succeed. Penguin Books: 2005.

4 Terry L. Hunt; Rethinking the Fall of Easter Island.

5 Easter Island is 1,400 miles from its nearest neighbor (tiny Pitcairn Island), and 2,500 miles from the nearest large land mass, Chile.

6 Competing clans and chiefs received social status and rewards, such as farmland and food resources, from the successful construction of more and larger statues, giving them clear incentives to continue carving and erecting Moai. In effect, Easter Island’s cultural / political / economic system was built around an unusual positive feedback loop, in which more statues for a clan meant more people and more power, which meant more statues, which meant more people and more power… Similar carving traditions exist among other societies elsewhere in Polynesia, but on much smaller scales.

7 A recent count shows 300 platform and burial sites (ahu) around the island, with approximately 400 statues. There are 300 tons of stone in a small ahu, and 10,000 tons of stone in the largest. The average moai is 13 feet tall and weighs 10 tons, the larger moai reach up to 32 feet tall and weigh 75 tons. Another 400 moai sit partly completed in quarries, reaching heights of up to 75 feet tall, and weighing 270 tons.

8 Simon G. Haberle, “Can climate shape cultural development?: A view through time,” Resource Management in Asia-Pacific Working Paper No. 18. Resource Management in Asia-Pacific Project, The Australian National University: Canberra, 1998 Working version obtained at http://coombs.anu.edu.au/Depts/RSPAS/RMAP/haberle.htm

9 Diamond writes, “The overall picture for Easter is the most extreme example of forest destruction in the Pacific, and among the most extreme in the world: the whole forest gone, and all of its tree species extinct.”

10 Rhett A. Butler, Easter Island settled around 1200, later than originally believed

11 Tikopia; Tikopia.

12 Permaculture Permaculture.

Lessons From Failure (Series Introduction)

by:   |  Posted on

At the IA Summit this year, a few of us presented a panel where we hung out our dirty laundry in front of a room full of voyeurs, many of whom accepted our invitation to come to the mic and tell their own tales of woe.

We talked about our failures—individual, structural, institutional, societal—and not just “failure” in the abstract, but specific situations, specific projects, where we personally failed. We also strove to hold back from blaming stakeholders and clients for these disasters. We owned our catastrophes and spoke about what we learned and why we are doing better information architecture today because of these painful, harsh lessons.

Each panelist addressed a different level of failure: the project level, the organizational level, the institutional level, the global level, but we all talked about why and how we fail, to what extent failure can and cannot be prevented, and how failure is an inevitable byproduct of creativity and experimentation.

With four panelists and a room full of fellows, we felt we only scratched the surface. In the welcoming pages of Boxes and Arrows, we can really let it all hang out, so we are starting a series of articles on failure. We begin with the four case studies we presented in Las Vegas, but also, we hope to include your failures and the lessons you learned. Contact me or one of the B+A editors if you’d like to contribute to this series.

On the panel we worked from the micro to the macro, but here we are going to turn that around and start with Joe Lamantia’s observations about enterprise-level failure and some intriguing parallels from the catastrophic failure of an entire society.

“Take it away”:http://www.boxesandarrows.com/view/it-seemed-like-the, Joe.

Straight from the Horse’s Mouth with Livia Labate and Austin Govella

by:   |  Posted on

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif Christina Wodtke traveled with microphone to the IA Summit in Las Vegas this year and sat down with some of the most interesting and accomplished information archictects and designers in all the land. Bill Wetherell recorded those five conversations, and now B&A is proud to bring them to you. Thanks to AOL for sponsoring these podcasts.

Christina talks with Livia Labate and Austin Govella about the UX practice in Comcast and how they have created an environment where they are treated as colleagues rather than a service organization.

We discuss…

*Big IA vs. Little IA*
Livia describes “Little IA” as the bottom-up approach to projects looking at the structure and organization of content. While “Big IA” is about acquiring user and business needs and then converging these, taking content and structure into account.

*Defining the damn thing*
Does the role define the person or does the person define the role? Austin believes that job titles are not relevant any more. What matters is learning from other professionals to improve upon a product or create a new solution to an old problem.

*Ying Yang*
The need for “specialization” and the need for “collaboration” in business is a big challenge. These two important yet distinct elements are rarely looked at in harmony.

*What is IA all about…besides “herding cats?”*
Livia defines this process through their mission statement: “Balancing user needs and business goals to create a framework in creating positive user experience”. This helps them define the boundaries of Information Architecture.

*Looking through the Looking Glass*
Austin suggests reading business publications thereby changing the words you use to sell ideas to different members of the corporation. Dress code also impacts the kinds of conversations you have with the client. Know who you are presenting too, and dress the part.

*Describing Value*
Austin discusses the importance of talking to business leaders about design choices in their own language. For example, “this move will decrease our acquisition rate”…”decrease our ability to convert people”…”decrease our referrals.” In essence, know your audience and speak their language.

*Secrets to Success*
Christina sums up this conversation beautifully, “…learn the language, lose the agenda, be a resource, and dress better!”




*TRANSCRIPT*

Announcer: This podcast is brought to you by AOL, now hiring designers in Silicon Valley, New York City and the Washington DC area. Help us set the standard for what happens next in the Web. Send your resume to UI Jobs at AIM.com today.

[musical interlude]

Boxes and Arrows is always looking for new thinking from the brightest minds in user experience design. At the IA Summit, we sat down with Livia Labate and Austin Govella from Comcast.

Christina Wodtke: Hi, I’m Christina Wodtke of Boxes and Arrows and we’re here talking to Livia Labate and Austin Govella of Comcast. We’ve been having some really interesting conversations here at the Summit about the importance of business to information architects and vice versa. So Austin’s is going to be giving a talk about that and so we thought we’d grab a couple of minutes with them and hear what they have to say. So Austin, what inspired your talk? Did it come from work?

Austin Govella: Yes, it came from work and it came from–like all the discussions we have, people have about big IA and now it’s inaccessible and, I think, they can’t do it or they’re not supposed to do it. I remember some of my experiences [indecipherable] the little IA that became big IA and I came on the idea that big IA is a way you work not the things that you do per se.

Christina: OK, some of our folks at Boxes and Arrows actually aren’t information architects and that’s a little bit shocking. So actually, Liv, can you explain the big IA, little IA definitions and how you see them at Comcast?

Livia: So generally, the way that I interpret that is little IA is really the bottom of looking at the content and building structure from it, so understanding and thinking about the more granular aspects of information and growing the structure and the hierarchies and things like that from that. The top-down big IA type of work is more looking from getting insights from user needs and the business needs and converging those things and then taking the rural aspects like content and other things into account but just from a different angle. I think it’s not a matter of one or the other, you actually have to work in both levels, and that’s something that we try to do. But it’s not like we have a formal way to do that.

But something that’s interesting in terms of business in IA is that often, I’ll get to the discussion of process, so thinking about “Who does little IA, who does big IA?” and how does that jibe with everyone else’s work? To us really what matters is servicing the business and so providing a service to the business and so the process needs to support that. So in many ways, we’re seen as top-down because we’re thinking about the goal aspects of the business and working with that to the more granular aspects of what we need to do.

Christina: A lot of people have said that the concept of big IA is really the job of a product manager or it’s something that they call user experience or UX. Your talk is to bring back big IA or at least defend it. Can you talk a little bit more about how it’s unique and why it’s important to Comcast or business, in general?

Austin: I don’t think it’s unique and I normally think necessarily it’s more important than other things so I think it is important. Even if you’re just doing a wireframe, something for just one screen or one product that maybe you’ve think only one user or need is something that’s to be driven by the business goals.

And that thinking from the goal of perspective like that, makes that one wireframe is sort of just being this one piece that isn’t in the [indecipherable] somewhere catapults that into something that’s part of the business’s conversation as a whole. And to me, that’s the kind of work that people should be doing regardless, like your work shouldn’t be just this one that doesn’t have any legs that should feed the business’s organism. So that’s the [indecipherable] I take.

Now, I don’t think it’s more important or less important than the business, but I do know like at Comcast, a lot of time people would tell me I’ll ask you a question or make a suggestion and I’ll say that’s not what IA does and I think that’s really humorous because that’s part of what I’ve been doing for years. I think it more matter that it doesn’t really belong to a specific job title. People just get together in a room and you do the work that needs to be done.

Christina: Do you think some people are a little too hung up on roles? I hear you say that’s not what IA does but you’ve been doing it for years. Does the person define the role? Does the role define the person? Because you do it does that make it IA? How do you see that relationship fitting together?

Austin: That’s a good question Christina and I’ve done a lot of thinking about this. [laughter] To me, in the new millennium, the concept of job titles and roles as silos is pretty much irrelevant. Everything is networked, everything is collaborative; everything feeds everything else.

So a lot of disciplines, they like to focus on one aspect of the entire experience. And that’s good because you need a specialist. But there are emerging disciplines or disciplines that have emerged, that bridge, that have lots of overlap like IA, like business analysis and architecture. And the overlap occurs not because they own those areas or that they own anything unique. They don’t even own the overlap but their focus is keeping all the small pieces aligned with the whole.

Now in an optimum organization, my opinion is, that you wouldn’t need IA, or an architect or business analyst because everybody on the ground would be going in the same direction but it’s like herding cats. So you need people to help you herd the cats.

Christina: So Livia, you’re a hiring manager. How does this philosophy jibe with your every day day-to-day experience, trying to get stuff done?

Livia: I think there is a very significant disconnect when we talk about those aspects of what is informational criteria, where does it fit and how does it jibe with the business. The need for a specialization and the need for collaboration are two different things. It’s collaboration of work and specialization of function. I think there is great value in specialization of function.

So I think yes! You do need an IA specialization. You need usability; you need business analysis. But the collaboration is a completely different level. The problem is that when we talk in terms of job titles, we’re not making any of those distinctions so you can interpret it in one way or another. So it becomes very convoluted to have a discussion about who is supposed to do what.

But we really should be having that discussion but it’s a discussion about process. Within the process you define roles and responsibilities but that does not at all eliminate the fact that you need to have dedicated functions. That should just exist. That should be part of the infrastructure. However, you are working your process or how rules are defined within the context of a product development process a maintenance process that is very contextual.

So it might be at one point in a particular project, the IA has a more overarching, organizing role like orchestrating what is happening. In a different context and in a different project, they have a more specific role that’s like figuring out taxonomies and categorization systems. And that is really the boundaries of the role.

So I think it’s important to have the function to indicate what is potentially offered by a function and but in the context of the project, a discussion about how the collaboration is going to work.

Christina: So I hear you say, “the business, ” a lot–“the business”–as if it was a very separate entity from Comcast or what you’re doing. How do you see the relationship of the business to your life as a Comcast employee, as your life as an IA at Comcast? How do you make that relationship with what do you say, satisfying the business or meeting that business’ needs? I think that’s the topic of your talk as well more or less.

Austin: I’ll let Livia take this first. [laughter]

Livia: I had it really good inside, during the Summit, with talking to some people because we always refer to what we do as a service to the business. After talking to people they’re like, “Why do you frame it this way? That might be the reason you’re so distant from the business.” And if you consider yourself just another business instead of the service organization that is servicing all these other business units, you’ll become an entity at the same level as them.

You may be doing the exact same kind of work, but just framing it differently might be a way to be closer to the business. So when I say, “the business, ” I mean the organization so I should probably be saying the organization and not the business. But, that’s something that…

Christina: So, it’s less than business people, it’s more Comcast, in general.

Livia: Yeah. So, when, so, we should really make the distinction of the organization and business units which are the people who are generating the initiatives that we’re working on.

Christina: OK. Do you have something further to say, roofing off of that?

Austin: Well, no, I think that’s important. And, that was one thing that, like, Adam, Adam Greenfeld complained once to me that every, all of the IA stuff is all about business. And, that makes some sense because that’s where the money is.

So, people want to kind of be close to the business talk. But, a lot of times we really do mean the organization. And that, and, if we, if we do frame it, if we were just more careful about how we framed it, then, then I think that opens, it continues to open more doors and also helps get us into other, like, other channels because it’s not just a business where you’re doing web stuff. You’re servicing organizations with experience.

Christina: So if I, it isn’t about business, then what else is it about?

Austin: Herding cats.

Christina: I think that’s project management.

Livia: So, one way, the way that we decided how do we address, how do answer that question for ourselves, and the reason why I wanted to do that is because if we don’t know what our team is about, how are we going to really be providing a good service?

So, the way that we define it, is we have a mission statement that says, we’re the field that balance user needs and business goals to create a framework to enable positive experiences. So, that mission statement defines what we do. And, we do information architecture and usability, but to us it’s a really good way to kind of define the boundaries of the responsibilities of information architecture.

Christina: So, you know, it’s always interesting to me when I hear people talk about we represent the user or we hold the user goals because I don’t know if you’re familiar with George Bull’s research but he shows that the company’s that are the single most effective are the ones in which every single person in the company are responsible for the company’s goals. So, how do you define your role in the company because you’re nodding, you know, you’ve seen this stuff, and you clearly believe it’s true. So, how do you, how do you balance both your direct responsibility to the user with the knowledge that that’s something that needs to belong to the entire organization?

Livia: So, one thing is that I explicitly ask the team not to portray ourselves as user advocates. We are user advocates. But, when we do that people have an expectation that they don’t have the responsibility So, yeah, just go to the IA’s guy, they know the users. And, that means that they are making all those, their decisions in the complete vacuum and they are not addressing those needs.

So, one thing that, I wanted to create some kind of mean that would kind of perhaps permeate the groups and kind of have the responsibility to the users in everyone’s hands. So, and I always go back to something that I heard from you Christina, which is you had those me-men, yahoo, which was every pixel has a job to make. And, I thought that was really good because in, regardless of the context, it was a good way to just kind of have that message out there.

And, we had a really big struggle internally about what is user experience in terms of which team should be called user experience. And, the developers wanted it. We wanted it. And, so, eventually, I said, OK, we’re information architecturing because really that’s what we do, but, user experience is everyone’s responsibility.

So, that became kind of the mean – user experience is everyone’s responsibility. And, I don’t know how far that has been dissipated. But, that’s something I’m trying to always bring up. And, some people have actually come back to me and said, Oh, I understand what you mean by that. But, how can I actually do something about it?

So, that allowed us to bridge some connections that we didn’t have, and say, here’s how we can help you. And, that role of user advocates, now, we can give something to them and they can be user advocates. So, it’s a work in progress. But, I’m pretty happy about where we’re going with that.

Christina: Leads can be pretty powerful, I must agree. So, to return to the sort of the concept of servicing business, how do you, how do you, what are some of the ways that you understand business and the businesses needs of the, the business needs of the organization, to use Lydia’s clarification. How do understand the business needs of the organization?

And, also, how do you help the business understand what you can bring to the table? I know that there a lot of young IA’s out there going, you know, they never talk to me. They bring me in too late, you know? How do you, how do you help them understand how you can help them?

Austin: Well, I think in terms of, like, specific skills, some things that I do that I’ve just picked up over the years of my experience is I read the business publications. Not so much so I know what all of the business people are reading. But, it changes the way you talk. You talk about things differently.

Another thing I do is just simple as dress code. If you walk into a room in T-shirt and jeans and you look designery, then, you’re the designer. And, you do, you do visual stuff, or you’re the user advocate, or whatever. But, if you walk in, walk in the room, you look like a business person, then, you’re having a business discussion because they automatically accept you in, and you’re having a different type of conversation. You’re talking about what the business model is. Or, what their goals are. Or, what type of, you know, market they’re trying to get into.

And, that’s the type of information that really helps you innovate good products and solutions. Like, knowing if they want a blue button does you no good.

Christina: Well, I’ve got to admit that looking at you two guys, I can easily picture you pitching the V.C. down in Palo Alto. You definitely are dressing the part. And, just for the folks at home that can’t see. So, you’ve got that sort of visual, business-casual thing down.

But, so to go back to it a little bit, that’s how you speak to them. How do you represent the value that you’re bringing, in particular. You can now put it into their language.

What sort of things do you talk about?

Austin: I’ll use an example because I’m trying to think, I’ll try to think of how to do this. We were discussing the header and someone wanted to put, do a link in the header back to the home page versus back to the sub-section page. So, it’s a very simple, they probably have this conversation in lots of places.

The response that I used wasn’t, you know, the users won’t like this, or blah, blah, blah. It was this will decrease our acquisition rate. It’ll decrease our ability to convert people. We’ll stop getting referrals from people. So, I couched, I couched the design solution in the business vocabulary because design solutions really are business solutions, right?

We talk about colors and experience, but those are fuzzy, abstract things. And, in my experience, couching it using the business terms has been, you’re just using different words. You’re still saying the same things, but they understand it better. They understand that if you, the link doesn’t work the way the user expects, that the business impact that you’ll have, you’ll have less advertising revenue, less traffic. The things that they can grasp.

Christina: OK. So, you’re saying, basically, that you become, in a lot of ways, the resource that they can turn to who knows about how design will affect their job and their life, and you speak to them in those terms. Because if you’re, you don’t own the user experience, but you can speak to an aspect of the user experience where you have a deep body of knowledge. And, you can speak to that in their language. Is that sort of?

Austin: Yeah. I wouldn’t have put it that way. Yeah. That’s probably, exactly what, I think that’s what I try to be is the, a resource…

Christina: Yeah.

Rather than, even more than just the service provider, just, like, a resource that can offer insight and…

Livia: And, that also, the way to do that was something that I struggled with for a long time because if, depending on how you frame it, if you talk, I noticed that whenever I talked about design, people lost interest. So, I stopped talking about design. And then, I started defining the types of things that we have to offer in different terms.

So, the way that we have, and there, we have our mission statement. And, we have like this dot Venn diagram that says, Discovery, Modeling and Validation. So, those are the three strengths that we bring to the team. And, within these three strengths, we have specific types of activities that we can do, like, Discovery and User Research, or Usability Assessments, you know, Task Analysis. Anything that, you know, tools of the design trade that we’re just framing as here’s, are the tools that we have to offer you, and these are the results that you can get out of it.

So, just framing in that way was very, also very helpful in getting people to understand what we do and understand how we can help them. So, they can, you know, it actually generates business for us because now they can come to us and they know what we do and what to expect.

Austin: And, I want to add something. One of the things that, sometimes, I’ll throw emails to Livia that, so that she can look at them and make sure that, you know, I know that I’m communicating, you know, the way I want to be communicating. One thing that she suggested was, not the exact words, but, just lose the agenda. Like, when they ask a question, just answer the question.

And, I think that when we talk about design to business people, we’re carrying our agenda with us. We care about design. We care about that language and that viewpoint, but they don’t care. They have a specific business question and when you answer their question then that’s, you’re solving the problem.

Christina: Great. So, learn the language. Lose the agenda. Be a resource. And, dress better. Secrets to success. Fantastic. Thank you, guys.

Livia: Thank you.

Christina: This was terrific.

Enterprise IA Methodologies:

by:   |  Posted on

Information architects working within enterprises are confronted by unique challenges relating to organisational culture, business processes, and internal politics. Compared to public website or interface design projects, key aspects differ in the application of IA discipline relating to uncertainties around the exact nature of the business problems being solved.

In a typical web or design project, the information architect is given a task, such as:

  • Improve the design of the website for consumers
  • Develop a user interface for a new business application
  • Make it easier for staff to find information on the intranet

In all these cases, the problem is known, and the challenge is to work out the best way to design the solution. User-centered design methodologies then provide a rich toolbox for delivering an effective solution.

However, within the enterprise space, the problem to be solved is often not well understood. For example, information architects may be approached with ill-defined “problems” such as:

  • Improve the effectiveness of the intranet
  • Help call center staff to access required information
  • Increase the uptake of the document management system
  • Support sales staff with better online resources

The first task for the information architect in this context is to better understand the problem. Only then can an overall approach be defined, and the normal user-centered design process initiated.

In practice, this means that enterprise IAs often start two steps earlier, focusing first on analyzing needs, and then defining a strategy and scope to meet those needs.

Traditional IA methodologies

EIA.0407.diagram1.jpg
Diagram 1: Illustrates a typical IA approach

While there are many valid ways to redesign a website or intranet, most projects start with user research to identify user tasks and goals. Then, the IA uses these results to develop a draft IA, which is tested in an iterative manner. Wireframes detail the user interface, and usability testing or similar techniques are used to refine it.

The overall goal of this approach is to clearly understand what the user is trying to achieve when using the site or system, allowing the IA to develop a solution that is both effective and satisfying.

This much is well understood, and much better documented elsewhere.

Enterprise IA approaches

Within the enterprise, the core user-centered design methodology remains just as valid. However, to be effective, the process must start two steps earlier.

EIA.0407.diagram2.jpg
Diagram 2: Illustrates an Enterprise IA approach

Step 1: Needs analysis
The first step now becomes needs analysis, which uses the same user research techniques as in typical user-centered design (interviews, contextual inquiry, observation), but to different ends. This time, we don’t ask questions about the system, but instead focus on obtaining a more complete and holistic picture of what staff do and the environment in which they work.

This might include questions such as:

  • What activities make up your job?
  • What information do you need to do these activities?
  • Where do you currently get this information?
  • How do you find out what’s happening in the organisation?
  • What is the most frustrating task you had to complete in the last month?

Rather than support the design process, this research helps the IA understand the nature of the problem. Open-ended and ethnographic, this research will undoubtedly highlight the unexpected and the unknown, both of which radically shape the approach going forward.

(For more on needs analysis in the context of intranets, see my earlier article on this topic, “Succeeding at IA in the Enterprise”)

2: Strategy and scope
The needs analysis then informs the creation of an overall strategy, scope and direction. From this clear framework for the IA work, a comprehensive overall roadmap of the activities required can emerge. The strategy also identifies the most critical issues to be solved, along with the activities with the potential to deliver the greatest business benefits. In this way, the IA work can be targeted for the greatest impact.

In many cases, needs analysis helps the team discover underlying issues which need to be addressed before any IA or design activity can succeed. (Cultural and business process issues are common examples.)

Together, the strategy and scope define the “problem” and provide a concrete context for the user-centered design process. Along with the illumination of the practical aspects of the work to come, the strategy also builds the business case for change and creates a sense of urgency.

A real-life case study drawn from a number of different intranet projects in call center environments illustrates the effects of the enterprise approach.

Case Study: Call Centers

In many organisations, call centers now serve as the primary point of contact with customers or the public. Whether in the insurance industry or within a government agency, call centers handle a huge volume of queries and transactions.

Within the call center, staff work in a high-pressure environment. They are expected to literally answer questions correctly within 30 seconds. Failure to deliver the right information leads to customer complaints or legal liability (organisations are directly responsible for every piece of information given out by a call center). Slow response times can create long queues, more complaints, and customer attrition.

To meet these expectations, call center staff require an effective and well-designed set of information resources. The typical call center intranet contains a large number of documents and news items for staff.

As an information architect, we are often brought into this environment to ‘redesign the call center intranet, to make it into an effective resource for staff. Based on experiences in other environments, it is natural to make a number of assumptions about where efforts should be focused:

  • The most common questions or transactions handled by staff should be identified
  • Effort should then be focused on providing resources to answer these key tasks
  • Paper resources should be migrated onto the call center intranet where possible
  • A user-centered redesign should be conducted of the call center intranet, to ensure it is effective

Spend a day or two in the call center, and the gap between these assumptions and reality will quickly become apparent. Let’s look at a call center in the insurance and investment industry.

In this particular case, the most obvious non-technical artifact in the call center was the book of photocopied notes that most staff had sitting beside them, scribbled on and annotated with sticky notes. Then there were the sheets pinned to the cubicle walls, similarly inscribed.

Additionally, product brochures adorned everyone’s desk to cover the 30-40 products sold at any given point. A deeper look uncovered the huge amount of email filed away in folders within Outlook.

There were good reasons why the call center worked in this manner:

  • Customers rang up asking, “On page 54 it says this, but what does it mean?” The call center staff needed to quickly access the same page to walk them through the details.
  • Key information (such as system codes) needed to be instantly available. Pieces of paper pinned to the wall would always be quicker than looking up an electronic system.
  • All important communications were broadcast via email, and maybe (only maybe) added to the intranet. Since the details probably were not needed at that point, it was necessary to file away the emails for later use.

In this situation, we drew some unexpected conclusions from these (and other) observations, even having been primed by previous call center projects.

In the end, our efforts focused on:

  • Managing uncommon rather than common details: The information related to the most frequent queries or transactions resided in the heads of staff. The complex issue that only came up every 6-12 months posed the real challenge.
  • Capturing old rather than new information: The brochures for the current products worked perfectly well. The real problem came from investment products that could go back decades and were still covered by the original terms of the contract. Finding a 20 year-old printed policy was not easy!
  • Eliminating email as the distribution mechanism: As long as email remained the primary way to deliver critical information, the intranet could never succeed. There were also clear productivity benefits in eliminating the duplicated information management conducted by every individual staff member.

The net result was that the call intranet still needed redesigning, but the needs analysis gave a very clear idea of where to focus efforts and identified the unique environmental aspects of call centers to be taken into account when conducting any work.

Solving the Wrong Problem

This case study highlights the importance of conducting the needs analysis process before embarking on any design or development activities. Failure to do so exposes the organisation to the risk of solving the wrong problem—putting significant effort into developing a solution that fails to work in practice.

Always assess the issue at hand to work out whether it is the cause or merely the symptom. For example, the intranet may be very poorly structured, with considerable usability problems. This naturally calls for a user-centered design project delivering a new IA and page layouts.

However, the underlying causes of the problem may be the disorganised publishing model, the lack of resources, or key cultural problems. If only the symptom (the design of the site) is tackled, the site will immediately start to slide back into disrepair the day it is re-launched.

A small piece of initial needs analysis work and strategy and scope planning allows identification of these underlying problems. Address them, if possible, before (or during) the project, improving the chances that the site continues to prosper post go-live.

Summary

Within the enterprise environment, our methodologies must start two steps earlier than the typical user-centered design process.

  1. Make use of holistic needs analysis techniques to build a clear picture of the real needs and issues of staff, along with an understanding of the environment in which they work.
  2. Then create a meaningful strategy and scope that identifies the symptoms and the causes. This information allows us to correctly target our work and ensure that we deliver solutions that actually work for staff.

 

(All of this is not to say that it’s easy to get the opportunity or the mandate to conduct this initial work, before being forced to jump straight into the design process. But it is possible—we’ve done it many times—and a discussion of how to tackle the broader positioning of enterprise IA will have to wait until another article.)

About the author
James Robertson is apparently the “intranet guy,” or so he was told at the IA Summit in Vancouver. He runs Step Two Designs (www.steptwo.com.au), a consultancy based in Sydney, Australia, and has written over 150 articles on intranets and content management, which can be found on his site. He also has a blog, the writing of which gives him something to do each morning while his brain warms up.

Using Technical Communication Skills in User Experience

by:   |  Posted on

It started with the small stuff. I sweated it all: field labels, button positions, lining up the label and the field, ensuring the icon was understandable. After 2 1/2 years of correcting designs, the heavens opened: the project was delayed, and no one could do the requirements and UI design. How were they going to get it all done? Special T (that’s me) stepped in to save the day, of course. “If you don’t have time, then I’d like to do it.”

I don’t care; I’ll take scraps (err—experience) where I can get it. I come from a technical communication background and seen many successes and failures with user experience in the software world.

It started as a backwards, fix-the-design approach but eventually became a more forward process, designing from a blank slate. Technical communication skills can be a great starting point to an interesting and more lucrative user experience career, if the communicator knows how to apply those skills.

User experience professionals can also learn some lessons from and find potential recruits in technical communicators as they have skills that can be applied directly to the design process. Continue reading Using Technical Communication Skills in User Experience