Published: July 21, 2008

One of my earlier careers was in manufacturing management, and it grounded me in the principles of project planning and management. When I moved into technical communication, I brought my project management disciplines with me, and I embraced the prevailing tools of my new profession. I dutifully produced documentation plans in Microsoft Word and supported them with detailed project plans in Microsoft Project. However, the problem is that—like bad relationships—these artifacts never gave back results that were sufficient to reward the effort I put into creating them.]]> By Mike Hughes

Published: July 21, 2008

One of my earlier careers was in manufacturing management, and it grounded me in the principles of project planning and management. When I moved into technical communication, I brought my project management disciplines with me, and I embraced the prevailing tools of my new profession. I dutifully produced documentation plans in Microsoft Word and supported them with detailed project plans in Microsoft Project. However, the problem is that—like bad relationships—these artifacts never gave back results that were sufficient to reward the effort I put into creating them.

Excel: A Minimalist Tool

Looking for a better way, I discovered Excel and the power of managing by task inventories and check-off lists. Project management boils down to just three essential requirements:

• scoping the size of the project
• bundling the tasks into manageable and assignable chunks, or components
• tracking progress

I have found that working with a simple Excel spreadsheet gives me everything I need. Knowing just a few tricks makes Excel a versatile tool that meets my needs over the life of a project. Unfortunately, Excel is not a tool most technical communicators learn in school. So, we tend to fall back into our comfort zone, producing documents—with their own overhead of creating templates and styles and writing lots of words that no one seems to read—and working with project planning tools that seem to ask us the hard questions we were hoping they would answer for us. For example, task duration is an input in Microsoft Project, not an output. It’s like having my doctor ask me what I think is wrong with me.

The Information Model

In discussing this different approach to project management, let’s start at the end, with an information model that shows what work we need to do, who to assign the different task components to, when the components are due, and what the current status of each component is. Figure 1 shows an example of an information model for a simple Help project. On this project, multiple writers are working separately on their own topics, and the manager wants all topics to go through editing before including the Help in the Quality Assurance build. To avoid creating a bottleneck at the end of the project, the manager wants the editing to keep pace with the information development.

Figure 1—A simple information model for a Help project

On real projects I’ve helped manage, the actual tables I’ve created have had more rows to accommodate more components than this example shows, but otherwise, this is a realistic example.

Next, I’ll discuss how to use this information model. Then, I’ll show you how to build one.

The first column is an inventory of stuff we need to document. I have found two useful organizational structures for Help projects. The one shown in Figure 1 lists the basic components of the user interface (UI) itself and even identifies them by their navigational paths in the product. Another approach is to organize the work around use cases—a useful approach if you must do your planning before the UI design exists.

The second column is for assigning writers. Instead of free-form text entry, it uses a drop-down list that includes the names of the writers on the team. (I’ll show you how to create these drop-down lists later.) The use of lists for data entry is important if you want to be able to filter consistently, as we’ll soon see.

The third column is an estimate of how long it will take to document a component. Later, I’ll show how Excel can help you come up with that number.

The fourth column is the due date, which the writer provides, basing it on the estimated durations. The last two columns are status columns—once again with data coming from a predefined drop-down list.

The power of this information model comes from its ability to let you filter by multiple columns. And, in this day of modular writing projects, it lets you track the status of components across a broad writing team.

Scenarios for Using This Information Model

Let’s review a couple of scenarios that show different ways team members could use this information model.

Scenario 1—Mary wants to see what components she is responsible for. (Granted, in this example, that’s not too hard, but a real project would have a much longer inventory.) As shown in Figure 2, she merely has to click the arrow in the Info. Developer column header to display a drop-down list and select her name to filter the list of components, displaying only those assigned to her. (The drop-down list lets her filter the list of components in several different ways.)

Figure 2—Filtering by writer

Once Mary has selected her name and the list is filtered to show just her assigned topics, she can further filter the list by selecting Blanks in the Dev. drop-down list under Status. She now sees just her own assignments that she has neither started nor completed, as shown in Figure 3.

Figure 3—Model filtered to show only components not yet started by a writer

Scenario 2—Mary’s boss wants to follow up on how the writers are doing, so she filters the list to see what topics are due on August 1st, the upcoming Friday, in the Due Date column.

Tip—Enter all due dates using a consistent day of the week such as Friday.

Mary’s manager look at the view shown in Figure 4, then walks by Mike’s and Mary’s cubes to ask them how the Updates and Status topics are coming, respectively, and whether they’ll finish them this week.

Figure 4—Model filtered to show only what’s due this week

How to Build This Information Model

The good news is that the information model I’ve shown so far in this article does not require any formulas. All cells require just simple data entry. Start by creating the headings for your columns, using the cell formatting tools for background color and font style. Personally, I find it convenient to give the whole page a background color, making data-entry cells white. (You can select the entire page by selecting the box in the upper left corner—just above the row identifier 1 and to the left of the column identifier A.)

The easiest and most powerful trick this worksheet uses is its ability to filter the table by column values. This feature is called AutoFilter, and you can set it up by doing the following:

1. Select the column headers across the top of the table—in the example, row 3, from UI Element/Use Case through Edit.
2. On the Data menu, click Filter, then AutoFilter.

There, you’ve done it. Now each column header contains a drop-down arrow that lets you display a list that includes all of the values in that column, plus the options All and Blanks—if some cells are blank. It also includes Sort Ascending and Sort Descending commands.

Tip—A good practice is to reset all filters to All when you’re finished, so the next user doesn’t panic when she opens the file and all of her topics seem to have disappeared.

The other trick this table uses is to provide drop-down lists where a limited set of data entries is allowed—for example, In Process or Done under Status or the names of the writers. Start by defining the lists in an out-of-the-way portion of the worksheet, as shown in Figure 5.

Figure 5—Defining drop-down list values

Then, follow these steps to create a drop-down list for data entry in a cell.

1. Place the insertion point in the first data-entry cell at the top of the column.
2. On the Data menu, click Validation.
3. In the Data Validation dialog box, shown in Figure 6, select List in the Allow drop-down list.
4. Place the insertion point in the Source box, then highlight the cells that contain the values you want—or type the values in the box.
5. Click OK.

Figure 6—Data Validation dialog box

Copy the cell format to the other cells in that column by clicking the cell to select it, then dragging its lower-right corner to highlight all the cells in that column.

What Else Can You Do?

Although the information model I’ve demonstrated here is a complete tool, you can add other columns as you see fit. For example, you could track project milestones other than just development and editing, record a context-sensitive link URL for each component, or use Excel’s formulas to help calculate durations.

To calculate durations, you need to define some additional columns. To continue our example, let’s say each page in the UI had tabs, and we decided to scope the size of our effort by the number of tabs on each page. You could add a Tabs column and designate a cell for your sizing constant (k). The sizing constant in this case is the number of days you estimate it would take to document a tab.

Next, write a formula in the first duration cell to multiply the number of tabs by the sizing constant shown in Figure 7.

Note—You must put a $ in front of the constant’s column and row identifiers, making that address an absolute address. This is very important for the next step, when I’ll copy that formula to all the other cells.

Figure 7—Duration formula based on the number of tabs and a sizing constant

Next, copy that formula into the other cells in that column by clicking the cell to select it, then dragging its lower-right corner to highlight all the cells in that column.

Now, each component’s duration is the product of the number of tabs times the sizing constant. It is easy to experiment with different values for the constant. You can see the durations change instantly. Of course, you could use more advanced formulas, but it is this write-once / play-many scenario that lets you change variables and immediately assess their outcomes.

Conclusion

After years of trying to manage projects with precision, I realized development processes defy precision. What has proven more valuable is to be able to maintain an up-to-date snapshot of where we are today and what still needs to be done. And I have found Excel to be a great tool for this purpose. Your information model can change as a project’s requirements change. For example, you can retire some columns and add others as your need for information changes or add or remove rows as a project expands or contracts. Try this useful and flexible approach to project management on your next project!

Published: July 21, 2008

Most of us who are working as part of a design team in a services company, a product company, or even a design boutique have to live with a generic intranet. In this article, I’ll describe how to leverage your company’s intranet and how to build a community around an intranet for a UX team.]]> By Anirban Basu Mallik

Published: July 21, 2008

Most of us who are working as part of a design team in a services company, a product company, or even a design boutique have to live with a generic intranet. In this article, I’ll describe how to leverage your company’s intranet and how to build a community around an intranet for a UX team.

Exactly Who Are We Designing an Intranet For?

Depending on the services a multidisciplinary UX team provides, it might comprise interaction designers, information architects, visual interface designers, graphic designers, Web analysts, ethnographers, usability professionals, copy writers, technical writers, instructional designers, prototypers, and developers. In addition to the UX team itself, others who might be target users for the UX intranet include business development people and, via an extranet, your clients. Typically, you would give your clients access to only certain parts of the intranet.

What Are Our Objectives?

Apart from the usual productivity tools and information resources that constitute a successful intranet, a UX team’s intranet must also achieve the following objectives:

• building an online community
• offering effective tools for collaborative knowledge management
• showcasing a UX team’s portfolio—keeping the creative juices flowing within the team and giving Business Development fodder on a regular basis
• building client relationships by leveraging the team as a brand and cross-selling the team’s services
• offering project management tools

Figure 1 provides an overview of a UX team’s intranet.

Figure 1—A UX team’s intranet

Building an Online Community

Ideally, a UX team’s intranet should provide a platform where team members belonging to different disciplines—with their diverse profiles—can collaborate on design and research activities. Often on large teams—especially in cases where a team is spread across geographies—expertise and knowledge become siloed. One objective of an intranet is to break those silos and involve each and every team member.

Building an intranet can kick-start a new collaborative culture within the UX team. In most cases, a small team has responsibility for building and maintaining an intranet, but imagine the possibilities if you involved the entire team in collaboratively designing and developing your intranet.

Community Initiatives

To build a community and leverage the collaborative power of that community, you first need to give a voice to each member of your team. Give each and every individual a space of his or her own. All team members should have

• a profile page where they can share some information about their background and inspiration
• a portfolio where they can showcase their work
• a blog for sharing their knowledge

Once you’ve created an enthusiastic community, you need to keep the spirit of collaboration going. To do this, you can hold competitions on an ongoing basis. Ask individuals to form multidisciplinary teams and pit them against one another in competitions that test their collective knowledge or in design competitions.

For example, hold a lightboxing bout, as popularized by Veer. In lightboxing, a competition’s organizers select some images and typefaces according to the particular theme they’ve chosen, and individual designers must create designs using only those images and typefaces. A jury or an entire community’s ratings of the entries can decide the winner. To make this exercise even more interesting, you can ask a designer to pair with a copy writer to write a paragraph explaining the concept behind the design.

You can try many things to harness the collective power of the community. For example, you can leverage your intranet as a design forum by putting up an interaction design problem from a current project to which the community can offer possible solutions. All of these initiatives require that you have some kind of reward system. This can be as simple as ratings given by other community members or inexpensive gifts.

Offering Effective Tools for Collaborative Knowledge Management

One of the most interesting features of a UX team’s intranet is its potential for collaborative knowledge management. You might divide the knowledge on the intranet along the lines of the service offerings your team provides. Within each broad topic, you can create more specialized subtopics.

Rather than individuals and teams storing knowledge as files on servers or local hard disks, a team might alternatively have a dedicated Web page or a section on the intranet. However, knowledge resources like whitepapers and case studies often become out of date, because with project pressures, people forget to update them. As a consequence, people eventually stop referring to them.

Instead, build a culture of collaborative knowledge sharing by moving knowledge from individual hard disks or servers to a common platform. Knowledge doesn’t turn stale, because all team members constantly update it and add information from various sources.

Often when people are transitioning from one project to another and are generally bored, your intranet can be a source of entertainment and knowledge rolled into one.

So, what can your team build collaboratively? Many things. Here are just a few ideas.

Using Frameworks

Often, teams unnecessarily spend time reinventing the wheel. This is especially true for teams that are spread across geographies. To prevent this, you can create frameworks for technical communications, e-learning, Web design, UX design, Web development, and so on.

I’ll give an example to illustrate how teams can use frameworks effectively to cut down on production time. Consider a scenario in which two teams of UX designers are creating intranets for two different clients. If you already have a basic framework for an intranet—complete with wireframes or templates—each team would simply need to tweak the branding, interaction design, and information architecture to meet the needs for each site. You might even go a little further and create standard types of HTML pages, with CSS styles and JavaScript. The developers would need to modify only those parts of the code that implement unique information architecture, interaction design, or branding.

Often, we need to build style guides for applications. Why not build a generic style guide and use it as a reusable component, changing only those sections that need customization? You can extend this idea to building a pattern library, consisting of design patterns designers can modify or reuse.

Designers often browse a lot of Web sites for ideas. Why not share what you find while browsing? If you find a nice example, where the designer has innovated either visually or in terms of interaction design or information architecture, take a screen shot, add comments, and upload it for other team members on your intranet. For example, you can create a page for a pattern like progressive disclosure, then team members can upload examples that show how designers have used this interaction design pattern across a varied range of applications. The Yahoo User Interface Library is a good example of a UI framework. Similarly, Prototype and Scriptaculous are good examples of JavaScript libraries.

When creating comps of Web pages, hunting for just the right image across multiple vendors can take quite a lot of time. You can collaboratively build a library of images from a variety of vendors. When you come across a good image, why not tag it and save it for your team to use, saving time later on.

Building Collections

Here are some other collections your team might put together collaboratively:

• inspirational scrapbooks—We spend a lot of time collecting interesting links to Web sites, articles, and graphics for later reference. Then, before we start a project, we look through our folders for inspiration and insight. Why not add a scrapbook section to each team member’s profile page and make them accessible to the entire team?
• whitepapers, articles, and book excerpts—Individually, we read a lot of articles, whitepapers, and books. I capture the main points of a book chapter or whitepaper in a Word document, for reference later. Why not write excerpts for the benefit of all? Your team could build a repository of notes that capture the core ideas, plus references for those who want to delve more deeply, and reduce the time it would otherwise take to read an entire article or book to get the same ideas. If everyone on the team reads a different book, then uploads their main ideas, your team can quickly build a vast, information-rich database. Blogs can be a good medium for collating this information. All it takes is for one enthusiastic person from your team to suggest a topic. Then, team members can do research and collect information for the blog—either individually or as a group.
• trends—How about keeping a tab on the latest design trends—from fancy gradient effects, to the buzz around eyetracking, to the latest trends in informal error message writing styles—a-la the famous Orkut? The list can go on and on.

Providing a Showcase for a UX Team’s Portfolio

A team portfolio plays a very important role in getting more projects. Transforming the intranet itself into a playground for your designers can keep the intranet fresh. Along with their profile pages and scrapbooks, all team members should have their own portfolios that showcase their best projects. In addition to uploading screen shots and design documents, creating case studies of your projects would benefit business development immensely. It would be a good practice to build up a case study with concept sketches and final screen shots, as soon as a project is complete, while the concepts behind the design are still fresh in the designers’ minds. I’m sure the Business Development folks would love that.

You can also dedicate a section of the intranet to an interactive newsletter, in which designers can showcase their designs, developers can show their wizardry with code, writers can display their writing skills, and so on. Each member of a multidisciplinary team must contribute to building the newsletter—perhaps once in three months. The newsletter can serve as an up-to-date marketing piece for Business Development to push to existing and new clients.

Building Client Relationships

An extranet wrapped around the intranet would help you cross sell to clients. Consider two scenarios: In the first, you mail project deliverables to your client; in the second, you send the client a link to an extranet where he can review the project deliverables. The second scenario would enable your team to showcase some similar projects, case studies, or whitepapers that would be of interest to your client or let your client read about the achievements of team members in a sidebar, while still keeping the focus on the project deliverables and artifacts. Perhaps, after reviewing a deliverable, your client’s curiosity would induce him to click a link to a case study and maybe get a new idea that might translate to a new business opportunity for the design team.

Offering Project Management Tools

You can integrate project management tools into the intranet. A lot of communications regarding the review and feedback of project deliverables happen via email. Something akin to what Basecamp offers could add quite a lot of value. Another product, Concept Share, has done a really good job of shifting the review process online. The whole idea is to integrate project-related communications and artifacts into an online platform with a robust search engine. With the rise of process centricity in organizations, management could drill down to any project artifact, cutting across geographies. This would also enable clients to have a better understanding of the progression of a project and do away with many issues resulting from miscommunications. The information is there online for everyone to see.

Conclusion

The main goals of a UX intranet are to bind an entire team together and foster collaboration—not only in jointly developing skills, but in collating information and disseminating knowledge across the entire team. In the Web 2.0 era, collaboration is absolutely essential, and the success of such an intranet platform depends first and foremost on building a community of collaboration, in which each individual on the team proactively contributes. Giving identity to everyone on the entire team through profile pages, blogs, and portfolios helps in achieving those goals. Keeping everyone involved—from the intranet’s creation to the day-to-day updating of its content—lets you build the groundwork for a robust knowledge management framework and sets the ball rolling for a culture of innovation and knowledge-seeking that, over the years, can benefit a team immensely.

Published: July 7, 2008

In my last column, I suggested that being a manager of UX is no better—and no worse—than being a great designer or user researcher, but the roles are very different. In fact, as the book The First 90 Days [1] points out, the skills that make you successful as an individual contributor are not the same skills you need as a leader.

Still, I was glad to see that a couple of people who talked with me after reading my column are being offered the opportunity to move into management roles and have decided to take the plunge. They asked me how they could make this transition a positive experience for them, their teams, and their companies. They were asking the right questions. This column discusses what attributes can help someone become a successful first-time UX manager—though these attributes are foundational elements for all managers.]]> By Jim Nieters

Published: July 7, 2008

In my last column, I suggested that being a manager of UX is no better—and no worse—than being a great designer or user researcher, but the roles are very different. In fact, as the book The First 90 Days [1] points out, the skills that make you successful as an individual contributor are not the same skills you need as a leader.

Still, I was glad to see that a couple of people who talked with me after reading my column are being offered the opportunity to move into management roles and have decided to take the plunge. They asked me how they could make this transition a positive experience for them, their teams, and their companies. They were asking the right questions. This column discusses what attributes can help someone become a successful first-time UX manager—though these attributes are foundational elements for all managers.

Before we dive in, please realize that this column cries out for the need to describe the differences between management and leadership. But to keep this article from becoming a treatise, I hope you’ll bear with me as I focus narrowly on how to survive and thrive as a first-time manager. I’ll take up leadership in my next column.

Holy Cow, Now What?

Becoming a manager can feel like the best choice you’ve ever made—like you’ve finally found your home and are doing what you were always meant to do. That’s how I feel about leading UX teams now. I thrive on it. The fact is, though, I certainly did not feel that way early on in my management career. I felt well out of my depth. While I survived the experience, my team put me on notice! Most new managers thought becoming a manager would feel exhilarating and refreshing—even as they began to feel lost in a hostile third-world country without a way out. Among the first-time managers with whom I’ve spoken, only those who managed just one or two people felt their first management role was what they expected.

The irony is: The skills that probably got you into a management role can guarantee your failure once you move into that role. As a designer or user researcher, your success depended much more on your personal expertise, focused execution, and ability to individually achieve goals. As a manager, your job is not to do the work, but to bring out the best in your team. You need to set your team’s direction so they’re working on the right priorities, make sure team members work together well and play their positions, and in the end, ensure they produce market-changing designs. Trust me: Your career as an individual contributor prepared you only very little for management. You have more to learn than you think you do! (Isn’t that true for all of us, though?)

As you move higher up the management chain, you’ll do more coaching and progressively less actual design or research. While you focused on being a great designer or researcher before, now you need to learn to coach. In fact, you’ll need to increase your coaching skills as you become a more senior leader. At each step, as your management career progresses, you’ll increase your scope of influence, which means there will be less time available for you to perform individual contributor tasks. Some people never want to stop performing the actual design or research. That’s fine. You just can’t do it vicariously through your employees. That is, you can’t try to do their jobs for them, or you’ll alienate them.

I believe, to a great extent, our first management experiences stay with us forever. The goal is to make your first experience a success and build on that success. Unfortunately, for many, their first experiences are far less successful. These difficult experiences also stay with and define us—hopefully for the better, but through hardships, which leave scars, rather than success.

For the discipline of user experience to continue becoming more influential, UX leaders need to create a working environment that stimulates not just good, but great design. We need to show that design can differentiate products and create a competitive advantage. Design can prevent products from becoming commodities, by making sure they are the most useful, desirable, and socially valuable products anywhere. Is this a high bar? Absolutely! That is what great managers can do. Hopefully, this column will help you achieve such results!

Common Misconceptions

Over the years, I’ve mentored a number of individual contributors who were transitioning into management roles. At first, they felt becoming a manager was proof they had the best ideas and could now drive their own personal agendas. It may seem ironic, but this attitude is a sure path to failure. Unlike being the superstar researcher or designer, the job of a leader is not to have the best ideas. Instead, it’s the leader’s job to assemble the best team possible and facilitate the team’s finding, aligning with, and driving the best ideas to realization. Many new managers feel being the manager means they can tell their employees what to do, and they’ll just do it. If only it were that easy.

I’m going to talk about several misconceptions new managers hold and show how new managers need to behave very differently from how they expected. You may find it ironic that, in order to demonstrate you are a strong and successful leader, you must ask instead of telling and coach instead of dictating. You have to let people find their own way to success, even though it’s different from how you would do it. It may feel unnatural, but you have to let employees fail, even when you feel a desperate need to succeed.

Part of your role is to hire the best talent and leverage their skills and knowledge. In fact, the book Good to Great [2] suggests the best companies and groups always get the right talent on board first, then define their direction. If you’re going to hire the best talent, don’t you want your employees to perform at their best? Your role, then, is less about direct execution and more about getting your individual contributors to produce the best work of their careers.

Yes, You Must Build Trust

Of course, new employees have to earn the trust of their leaders by delivering great results. In the same way, as a leader, you don’t automatically have the trust of your employees. Like in any relationship, you have to build that trust. How do you build trust? Not by being the smartest person in the room. Certainly, you have to have a strong vision, and you have to show you are a strong, capable leader. But the way you do this is very different from how you demonstrated you were a kick-ass individual contributor.

Rather than telling your employees how to succeed, you need to learn to solicit their input to determine the best path and agree on it, then let them execute on it. You need to become a great facilitator. Look: Your employees want to impress you. They want opportunities to hit the ball out of the park—just like you. Most of us—whether we’re working in corporations or small firms—are looking to grow. We want our leaders to recognize our talents, promote us, and give us bigger paychecks—okay, most of us. When our bosses give us room to be successful, coach us toward greater success, recognize our great contributions, and help remove barriers, we perform better and appreciate their leadership. As a leader, you must give your employees these opportunities.

And as a leader, you also have to defend great ideas that may, at first glance, seem wacky, defend great designers who don’t sell themselves well, and in general, demonstrate managerial courage. When you advocate for your team, they’ll advocate for you. In fact, you’ll find there are many ways of building trust, and this will be a theme throughout the rest of this column.

Ask, Don’t Tell; Coach, Don’t Dictate; and Let ’em Fail

In terms of building trust, many new managers think: “I was given the power, so my job is to tell my team what to do, and they have to listen.” Again, this is a sure-fire way to lose control of your team and prevent them from aligning with goals and generating tangible value. With such a mind set, managers fall into a vicious cycle of correcting and criticizing people who are highly competent. To these employees, such managers begin to seem like totalitarian dictators. Your goal is to help generate a virtuous cycle, where the team executes well, you recognize the contributions of team members, and they continue to grow in their ability to make a positive impact.

Look, from an employee’s perspective, at taking direction from a totalitarian boss: “He hired me because I’m good at what I do, and yet he’s dictating how I do the job—and he’s wrong, darn it!” Do you think telling an expert designer how to do her job makes her feel valued and empowered? Does it make her feel as though you trust her skills? Of course, it doesn’t. So, how do we build trust? I’ll get into that.

Don’t get me wrong: You do need to offer your guidance. You were put into your role as manager because you were successful as a user researcher or designer. The point, though, is that you have to learn to facilitate and guide and make your team members feel excited about making their own contributions rather than telling them exactly what to do.

It’s sad to say that I have worked not only with new managers, but also with peers—and a boss or two—who did not understand the importance of building trust among their employees. One such peer—we’ll call him Paul—told me point blank: “I don’t care what my employees think.” How did Paul do? In my last column, I pointed out that bad managers eventually get found out. Paul certainly did. Everyone in the organization talked about him. Employees came to me daily looking for help. I encouraged my boss to define leadership competencies to measure us by—me included—and he did. Within a month, this manager “left the organization.” In one way, we were fortunate. Most poor leaders are not so blatant. Whether you are a new or an established manager, spend the time building trust. It will pay off. Seeing a team gel, execute at a high level, and weather hard times without difficulty is—for me—a joy to observe. That’s when I know I’m doing the right thing.

Get Your Entire Team in the Game

Listening to your team is essential. You hire the best designers and researchers in the world, and you need to get their minds in the game. Good to Great articulates this well. The book identified—among other things—the leadership attributes that result in the most successful companies and teams in the world. The first is to hire the most talented employees, then to define direction. Using a term from the book Winning [3] by Jack Welch, you truly need to get every mind in the game. Provide direction to your team’s discussions, provide the appropriate structure, pull in the right people at the right time, and help synthesize different ideas. You are not there to be the one who just dictates the team’s appropriate direction.

Not only do you need your team’s expertise—their minds—you also need their hearts. You need them to emotionally buy into the direction you establish. There’s nothing more difficult than trying to drive a team in a direction they do not understand and have not bought into emotionally.

Demonstrate Strength by Soliciting Input

It’s worth taking a minute to clarify one key point: I am not suggesting you become wimpy or indecisive. Quite the contrary. As suggested in the book Great Boss, Dead Boss [4]—an unfortunate title, but a great book—people intuitively follow strong, capable leaders, not those who vacillate. You have to be confident in yourself, show you can make hard decisions rapidly, and solve very real problems, enabling your team to succeed. For example, you might need to fight for increased headcount or outside consulting dollars, get UX an equal voice with other organizations, or simply drive process improvements. You need to get your team members focused on objectives and be very crisp in your expectations.

In no case, though, should confidence equate to arrogance. The most confident leaders do not need to constantly prove how much they know. The book Lions Don’t Need to Roar [5] articulates this principle well. You can show your confidence by presenting a strong, clear vision for the future and asking others for help in defining how you as a team can realize that vision. I once helped one of my teams handle a challenging time by making a statement something like this: “I am deeply proud of some of the successes this team has had over the past year. At the same time, I recently talked with some of our stakeholders, who have told us we’re not executing at the level they’ve come to expect from us. Before I make a decision about changes we will make to increase our impact, I’d like us, as a team, to be brutally honest about our challenges and work together to define possible solutions.”

Instead of deciding on a solution that very day, I recognized that the team needed discussions to evolve over several weeks. In the end, I communicated to the company that we needed to function like entrepreneurs on every project and turned the team into an internal consultancy. This UX team had to bid on jobs within our company and be competitive with external design firms such as IDEO and Frog Design. In the end, it was this organizational structure that made my team responsible for driving $2 billion in revenue. This could never have happened without the following events occurring:

• I expressed my trust in the team’s ability to identify and solve our challenges.
• I made sure we engaged every brain in our talks about challenges and opportunities.
• The team synthesized the input and discussed possible directions.
• I decided on the team’s direction, then praised the team for their courage in informing such a creative direction. Really, it’s not easy to do things differently.
• The team understood the reasons behind the change and felt emotionally bought into an exciting new direction.

My point here: I was not passive and did not ask others to define our team’s direction. I was responsible for that. I also did not make decisions by committee. I listened and made the decisions myself, and everyone knew why I had made the decisions I did, and how they had contributed to the direction. But I made sure to include the team in the dialogue and gave credit to the team for their insights. I learned a great deal from the discussion, and working through our challenges helped us bond more strongly as a team.

Set Clear Expectations

You do have to help employees understand what you expect of them. Generally, it’s okay to express these as your expectations. But better yet, ask the entire team for help defining success. Solicit their dreams and goals. What do they want to see happen for the group? Allow them to think big. Then, help them to identify the employee characteristics—competencies, professional practices, and values—that define the ideal employee.

It is amazing how leveraging your team in defining explicit competencies and expectations helps the team normalize itself. Of course, these competencies give you specific areas in which you can appraise your employees. And you should establish a coaching plan, then coach individuals against these competencies.

Exercises in defining a team’s direction create a bond among members of the team. Leveraging the group’s insights through structured brainstorming helps the team gel. Every team has its own personality, and you need to let your team find its unique way of interacting. Once all of your team members are contributing at a high level—once they show they trust one another and give you their very best with the intent of helping the team succeed—you have a team that can endure hardship and thrive.

More importantly, when each member of your team understands and buys into the practices the team has identified, they can help one another normalize their practices. In one case, I had a team that agreed it had to stop complaining about product managers. They agreed that, any time they heard someone complaining about a PM, they would suggest the complainer go hold a stakeholder interview with the PM with whom he was having trouble. Or, if they saw unhealthy argument within the team, they would point out that our competition was external, not internal, and we needed to engage in a discovery session to work through challenges.

Stop Being the Smartest Person in the Room

One of the most difficult habits to break for great designers and researchers is being the smartest person in the room. Even if you are, asking targeted questions to facilitate a discussion and elicit understanding from your team makes team members respect you a great deal more. And in doing so, you are in a position to praise them for their good work. It becomes that virtuous cycle: You give them room, they do well, you praise them—and in the end, they see you as a good leader. Amazing!

I’ve known a number of designers and researchers who thought becoming a manager would give them the credibility they’d always wanted—to make people listen to them. They’re looking for respect. Therefore, they attempt to impart their wisdom to both individuals and the larger team. This is one principle virtually all management books agree on: The best leaders—as measured by objective performance—are truly humble, not arrogant. Jack Welch points out in Winning that, even when he was CEO of GE, the world’s largest corporation, he consciously made the effort not to appear to be the smartest person in the room. Even if he was, he let others feel as if they were. Why? He wanted them to contribute, and they would not if Jack was always there to upstage them or even just give them the answer.

The fact is: Unless you can participate in every discussion and design session, you need to coach your individual contributors to become more independent and able to solve problems more and more independently. The reality, though, is that even if your path to success has, in fact, been highly effective, your employees might find an even better way of doing things. Because I try to hire people who are much smarter than I am—and there’s always someone who’s better than you—my reports often help redefine goals and find superior ways to success. If we, as managers, try to control our employees, we not only diminish trust, we also stifle potential creativity and innovation.

Start Giving the Credit To Your Team

Even if you did come up with a great idea, give the credit to your team—especially when you’re in the trust-building phase. The ironic thing is, when you give others credit, you set them up for future success, and you receive even more respect. It takes nothing away from you, and sets you up as a leader in the eyes of others. What it shows is that you are an emotionally mature leader who values your employees and can direct a team to produce results. And it shows your team you’ll go to bat for them. It increases their loyalty, their willingness to support you—which you really do need—and their willingness to contribute in the future.

Become a Great Coach—Help Your Employees Grow

One of the best coaching experiences I’ve ever had was when I delivered a presentation to an executive. He listened, asked questions, and gave me feedback on what I did well. Then, instead of criticizing me, he said, “You did a great job. Would you be open to me coaching you in a few areas?” Once he got my agreement, he helped me immeasurably. He pointed out that senior leaders need me to get right to the point, help them understand what needs to be done, how it will benefit them, what it will cost if we do not do it, and produce an implementation plan. They also want you to present alternatives, to show you’re not unduly attached to one idea and have thought through your options. His doing this helped me deliver better presentations. More than this, it made me feel that he cared, and it built a loyalty that inspired me to double and triple my efforts. The result? He got credit for $1 billion in revenue increases for his line of business, and I got a promotion to a senior leadership role. None of this would have happened had he not suggested he trusted me through his willingness to coach me.

I think too many of us are afraid to truly coach today, and even I forget to do it often enough. But every time I have offered coaching in the spirit of promoting growth, it has helped my reports, the team, and me.

It’s important to remember though that a coach isn’t passive. The best coach really is like a counselor. The best counselors don’t just ask, “What would you do?” They also provide clear insights and recommendations. But they recognize the need for the person being counseled to internalize lessons, and that’s only possible if they truly understand the lessons themselves. Your telling someone what to do won’t help, but you can guide.

I like to set up a specific coaching plan and work toward it every month—setting up regular sessions and helping my reports grow. Many times employees grow to a point that they no longer fit in my group. That’s not only okay, that is the best result possible. I spend a lot of time helping my employees grow. Even though it takes my time and often costs money, it always helps the team and the company as a whole. As employees grow in their skills, they perform better, make a larger impact, and in fact, make you look good, too. It’s worth everyone’s efforts. By trying to hold onto employees, we stunt their growth. That is not beneficial to them, the company, your group, or to you.

As good managers grow through the ranks, they realize employees are not really their employees. They are the company’s employees, and they are their own people with their own career aspirations. Don’t keep employees in your group just because they’re good. If you agree to work with employees to set and achieve goals, they are growing and getting better at their jobs. They are also setting a good example for others to work hard and grow, which has a positive effect.

I even push my employees to grow. I find out where they want to grow, validate that, and set goals. We then add these goals to their annual performance reviews, and if they do not achieve their targets, I have a conversation with them about it. I take employee growth seriously and make employees take it seriously as well. I support their taking training courses, even if they are costly, and connect them with others who can mentor them.

Now, not only do I support my employees’ potentially growing out of my group, I explicitly facilitate that. “What?” you say. Yes. I ask them not just what the next step in their career is, but what their next step is after that. What’s their second step? My friend and a great leader, Devin Jones, taught me this. The goal is more than just to make sure they’re clear on their career aspirations, but to ensure they know I am dedicated to their success. And when it’s time, I help them find a new role that will get them to that second position they’re looking for. This isn’t altruistic. It’s selfish. By doing this, I get employees who are deeply dedicated, who will watch my back as I watch theirs, and who would jump through a ring of fire to execute well.

Spend More Time with Your Best Employees

One lesson I learned the hard way was that I needed to spend more time with my best employees and less time with my poorest performing employees. That’s hard to do. It’s human nature to focus on improving those who need it most.

John Chambers, CEO of Cisco Systems, Inc., pointed out to my leadership development class that he learned this lesson the hard way. He was a senior leader of a sales organization at one point and wanted very much for his poorest performers to improve, to start selling more. His boss pointed out that he had the wrong idea. If he worked with his poorest performers, they might, in a good month, increase performance by 10%. But if he spent more of his time making his best employees the best ever, he could increase performance by 50% or more. In fact, John pointed out, by changing his focus from the bottom performers to the top performers, he delivered even better results. I can’t remember the specifics of his story, but I took this message to heart. In the end, it’s difficult to not spend as much time with people who clearly need help. But in the end, you get better results by working with those who have the most potential.

Many People Interview for Their Boss, Not the Job

Honestly, when I consider a new job now, I interview less for the position than for my new manager. That is, I want a manager who understands the value of trust, permits me to take risks, and who is, in fact, a Level V Leader—as Jim Collins defines in Good to Great. According to this book, Level V Leaders build enduring greatness through a paradoxical blend of personal humility and professional will. They are able to “channel their ego needs away from themselves and into the larger goal of building a great company.” I am fortunate and completely unembarrassed to admit that this approach helped me successfully find my current position, working for a great boss. Truthfully, I wouldn’t have it any other way.

What New Managers Think Versus What They Really Need to Do

Great leaders start by being great managers who inspire and guide their teams to excel. They are not just superb designers or user researchers. Rather, they can direct entire teams to produce better results than they ever could have achieved alone. As UX managers, we begin by focusing internally on our teams—on making sure individuals develop great designs. But, by truly getting all the best minds in the game, can we generate market-changing ideas that help promote members of our UX community into positions such as the CEO of a large company? See, that would be inspiring to me. Then, we really would be design led. It would be inspiring to me if the UX industry became known as a leadership factory. More about leadership in my next column. Now, I’d like to hear from you about how you succeeded as a first-time UX manager. What are your stories?

References

[1] Watkins, Michael. The First 90 Days. Boston: Harvard Business School Press, 2003.

[2] Collins, Jim. Good to Great: Why Some Companies Make the Leap… and Others Don’t. New York: HarperCollins, 2001.

[3] Welch, Jack, and Suzy Welch. Winning. New York: HarperCollins, 2005.

[4] Immelman, Raymond. Great Boss, Dead Boss: How to Exact the Very Best Performance from Your Company and Not Get Crucified in the Process. Gurnee, Il: Stuart Philip International, 2003.

[5] Benton, Debra A. Lions Don’t Need to Roar: Using the Leadership Power of Professional Presence to Stand Out, Fit In, and Move Ahead. New York: Warner Books, 1993.

Published: July 7, 2008

Interviewing is an artful skill that is at the core of a wide variety of research methods in user-centered design, including stakeholder interviews, contextual inquiry, usability testing, and focus groups. Consequently, a researcher’s skill in conducting interviews has a direct impact on the quality and accuracy of research findings and subsequent decisions about design. Skilled interviewers can conduct interviews that uncover the most important elements of a participant’s perspective on a task or a product in a manner that does not introduce interviewer bias. Companies hire user researchers and user-centered designers because they possess this very ability.

There is a wide variety of literature regarding best practices for user research interviews. For example, in their book User and Task Analysis for Interface Design, Hackos and Redish devote an entire section to the formulation of unbiased questions. They advise interviewers to avoid asking leading questions, to ask questions that are based on a participant’s experience, and to avoid overly complex, lengthy questions.]]> By Michael Hawley

Published: July 7, 2008

Interviewing is an artful skill that is at the core of a wide variety of research methods in user-centered design, including stakeholder interviews, contextual inquiry, usability testing, and focus groups. Consequently, a researcher’s skill in conducting interviews has a direct impact on the quality and accuracy of research findings and subsequent decisions about design. Skilled interviewers can conduct interviews that uncover the most important elements of a participant’s perspective on a task or a product in a manner that does not introduce interviewer bias. Companies hire user researchers and user-centered designers because they possess this very ability.

There is a wide variety of literature regarding best practices for user research interviews. For example, in their book User and Task Analysis for Interface Design, Hackos and Redish devote an entire section to the formulation of unbiased questions. They advise interviewers to avoid asking leading questions, to ask questions that are based on a participant’s experience, and to avoid overly complex, lengthy questions.

Writing interview scripts in advance of a session lets researchers review and revise wording to elicit useful and unbiased responses from participants. However, in many interview formats, a significant portion of each session involves ad-hoc, probing, follow-up questions that require researchers to think quickly to maximize their time with participants. In my experience, this is where the potential to introduce bias is the greatest. In addition, conducting a successful interview involves more than just asking questions. There are also a number of guidelines for how researchers should interact with participants to enable successful interviews. These include monitoring body language, recognizing self-censoring, and understanding the correct balance between leading an interview and listening to a participant.

Experienced researchers may become more comfortable in different kinds of interview situations and have an easier time interacting with participants during interview sessions. But, over time, researchers may also develop familiar patterns for asking questions and ways of interacting with participants that could prevent them from uncovering a unique perspective in the context of a particular interview. Also, the introduction of bias in an interview is often subtle, and it may be difficult even for researchers with years of experience to notice it during one of their own sessions.

Seven Interview Best Practices

Given everything there is to remember to ensure we conduct successful interviews, I find it helpful to remind myself of the following seven key best practices immediately before an interview session:

1. Set proper expectations. Generally, interview participants are not experienced with the user-centered design process. A recruiter may have given them a brief description of the purpose of an interview during the recruiting process, but it’s very likely participants don’t have a clear sense of why they are there. They may be apprehensive, nervous, or skeptical about your intentions. Business stakeholders especially may come to a session with a negative attitude if they believe a researcher is there to check up on them. All of this will serve to influence the responses they give to interview questions. To minimize this impact, be sure to describe the intent of the interview, your role in the design process, and how the interview process will proceed. Include details such as why you will be taking notes and how you will compile the results.
2. Shut up and listen. As a researcher, it is easy to get wrapped up in the interview script you developed, all of the questions you want to ask, and your own ideas about the salient points to uncover. It is easy to dominate the conversation and move through the interview at a pace that is too fast for a participant to keep up. In my experience, participants often raise the most interesting points only once they’ve had a chance to internalize and think about a researcher’s question. Listening appropriately involves minimizing interruptions and slowing down the pace of the interview to give participants an opportunity to qualify their statements or provide additional insights.
3. Minimize biased questions. Asking leading or biased questions is all too easy to do. Even a simple question such as How did you like that process? subconsciously suggests to participants that they should like the process more than they should dislike it. In our attempt to be conversational, such questions as these often roll off the tongues of even the most experienced interviewers. I’ve found the best way of minimizing these types of leading questions is to read a set of good and bad examples before an interview session. Examples might include:

Bad: How did you like the login screen?

Good: What do you think about the login screen?

Bad: Is the feature helpful to you?

Good: Is the feature helpful or not helpful to you? Why?

Bad: Would this be a good idea?

Good: How valuable would this be to you in your job?

4. Be friendly. Interview scripts are useful, because they help researchers remember all of the topics they need to cover. But reading directly from interview scripts can have a negative effect on the dialogue between an interviewer and a participant. The result: formal, unengaged conversations in which participants give the shortest, simplest possible response to a question so they can move on to the next one. Developing a friendly relationship and an open style with participants starts with the initial greeting and continues through the interview to the closing. Establish eye contact, remember each participant’s name, and develop a casual conversational style to elicit the most thoughtful, considered responses from each participant.
5. Turn off your assumptions. It is human nature to let your perceptions of a given topic influence your questions and even the responses you hear from participants. You may also be biased by responses you’ve heard from other participants, perhaps earlier in the same study. While it may be impossible to avoid these influences altogether, reminding yourself that they exist before the start of an interview session helps minimize their effects. Especially during the last interview in a series of interviews, make it a point to be open-minded and responsive to alternate points of view.
6. Avoid generalizations. In rare circumstances, it may be appropriate to ask participants to speak on behalf of others or predict how certain groups of people would react to particular experiences. However, for the most part, the best research interviews are those in which the participants speak about their own experiences and preferences. Researchers must recognize when participants are generalizing their responses and attempting to answer on behalf of others. In such cases, a researcher should politely ask participants to speak about their own experiences.
7. Don’t forget the non-verbal cues. Participants communicate through more than just their verbal responses. Body language and tone of voice convey a great deal about participants’ comfort levels with the interview session in general, their perspectives on a task or product domain, or their opinions of a researcher or the goal of a project. Researchers who focus too intently on their interview scripts and miss participants’ non-verbal cues may miss the necessary clues that would suggest they should adjust some aspect of the interview. Customers might be nervous or apprehensive and limit their answers. Business stakeholders might be skeptical about a project or the context of an interview. So, researchers need to recognize the clues that indicate such emotional responses and be flexible enough to adjust an interview session to ensure they can properly interpret participants’ responses and get the maximum return on their effort.

Conclusion

As Dumas and Loring note in their excellent new book Moderating Usability Tests, it’s difficult to conduct a perfect interview session. All of us are prone to bias or can fall into bad habits that can limit the reliability and effectiveness of results. This is especially true for the last sessions in a series of interviews, when you’re likely to be tired or already have formulated opinions on the outcome of a study. But, by reviewing a checklist of best practices before each interview session to remind yourself of the things you should avoid, you can minimize the impact of these pitfalls and maximize the return on your research effort.

Additional Resources

Dumas, J. and Loring, B. Moderating Usability Tests. San Francisco: Morgan Kaufmann, 2008.

Hackos, J. and Redish, J. User and Task Analysis for Interface Design. New York: Wiley, 1998.

Published: July 7, 2008

The 2008 IA Summit was held April 10–14, at the Hyatt Regency in downtown Miami, Florida, shown in Figure 1. It had the highest attendance in the conference’s nine-year history: Over 600 people signed up for the conference run by ASIS&T (American Society for Information Science and Technology). All the signs are that information architecture (IA) is a community and a practice that is growing, and that its sister disciplines—interaction design (IxD) and experience design—are well-represented at the conference—not just in terms of attendees, but also speakers.]]> By James Kelway

Published: July 7, 2008

Organization
Content
Presenters
Proceedings
Venue
Hospitality
Community

The 2008 IA Summit was held April 10–14, at the Hyatt Regency in downtown Miami, Florida, shown in Figure 1. It had the highest attendance in the conference’s nine-year history: Over 600 people signed up for the conference run by ASIS&T (American Society for Information Science and Technology). All the signs are that information architecture (IA) is a community and a practice that is growing, and that its sister disciplines—interaction design (IxD) and experience design—are well-represented at the conference—not just in terms of attendees, but also speakers.

Figure 1—Bank of America tower in downtown Miami

There certainly is a need for our design services, as a photo Kristen Johansen captured of the lifts—that’s elevators to those of you from the US—inside the conference hotel shows. (See Figure 2.)

Figure 2—An interface design failure

Photo by Kristen Johansen

This was my first IA Summit—and a conference that I had anticipated would be “one of the best I would ever go to,” as touted by a previous boss who had attended the Las Vegas Summit last year. Though I try to avoid hype at all times and was determined to look at the Summit through objective eyes, I must say the range of speakers was impressive.

Organization

IA Summits have always attracted a diverse crowd—not just information architects, but those involved in all aspects of user experience, from usability consultants to interaction designers and librarians to product managers and business analysts. This diversity in the community has provided it with a source of ever-evolving ideas and theories about how the practice can conduct itself and develop into the future. The dialogue around emerging tools and techniques is fascinating and inspirational—and not without disagreement and argument.

On Saturday night, amidst a Yahoo!-sponsored evening reception, information architects discussed new concepts presented on posters displayed around the room. This event was designed so attendees could interact with the poster’s authors, so it was a great way to engage in some conversation and gain inspiration.

As a first-timer, a few things struck me. This was a vivacious crowd—outgoing and talkative. The attendees here love to communicate, and the venue was very conducive to this. Groups could easily form and circulate, especially in the Miami sunshine overlooking the river, as Figure 3 shows. All the conference halls were arrayed around one central area, so going between sessions was an easy experience.

Figure 3—Area outside the conference hall, where people frequently met between sessions

Unfortunately, this was a weekend when American Airlines had grounded over a thousand flights for safety checks, and this had an impact on the schedule and the available speakers. I had particularly wanted to see Garrick Schmitt from AA | Razorfish, but alas, because of the problems with flights, he failed to materialize. The organizers did their very best to cope with this situation, and there was a minimum of disruption over the three days of the conference. They also ensured that popular sessions ran again in a few overflow rooms, and that was a popular decision made in difficult circumstances.

There were several social events for those new to the community and those who wanted to catch up with old friends. I have heard it said that some Summit attendees feel that they are on the periphery of a clique of Internet gurus that seems impenetrable to those who are new to the discipline, but I didn’t find this to be the case at all.

Once you get over the shyness of approaching somebody—be they well known or not—everybody was open to talking. I made at least twelve new friends that I intend to keep up with, and I wouldn’t call myself an outgoing type at all. As long as you are willing to discuss topics openly, I felt this community was perhaps the friendliest I have experienced at any conference.

Content and Presenters

Fortunately, I had convinced my company to invest in my enrollment in the workshops that preceded the main conference. This proved to be a good move, as I needed not only to overcome jet lag, but also to acquaint myself with the environs—Miami has many distractions—and the people attending the conference.

Day 1: Pre-conference Workshop: Yahoo! Pattern Library

Presenters: Erin Malone, Christian Crumlish, and Lucas Pettinati

On the first day of the pre-conference workshops, I opted for the Yahoo! Pattern Library, as I had recently written a sector-specific pattern library for my company. To actually be taught by the creators of the most celebrated pattern library how to produce one was a really useful opportunity, and I wasn’t disappointed. Figure 4 shows the workshop’s participants.

Figure 4—Workshop in action

Photo by Erin Malone

Not only did Erin Malone, Christian Crumlish, and Lucas Pettinati tell us how to construct a pattern library, they also discussed the concept behind building one, the history behind Yahoo!’s development of their own collection of patterns, and how to manage and evangelize the use of a pattern library within a company. Here are some of their key points:

• “A pattern describes an optimal solution to a common problem within a specific context.” Context differentiates a pattern from a standardized treatment.
• A pattern library needs to be a living thing. It must be published online where all users of the library can access and refer to it. It needs developers at its core and the code behind the pattern to ensure the patterns are workable, useful, and immediately effective.
• Developing a pattern library requires debate and conversation within a community of decision makers for it to thrive. Patterns are not prescriptive, but descriptive. They are a more democratic way of implementing design changes in which best practices become the foundation of patterns.
• Pattern libraries help empower people by encouraging collaboration. They serve as a bridge between people, allowing an agile approach to implementing solutions.
• “People will not turn away from saving time and money. Rapid prototyping enables that.”—Erin Malone

My View

I was already sold on the idea of using patterns and their importance, but learning about the history behind them, how to manage a pattern library, and where within Yahoo! the UX team that develops patterns is placed—within the Development group—were really useful key insights.

During the workshop, we worked together in teams, which was a good way to start to get to know my peers. So, from this point on, I had some familiar faces to say hello to in the corridors or with whom to share a beer in the hotel bar.

As a parting gift, Yahoo! gave each of us a memory stick with their entire library on it, plus stencils for Visio, OmniGraffle, and Illustrator to help us with wireframe generation. Like the whole workshop, this gift was well thought through and delivered. The passion and commitment of the presenters really shone out and made for an enjoyable first day.

Day 2: Pre-conference Workshop: Information Architecture 3.0

Presenter: Peter Morville

On Day Two, there was again a wealth of choice from among some of the leading lights of the IA community.

I decided to attend Peter Morville’s Information Architecture 3.0. I had read both Ambient Findability and the polar bear book, Information Architecture for the World Wide Web, so I thought this would be a progression from those keystones in IA thinking. Figure 5 shows a slide from his presentation.

Figure 5—Information Architecture 3.0 title slide from Peter Morville’s presentation

In many ways, though, Morville’s presentation was more of a review of all the key points from his books, with extra elements thrown in. I enjoyed the session, but some felt it was more of a lecture rather than a workshop.

There were a few in the audience who either had a personal point to prove or just liked the sound of their own voices. This generated some noise around topics about which I would have liked more constructive discussion. However, I think the main topics Morville talked about during his presentation will formulate ideas for his latest book about search patterns, which is due out later this year. Morville’s key points included the following:

• Compelling content is the key factor that tips the scale in determining at what ranking a search result ends up. Inbound links are a massive factor.
• We have to make judgments and identify questions, but we must test them on our users. In an associative learning experience, we must strive for the 80/20 rule. A user’s search query evolves, so simply reducing the time to find may determine a user’s ability to find.
• A search interface is the second most accessed area on a page, regardless of layout or site purpose.
• The ability to include users without disturbing the experience is key. Many Web 2.0 sites engage users in helping with the organization of site content. This willingness to be messy and iterate makes for a lot of change and noise, but this change is good for information architecture, and many of these sites do have good information architectures. (Morville cited Flickr as an example.)
• Remember our roles will evolve; the name of what we do will change. We need to do more than just follow our users to create solutions that are creative and innovative. Information architecture is both a project and a process.
• Ethnography is the killer user study tool.
• IA strategy commonly throws up challenges to a company’s strategy, and change management will be a common factor in many IA projects.
• Facilitate conversations to establish success metrics. Is the client happy a year later? Customer satisfaction and metrics define success.
• “Iterative design is good, but you need a structured method to stop going around in circles.”—Peter Morville
• We must evangelize and be bridge builders. In the collaboration space, you must allow people to collaborate. We need to learn from experience and design for the future, as we are producing the legacy systems of tomorrow

My View

Morville’s talk really encapsulated a lot of the themes that recurred throughout the next three days of the conference. At the time, it felt like a 7-hour brain dump from one of the leading thinkers in the field. To this end, I was happy to be there, but perhaps because of the style of delivery, I think many people felt that they were sold short.

From my point of view, Morville raised some important questions. He was also candid in admitting he didn’t have all the answers and shared some project failures that he had experienced.

What Morville did, like many good teachers, was ask more of us at the end of the session than at the beginning. If you expected to leave with all the answers to what IA 3.0 is, the likelihood is that you left with more questions. This is not a bad thing in this domain. We are still evolving as information architects, as is the Web.

This was a thought-provoking session that showed how Peter Morville can be a catalyst for advancing the discipline with new ideas and techniques. He certainly raised some really important issues in terms of what information architecture is, where is it going, and how important it is that we are instrumental in the design of systems.

Days 3–5: Conference Highlights

The following presentations were the ones I gained the most from, but from talking with other attendees, I know I missed many other great presentations. This is an unfortunate element of any conference, and this review is a personal one. I recommend you go to the IA Summit Web site where there are links to presentations on SlideShare and audio files on Boxes and Arrows. A majority of the presentations are available on SlideShare.

Keynote: Journey to the Center of Design

Presenter: Jared Spool

I remember the almost audible shock from the audience when Jared Spool, shown in Figure 6, opened up with a slide that stated UCD is dead. I know a few people really thought he went a step too far, but it certainly grabbed your attention. I think the main thing for me was that he did at least qualify this statement through some very well observed and researched analysis.

Figure 6—Jared Spool giving his keynote

Photo by Kristen Johansen

The key points of Spool’s talk follow:

• User-centered design (UCD) came from psychology and human factors, not product design. Companies that design through a UCD process are missing a vitally important element. If 20% of your users provide more than 80% of your revenue, designing for all users is inefficient. In effect, UCD is an inefficient methodology that has become dogma.
• Spool has studied the best design teams and found they use tools and techniques rather than processes and methodologies. The best teams ignore their methodologies, and the least successful are chained by theirs.
• Spool’s stone soup story illustrated the nature of collaboration. In the anecdote, the stone was an object that helped people work together. The stone could be a metaphor for a methodology, but it is not the thing that makes the product—or the soup in this case.
• People are the most important parts of a process—those that facilitate—not the process itself.
• The goal is to create informed design. What gets measured gets done, and yet, what gets rewarded gets done well. We should build a reward system based on informed measures.
• The determining factors in whether a company achieves a quality user experience through its products are
  • gathering feedback from users to gain a clear vision of their future
  • a corporate culture that rewards failure

My View

Spool’s deliberately inflammatory start aside—remember Spool is an entertaining showman—I think he offered a collection of valid and well-timed observations. As we move onward into an ever more agile development environment, these ideas are vital in defining success. In companies that have embraced UCD and in which it has become the only method of tackling a problem, UCD’s becoming an obstacle to progress is a very real threat.

Spool rightly suggests we need to think about being adaptive and versatile in the way we approach our problems and offer solutions that are sympathetic to the context in which they reside.

There were amusing moments of audience participation and meanderings around the ineffectiveness of the US Transport and Security Association. But the main point of this hour-long talk was how important the culture of a company is in defining its success. (In my mind, this relates to a recent post by Peter Merholz about getting a design director onto a company board of directors.)

Spool’s talk was not so much a dig at UCD as a methodology, but more about the business strategy a company needs to produce a quality user experience through its products.

You could argue that information architects are not at the right level to influence cultural change, but actually, I think it’s exactly the right area in which to apply some pressure to make companies more dynamic and responsive.

Once we got over the initial attention-grabbing headline, this keynote delivered some eminently sensible thoughts, and I hope they resonate with change agents, including information architects, and that we do something about it.

IA Enterprise Portals

Presenter: Joe Lamantia

I wanted to see this presentation primarily because I have been following Lamantia’s five-part series on his building blocks system on Boxes and Arrows. Figure 7 shows Joe Lamantia taking the audience through his slides.

Figure 7—Joe Lamantia’s presentation

Photo by Bart Vermeersch

In his talk, Lamantia outlined the main principles of his building blocks approach. Building blocks have the following characteristics:

• portable—syndicated, reused, duplicated, and distributed
• independent—can work alone and also within a hierarchy when stacked together
• inheritance—scalable, with interactions and relationships that are remembered between page elements
• layering—blocks cover all aspects of the experience.

From a professional point of view, I have felt this concept has a real use for CMSs. Though this presentation focused on enterprise portals, which are “universal, ubiquitous, and permanent” and hold “more pressure, politics, and risk” than the average Web site.

The presentation unfortunately suffered from running short of time, so half the audience got up and left to go to their next session. Lamantia continued amid three minutes of hubbub, describing his building blocks system, which is designed to “escape flatland” and offers a richer and more diverse user experience. His system fits very well with design pattern libraries, because it breaks up the components of Web sites into sections that sit within a hierarchy and have solid logic behind them.

I see no reason why Lamantia’s theory cannot expand into all kinds of Web sites, because it offers a way of organizing pages in a widgetized way. My company is currently investing in a CMS that would benefit from the architecture Lamantia proposes. The system is vendor neutral and technology independent, so that is yet another reason for following this approach to building the information structures of sites.

I found this a useful session, but I did want more and wondered whether a 45-minute session was enough. Perhaps a workshop would have been better, because it was a conceptually challenging talk that may have been too complex for such a short time slot.

How to Be a User Experience Team of One

Presenter: Leah Buley

In terms of engaging the audience, this session was a personal favorite—not only because of the subject matter, as I am a lone-wolf IA in the company I work for— because of the manner in which Buley, shown in Figure 8, conveyed her subject matter. I strongly suggest you see her presentation on SlideShare.

Figure 8—Leah Buley giving her presentation

Photo by Javier Valasco

What really stood out was her enthusiasm, and that energy is absolutely vital when working on projects with clients who may not be confident in you or who need encouragement.

Buley outlined her methods of idea generation, how to assemble an ad hoc team, and the methods she uses for picking the best idea. She really focused on collaborating, testing, and showing ideas spontaneously. She offered a whole range of tools and techniques that would enable rapid prototyping based on a large number of initial ideas.

Buley stated that design principles are very important, because they not only let you refine the ideas you generate, but also help you defend those ideas. These mantras enabled her to give confidence to other team members and the client, because they helped establish her authority and showed that she cared.

Those three elements—confidence, authority, and being conscientious—really do define a professional, and of course, being a good designer! By the end of the session, she had a few people cheering in the aisles. It was a rallying call for all those lone UX people out there. Being there let me realize that many people do work in isolation, and that is exactly why this conference is unique and so important to them.

Inspiration from the Edge: New Patterns for Interface Design

Presenter: Stephen Anderson

Extending the Gaming Experience to Conventional UIs

Presenter: John Ferrara

These two presentations effectively demonstrated that the jump from standard Web interfaces to something more intuitive—like the iPhone—has become reality. Both of these talks interested me, because I think the medium in which we interact with information will eventually become increasingly game-like. In other words, the tools we use to access information will be as easy as playing a game on a Wii console.

Anderson, shown in Figure 9, wanted us to “look beyond the industry rivals and say no to default thinking.” His presentation was about seeking inspiration that influences design. With new technologies, almost everything is possible and software is changing.

Figure 9—Stephen Anderson

Anderson stated that natural behavior is superior to learned behavior, citing the iPhone, on which you touch and drag a page to move down and can push the contents of a page around. Yet on a Windows interface, when you click a down arrow on a scroll bar, the page goes up. The four key takeaways were:

• Look beyond the surface.
• Think outside the UI box.
• Design with less space and think in conversations or scenarios.
• Make it visual.

So, our designs need to be adaptive, and associative learning should aid a user in following a path. This was an enjoyable talk. Technology seems to be at the right stage for a new approach to user interfaces, and the iPhone seems to be the clarion call for them.

John Ferrara concentrated purely on games and took a slightly more analytical approach than Anderson’s purely show-and-tell approach. Anderson said games have the benefit of creating an effortless community, in which you learn by watching and experiencing. They exhibit a fluid system of human computer interaction, and they are easy to customize. Ferrara added that they have a vast popularity that is seemingly untapped. “Games don’t need to be artificial. They can solve real problems.”

Ferrara also looked at patterns in game design, such as the physical presence of the user in an environment, temporal motion, adaptive experiences—visualizing how you play—and the ability to build different user experiences into different contexts—again hinting at the value of associative learning to the user.

Both Ferrara and Anderson talked about the importance of the user interface and how its design and user interactions can dictate how we display content and how users can interact with that content in the future.

I think we are nearer to a convergence of information architecture and interaction design, because the technology of touch-screen computing is forcing us to look at our disciplines in new ways. If you could present users with different information, because the computer has learned from their behavior, imagine the possibilities? If you can make a user experience addictive and fun—as Buley stated in her presentation—you really will have a successful site, with entertained users.

Content Page Design

Presenter: Luke Wroblewski

Wroblewski, shown in Figure 10, has an enviable knack of being incredibly relaxed and lucid while delivering solid gold nuggets of insightful observations and recommendations. This presentation was probably the most useful in terms of being able to apply learning in my workplace.

Figure 10—Luke Wroblewski

Photo by Bart Vermeersch

It was the research that was the most eye opening. For instance, out of 650,000 URLs, page views for 25% were for less than four seconds. This affirmation of our users’ scatterbrained tendencies makes it clear we need to employ good page-layout design and visual hierarchies when displaying information.

Wroblewski walked through various elements that address the need to focus on content and deliver on the promise of content that users find through search results pages.

I found this session informative, and it really helped me think about the context in which we deliver content to our users. When displaying information users seek, we need to ensure the relevance of our content to avoid high bounce rates and low referrals. We also need to display clear calls to action that our analytics teams measure.

The Information Architect and the Fighter Pilot

Presenter: Matthew Milan

This was a really interesting look at how we can apply the strategies of John Boyd, military strategist, to the design domain. Milan looked at Boyd’s OODA model (Observe, Orient, Decide, and Act) and proposed it as a method we can use in our design practices.

Milan presented his ”discourse to make people think,” and it certainly did that. One member of the audience questioned Milan about whether he thought information architecture was worth saving? He, at the time, replied yes, but has since questioned this on his own blog. (I won’t go into explicit detail here, because it is quite theoretical, and I am not entirely convinced of how legitimate it is to draw parallels between a domain that destroys and one that creates, but I can see his point in some areas.)

As a design discipline, we do need to deconstruct problems and solutions more readily. Milan stated, “We are good at structure and yet bad at unstructure.” I guess unstructured approaches do tend to upset IAs, and this is why the folksonomic tagging and emergent taxonomies cause so much discussion and division.

I suppose what Milan really wants is to generate a new way of looking at what we do and break from the confines of what we now accept as information architecture. As we neared the end of the conference, it appeared that what we are and what we thought we were are entirely different things.

Day 5: Closing Plenary: Linksosophy

Presenter: Andrew Hinton

After five days at the conference, Andrew Hinton’s presentation, shown in Figure 11, was a refreshing take on the state of the IA nation. He effectively illustrated the confusion around our discipline, the different schools of thought in the community, and how arguments about what IA is have created divisions between different groups and personalities.

Figure 11—An animated Andrew Hinton during his closing plenary speech

Photo by Javier Valasco

“Findability is only useful in service of context and connection. IA defines the relationships and connections between contexts. Interaction design is the interactive function within a given context. This overlap is seen in navigation.”—Andrew Hinton

Hinton stated that the practice of information architecture is both a shared history of learning and a community of practice. We are an emergent group. There are many new factors emerging within the context of the discipline, which is still defining what it is.

To this end, you could say that information architecture is emerging and converging at the same time. The overlaps are evident and real. The boundary between where information architecture ends and interaction design begins is hard to define. In the same vein, where does a taxonomist end and an information architect begin? There is no clear answer, because each role—regardless of whether person is called an information architect—is subject to a specific context and culture. These factors will always influence what explicitly an information architect does.

The closing plenary provided a fitting end to a great set of speakers. The field of information architecture is very much alive. It is evolving and still very much in its infancy.

Proceedings and Themes

The theme of this conference was “Experiencing Information,” and certainly, the interaction element of user experience was well-represented here—perhaps more so than at previous conferences. Throughout the week, I met several interaction designers, and they considered themselves to be a part of this community. It is a good thing this is not an exclusive community, but it is also one without defined borders and has overlapping disciplines.

There was a lot to see and do at the conference, and it is a little overwhelming. It seems like you should be in all of the sessions all of the time, but of course, you need to be selective and go to those sessions that are most relevant to you.

I felt it would have been good to repeat a few more sessions. Looking around a room, you would most likely see speakers from other sessions. Everybody needs inspiration, and there were many informative sessions.

Hospitality

There were plenty of social events, and Richard Dalton, Conference Chair, and Priyanka Kakar, Chair of the Social Committee, both shown in Figure 12, deserve a special mention for being pleasant and cheerful during the entire five-day stretch.

Figure 12—Richard Dalton and Priyanka Kakar

Both work as UX professionals and have been involved in the organization of the previous IA Summits, and their experience definitely showed. I know they had some tricky issues to deal with, but their enthusiasm helped make the conference a great one for me.

Community

The IA community is unique. Perhaps it is because everybody has a genuine interest in their colleagues and peers. Or that we all share the experience of nobody else in our company really knowing what we do.

The wall of deliverables, shown in Figure 13, was a hit! The posters were entertaining. I heard the IA slam was a lot of fun. All of these events help to make a memorable event, unlike any other I have been to.

Figure 13—The wall of deliverables

The sense of community provides a lovely atmosphere. The conference is exhausting, and your head spins with all the new ideas you have just heard. You have just 15 minutes to have a coffee, check out the career room, or swap some trading cards, shown in Figure 14. (Yes! They did them again this year!)

Figure 14—The ever popular trading cards

Photo by Kristen Johansen

The people at the conference are ready to listen and offer advice and support if you need it in your work. The Information Architecture Institute (IAI) are also very visible, e