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.

Enterprise IA Methodologies:

Written by: James Robertson

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

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

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

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

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

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

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

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

Traditional IA methodologies

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

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

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

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

Enterprise IA approaches

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

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

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

This might include questions such as:

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

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

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

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

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

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

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

Case Study: Call Centers

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

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

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

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

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

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

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

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

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

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

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

In the end, our efforts focused on:

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

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

Solving the Wrong Problem

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

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

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

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

Summary

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

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

 

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

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

Using Technical Communication Skills in User Experience

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!

Two Designers, Two Years, One Facelift…

Written by: Alex Chang

I can’t recall how or when I first learned of the Boxes and Arrows redesign contest. On July 5, 2004, I sent an email to a good friend, Matt Titchener, proposing that we enter the contest together. I got to know Matt while working with him at a nonprofit organization developing intranet web applications. We discovered that we shared the same appreciation and views toward usability, accessibility, web standards, and visual design. Matt is also one of those rare talents that possess great design ability as well as a keen technical understanding in web development/design. After confirming Matt’s interest in the contest, we embarked on what would become more than a two-year journey to redesign Boxes and Arrows.

The contest

From the start, Matt and I agreed to take this contest seriously, approaching it as if we were revamping a website for an actual client. We spent much time studying the existing site hierarchy and brainstorming for ways to produce better user experience. We knew that we didn’t have to convince Boxes and Arrows’ audience of all the invaluable and insightful articles and discussions on the site. It was only a matter of how to get readers to the content more effectively. We were looking to accomplish a very intuitive navigation and site structure/flow to allow the readers to reach their desired content with the fewest clicks possible. It took us roughly a month to create our initial design concept (see Figure 1 & 2), which we are still quite pleased with even to this day. Then with about four days remaining to the deadline, I revisited the contest guidelines and comments posted by the Boxes and Arrows staff. I realized that the B&A folks were looking for a fresh and entirely different look, but the design that we created still too closely resembled the existing site (with its color scheme and layout).

I became convinced that in order for us to have a better chance at winning the contest, we would have to rethink our concept. So painfully, we decided to put aside the design that we had worked so hard on, and started from scratch with a different visual approach. After a few sleepless nights, with heavy bags under our eyes, we submitted our new design concept less than two hours before the contest closing time (see Figure 3 & 4).

Then we waited…

Three months later, I received an email with the subject line “Congratulations!! You have the winning Boxes and Arrows Site Redesign Submission.” I habitually ignore and delete all email that has subject lines beginning with “Congratulations!! You have won…”, assuming spam, so I nearly missed this one! Not until I read through my inbox more carefully later that day and recognized it was from Erin Malone, did I realize that we had actually won the contest. I immediately rang up Matt in London to share the good news with him. I stopped everyone that passed my desk that day to tell them all about the contest. The announcement of our win put a fixed grin on my face for days to come.

front page
Figure 1: First iteration of the front page design

author page
Figure 2: First iteration of the author’s page design

front page contest
Figure 3: Final front page design submitted to the contest

category page contest
Figure 4: Final category page design submitted to the contest

Redesigning the redesign

In January of 2004, we began working with Christina Wodtke and Erin Malone on the implementation of the design. During one of our initial conference calls, we asked for permission to create another design concept different from the one we submitted. Since we only had a very short timeframe to put together the contest entry after our decision to start from scratch, we felt that we did not have adequate time to create a design that fully represented our capability or design vision. Christina and Erin kindly agreed to our request.

For the next nine months, we went through many rounds of brainstorming sessions, looking at ways to improve the visual presentation, the functionality, and the structural flow of the site (see Figures 5-7).

site structure proposal
Figure 5: Site structure proposal submitted with the design

issue transition
Figure 6: Idea for how articles should flow/transition through the front page from issue to issue

site map
Figure 7: Proposed sitemap

The folks at Boxes and Arrows made it clear from the onset that they would like to see B&A take on more of a magazine look instead of the blog-centric feel that it had previously. We began looking at various print magazines like Time, Wired, Newsweek, and National Geographic, trying to figure out what elements in periodical cover designs make people quickly recognize a magazine when they see one. We identified strong typography, compelling imagery, and the concept of weekly or monthly issues as the elements that we would like to bring into our site design. (“Transcending CSS”:http://www.transcendingcss.com, a book recently written by Andy Clarke, includes chapters entitled “Marking Up the World” and “Looking for Grids Outside the Web” touching upon the approach of bringing visual elements from different media to the web.) A few weeks later, we created a mockup of the front page. This mockup became the foundation of the design that you see today.

second redesign
Figure 8: First iteration of second redesign

Design ideas and solutions

Instead of a traditional navigation menu, we incorporated a tag cloud into the site’s left navigation design. Because of the variety of categories listed in the left navigation, we initially took this approach not only to highlight the categories with the higher number of articles, but we felt that different font weight distributions in the navigation menu would also draw the users’ attention to the category list. We invested much time in creating the best algorithm and rendering method to make this work effectively. At the end, B&A decided to leave this piece out after the site launch due to the arrangement of the current taxonomy on the B&A site and the evenly distributed number of articles across the categories (which negates the reason for having a tag cloud to highlight the variance between categories). Nevertheless, we still considered it a clever design approach and hope to see it implemented on the site again one day.

Two other areas that we put much thought into were the layout of the new articles on the front page and the transition/flow of the articles from issue to issue. We wanted to accommodate the different number of articles being published and at the same time create a dynamic layout that provides a fresh look to the front page in every issue, much like a print magazine. We proposed a template system that will allow the editors to easily choose the layout with the best fit each time they publish new articles (see Figure 9 and 10). I believe as the PublicSquare CMS continues to mature, a future plug-in can make this workflow even more automated.

Regarding the transition of articles on the front page, as you can see in Figure 6, we created a flow that will smoothly bring the articles from the new article spots at the top of the front page down to the “Previously” section whenever new articles are published. Eventually, the older articles will be moved out of the front page and will be found in the archived story section of the site. This helps to provide our readers a good sense of continuity each time when they visit the site and enables them to quickly locate the most recent issues.

Anther finer touch was the use of the font-embedding feature in Internet Explorer to apply a more attractive type (Helvetica Neue Medium 67) to the article titles and the issue header, while making sure it degrades gracefully with a similar core web font in other browsers with the help of CSS.

page layout creation process
Figure 9: Proposed process for creating different front page layouts for publication

article transition
Figure 10: Examples of different front page layouts based on the number of new articles

After several iterations of changes and refinement of this magazine site concept in collaboration with Liz Danzico and Christina Wodtke over a period of two months, we arrived at a polished design concept that was ready to be implemented (see Figure 11 & 12).

final front page design
Figure 11: Final front page redesign

final article page design
Figure 12: Final article page design

A bump in the road

While we were conceiving Boxes and Arrows’ new site design, “PublicSquare”:http://publicsquarehq.com/, a new content management system (which now drives the B&A site) created by Christina and Lars Pind was in the works. We soon shared the growing pains of PublicSquare as we were met with challenges in implementing our design into this developing CMS. After failing to launch the new design prior to the 2006 IA Summit, we went back to the drawing board and the implementation phase of the design was put on hold as Lars worked hard to integrate a new theme engine/templating language (“Liquid”:http://home.leetsoft.com/liquid) into PublicSquare. You can read more about this in “Christina’s article”:http://www.boxesandarrows.com/view/are_we_there_ye.

Towards the later half of 2006, the maturing PublicSquare was ready for us to begin the implementation phase again. It took another few months for us to port over our design into the Liquid theme language with the PublicSquare API. Because of some intricacies in the design, the amount of effort and time required for this phase far exceeded our expectation. It also happened to be the busiest time of the year for our day jobs so we had a bit of a difficult time juggling the work. Nevertheless, slowly but eventually, on the evening of January 15, 2007, we raised the curtain on the new Boxes and Arrows site. I can’t begin to describe the overwhelming sense of joy and relief that we had seeing our design live on the web.

The tortoise crosses the finish line

It has been a long ride. From the day that we received Erin Malone’s email to the day that our design finally launched was almost exactly two years. On this road of redesign, there were many IM chats and Skype calls made, numerous late nights and working weekends spent, and countless cups of tea and coffee consumed. It took awhile, but we got there. Working with these folks at the forefront of the IA community has been a great learning experience. The positive responses from industry leaders in the field of web design have also been a real reward to us.

We hope to continue to contribute to Boxes and Arrows as well as the community it serves. But for now, I am going to get some much-needed sleep, so good night!

See also: Are We There Yet for more tales of the redesign.

Are We There Yet?

Written by: Christina Wodtke
“Design is often the place where ideas become flesh, and that is where you discover conflicts in the constituency. We were no different.”

Over two years ago, Boxes and Arrows’ then editor-in-chief, Erin Malone, and I decided it was time for a redesign of the magazine. The site had been tweaked and tortured into a shadow of itself over its first two years, the staff struggled with the hacked-up Movable Type installation (the software the site ran on), and it seemed about time for a makeover. Design magazines should be updated often. It’s in their nature.

That was over two years ago. And you, gentle reader, are still asking “Are we there yet?”

Finally, barraged by emails asking about the mystery surrounding the contest, the strange under-explained changes, the increasing degradation of Gabe Zentall’s elegantly understated design, we’re coming clean. We’re sharing the redesign and development process—in all its messy glory—with you.

Yes, folks, we are opening the kimono… just don’t expect Cindy Crawford underneath.

Where is the new design?
Back when we decided B&A needed an overhaul, we held a contest for a new design of Boxes and Arrows. Boy, was that a mistake.

Quality wasn’t the problem. Although the designs were terrific—beautiful, clear, and innovative—not one was what we needed. A successful design is more than beautiful; it is appropriate. And for a design to be successful, the designers need to work hand-in-hand with the client so they understand the client’s vision, and so the client understands the choices made by the designer. Collaborative iteration is the secret to getting to the right design solution. It’s embarrassing that we tripped up this way, knowing how many articles this site hosts on good process. We should have realized a contest was the very opposite of good collaboration.

Compounding our mistake, we chose to have judges—judges who weren’t us—because we thought that seemed right. A contest needs judges, right? Let the experts decide! Well, the fact is: Boxes and Arrows is our site, and the judges had differing ideas of what a great design for B&A was. They even had differing ideas of what kind of magazine B&A is—a usability blog? An information architecture site? They choose designs as winners based on their vast experience in IA, usability, design. But they all had different experience, none of it in being a B&A staff member, and they all choose different winners. The most usable, the most beautiful, the most… you get the picture. When Erin and I saw the judge’s favorites, we knew we were in trouble. Not only did they differ in preference, they could not envision the direction we planned the magazine would go. The judges just weren’t psychic!

Erin and I struggled through the contest process, realizing the issues but committed to following through. Too many people had worked too hard on wonderful designs to toss it all away. We tried to reframe the problem with additional instructions to our judges, and further-defined specs, but it was clear we were in too deep for an easy out. So we held fast to our core goals and prayed the winner might understand.

Luckily, the winning team, April 3rd, had a similar attitude about process. When they won, they immediately asked “Can we redo the design?” They wanted very much to work with us, iterating and exploring, to come up with the right design for B&A. Somehow they’d kept in mind what we had forgotten.

FrontPage_redesign_450.jpg

Figures 1: Contest winner by April 3rd (Click to enlarge)

Those who don’t learn from history…
We also should have known better because we’d been down this path before. When we were working with Gabe on the first B&A design, it took a while to find the right style. He went through multiple color and font explorations before even beginning page design, and founding team’s struggle with the design led us to write a mission statement so we could share a single vision. Design is often the place where ideas become flesh, and that is where you discover conflicts in the constituency. We were no different.

Even after we thought our design was perfect and launched with it, we discovered many things needed to be changed to accommodate our audience and staff needs. Today it’s the font size-too small! The next it’s the color-too light! The next it’s the images-we don’t have a Welcome this week! We need a new icon! And soon the design only loosely resembled the original.

Even Gabe was annoyed with his design when he saw it in HTML. Daily, I received polite little fix-it notes. “The gray is #eeeeee, not #cccccc.” “Please make the type 10px, not .8em.” Eventually, he forced himself to stop looking at it and no more sad emails appeared in my inbox.

ba gabe sketch ba 2002 screenshot thumb

Figures 2: Original sketch by Gabe Zentall and the design in September 2002 (Click to enlarge)

B&A finally settled into a stable form, and lived more or less happily housing smarter and smarter articles by the design community. Until we decided to muck…

Our story continues
So finally we had a light at the end of the tunnel for the redesign. The design team had been selected, was ready to go and was eager to design something amazing. We had done our homework and we knew what we wanted from a new design! Ready, set…

And then several things happened at once. I decided to build a new CMS from scratch, and Erin decided it was time to pass the baton on to a new editor-in-chief.

Rolling your own
Movable Type, despite the glowing blog entries and great success as a self-publishing tool, was not made for and is not a suitable tool for a team of writers and editors using an editorial workflow to produce quality articles. It’s a blogging tool. Knowing that we wanted a more-robust CMS, we looked at a number of open source solutions, including Drupal, WordPress, and Mambo. But after hacking Movable Type, we were wary of using the wrong tool for the job. That took WordPress out of the equation. And both Drupal and Mambo are like Swiss Army knives: they do everything, but not one thing well. Ever open a bottle of wine with a Swiss Army knife? Using an open source CMS is about as pleasant.

The fact that there were no tools for small groups to publish collaboratively seemed strange, and an opportunity. I suspected fate’s hand when, while giving a talk in Copenhagen, I was introduced to Lars Pind, a programmer who had built several CMS’s. He and I chatted, and he expressed the belief that it was time for a revolution in publishing tools. Around that time, both A List Apart and Digital Web were building their own CMS’s to run their magazines. I cried out “The writing is on the wall! Citizen journalism! New paradigm! Let’s make software!” With that, Lars and I started a new company, Cucina Media, and began our first product, PublicSquare.

So how does this fit with the redesign?
PublicSquare was originally designed to allow for lightweight customization. We thought if we wrote nice, semantic HTML all it would take to customize would be stylesheets, Zen-garden style. Again, we were mistaken. It soon became clear that people care even more about customization with their publications than with their blogs. A stylesheet can take you only so far, despite many articles to the contrary. It’s really not possible to completely separate form and presentation, as April 3rd learned to their chagrin. They struggled mightily to get the new B&A design launched for the 2006 IA Summit, giving up sleep only to see the launch fade in the 11th hour, thwarted by what CSS can and cannot do. With that failure, we decided to regroup.

Luckily, Lars tripped over an interesting templating language, Liquid, made by the folks over at Shopify. Liquid gives all PublicSquare users the ability to fully customize the design-including our much-put-upon B&A design partner, April 3rd. Now that we’ve got the templating language in place, we’re working to stabilize the markup so that April 3rd can do their job without having to redo it over and over again. Nobody wants to see the IA Summit fiasco happen again, even if the only ones who knew about it were Lars, April 3rd and I.

FrontPage_now_450.jpg

Figures 3: More recent iteration on contest winner by April3rd (Click to enlarge)

Now what? The redesign and beyond
With Erin’s move out of day-to-day oversight, Boxes and Arrows’ internal processes really had to start changing. We brought on new staff, including our first managing editor Javier Velasco, who watches over deadlines and quality; and Liz Danzico, the new editor-in-chief, who helps shape strategy. With new people, we’ve gotten a few new projects underway:

* Publishing: We started a series of new projects, including our first publishing venture. We’ve been talking about paper publishing since the beginning, but it’s just been this year that we’ve started planning in earnest. We’re stepping out with a collection of essays on tags and tagging.

* Events calendar: The Events Calendar, which you may have noticed, is another new addition that came about from personal experience. As a former design manager, I always had a hard time finding events for my direct reports to attend. My staff often came to me trying to choose a conference, but I never really knew about every event that was out there. I saw another opportunity: why not create a centralized dedicated list of events for design practitioners? I see you folks agree; we’ve been bombarded with events!

* Suggestions: You may have noticed the Suggestions area. This is the place for you to add your own story ideas and vote on what you think we should be doing. Beyond that, people have been using it to ask questions, note interesting articles, and make suggestions about site functionality. Don’t think we’re ignoring that! It’s clear more features such as a forum are required. B&A is a place for many voices, and we want to work toward making a tool that makes publishing more participatory while maintaining the quality that an editorial process and staff provides. We’re also learning a lot about voting, reputation systems, and user profiles (i.e., what makes a community tick).

Being without-profit
Until now, B&A has been a “without-profit” venture—just me, paying the hosting and keeping volunteers motivated with the help of an amazing volunteer editorial staff. B&A is still going strong, but we want to take it to the next level, which requires money. We could pursue sponsorships and go non-profit, but we’ve decided to try to make B&A into a self-sustaining business. People, no matter how committed to design and the community, eventually want their weekends and evenings back, and get sick of working with no return beyond the gratitude of the community. The goal is to be able to pay editors and writers, as well as fund new ventures needed by the design community.

This does mean some changes in the site you’ve grown so fond of, including the addition of ads. Don’t fret! We plan to stick with only relevant ads and relevant features. Although Budweiser won’t be advertising here anytime soon, do expect things like a job board or a bookstore.

We care about “Y”
We’re working toward a special way to launch the new design. We’ve asked a guest editor to curate a special issue on virtual and physical spaces, and we hope that will be the first in many special issues to come. Sure, we all love wireframes, but man cannot live on Visio alone!

We’re also interested in hearing more about the directions in which you’d like to see the magazine go. Too often, people dismiss the chance to help a publication grow—”They are all about X, they don’t care about Y.” Well, we do care about Y, we care about it very much. Boxes and Arrows was originally created to fill the need of senior practitioners to get better articles on the questions they faced in their work. As those practitioners have grown, we needed to grow also. Watch for more articles like Erin’s on creating a five-year plan, more articles like Icon Analysis, and, in general, more exploration of the issues you are just becoming aware of (…We hope! You are hard to keep ahead of!).

So, that’s our story so far. The good, the bad, and the ugly. We decided to let you know, even though it’s not a pretty story. We have made missteps, gone out in strange directions, realized we were drinking strange brew, and then tried our best to get back to a better course. In our daily lives we often make mistakes and then spend our time covering them up, trying to look cool. So this article is all about admitting we’ve done dumb stuff and owning up to those mistakes in the hope that you won’t emulate us, but will keep us honest and relevant.

Boxes and Arrows is our magazine. The line between staff and reader grows thinner and thinner. We welcome you to help us as we grow, with your honesty, your critiques, and your participation!

Excelsior!