Tackling Maintenance Projects

“Maintenance projects are distinguished by their (relative) brevity: for a majority of them, the design period will be two weeks or less, and very often only a day or two.”Most of what one reads about information architecture and interaction design work assumes several things: that you are creating the project from scratch, that you have the ability to alter anything on the screen, and that the project is free of technical or political constraints. None of these assumptions are true when you are dealing with maintenance projects.

Defining maintenance projects
Very soon after the first website went up, the first maintenance project began.

By maintenance project, I’m referring to altering an existing website or application, one that you likely had nothing to do with creating that comes loaded with technical and organizational baggage. It can be as small as adding a link to a page, or as large as restructuring the entire site. For in-house IAs like myself, these can make up the majority of work of you do. But more and more, consultants (since the collapse of the New Economy and the dearth of new web projects) are being asked to deal with them as well.

Most maintenance projects involve one of the following:

• Adding functionality or content.
• Removing functionality or content.
• Revising architecture — moving content, pages, or whole sections to a different location.
• Changing interaction — altering the way an existing piece of functionality works.

Maintenance projects are distinguished by their (relative) brevity: for a majority of them (excepting major restructuring work), the design period will be two weeks or less, and very often only a day or two. They generally require a quick assessment of the situation and decisive judgment, not to mention immediate action: rapid prototyping, wireframes, and site maps. Few maintenance projects will allow the luxury of a full exploration and design process.

A typical maintenance project goes something like this: someone has a new piece of functionality or content they want to put up on the website. The IA’s job: find the best place for it, both in the site overall and on the specific page chosen.

Server logs or a usability test (or common sense) can trigger a maintenance project by revealing that a site or an application has been structured wrong, and users aren’t able to complete their tasks (finding information, buying things, etc.). The IA’s job: fix it.

Two types of maintenance projects
There are two types of maintenance projects that I’ve taken to whimsically calling “Atomic” and “Neutron.” Each has pitfalls and challenges. I’ll discuss the rarer of the two first: Atomic.

Atomic Maintenance Projects (AMPs) are those projects that allow you to completely change how the page, section, site, or application works. AMPs usually occur when a business requirement causes you to rethink the whole “environment” around the requested change. Like an atomic blast, it can destroy things on all three tiers of development — front end, middleware, and databases. AMPs are actually regular projects in the guise of maintenance, and if you are lucky enough to convince your team to tackle one, you will likely be able to do a fuller design process than you would have otherwise.

“Often, IAs are left to wrestle with decisions that were made long before their involvement with the project; decisions that people in the company may not even like but are stuck with.”For example, let’s say an existing online form needs to capture some new sort of data (e.g., a phone number). Typically, this might just involve adding another form field. But, on examining the page where the form resides, you discover that the whole thing should be reworked: the format is too confusing, the required fields aren’t indicated, and just adding a field would make the visual design even more cramped.

This type of discovery, I should add, is not rare. I guarantee you’ll come across all sorts of things that need to be improved when you take a critical look at many web pages. What is rare is being able to convince your clients and the rest of the team that more redesign needs to be done than just adding in a form field, as everyone expected.

This, in project management terms, is called “scope creep,” and now you are the advocate of it. Sometimes this is welcomed, because a small change can reveal how poorly something is built, or show possibilities no one has thought of. But be prepared for pushback! If time is of the essence (and when is it not?), the rest of the team will want you to just pipe down and make the less-drastic change they were expecting. In other words, they will want you to make the project Neutron.

If Atomic Maintenance Projects level everything and start from scratch, Neutron Maintenance Projects (NMPs) leave the “buildings” (a.k.a. the three development tiers) mostly intact. These are much more common, because, as we’ve seen, even projects that should be Atomic aren’t because of the difficulty in convincing people that they need a more thorough treatment. Instead, the IA is left with making the best choice possible given the existing conditions.

And there’s the rub. Often, IAs are left to wrestle with decisions that were made long before their involvement with the project; decisions that people in the company may not even like but are stuck with. Or decisions they have a vested stake in keeping intact. Or decisions various forces in the company (IT, Marketing, and Legal being typical stakeholders) insist must remain, for reasons the IA may or may not agree with.

To illustrate, let’s look at the online form example. The new requirement is to collect a phone number from the user. Since the phone number could be international, you decide to create one long text field. Simple, right? Yes, until the database manager tells you that there are already two fields in the database: one for international phone numbers and one for U.S. phone numbers — and she’s not about to change the whole database structure to combine them. The Java developer doesn’t have time to write a script to send U.S. numbers to one field, and international to another. And the graphic designer mentions that by adding two separate fields, it will knock the page “below the fold,” and that’s against company policy. Oy.

It’s often frustrating to deal with NMPs, especially when you know they should really be AMPs. But there are ways to cope.

Maintaining your sanity during maintenance projects
Hardly anyone likes to do maintenance projects. They are seemingly unglamorous, janitorial chores to be dealt with in-between the bigger and better projects. And while I am not going to argue otherwise, I can provide some hard-won hints that might make them easier the next time you’re handed one.

Think inside the box. The first thing you need to do is review the requirements and figure out the best place at a high level for the change you are being asked to make. Many requirements are pretty specific about this (“We need to capture the phone number on the registration form”), others much less so (“We need to put the bios of our board members on the site”). If you have a map of the site or application, it will be handy. If not, sketch one, briefly. Find (or create) a logical space for the change.

Know the page (Part I). Once you’ve found a place for the change (if it is an existing page or screen), examine the page closely, click links, push buttons. This may seem basic, but pieces of functionality and content don’t often work the way you think they will (or the way they should). Recently, on a Neutron project, I blithely assumed that underlined items were links to related pages of “help” content. Not so: they revealed a hidden DHTML layer with a brief description of the item. You’ll often come across things that make you want to make the project Atomic during this investigation.

Know the page (Part II). If you have any technical savvy at all (and you should), find out about how the environment was constructed. Is it part of a content management system? Is any of the content dynamic? What is the application built in, Flash? C++? Java? Look at the source code if you can. Talk to the developers, the people who built it. This will allow you to know what is possible given the technical constraints, as well as alert you to any hidden problems before you start your wireframes.

Beware of hidden traps. Often, there are secret conditions and corporate political issues that you may be unaware of. These, of course, won’t be written down anywhere. Your clients just know them. The best way for you to know them as well is to cultivate a friendship with the people who know this information: the members of the development team, and especially the project manager. She can tell you that the CEO hates the word “corporate” or that Marketing is opposed to underlining links.

Pick your battles. When you do discover serious problems with a page, pause before sounding the cry to get it changed. Most importantly, consider how much impact there will be for the user and weigh it against the battle you will have to wage to get it fixed. If it will substantially make the user’s experience better and only requires you send a nice email to the Visual Basic programmer, then, by all means, proceed. If it will make a slight difference, but requires you to argue your case to the President and CEO for the next month, maybe it isn’t worth it. Here, consultants have the edge over in-house IAs. “Innies” have to measure their own reservoir of corporate goodwill, built up on the projects that have gone before and estimate how much they’ll need for projects coming in the future. “Outties” have less to lose, other than annoying those people who have hired them in the first place (and could get them more work in the future).

Down ‘n’ dirty wireframes. Unless you’ve managed to talk your way into an Atomic Maintenance Project or are creating a new page or screen, it rarely makes sense to reconstruct an existing page as a wireframe. You’ll waste a lot of time doing that, because typically you are only affecting one area of the screen. Instead, take a screenshot of the existing page, move it to Photoshop or Illustrator and make the changes in the image. Then export it as an image into your wireframe template where you can layer your annotations on top of it. These “wireframes” will be easier for the developers to understand, too.

Be considerate of visual design. On new projects, IAs often have the luxury of doing their work prior to visual design. But on maintenance projects, specifically NMPs, you are often adding things to existing pages, so even more care than usual needs to be paid to the visual design. One large, ugly button, ill-placed, can ruin a look and feel that might have taken weeks to get right and get approved. It may go against what usability gurus have traditionally been screaming at us, but I contend that an ugly solution that is functionally correct is worse than a handsome one with less-than-ideal functionality.

While handling maintenance projects are few people’s idea of a dream job, they can help sharpen your IA skills. They make you more aware of what happens in development after your designs are approved. They demonstrate how sites evolve over time, and can help you better design things that account for that reality. They make you aware of the business and technical forces that ultimately affect the design. And, best of all, they make you appreciate non-maintenance projects more.

Dan Saffer is a senior interaction designer at Ameritrade. Over the last seven years of web work, he has worked with a diverse set of clients, from Lucent Technologies to the World Wrestling Federation. He is contractually obligated to say that he won a fellowship in 1998 from the Mid-Atlantic Arts Council. He lives and works in New Jersey and is not writing a book about IA.

His portfolio and blog can be found at www.odannyboy.com.