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.

Pioneering a User Experience (UX) Process

by:   |  Posted on

Maybe you’ve recently been hired by a company who wants to “do usability.” It could be that you’re a UI designer, business analyst, or front end developer who’s been conducting impromptu hallway usability tests and you’ve started to think you might be on to something. Or perhaps you’re a product manager who’s realized that the key to a better product is a better understanding of the people who use it. Whoever you are, wherever you are, one thing is certain: You’ve got your work cut out for you.

Creating a User Experience (UX) process can be a very rewarding journey; it can also be a nightmare if approached from the wrong angle. Initiating a culture-shift, overhauling existing processes, evangelizing, strategizing, and educating is an enormous undertaking. Often it’s a lonely path the UX advocate walks, especially if you are the only one who is driving that change from within the company. But that path is ripe with opportunities to improve your company’s product creation process, as well as the product itself.

So, where do you start? What approaches work? What pitfalls can be avoided? How can you stay motivated, encouraged, and professionally connected—even if you’re flying solo?

Why Create a User Experience (UX) Process?

Understanding why you should create a UX process is a good place to start. If you’re already in the initial stages of UX startup you probably have a number of answers to that question already. It’s important that you know why using a UX process is valuable because you’re going to be explaining it to everyone. A lot. Many companies are just starting to realize the value of keeping their end users in mind before, during, and after the product creation lifecycle. If your company hasn’t quite figured this out yet here are two of the most powerful arguments you can make:

  • A UX process helps build products people want and need
    You’ll create a product that’s a good fit for the people who end up using it—instead of for the developer who built it or the CEO who envisioned it. This is particularly important if your users also spend their hard earned dollars to buy your product.
  • A UXprocess saves time and money
    Your team will save valuable time and resources by getting it right, or mostly right, the first time. And they’ll be faster doing it.

Keep in mind that both arguments have a strong tie to something many people in your company already value: Money. Whether it’s money gained through sales or saved through efficiency, financial impact is a very tangible way to illustrate the value of UX activities.

Start Small

Starting small will keep you from biting off more than you can chew, but it also allows you to focus your attention on building your process from the ground up. You’ll be nurturing both your growing process, and the people with whom you work, as you go. A gradual introduction to UX methodologies is much more effective than trying to completely change everything about the existing process all at once.

If you attempt to immediately overhaul the existing process you risk overwhelming, intimidating, and offending many people who could otherwise be turned into UX allies. So pick a smaller, less visible project where you can start integrating new techniques while showing your team how to build products with your users in mind.

Be sure to document and track the progression of UX activities and outcomes so that you can use that information in the future to illustrate how your process works.

Find Business Drivers and Track Against Them

 

Simply put, numbers talk. Find out what your company’s goals are and align your UX goals accordingly. When you know what’s driving strategy in the finance group, or what targets the marketing team is aiming for, and you can show how your work helps achieve those goals, you’ll be speaking their language.

For example, if one of the primary initiatives company-wide is to reduce costs by reducing the number of tech support calls, make one of your primary UX goals for the next release improved usability and a higher rate of self-support. Get a current baseline for how many tech support calls are being received on the current product and at the end of your project do a comparative analysis for the reduction in tech support calls.

Plan UX Activities Upfront

 

Another great reason to pick a smaller project is that it’s more likely you’ll have some influence on the project planning. By working with your project manager in the early planning stage you’ll be able to prepare the team for the UX activities you will be leading. If you don’t show up early and stake a claim to the dates and gates on your project, you’ll end up squeezing your research and design activities into a process that already exists—without you.

Ideally, you’ll plan an ideation phase or “iteration 0” where you help clarify business requirements by researching the real people who use your product. Iteration 0 may include some initial conceptual design work as well. When project iterations begin, you’ll have negotiated what sorts of UX activities are going to take place as you move from one iteration to the next.

Go Deep, Not Wide

A common pitfall to avoid is spreading yourself across too many projects. If you’re the only person doing UI design and usability research, it’s tempting for project managers to want you to consult on all of their projects. Avoid this at all costs.

Distributing a single UX resource across multiple initiatives is destined for failure for two reasons.

First, by working broadly across many different projects, you compromise the quality of your UX work. You run the risk of producing mediocre results on many projects, rather than doing a great job on one or two projects. You need strong examples of success, especially if you’re trying to convince others why a UX process is valuable.

Second, you will rapidly become burnt out and frustrated because you never have the opportunity to impact any real change. When your role on a project is limited to someone emailing you for your opinion, or briefly running an idea past you without any deep contextual understanding of the project, it won’t take long for you to become disillusioned. Your role on a project needs to be more than just providing the UX seal of approval.

It’s difficult to find the balance between advocating a UX process and having to say no to some projects. You may feel like you’re delivering a mixed message because one day you’re explaining how important UX activities are and the next day you have to say no to a project. But here’s the twist: As demand increases, it provides more support for growing your UX team. Every time you have to say no in order to keep your focus deep, remind those around you that it’s a sign you probably need more UX resources.

Be Realistic and Flexible

Do a reality check and figure out how much support exists for UX activities in your organization. Then adjust your expectations accordingly. If many of the people with whom you work are new to the concepts of user-centered design and usability testing, then you probably won’t be able to spend months on ethnographic research or thousands of dollars flying around the world to conduct elaborate usability tests on site.

Stay flexible. Make your points and recommendations, but show that you can see all sides and are willing to compromise as needed. Avoid dogmatic thinking that says there’s only one way to correctly do usability research or design. At this stage it’s less important that you do everything by the book, perfectly, formally—and more important that you integrate the user’s perspective to make your product better. Keep your idealism in check and introduce people to UX methods gracefully instead of beating them over the head with it.

If you’re a perfectionist you may feel like nothing is being done the right way at first. There will be a lot of kinks to iron out before your UX process runs smoothly, so try to go with the flow during this awkward stage of your evolving process. Remind yourself that the smallest amount of UX activity is light years beyond no UX activity at all. In this early phase, even the smallest bit of user perspective can have a profound effect on the outcome of your product.

You’ve heard it a million times before: There’s a lot of low hanging fruit. Don’t get too caught up in worrying about how it’s being picked, just make sure it gets picked!

Watch Out for Toes, but Don’t Avoid Them

It’s inevitable that, over the course of building a UX process, you’ll bump into others who feel you’re encroaching into their area of contribution or expertise. No one wants to hear that their way of doing things results in a bad product or the company losing money. No one wants to hear you telling them your way is right and their way is wrong.

The key is to show, rather than tell; persuade, rather than dictate. Use a screen/video capture tool, such as Morae, to make video snippets of users struggling with that widget everyone on the team thought was so cool. Convince your developer that you can make her job easier and save her time by doing the conceptual design and sketching out some prototypes before she ever starts writing a line of code. Show your product manager that you can help him define his business requirements by talking to end users and finding out what their needs really are.

Once you’ve built credibility with the team and have diffused any potential rivalries, you’ll all be on a level playing field. Then they’ll look to you for your perspective, input, and expertise rather than being threatened by it.

Be Patient and Set Clear Expectations

Being patient can be one of the hardest things about building a new UX process. It doesn’t matter how committed you are, how many hours you work, or how persuasively you evangelize…it won’t happen overnight. It’s important to set realistic expectations with others, as well as yourself. Set clear, attainable goals with your manager at your yearly review. Review those goals together quarterly and make adjustments if needed. Communicate openly about deliverables and milestones with your project manager and other stakeholders. Then deliver.

With every expectation you meet, or exceed, your case for the UX process will be building momentum. Visibility and understanding will increase with every win you publicize. But be patient.

You’ll probably have days where you question whether you’re making a difference, whether you’re making any headway at all. You’ll have days where you feel frustrated and confused. When you start to question the impact you’re having, remind yourself how far you’ve come since the pre-UX days.

Get Creative

Because you’ll almost certainly have limited resources, it pays to get creative. Show your team that UX activities do not need to be expensive or time consuming.

  • Is anyone in your company a representative user? Grab them and schedule a feedback session on your wireframes. There’s no need to recruit strangers to help with usability research unless your end users are highly specific and there are no representative users available.
  • Do you need global perspectives but have no budget for travel? Conduct remote contextual interviews and usability sessions. Webcams and online software such as WebEx and UserView make it easy to connect to users all around the world and gather valuable information from them.
  • Have you been told there won’t be a budget for hiring more UX professionals in the next few years? Teach your developers some UI design best practices, show business analysts how to conduct usability tests, lead participatory design sessions with your team. If you know you can’t hire more UX practitioners, start teaching others how to make good UX decisions.
  • No budget for expensive software and research tools? It’s amazing how much you can learn using paper, pencils, pens, and sticky notes. Learn more about paper prototyping and guerilla HCI.
  • Email video clips from usability sessions. This is always a great way to spread the UX message because it’s hard to argue with the real live people who are shown using your products.
  • Make posters showing common UX mistakes and great UX solutions.

Document Your Wins, Then Publicize Ruthlessly

 

This is probably the most important thing you can do to sell the value of UX within your organization. This is where you put it all together. You’ve focused deeply on a small project, planning and tracking UX activities from beginning to end. You understand what’s motivating your company and you can show improvements in the user experience that support those goals. Because you measured the user experience of your original product against the new product your team just built, you can prove how much better the new product is for your users. And you can clearly tie those improvements to the UX process your team employed during the project.

Once you have one UX win, no matter how small, that you can clearly map to your process publicize that story ruthlessly throughout the company. Be sure to credit the entire team for their role in the UX work that contributed to the project’s success. And get ready for more work to come your way.

Being Shallow

by:   |  Posted on

“It is important to consider the balance between breadth and depth in your taxonomy.”

—Lou Rosenfeld and Peter Morville, Information Architecture for the World Wide Web 2nd ed., p. 67

“Deep down, I’m a very shallow person”

—Charles Haughey

We’re all painfully familiar with flame wars. But they’re not always marks of dysfunction. Watching flame wars over a period of time can make one aware of patterns within a profession. After witnessing a few acrimonious threads, you start to notice the personalities that play different roles in that community: the elder statesman (usually one of the younger ones), the enfant terrible (usually one of the older ones), the one who tries to make everyone get along, the one who delights in poking people with a stick. You can watch allegiances form and re-form as circumstances change, and glimpse the darker and less friendly thoughts of all those smiling faces at a conference. Above all, you can find the hot buttons: the statements and accusations that will always provoke a hostile response in the community.

In my lurking on various IA lists over the past 4 years, I’ve noticed that some accusations can always be relied upon to get IAs angry and vocal:

* IAs are history. They used to be cool, but they got caught on a few irrelevant issues, and have lost their chance to gain and hold a central position in today’s information environment;
* IAs are insular. They are unfamiliar with, and indifferent to, things going on outside the world of wireframes, facet analysis and web analytics;
* IAs are shallow. They may be flashy and indeed intelligent, but they don’t think deeply about things, and they have failed to reach the subterranean profundity that other fields have attained.

These are serious accusations: so serious that it’s easy for IAs to forget how easily one can make such accusations about anything, and how common such accusations are. In my 20 years on the academic conference circuit, I’ve seen many speakers punctured during question period, not by a loud-mouthed bully (although they show up, too), but by a weary, kind-looking figure with a gentle voice, who is normally reluctant to make a fuss, but cannot, simply cannot let such intellectual prostitution take place without raising an objection.

But these accusations, while easy to level at another, are not so easy to deflect. If you refute them, you sound defensive; if you get angry, you lose the moral high ground. And if you let it go, people might think the accusations are true.

And what if they are?

Let’s face it: the accusations are serious. So, let’s take them seriously. What’s more, let’s assume for the moment that they’re true, take them in reverse order, and delve into them more deeply.

1. IAs are Shallow.

Long before Dorothy Parker accused Katherine Hepburn of “running the gamut of emotions from A to B,” we’ve all been terrified of having a narrow range, or of having no hidden depths. The terror arises from that gnawing suspicion that it’s true, together with a hideous fear that other people span the whole alphabet.

Here’s a suggestion to begin with: recognizing your shallowness is perhaps the most profound act of your intellectual life. It’s the recognition that you’re mortal, that you’re busy, that you’ve got to survive in a cruel world, and that there’s more to read, more to write, more to think about, and more to solve, than you could ever possibly manage in your lifespan. I suspect that most of the standard disciplines begin with this recognition of shallowness. My doctoral program in English, which I thought would open doors onto a wild orgy of knowledge acquisition, forced me to close all kinds of tantalizing doors, and confine myself to a tiny, tiny, tiny patch of ground that I could master in four years. I’m a Doctor of Philosophy, and if you want to know how much money Juliet Granville had in her purse on page 254 of Frances Burney’s The Wanderer, I’m your man. But like most Ph.D.s, I emerged from my final thesis defense, not empowered by a sense of mastery, but horrified at how little I knew.

I sometimes wish that IAs were more shallow, that they were less insistent about staying at that giddy nexus where your small activities resonate across the entire networked world. I’ve been known to hide in my hotel room at the IA Summit, rather than risk being invited to dinner, simply because I don’t have the energy to hold up my part of an intense conversation. I sometimes wish we were less eager to leap from visualization to facet analysis to web analytics to information scent to pace layering before I’ve even had a chance to look at the menu. What some people would call shallow, I would call a fear of being shallow, which translates into a frenetic inability to calm down.

What’s more, this inability to relax and be shallow is a formidable barrier to IA curriculum development. A field has to have patches of stability: areas that stay constant, not because the world is constant, but because people are sufficiently mule-headed to insist on not changing. Ranganathan’s Colon Classification foundered, at least in part, because he kept tweaking it massively from edition to edition, making it impossible for libraries to keep up. And a curriculum of study can only develop when a field hits a good mix between navel gazing and stubborn obliviousness. Questioning is good; questioning is necessary. But there have to be times when you fold your arms and say, “Because, that’s all. Just because.” ( I teach cataloguing, and I’ve grown used to saying that. ) The fear of being shallow could prevent IAs from reaching a working consensus on what constitutes an adequate skill set.

2. IAs are Insular

Yes, they are. I’ve never seen a field more earnestly dedicated to welcoming newcomers at the IA Summit. We have nuts and bolts; we have newcomer tables; we have baseball cards. (I tried to get my sister to accept my swimlanes card in exchange for her treasured card for Jean Beliveau of the Montreal Canadiens, but she refused.) And yet in the registration area you inevitably hear wild shrieks of joy as delegates fly rapturously into each other’s arms and start making plans for a no-holds-barred, dish-it-all dinner, far away from all these other tiresome people. And at one point in every summit, the Argus Rapture occurs, where everyone who ever worked for Argus suddenly disappears for a dinner of reminiscing.

IAs make friends. IAs love each other. IA is a community, and one with solidarity and affection and mutual respect. There are worse things to be. And I can attest to the fact that if you hang on and stick it out, you’ll get in there eventually.

But what about intellectual insularity? What about the accusation that we’re not familiar with the work being done in other fields? Here, the problem is more complex, and I think it revolves around a nasty distinction: the field of practice, and the field of study.

IA professes to be a field of practice, and aspires to be a field of study. As a field of practice, it has no great need to define an intellectual foundation of its own; as a field of study, it can’t live without one. If IA is a field of practice, it simply needs to combine ideas wherever they can be found into a set of practices and skills that others find useful. If IA is a field of study, it requires a distinct field of discourse, with both canonical and resistant texts, multiple voices, and a constellation of methods of inquiry. As a field of practice, IA can lift whatever it wants from philosophy, computer science, architecture, graphic design and library science; as a field of study, IA must appropriate and redefine those things into a common discourse.

I, for one, believe that developing that common discourse is a good thing. But imagine how it looks to outsiders. Those of you with children probably know how hard it is to watch them learn to do something you know how to do very well, and how overwhelming the temptation can be to rush in and fix things that you know will go wrong. Those of you with older children probably know how irritating it is when your children learn rapidly to do something that took you years of painful study to learn, and how disorienting it is to see them appropriate that knowledge in a totally different way.

It’s hard for experts in the fields that feed into IA to sit back and watch us stumble around, and probably harder still to watch us leap ahead unexpectedly, often at the cost of some unquestioned dogma in the parent field. And it’s hard for IAs not to snap with irritation when someone pipes up with phrases like, “you’re doing it wrong, you know.” It’s especially difficult to remember that phrases like that are infinitely preferable to the alternative: “I thought all along that you were screwing up, but I didn’t want to say anything.”

Maintaining a certain insularity is a necessary part of nurturing a common discourse; like children, we’ve got to learn to do it ourselves. The challenge lies in ensuring that cordial and productive relationships are maintained between those fields that lie outside that discourse; like children, we’ve got to learn to ask for and give help. And if we sometimes don’t get the mix right: well, what family does?

3. IAs are History.

It’s true, and I for one am glad that it’s true. Christopher Hitchens “once called”:http://www.identitytheory.com/people/birnbaum22.html North America the only culture “in the history of the world, where the words ‘you’re history’ are an insult.” Against a culture-wide disdain for history, and for longitudinal perspectives on current problems, prominent IAs are mounting a vociferous resistance. Peter Merholz, in his closing plenary of the 2006 Summit, treated us to an enlightening history of the term “information architecture,” showing us that the term has indeed a history, and that the concepts have a history longer than the actual term itself. As a profession, IA is struggling to avoid reinventing the wheel, and that can only come from a sense of history.

But what is history, anyway? T.S. Eliot once said that history is a collection of timeless moments, and that’s a very apt description of what IA is all about. Underneath all our usability studies and frameworks and paradigms and swimlanes and facet categories lies a core conviction: if you’re going to present complex information effectively, you’ve got to stop and think about it. You have to insist on your right to stop and think.

That’s not easy to do, when a chorus of voices is telling you that you’ve missed the boat, and that the world has moved on. It’s even harder to persuade an organization to do it, when its leaders are afraid of becoming history. Of course the world has moved on; the environment that produced the first edition of the Polar Bear Book is ten years in the past, on the other side of Google, the dot bomb, the Web 2.0, 9/11 and American Idol.

Information architecture at its best is not about the cool, the newest, or the latest. Information architecture is about the breath, the pause, the stillness in the eye of the information hurricane. I’ve experienced that stillness in many places. I feel it when I play Bach, and sense those incredible structures that stand like cathedral arches within the myriad notes that I’m trying to play. I feel it when I’m programming, and I sense the logic of the program I’m struggling to create emerge out of all my false starts and stumblings. I feel it whenever I see someone, from whatever walk of life, come down from the heights to figure out patiently what’s happening between A and B. IA is history, and a part of history: one class of those timeless moments in human life when we’ve stopped chasing about, one of those moments when we’ve stopped to think.

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.