Category: Professionalism

HTML Wireframes and Prototypes: All Gain and No Pain

by:   |  Posted on
“Using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time.”

Mention the use of HTML for wireframing or prototyping, and some information architects and interaction designers frantically look for the nearest exit. In some circles, HTML has acquired the reputation of being a time-consuming, difficult undertaking best left to developers. I’m here to convince you that this is very far from the truth. In fact, using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time. As a matter of fact, at Sliced Bread Design, Dreamweaver is the ONLY tool we use for our wireframes, and we love it. For those of you who may stop right now because you don’t know how to do HTML, let’s first discuss why you would want to use it. Then, read the HTML Wireframing Primer to find out how to do it yourself.

What people are using now
Henri Olson of guuui.com recently conducted a survey of 52 people to understand their use of web prototyping tools. He found that only 28.3 percent of interaction designers surveyed use HTML tools such as Dreamweaver or FrontPage for prototyping. The rest use visual and diagramming tools such as Visio, Illustrator, PowerPoint, or paper. While I am happily surprised by the quarter of designers using HTML tools, I am still left wondering why more people don’t take advantage of the benefits of HTML. In fact, the survey found that over 67 percent of HTML prototypers agree with the sentence: “I’m perfectly happy with the prototyping tool I’m using.” And, in a question that measures how well their current prototyping tool lives up to their functionality requirements, prototypers agreed that HTML tools came out with the highest overall score. This compares to only 8 percent of diagramming tool (i.e. Visio) users and 50 percent of graphic design tool (i.e. Illustrator, Photoshop) users who are perfectly happy with their tool. So the question is, if HTML is so great for design, why aren’t more people using it?

Definitions
There are many different definitions of wireframes, prototypes, and visual design, so let’s start by defining how these terms will be used in this article. A wireframe is a grayscale block diagram that illustrates the overall navigation and the blocks of elements such as content, functionality, etc. that will go on the screen. It does not contain pictures and doesn’t necessarily need to link to anything. It just demonstrates what elements a web page or application screen will contain and roughly where they might go—although the location can change. It does not include visual design. An HTML wireframe is created in HTML using a program such as Dreamweaver. A flat wireframe is created using a program such as Visio, Illustrator, or Photoshop and does not have interactive components, but is a flat image of the elements on the screen.

What I call an interactive HTML prototype goes a step further by linking navigation on an HTML wireframe to other wireframes representing subsequent screens, filling in content as needed, and adding mock functionality such as drop-down menus and fields that don’t tie into any backend. Note that this sort of prototype is somewhere between high- and low-fidelity as defined by Chris Farnum in his recent Boxes and Arrows article. This prototype does not represent any visual design other than simple layout. It does not require enlisting the help of a developer because the interaction designer does all of the work in a program such as Dreamweaver.

The screen shot below shows one page of this sort of prototype. Notice that it shows that the design will have primary navigation with four categories (Dashboard, Database Setup, etc…), secondary navigation that integrates the steps of a wizard with navigation (an idea we were testing), a form to fill out in the middle that a user can try out, and navigation at the bottom that might be buttons or links when the design is complete.

By linking together multiple pages of HTML wireframes for a site or an application, you can quickly end up with a prototype to user test or show the client. For the purposes of this article, when I use the term “wireframe,” I am referring to an HTML wireframe and will use the term “flat wireframe” to refer specifically to wireframes not in HTML.

Why avoid HTML?
I’ve heard many reasons why designers don’t want to use HTML for wireframing and prototyping. The most common reason they are reluctant to use HTML is because they are already comfortable with tools such as Illustrator and Visio. I’ve heard people say, “Making HTML really work is difficult” or “I don’t know JavaScript.” To combat these concerns about ease of use, the accompanying HTML Prototyping Primer article teaches you how to create quick, functional, flexible wireframes without any real programming by using Dreamweaver. But the flexibility and functionality of Dreamweaver is not the main reason to switch to HTML. Let’s go on a short tour of the benefits of HTML wireframing and prototyping that will convince you to make the switch.

Increased user testing
The most important interaction design benefit of HTML is the way it lends itself to ongoing user testing. Because of their interactivity, HTML wireframes are regularly used to user test design ideas on the fly with people in the office, friends, or anyone who happens to stop by. When there is no one around to show, we post designs to the web and instant message a friend to try them out – we always get some quick, useful feedback. For example, Sliced Bread Design recently worked with a company called Elevon on a new version of their enterprise budgeting software. From the beginning, the client had many different ideas for the flow of the set-up wizard. Some parts of the set up had to be done in a specific order, while other tasks could be done at the user’s convenience. We approached these different aspects of the functionality by creating a list of tasks involved in the set up, and disabling the tasks that could not yet be started (see Figure 2 below). Then, we quickly user tested the wireframe with people in the office to see if they understood the interaction idea. After validating the base design, it was ready to show to the client.

When everyone is satisfied with a wireframe, like the one above, we can then link all the screens together into a wireframe prototype and conduct more formal usability testing without having to do additional set up work. Of course, for formal usability testing we still have to create a script for the tasks that we need to test. Your prototype might need more or less modification to fully cover those areas you need to test. However, we’ve found that our wireframe prototypes convert to user test material with minimal effort because the framework for every page is already in place and is very flexible. Above all, our reliance on HTML wireframing lets us promise all of our clients that the final design will ALWAYS be user tested, even if only via guerrilla user testing – especially important if the budget is tight.

Creating visible client value from the start
Another big benefit of HTML is visible value for the client at the beginning of the project. Some of our clients are confused about the difference between interaction and visual design. By focusing on creating something interactive at the beginning of the project in the form of an HTML wireframe, we can demonstrate that the focus of our work will be on how people use the product as opposed to how it looks. And, as we are busy showing off our knowledge of interactivity, we are also demonstrating our awareness of technical constraints. Even if your wireframe is based on the simplest HTML out there (ours always are) and only takes 10 minutes to create, the fact that you have ventured out of the realm of graphics software demonstrates your concern with creating something that is implementable, not just a blue-sky concept.

Improved client communication
When it’s time to show the work to the client and demonstrate its value, the next benefit of HTML becomes improved client communication. Sometimes it may be difficult for a client to understand the brilliance of the user experience that is being proposed because they cannot experience it for themselves. Miscommunication can result from misunderstood verbal descriptions of how users will interact with a flat prototype. We experienced this on a project where client team members were located on multiple continents and had varying English skills. By demonstrating the functionality instead of describing it, we were able to greatly reduce miscommunication that initially resulted from teleconferences and documents in rough English. Furthermore, team members in different time zones could review designs that we posted on their own time without additional explanation. By allowing our client to experience the interaction, we knew that they understood exactly what we were talking about and had agreed with the direction we were heading early on in the process.

Communication through demonstration is especially important when the project does not have a pre-defined functional specification, i.e., a definitive list of the functionality and/or content areas that the product must have. For example, on the Elevon project, we were hired at the beginning of the project to help replace old desktop client server software with a shiny new web application. At this stage, there was no specification, so our work played an integral part in helping define the product’s functionality. By creating interactive wireframes that represented the functionality under discussion, we were able to quickly reach agreement on what worked best for the end users. Furthermore, everyone could click through the wireframe prototype to make sure that all the pieces were in there, and any functionality that had been casually discussed wasn’t getting lost. The Elevon team also used the prototype to reach internal consensus and demonstrate the project’s progress to management.

Disqualifying poor ideas
Another client communication benefit becomes apparent when your client suggests some interaction scheme that they are sure will work, and you are sure won’t. If a gentle suggestion to steer the client in the other direction doesn’t work, we’ve found that creating an HTML wireframe to demonstrate the problems of the proposed interaction is much more convincing than further discussion. Often experiencing an idea is very different from describing it. And, since the idea is now prototyped, it can easily be user tested if you need more ammunition to disqualify it.

Simplified implementation
If I haven’t yet convinced you of the benefits of HTML prototyping, perhaps this point will: return on investment (ROI). These days, everyone is chatting about the hot topic of ROI. By emphasizing your use of HTML to the client, you can also make legitimate claims about decreased development costs through more consistent implementation and quicker specification. We use our HTML prototypes directly in our specification to communicate to developers exactly how the final product needs to work. More complex functionality, not in the prototype, is explained via bullet points under the screen itself. Although the prototype lacks the final graphic design, it demonstrates the functionality and the flow, leaving little room for developer confusion, which in turn saves time during the development cycle. Furthermore, your client saves money because your time isn’t spent explaining every detail in a text heavy specification.

Upsell to marketing
And finally, the last client benefit is actually a potential follow-up project for you. Since you saved the client money in specification, you can now spend it by selling them a robust version of the prototype. Well-crafted HTML prototypes can easily be turned into marketing prototypes once the visual design is complete. Many projects that we’ve worked on take a long time to implement, but inevitably the marketing team always needs something to show next month at the big conference. Voila! With an existing prototype, it is easy to apply the final visuals for your client to show their customers before the final project is complete. Everybody wins.

HTML is for more than just the Web
Hopefully, now that I’ve sold you on HTML prototyping, the important thing to note is that HTML wireframing and prototyping is for more than just web projects. In the past, we have used HTML prototyping for both desktop and cell phone applications. For example, through the use of screen shots and some carefully placed web layers, we were able to create an interactive prototype of a Windows file management system. On another project, we prototyped in WAP (roughly HTML for cell phones) using a Dreamweaver plug-in. By creating a mobile phone interface to user test, we were able to capture interaction problems before we presented the ideas to the client. Once you get hooked on HTML wireframing and prototyping, you really can’t go back.

OK, I’m ready. What do I do next?
Read the HTML Prototyping Primer for concrete instructions that will make you more comfortable with Dreamweaver. Although it might be hard to abandon what you are used to and get turned on to HTML, hopefully, I have emphasized that in today’s tight economy, the benefits are well worth it.

  • Results from a survey of web prototyping tools usage
  • What an IA Should Know About Prototypes for User Testing by Chris Farnum
  • Definitions used in this article:
    Wireframe: a grayscale block diagram that illustrates the overall navigation and blocks of elements
    HTML wireframe: wireframe created in HTML using a program such as Dreamweaver
    Flat wireframe: wireframe created in graphics program such as Illustrator, diagramming programs such as Visio, or on paper
    HTML prototype: HTML wireframes with actual content and interaction components filled in that are linked together to form a rough interaction

Julie Stanford has been a practicing experience designer since 1996 and is a partner at Sliced Bread Design, an interaction design and usability agency. Through her work at Sliced Bread, Julie has specialized in designing complex online, wireless, and voice applications for clients such as Elevon, Tellme, Agilent, and Casio.

Leading from Within

by:   |  Posted on

About this time last year, I was a student in a sort of impromptu seven-week “master class” on user-centered design, taught by Marc Rettig. When I heard about the class I jumped at the opportunity to be involved, not only because Marc was the instructor, but because it was a chance to be immersed in a totally positive and constructive design environment, one removed from corporate politics, strained budgets, and misplaced egotism. It was a chance to talk about, learn about and practice user-centered design techniques in a room with sympathetic colleagues—people who didn’t view me as the “usability police.” It was a chance to learn better how to understand users, without having to convince people that understanding users was a good thing to do in the first place.

The class was fast-paced, and although we covered a lot of ground in a short time, I loved every minute of it. But for every moment of the class where I felt totally in my element—challenged creatively, intellectually, working through problems I had a passionate interest in solving—I felt a twinge of disappointment that I wouldn’t be able to practice the same methods back in the “real world,” in my job as an information architect. I knew that, as much value as these user-centered approaches could add to the work we did for our clients, there just wasn’t room for them in the project budgets, or the processes, or even in the company’s overall culture at the time. I believe many of my classmates shared this frustration at the contrast between the “ideal” process scenarios we talked about in class and the reality of what we’d be able to incorporate into our jobs. At the end of the last class, someone said out loud what many of us had been thinking. “This is all great, we believe in the value of it, and we’re dying to go out there and do it. But, realistically, how can we possibly get our teams to work like this?” Marc responded, very simply: “By virtue of the job you’re doing, and the work you’re doing, you are all leaders in your organizations; you’ll create the opportunity to work this way.”

Since the final class session a year ago, that sentiment has remained with me and has materialized into a truth I’ve come to accept and embrace: Being an IA, at this point in time, also means being a leader—ready or not, like it or not. Information architecture is still a nascent field, and as a result we often encounter uncertainty in our organizations and with our clients (sometimes even within our own profession) about the role we play on a design team. Only as leaders, who are able to skillfully educate, guide, and influence those around us, will we be able to succeed as practitioners at the forefront of this emerging field.

While there are practicing IAs fortunate enough to work in companies that wholeheartedly embrace user-centered design (and an IA’s critical role within that process), there are many more IAs whose biggest challenge on a daily basis isn’t the work itself; it’s finding the opportunity to do the work, at the right time, in a meaningful way.

To create opportunities to practice fully as information architects, and in turn, contribute fully as a member of the larger team, not only do we have to become experts in the stuff of our profession—site architecture, user scenarios, prototyping, conceptual models, etc.—but we have to become skilled in things like change management, process engineering, negotiation, persuasion, team building, and organizational politics. And, in most cases, we have to exercise these skills from a position that is not, by default, one of authority in the company, possibly not even one of authority on our respective teams.

Because many of us don’t have the opportunity to influence change from the top down, we have to be resourceful and find ways to effect change from within. In other words, if we are committed to creating an environment where we are fully utilized, one that enables everyone on the team to do their best work for our clients and their customers, we have to take the initiative and lead from within.

What does it mean to lead from within? J. Donald Walters, author of “The Art of Leadership,” envisions a good leader as “an artist whose medium is the dynamics of human cooperation.” He believes leadership is a role that is people-oriented, not position-oriented, and as such is guided by principles that can be applied to any situation that involves working with and influencing others. He offers “principles for leaders to live by,” many of which are relevant and helpful to an IA (or anyone) interested in making change in their organization. Some of these include:

  • Persuade people with the power of your conviction. Involve others in your vision, and inspire them to also be visionaries.
  • Be a good listener, and be willing to listen to other points of view, even if at first they seem to conflict with your own.
  • Focus on the job to be done, more than your own role in the task, however critical your role may be to that task; always keep the big picture in mind.
  • Be willing to take risks yourself, instead of waiting for other people to take them. With this comes the obligation to take responsibility for failure, as well as success.
  • View your role as a service to others—clients, employers and coworkers; there is strength in humility.
  • Work with people as they are, not as you would like them to be. Realize that it takes time to bring people to new points of view; be patient.
  • Adapt your actions to reality (what can be) rather than theory alone (what you think ought to be); be flexible in your ideas of perfection.

While some people believe leaders are born, it’s more accurate to say that leadership is a set of learned skills and sensitivities, born out of a strong commitment to and passion for an idea. If you’ve accepted the challenge of creating change in your organization, there are a few ways to get started on the path to becoming a strong, successful leader.

  • Become an expert in your field. Immerse yourself in the subject matter—read everything you can, attend professional conferences, participate in discussions with colleagues. While passionate commitment is the cornerstone of good leadership, knowledge is a leader’s greatest resource.
  • Identify people in your life you consider to be good leaders, people who have been successful in motivating others to share their vision. If you can, observe how they work, and how they influence people around them. Take note of how they handle mistakes, and failures, and successes. When you encounter obstacles you can’t overcome in your own efforts, consider asking them to act as your mentor, to share their expertise and help you through the rough spots; chances are they won’t say no—good leaders know everyone benefits when they teach others what they’ve learned.

    If you’re unable to identify people in your personal or professional life you consider to be good leaders, you can turn to history for examples. Biographies of great leaders can be a rich source of guidance and inspiration.

  • Look for opportunities to take on active leadership roles, personal or professional. Start a special interest group, or volunteer to lead an initiative in an existing group. Non-profit organizations are a great learning ground for things like taking risks, accepting accountability, facilitating teamwork, and overcoming obstacles creatively—all skills that are critical to becoming a good leader.

One of the things I remember most about that class last Fall was the weekly update from a pair of intrepid classmates who combined what they were learning in class with an enthusiastic desire to change the way their company approached design. Motivated by a commitment to their customers, and supported by our instructor’s advice and encouragement, these two coworkers took each week’s lesson back to their jobs and applied the approach to a product under development (and then they came back to class and shared all the juicy details with us!). Even though they had setbacks and encountered resistance, it was encouraging to hear that—even in that short seven-week span—they made progress in the incorporation of users in their company’s design approach.

Making change can be an incredibly rewarding experience; it can also be an excruciating process, and along the way you may question whether it’s worth the stress and frustration you experience, or if you even have a chance of succeeding. Be confident that if you believe in yourself and your vision, follow your instincts, arm yourself with knowledge, and gravitate toward people who support you, you will be successful as a leader, and you’ll inspire others to follow along.

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