Lessons From Failure (Series Introduction)

Written by: Christian Crumlish

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

Written by: B&A Staff

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

Written by: Grant Campbell

“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

Written by: Christina Wodtke

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.

Using Technical Communication Skills in User Experience

Written by: Theresa Putkey

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.

Technical Communication Skills

Technical communicators may be the only user representative in an R&D group. As a more traditional role, managers have some embedded idea of professional responsibilities. In these situations, the communicator must speak up often: when an error message sucks, when a field label is inappropriate (or misspelled), or when the flow of a wizard doesn’t work.

Communicators must understand both the forest and the trees, and they must constantly scan for inconsistencies. As a best practice, communicators create documentation plans that include help topics, embedded assistance, and context sensitive help. When the plan doesn’t flow, the communicator speaks up to illuminate the shortcomings of a design. (A solid plan, like a solid information architecture, highlights when a feature is problematic or just doesn’t fit.)

As a communicator moves from novice to master, emphasis moves from editing messages and button labels to the placement of those elements. Grouping fields on a form or the location of forms in a program transforms into scenarios and use cases behind those forms. This is how I started my move from technical communicator to user experience.

Along with the big picture/detail skills, communicators must be able to structure information and see the not-so-obvious structure of an interface. Structuring information starts with the documentation plan, but goes beyond that exercise. As features are fleshed out, more information becomes available and must fit into the plan. I liken it to expanding an information architecture: your architecture can be too ridged, too flexible, or appropriate and accommodating.

Eventually the ambitious communicator can start to develop the initial design instead of fixing it, or find opportunity in a design vacuum, as I did. When I volunteered, the project leads thought this was a perfect fit. I always complained about the design, so why not let me do the initial design? (I also benefited from a trusting team that worked well together.)

Giving something in return: how communicators can help UX pros

Communicators are the UX professionals’ natural ally. Since communicators know that fantastic documentation can’t make up for a poor design and system architecture, they champion the cause of better design and information architecture. Communicators are in the trenches, talking with QA and developers about problems and how to solve them.

On multiple occasions, coworkers asked me about changing a design that was created by the UI designer. “It’s just a small change, can’t you just make it? It’s not a big deal.” Having seen the results of a lot of small changes, my responses included:

  • I’m sure the designer would love to address your issue…
  • I’d love to help you, but I really feel that I would be stepping on toes by fixing the problem myself…
  • He won’t bite, I’m sure he’d be happy to talk to you…
  • I know he’s busy, but I’m sure if you told him it was urgent, he’d be able to help you…"

 

Communicators reinforce the idea of a formal design process and back up the designer in advocating a positive user experience. In certain company cultures, designers can be seen as antagonistic to developers and QA. Communicators can use relationships with these roles to smooth the way for the UX professional.

How to make that move

Based on personal experience and speaking with other communicators and UX professionals, here are my recommendations for making the move either as an employee or independent:

  1. Ask and don’t take no for an answer: The best way to get what you want to is to let people know what you want. It’s a good life skill. I became a communicator because I asked for the job. Once I had communication experience under my belt, I started to ask for UX opportunities and unknowingly started structuring and restructuring information in help systems with better information architectures.
  2. Just do it: If you see a need, fill it. Sometimes it may not be appreciated, but more often these kinds of actions are labeled as “proactive.” If you see a bad design, sketch a better one and show it to the most appropriate person, being sensitive to the group dynamics and company culture. Make sure you appreciate the effort already given and stress that you are representing the users’ interests.
  3. Build relationships: with coworkers and managers, making sure to tell them your career aspirations. Tell them in terms of “this is what I do and this is how it can help you.” One day, when a developer or manager has a problem, she might think, “Theresa told me she could help me if I ever had this problem…” It takes effort (and constant vigilance!), but it can work.
  4. Get a mentor: I’ve had several mentors over the years. At one company, the UI designer taught me task analysis, user analysis and UI design. He did several training sessions for the whole team. After joining the IA Institute, I found a mentor to help me identify my transferable skills and learn how to sell my services.
  5. Get your foot in the door: Taking a communicator contract can be a foot in the door to a UX job. You can get in, do a great job, figure out the company culture and scope out the opportunities for UX work.
  6. Take a class, network, moonlight: To gain knowledge outside a company, take a class on UI design or information architecture. Many websites have lists of these kinds of classes. Networking at local user experience groups is a great way to meet peers. Eventually, you might find small contracts you can do in your spare time. When you want to complete your move, you will already know people.
  7. Do informational interviews: From your networking, you’ll know people. Meet them for 20-30 minutes and ask them what skills they use, what challenges they face, what they like about their job, what they think you can do to make the move, what the market is like. Keep in touch, keep networking.

Remember that it might take longer than expected: I love when things happen overnight. I’m an instant gratification kind of person, so naturally my move is taking longer than anticipated. I keep advising myself to stick with it. As an external motivator, my spouse would freak if I went for a career change! Being independent was enough of an adjustment.

Conclusion

I’m following my professional passions from communicator to user experience professional. I’m a mover and am trying to smooth the way for those who will come after me. Not all communicators want to be in the UX field, but for those who do it is a natural move.

For those already on the design side of the house, hopefully technical communication colleagues can become allies, and you can look to them for support, insight, and maybe even as your next new hire!