Teaching Information Architecture to the Design Student

by:   |  Posted on

I teach an Information Architecture class for undergraduate design students at ”I knew that I was not going to turn a junior-year graphic design student into an information architect with only six credits of course work.“Pratt Institute. Teaching IA to students of design is not unlike working with practitioners of design. A good designer will usually have an instinctual understanding of IA, but without deliberate attention given to IA, it sometimes gets ignored. In order to talk about IA, it needs to be made relevant to the designer. IA issues should not be addressed by suggesting visual solutions but instead, the designer should be shown where the design is weak because of poor Information Architecture.

Prior to teaching, I was a student at Pratt Institute. At the start of my senior year, the ‹img› tag was brand new, Netscape Navigator was just unleashed upon the world, and a professor of mine handed me a copy of Edward Tufte’s “Envisioning Information.” It would take years for me to begin to understand how the first two events would affect my life, but Tufte’s book immediately began to shape me as a designer.

My senior year was spent doing nothing but information design —maps, diagrams, interactive information kiosks. At the time few faculty members understood my desire to work on these projects, but many years later I was asked to draft a related course. The school needed to prepare students for the large number of ‘Information Architecture’ jobs that had started to flow into career services.

The class
Approaching the class realistically, I knew that I was not going to turn a junior-year graphic design student into an information architect with only six credits of course work. I also doubted that there would be 12 students every year that wanted to digest the library science and human cognition knowledge in order to become an IA. Instead I decided that what the design student needed was a design course that stressed usability, human factors, and clarity, instead of the typical branding and interpretation problems they usually encounter in their other design classes. This class would be very similar to the work I did in my senior year.

Such a class would give these students a good foundation if they ever chose to pursue IA or collaborated with an information architect in the workplace.

Studio classes at Pratt all have a similar structure, and usually meet once a week for a three-hour session. An assignment is given, and in the subsequent weeks, sketches and final projects are reviewed. The class critiques are designed to help the students learn from each other and resolve their design solutions. Class discussions are encouraged. My class follows the same structure. The difference being that the projects assigned and the critiques given put the usability of the students’ solutions above than the visual aesthetics or composition.

The class is also broken into two semesters. The first half of the year consists of short projects designed to teach specific information design concepts, and the second half deals with one or two large-scale projects where students have the chance to wrestle with multiple problems. So far I have taught two classes, both of which were the first half of the course, the Information Architecture I class.

Going from theory to practice
I always approach teaching IA to the designers in a very abstract way instead of giving specific rules and solutions. I want the students to understand why and how things work so their creativity can be guided by knowledge rather than having their designs be burdened by arbitrary rules. Because of this approach I have found that communicating academic IA topics, like labeling systems, wayfinding, and interface heuristics is much more successful if I present them during a class critique, rather than during a pre-scripted lecture. The students are more likely to pay attention because of the very clear relevance to the work they are doing, and a tangible problem helps them understand the abstract concepts.

In one of my first classes after assigning a project about organizing photos, I gave a lecture on classification systems. It was less successful than I had hoped because it was structured and pre-scripted to some extent, and I found that the lecture I had planned did not address a fair number of issues that I saw in my students’ work. In subsequent projects I wove this type of information into critiques, and the class was more receptive.

Classifying and grouping is such a basic skill; I thought that this assignment would be finished in a week or two, and we would move on to something more interesting. This assignment ended up dragging on for five weeks, and the students got bored and frustrated. The problem was that there was no end purpose for organizing the photos-no context. The assignment became an abstract exercise with very little relevance. The students could have come up with a perfectly reasoned organization scheme, but without knowledge of how the photos would be used, there was no way to evaluate their work.

In short, design students (and designers) will more often produce wonderfully functional pieces of design if they understand the human interaction problems they are being asked to solve.

Realizing my errors, the next assignments I gave worked much better. I gave very clear problems that needed to be solved. I gave restrictions and requirements that focused the students’ attention on the problems that I wanted them to think about. I removed formalized lectures from my lesson plans.

The follow-up assignment involved doing on-air graphics for an Olympic sport. I brought in screen shots and video clips of what NBC had done for the 2002 Winter Games. I personally thought NBC had done a poor job, and pre-discussion of the NBC examples allowed the class to get past the aesthetics and focus on the functionality of the design.

The students were asked to pick a sport and watch it on TV (the Olympics were on for another two weeks after I gave the assignment). During the broadcast they were to write down what information they wanted to know about the game, if the on air graphics (or the announcer) were supplying them with the information they needed, and how well that information was presented.

Armed with a user’s perspective and a clear objective, the solutions the students came up with were quite good. In addition, we did all of the class critiques with the designs displayed on a television, and the class began to understand how to edit their designs so they would read on low-resolution mediums. This skill also helped them in later print-based assignments.

Other projects that I assigned included: designing a kiosk for ordering commuter train tickets, making parking and trash collection street signs, and visual directions for making a food item. During class sessions I would ask students to use the designs made by their classmates. This form of user testing was easy and beneficial.

What about websites?
I have purposely avoided directly giving assignments that deal with websites. It is not because I think they are poor design problems. The issue is, websites have too many problems that need to be thought about and solved, a task that can be overwhelming. I also believe that many of the design issues that websites present can be taught using non-website projects.

Websites also bring with them the quagmire of technology. I want to teach a user-centered approach to design, and if my students also need to learn a new way of working (i.e., HTML, CSS, etc.) at the same time, I would spend a bulk of the class not teaching design. It is my opinion that the design issues I am teaching will help the student after they graduate, while any web technology I teach them will be incomplete (because it not the focus of the class) and several years out-of-date by the time they enter the workplace.

A solution might be assigning traditional IA deliverables like wireframes and flowcharts. I am concerned about having the students create these planning tools without seeing them as a finished product. This means there is no way for the student to evaluate, and learn from, their work in a more realistic context. It could be like going through the motions of organizing photographs.

I also have mixed feelings about having students do static Photoshop mock-ups of websites. This exercise places too much focus on the aesthetics, and doesn’t give them any experience in designing interaction. Photoshop mock-ups also don’t allow students to solve the design issues of designing for sites where most of the content resides in databases, and the content is created after the design is completed.

These are some of the issues I plan on teaching during the Information Architecture II class where assignments will allow the students to wrestle with interaction and fluid data problems. The trick will be to not have the students overburdened with unfamiliar technology. Not every student will have taken an HTML course, and I would prefer not to make it a requirement.

Despite the challenge, a website will most likely be a project in the second semester. I would be neglectful as an educator if I let students walk out of my class and into an interview for an IA position without a well-architected site in their portfolio.

See You in September…
I am looking forward to teaching again; former students have overwhelming said that my class was worthwhile and invaluable because it gave them a completely new way to think about design. Teaching students is not unlike working with professional designers, both require a fair amount of respect, effort, and patience. But, once a designer understands IA issues, their designs become successful on another level, and only good things can result from that.

James A. Spahr works as a designer and programmer for Designframe Incorporated. His design work has been showcased in Graphis Books and in ID Magazine. He teaches undergraduate Information Architecture and Graphic Design at Pratt Institute.

The Big O: IA Lessons from Orienteering

by:   |  Posted on

Orienteering is a sport where competitors use a map pre-marked with a series of control markers to navigate through a terrain (usually a park). Competitive orienteers run between control markers, using a combination of map-reading techniques and navigation strategies to find the quickest route.

Backstory
Last June I found myself in Calgary, Alberta, on business. I had a few hours to spare in the morning, so I grabbed the map of Nose Hill Park I’d ordered from the local orienteering club, and went out to practice my orienteering. From the parking lot, I started to run up the large hill to the first control marker, carefully checking my map and route along the way.

“Designing effective catching features is similar to providing a strong information scent. Within ten minutes I was lost. The terrain I was running across didn’t resemble the terrain described on the map. What should have been open land was actually a small forest. A dozen unmarked paths crisscrossed through the trees. While searching for that first control, I had two thoughts. First, I was feeling the same kind of frustration I’d seen from people in user testing (“It should be here… why isn’t it here?”). Second, if orienteering isn’t that different from web navigation, then maybe it can inform the practice of information architecture.

John Rhodes used a real-world navigation metaphor to explain information architecture in his WebWord article “Information Architecture for the Rest of Us.” The article goes a step further by applying orienteering strategies and terms to IA and navigation design. Several orienteering strategies – including map simplification and contact, navigating by checkpoints, rough and precise map reading, and using attack points to find the goal – have useful IA parallels.

Simplification and rough map reading
An orienteering map has too much detail to absorb quickly, and most of it is extraneous to the orienteer’s goal of finding the shortest path from their location to the next control. A good orienteer maintains “map contact” by checking her map once every five to ten seconds. Simplification – the practice of ignoring unnecessary map details and focusing on important ones – is an important skill in orienteering.

This kind of rough map reading is analogous to scanning a web page for information (see Chapter 2, page 22 in Steve Krug’s book, Don’t Make Me Think). Both the orienteer and the user know their goal isn’t immediately in front of them, so they focus only on details that will bring them closer to their goal.

Checkpoints and catching features
Checkpoints and catching features are easily-recognized features of the terrain, such as a hill or a fork in a path. Just as the name suggests, orienteers use them as cues to “catch” themselves, or to stop, check the map and adjust their route. Catching features also allow the orienteer to focus on only one or two details on the map, and to create ad hoc, but effective, navigation rules that allow for speedy movement. For example, “Follow the edge of the forest for one kilometer until I reach the boulder.”

Designing checkpoints and catching features
Designing effective catching features is similar to providing a strong information scent. Effective labels and logical groupings of content can help users create those ad hoc navigation rules that let them move quickly to the area of the site they want. Images help reduce the ambiguity of labels. You want to make the features of the terrain as clear and unambiguous as possible, allowing your users to move rapidly to their goal.

Precision map reading and attack points
In usability testing, subjects often reach a point where they are confident they can complete a task – such as filling in a form, making a purchase or retrieving a particular piece of information. Many of them get to a point where they can say, “Okay, I know I can do that from here.” In orienteering terms, they have reached an attack point.

As experienced orienteers move toward a control marker, they shift from rough map reading to precision map reading. Precision map reading involves moving slowly, paying more attention to the map details, and scanning the terrain for the control. Typically, when approaching a control, the orienteer will pick a catching feature to use as an attack point. Arrival at the attack point is where the precision map reading begins.

Creating attack points
An attack point is where a user starts to work at reaching their goal, such as purchasing a product or reading an article. When the goal is simple, such as reading today’s headlines, the homepage often serves as the attack point. With a more complicated goal, like purchasing a PDA, several attack points may be offered based on users’ goals.

Attack points can be links, pictures or any other combination of page elements that facilitate the shift between rough and precise reading. Amazon, AOL and AT&T use the search box as an attack point by using keywords to take users directly to a page, or by presenting a filtered set of best-bet search results.

Figure 1
Figure 2

Amazon vs. Buy.com
To put the orienteering analogy to the test, let’s compare Amazon and Buy.com and look at how we might “attack” our goal of purchasing a PDA.

Figure 1 shows the main electronics page for Amazon and Buy.com. In addition to the left-hand menu, Amazon has prominent images and descriptions – these are checkpoints or catching features – for the main electronics categories. Buy.com merely has a menu on the left-hand side, and probably hasn’t included enough catching features for users who want PDAs However, the Buy.com list of featured products on this page is essentially a series of attack points.

Figure 2 compares the main PDA page from each site. Buy.com shows several products, attack points for people who want to purchase those products. Amazon’s page is a hybrid of checkpoints in the upper left, additional navigation for users seeking a particular brand of PDA or operating system, and attack points on the right. Offscreen, Amazon also offers two unconventional attack points – a buying guide and Consumer Reports product reviews. These might help “rough map readers” who are unsure about committing to a purchase or are lost in the section to switch into their precise map reading mode.

It’s also worth noting that in Figure 2 the design of each page changes. Those changes are consistent with what we’d expect from attack points: the product images are larger, there are more details on each product, and on Amazon the left-hand menu disappears.

Conclusion
Analogies between spatial and hypertext navigation tend to break down at some point, and this one is no exception. But up to that point, these analogies can still provide us with a helpful framework for analyzing site structures and designs. My hope is that by borrowing from orienteering’s well-developed navigation strategies, vocabulary and practice, IAs gain another way of thinking about, explaining and solving navigation problems.

(And you should really go out and try it, since it’s a helluva lot of fun, and easy too.)

For more information:

Gene Smith works for the government of Alberta, Canada. He leads the team responsible for the content, IA, design and usability of the main government web site (http://www.gov.ab.ca), and manages a government-wide web site standards process. He occasionally writes on his web site www.atomiq.org. Most Wednesday nights during the summer you can find him orienteering with his local orienteering club.

CEOs Are From Mars…

by:   |  Posted on

I’m pretty much a professional half-breed. You see, with both a television production background and an M.B.A., I have spent the past 20 years trying to bridge, heal, soothe, mend and otherwise repair the pervasive gap that divides “suits” and “creatives” in the business world. Along the way, I’ve played a number of roles including ringmaster, referee, coach, ambassador and even secret agent.

In an ideal world, both sides would meet in the middle and split the distance 50/50. In reality, many business managers are simply unable to reach across more than 20 or 30 percent of the distance.

What I’ve learned is that the antagonism, hostility and resentment often felt on both sides of the equation is the outgrowth of a basic failure to understand what makes the other side tick.

What we have here is a failure to communicate
I used to believe that hard-core businesspeople actually understood their Photoshop-toting colleagues but chose, proactively and aggressively, to dismiss their skills, capabilities and talents as inconsequential fluff. The truth is much worse: many businesspeople simply don’t have the slightest idea what separates “good creative” from “bad creative.”

I’ve had executives admit to me that they couldn’t tell the difference between two competing portfolios, designs or layouts if their lives depended on it. At the same time, it’s fair to say that many designers are equally oblivious to the underlying business issues that drive decision-making in their organizations.

But, here’s the catch: design teams are the ones most likely to lose out when business requirements clash head-on with design imperatives. Because executives must stay focused on bottom-line results, aesthetic elements that seem indirectly related to the company’s business goals are easily dismissed in the corner office.

The hard part is that these design imperatives are, many times, a large part of the bottom-line results. To bridge the gap that divides business and design teams, it’s important that IAs and designers:

  • understand and respect the fundamentally different world views that separate them from most business managers,
  • commit to meeting business managers halfway (or more) when it’s time to define and articulate project goals and expectations, and
  • commit to educating themselves more completely about business issues, ideas and trends.

The view from the corner office
Try to put yourself in the CEO’s natty suede loafers for a moment: As the keepers of the fiscal flame in an organization, most executives are, understandably, more focused on the more quantitative elements of a corporation’s daily life.

They’re tasked specifically with both generating revenue and saving costs. And, at the end of the day, will be measured and compensated (or penalized!) by results that are summarized at the end of each quarter on a spreadsheet. Qualitative factors including user experience, design, content strategy and customer experience are considered a means to reach end-of-year financial goals, not an end unto themselves.

In fact, compared to complex quantitative calculations and projections, design and content architecture issues seem relatively straightforward and simple. With no spreadsheet to consult, final decisions about design, customer experience and navigation elements might seem to be based on personal preferences, favorite colors and an armchair quarterback’s appreciation of what’s stylish and hip.

Most quantitatively-focused managers simply don’t comprehend the relationship between business strategy and customer experience, or how design and content architecture serve to facilitate and articulate strategic corporate goals in the marketplace. And, without a clearly articulated business rationale to support IA and design priorities, they never will.

Finding the middle ground
Most deadly of all is every businessperson’s deep-seated allegiance to their own creative point of view. As I learned in business school, you can never convince a “qualitatively challenged” M.B.A. that a) they can’t write, b) they have limited people skills, c) their PowerPoint slides are dull, or d) they have no creative aptitude.

Redefining user experience issues in terms of business impacts and “domino effects” empowers business managers to defend and explain initiatives to other senior managers further up the chain of command.

Make no mistake: when it comes to design and customer experience issues, most business managers have stretched themselves as far across the divide as they’re capable. In an ideal world, this would mean meeting their IA teams in the middle and basically splitting the distance 50/50. In reality, many business managers are simply unable to reach across more than 20 or 30 percent of the distance.

In this context, it becomes imperative for IAs and designers to take action to close the gap. And while this may mean that design teams have to take on more than their “fair share” of the burden, it’s important to not lose sight of the overall goal: delivering the best work possible.

By learning to frame creative issues in business terms and to draw meaningful connections between design efforts and the corporation’s bottom line, design teams and their projects are more likely to survive the corporate gauntlet.

The intersection of art and commerce
First, it’s important to take a close look at the organization from the inside out. Understand who’s writing the check for the project and what results they are being held accountable for. Ask:

  • How do project goals connect to the overall mission of the organization (if at all)?
  • Who stands to benefit from the project’s success?
  • What expectations—right or wrong—are associated with the project?
  • How long will it take the organization to see a return on their investment in the project?
  • How will the projects success and/or failure be measured at a corporate level?

For example, many corporate websites are created, primarily, to reduce costs associated with customer service (e.g., call centers, product documentation, software upgrades). To that end, the extent to which call center volume decreases and use of web-based tools or FAQs increases provides management with some indication of the site’s effectiveness.

Then, consider your project and the organization from an “outside in” perspective. Ask:

  • Are internally-driven corporate goals aligned with real customer needs?
  • Which customer needs is the project meant to address?
  • How are your company’s competitors responding to these emerging needs?
  • How will the new project impact other stakeholders (e.g., vendors, partners)?
  • How is success defined in this larger context?
  • Are there any related examples in your industry (or in other industries) that you can reference and learn from?
  • Have similar initiatives worked for other companies?

In the case of the customer service-focused website described above, it would be important to understand whether or not users are likely to accept a new form of customer service. Would an online option solve a problem for them or cause additional complications?

Armed with these two critical perspectives, a design team can begin to craft arguments that are solution-oriented and in line with the corporation’s bottom line.

Returning to the online customer service solution one last time, a business-savvy design team would focus on those elements that have the greatest impact on a user’s customer service needs. In this case, superior content, information architecture and user interface design are critical to the customer’s ability to find information and, by extension, solve the immediate problem that brought them to the site in the first place. If a customer in need becomes confused by the site’s navigation or search capabilities, they will never return to the site. By extension, their opinion of a company offering such a sloppy and incomplete solution will surely diminish.

Defining these kinds of business issues and “domino effects” also empowers business managers to defend and explain initiatives to other senior managers further up the chain of command. By anticipating questions and providing managers with the language to describe each design choice and associated business solution, projects are more likely to be spared endless rounds of questioning and negotiation.

And don’t forget to embrace and support those rare business managers who actually understand and support of your design team’s issues. These managers can be terrific allies and can also serve as a resource while you’re crafting the business case for your project.

A mind is a terrible thing to waste
You certainly don’t need an M.B.A. to understand basic business principles. It’s simply a matter of engaging your curiosity and beginning to make business issues relevant to your particular situation. On an ongoing basis, make a personal commitment to increase your general understanding of business issues, ideas and trends.

You certainly don’t need an M.B.A. to understand basic business principles. It’s simply a matter of engaging your curiosity and beginning to make business issues relevant to your particular situation.

By taking the time to study various industries and macro business issues, it becomes clear that there are business basics that drive every company. By finding parallels and lessons in other industries, you can begin to make better sense of your organization’s issues and challenges.

Understanding, for example, that Southwest Airlines actually considers its primary competitors to be railroads and bus lines (versus other regional airlines) not only provides you with insight into their business strategy, but also offers a great lesson in thinking more broadly about the dynamics of your business.

Begin picking up a Wall Street Journal once a week or, very simply, browsing the business section of your local newspaper. For more in-depth stories, the Harvard Business Review, despite it’s lofty and journal-like appearance, is a wholly approachable and practical source for new ideas, case studies and best practices across a number of industries. In fact, I have often recommended an article called “The Ultimate Creativity Machine: How BMW Turns Art Into Profit” from the January 2001 issue. It describes the challenges faced by the head of BMW’s German design studio as he seeks to ride the line between aesthetic, engineering and business requirements. For yet another look at emerging business trends, monthly magazines Fast Company and Business 2.0 scour the world for the most innovative and radical new ideas, companies and executives.

Business classes and seminars offer an opportunity to connect with other students to share new ideas. They are also a valuable resource for expanding your network of professional resources. This face-to-face interaction is critical. Imagine trying to learn a new language without having someone else to talk to.

Can’t we all just get along?
Remember that corporations are living, breathing ecosystems that are given life by the people who populate them. By making a conscious effort to focus on the big picture and bridge the gaps that divide the organization, you are contributing to a company’s overall success and, along the way, making your day-to-day working life, ultimately, a little less stressful.

Alma Derricks is the founder and principal of REV, a unique business strategy consultancy that provides firms imaginative strategic guidance, new revenue-creation models and fresh insight into what motivates and inspires customers. She can be reached directly at .

When the Show Must Go On, It’s Time to Collaborate Or Die

by:   |  Posted on

It was a tense meeting. Forty-eight hours before launch and a key multimedia effect was still not ready. The developers were trying to catch up on a long punch list of bugs; the designers wanted last-minute changes to things that were already on the “done” list. No one knew what to do. But there was a deadline, and the reviewers were coming. As a team, we walked through the schedule again and again until we had a plan. The next day, the video was edited, the shop finished the screens, and the production crew walked through the critical paths. Two nights later, the cannon fired, the song began, the screen dropped into place, the film played just as we’d envisioned it, and the cast members of “A Man’s A Man” took their bows before an appreciative live audience. Another show had opened.

Photo from "A Man’s A Man"
“A Man’s A Man” by Bertold Brecht Hyde Park Festival Theater, 1986. Directed by Tim Mayer. Lighting by Whitney Quesenbery. With Bill Murray, Stockard Channing, Gerrit Graham, Mark Metcalf, Brian Doyle-Murray, Bob Halley, Jr.

I became a lighting designer because I was in love with live theater, where lighting only exists in real time as part of the performance. Certainly, it has a utilitarian role: to put enough light on the stage so that the audience can see the actors. But the lighting also helps shape the performance by providing the color and overtones that add meaning and layers and depth. The same mix of art and technology, craft and discipline exists in user interface design.

Fast forward a few years, and it’s another tense meeting. Our demo was part of a presentation to the board of directors who were voting on whether to fund a new multimedia news service, but the video encoding was taking longer than we expected, and we weren’t sure if the bookmark feature would be intuitive enough. More late nights and it all came together. Another project launched.

As different as my two careers may seem from the outside, I never thought they were so different. Switching from theater design to interface design, I traded a forty-foot wide proscenium for one that was just seventeen inches across, and the big gestures of the stage for the more subtle movement of a hand on a mouse.

Are we all on the same team?
One thing that software and theater have in common is how many different skills are required. There are individual performance artists who pretty much do it all — write, direct, design, perform — creating perfect gems of performances, just like there are personal websites conceived and created by a single person. But most productions are the results of work by dozens of different people. At the center is the director, surrounded by the production team: designers, choreographer, and musical directors. Each of them has a team of people to create the design. It takes a lot of collaboration to keep everyone’s work in sync. We used to ask, “Are we all designing the same show?”

Sometimes we weren’t. When there was no shared vision–no overall design concept — I would end up in a situation like trying to light a musical comedy with a brown set and dark, brown wool costumes. Brown wool soaks up all the light and dulls the production’s sparkle. The lights may be bright and the actors perky, but the whole effect doesn’t hang together, and the audience can always tell.

But when all the elements work together, the effect is profound.

On the opening night of a new opera that I lit, the curtain opened on a scene that looked just like the pencil sketches from our design brainstorming sessions. Everything had come together to bring that vision to life. It wasn’t just that the stage looked like the picture. A performer told me that it felt like the only place where that opera could possibly take place, that it just “felt right” to be singing that story on that stage.

Original sketch for Tomorrow and Tomorrow   Actual scene from for Tomorrow and Tomorrow
Original sketches and the actual scene for “Tomorrow and Tomorrow” by Timothy Sullivan Center for Contemporary Opera, 1987. This one-act opera is an interior monologue, recounting an unhappy and lonely life. Directed by Stephen Jarrett. Scenery by Robert Edmonds. Lighting by Whitney Quesenbery. With Suzan Hanson.

A theatrical production includes several teams of people. Just in the physical production alone, there are scenery, lighting, costume and sound designers, supported by carpenters, electricians, drapers and a whole raft of craft shops to build and install the sets, props, effects and lights. As many as 50 craftspeople may be working in a theater just a day before opening night. That’s a lot of people, especially for the speed with which shows are produced. The collaboration works only because the roles and responsibilities are well defined and respected.

Despite all my years away from theater, I could still draw a competent light plot. It would not reflect all the new equipment and the design would probably look out of style, but an electrician would still understand it. The design artifacts communicate not only within a single craft, but between disciplines, and they are the language of the collaboration.

We are just beginning to understand all of the roles in designing the user experience. From the brand design that expresses the promise to the user interface that communicates it to the code that supports the functionality and interaction, all of the designers need to be speaking with one voice and a language that lets them work together.

Light plot Cue sheet
There is a standard set of paper work, or design artifacts, that includes the light plot, hookup, cue sheets and, to help the designer, a magic sheet.

If you can’t find it… it might as well not be there.
A lot of the work of putting on a play is simple craft. In lighting design, that means putting all the pieces together in a technically competent way so circuits don’t blow, lights don’t fall, and fire laws are followed. You need to have the lights placed so the entire stage can be lit, effects can be created… and the budget met. Finally, after all the planning and preparation, you go into the theater and create the cues — the looks, timing, and changes in the lighting — and coordinate them with the work of the actors and the other designers. And here, you get a few moments for inspiration and art.

When those moments come, it’s easy to forget that it’s not all about the lighting. The audience comes to see the play, and your work is just one part of the whole thing. Pursue gorgeous chiaroscuro at the expense of illumination and you get lighting that creates an effect of dark shapes. “The ones at the top that don’t move… those are the scenery. The shapes moving at the bottom… those are the actors.” When that happens, the designer has forgotten that, as important as the design is, the audience doesn’t come for the lighting or leave “singing the scenery.” Worse, instead of being wowed, they may just be baffled. It’s hard to hear when you can’t see the actors’ faces, and the brilliant nuances of the design are probably lost on an audience that came for the play.

I used to wonder why so many experienced professionals couldn’t get it right on the first try. Why were scripts that seemed so obviously bad on opening night ever produced? Wasn’t the very heart of the profession being able to visualize the results in advance? But what you can’t see in advance is how it will all fit together. You are supposed to be designing not only the same show, but the one the audience wants to see. That’s why those preview performances are so important: they give the production a chance to add the audience to the collaboration and to knit all the elements together more tightly.

Usability testing… coming to a theater near you
When you’ve worked on a show for several weeks, it’s hard to remember what it’s like to walk in the door and spend two hours seeing the performance unfold. You know all the nuances and characters and turns of plot. But what’s the experience like for an average audience? In software design, the solution to this dilemma is usability testing. In theater, it’s previews. A production used to have out-of-town tryouts. A show would play in smaller cities, testing the production in front of live (and paying) audiences until it was ready for Broadway. Other plays are developed in workshop or regional theater productions. Either way, it gives everyone a chance to see the play “on its feet” and make changes before they face the New York critics. It’s a nightly, elaborate usability test, as audience reaction is scrutinized and the production adjusted (whether minor changes or massive rewrites) until it all works for the audience.

One year, the Big Apple Circus included a famous clown, a top star of the one-ring European circus, with an act that was completely different from the red-nose physical humor of American clowns. His first night, he bombed. The kids just stared at him with no laughs and hardly even a giggle. We all waited for the tantrum, for the star to blame the audience. Instead, the next morning, while we were working on the lights, he brought his trunk into the ring and quietly rehearsed. That night, he got a few laughs, and over the next days he continued to work, changing some bits, dropping some, adding new ones. By the end of the week, he was getting the big laughs and the applause. He didn’t do it by abandoning his style of clowning, but by listening carefully to the audience and learning how to speak to them.

A play is different to everyone who sees it, just like an interface is different to every user. The interaction between the performers and the audience is part of the magic. Software is like that to me: a dance between person and machine, different in small, subtle ways every time, something that comes to life only in the user experience. It’s not surprising that when I was seduced away from theater by a small beige box, it was to design the user interface. The interface is live in the interaction, taking place in real time.

For more information

Want to know more about theatrical design? The two books I have read and re-read are:

Each was a pioneer, changing our vision of how theater is made.

Whitney Quesenbery designs user interfaces for Cognetics Corporation, a design and usability company dedicated to creating excellent user experiences. She is the manager of the STC Usability SIG and a member of the board of directors for UPA.

Getting into Government Consulting

by:   |  Posted on

From Washington, D.C. to Olympia, Washington, there’s a rich potential for user experience (UX) consultants of all flavors to provide services to government. In this article I’ll share some thoughts directed toward you, the independent consultant or small firm that would like to work with government. I’ve tried to imagine what I’d tell you if we sat down for a drink together and you wanted to get into government consulting. Here it is.

On safari in deepest, darkest bureaucracy: Understanding government culture is crucial for ongoing engagement.

Developing a consulting relationship with government can be quite different from your previous experience consulting for business. To help you get started, I’ll outline some lessons I’ve learned in my work with government, in three key areas:

  • Appreciating the differences
  • Understanding the culture
  • Finding your niche

These strategies promote a customer-centric consulting practice—after all, your clients are your customers, and many of the same user-centric principles used in design apply to your business operations. That’s not too different than consulting anywhere else. But your niche in government culture is likely to be something other than what you’re used to in business.

Dorothy, we’re not in Silicon Valley anymore
Assuming that government works just like business will cost you the contract. Appreciating the differences allows you to target your efforts effectively.

For consultants engaging government, focusing on the different levels of jurisdiction is a critical first step in targeting your potential clients. Do you want to work with local, state or federal government? While the federal government makes headlines with “$700 million in new IT spending,” local and state governments are often more accessible and can provide valuable opportunities.

Deciding which segment to serve is largely a factor of access—state and local governments often prefer “hometown” consultants who are sensitive to local issues. Federal contract opportunities exist across the country, but may be too large for independents to tackle alone.

Political ROI trumps all
Once you’ve decided where to focus your attention, someone has to buy in to what you’re offering. In business, return on investment (ROI) drives those kinds of decisions, and the same goes for government. But ROI is so much more than money. In government (and often in business), financial ROI is secondary to political ROI. What do I mean by political ROI? Just that the cost-benefit ratio measures risks and rewards in political terms: how does any given action fit with the current elected policy? What are the ramifications for re-election? Negative media coverage? Public perception? How does it benefit the government, the department, a politician or senior executive? Does it make the job easier? What’s the worst-case scenario?

In the end, you may have a brilliant proposal with significant financial benefits that gets torpedoed because of politics. Selling your services requires you to position yourself as a political solution first—your services need to acknowledge the party line and make bureaucrats, politicians, internal teams and departments look good.

Beware the Ides of November
Even when you’ve covered your political bases, in an election year, all bets are off. This is true at any level of government, not just in presidential elections. A new administration can (and will) extinguish initiatives started by the ousted party. And even in the case of re-election, the focus isn’t on your precious UX proposal—it’s on the election aftermath. Budget announcements, major policy initiatives, departmental shuffles and other shifts in government will interrupt projects, too.

The bottom line is that you need to be patient during upheaval, and even more than being patient, you need to understand the culture of the departments you’re approaching.

On safari in deepest, darkest bureaucracy: Understanding government culture is crucial for ongoing engagement.

Learn the language
Like any foreign land, government has its own language. When traveling abroad abroad, knowing the local lingo—even a bit—goes a long way in building relationships. Without some advance effort on your part, departmental acronyms, official program names, building locations, internal traditions and initiatives can create a maze of jargon that keeps you from making the connections you need to sell your services.

Alongside this idiosyncratic vocabulary that defines your clients’ “national borders,” there is an additional set of buzzwords that can be aligned with UX goals and objectives. The language of eGovernment is full of things like “citizen-centric,” “G2C” (government to citizen), “C2G” (citizen to government), “service-centric,” etc. The actual selection “eGov” buzzwords will vary, but knowing what they mean can let you frame UX issues in terms that mesh well with existing eGovernment projects.

Know the people—top down and bottom up
While you’re learning the language, get to know the people. Consulting relationships are largely about people relationships—assuming you do good work, the difference between business success and failure is often who you know. In government there are two kinds of people who you’ll get to know: “top down” people are the people in charge. While this includes elected politicians, senior civil servants endure between elections and have more to do with strategic policy than many “backbench” politicians.

“Bottom up” people are people in the trenches actually doing the work—the internal web teams, the middle managers. If you can start talking right away with senior people, that’s great; but the grassroots civil servants will sink or float a project with their acceptance (or lack thereof). Use your personal network to make both kinds of contacts when you’re looking for government work. Even if the people you meet don’t have work for you immediately, you will learn more about government culture, establish longer-term relationships, and find leads on work in other departments.

Big picture, little picture
Even if you’re perfectly fluent in local jargon and know heaps of people, you still need to understand the political landscape. Two flavors of politics inform that landscape: the “big picture” of government initiatives and policy (particularly eGovernment or citizen-centric initiatives) and the “little picture” daily reality of how your client fits into those initiatives.

The “big picture” is usually public—take the time to get to know more than the sound bites from the 6 o’clock news by reading policy documents, studying up on current initiatives, and talking with your contacts to get the word on the street. Those same contacts can help you see the “little picture,” which is no less important. Understanding how your clients fit into the big picture—and where they’d like to fit into the big picture—goes a long way to in tailoring your offering.

Symbiosis is reality: Finding your niche means working with others
So you’ve learned the language, know the people and the landscape, understand the power of political ROI… now what?

While there may be small projects you can tackle on your own, many of the contracts considered in government are beyond the means of an independent or small consulting firm, particularly since the contracts are often package deals (there is the expectation that you will scope the project, create the spec and design, and then build it, maintain it and support it).

Think about working with existing development teams—this routes around the limitations of a smaller shop. This approach can take the form of supporting in-house efforts or working alongside a larger contractor (right now I’m working with an in-house government team; over the summer I did the UI design for a $1.2 million government extranet application that a large contractor is building). Since you can’t compete with larger firms, cooperate with them or change the field on which you compete by doing things they don’t do.

Go get ’em, Tiger 😉
That’s all there is to it. Well, not really. There’s more to consulting with government than this article can cover. But if you appreciate the differences, build connections and cultural understanding and pursue good partnerships, things are off to a good start. Drop me a line and let me know how it goes. Maybe we can go out for a drink.

For more information:

  • California eGovernment Plan
    http://www.ss.ca.gov/executive/bj_tech_plan.htm
    Most governments have a similar public policy document that you can find on their website. It’s required reading before any pitch.
  • Six Ways eGovernment Can Alienate Citizens
    http://infocentre.frontend.com/servlet/Infocentre?access=no&page=article&rows=5&id=265
    Sometimes good ideas get taken too far—in usability testing with over 40 participants, the life events model didn’t scale well to meet a wide variety of information needs.
  • Building Better eGovernment: Tools for Transformation
    http://www.nga.org/center/egovernment/
    Knowing current trends in eGovernment means that you’re being customer-centric in developing your own practice—after all we should practice what we preach.
Jess McMullin is active in the online UX community. He is on the CHI-WEB moderation team, is a User Experience Architect and serves on the info-arch.org advisory board. In his spare time he’s a family man. His personal site is www.interactionary.com