While both agile and UX methods share some best practices—like iteration and defining requirements based on stories about users—agile and UX methods evolved for different purposes, supporting different values. Agile methods were developed without consideration for UX best practices. Early agile pioneers were working on in-house IT projects (custom software) or enterprise software ^{[1, 2]}.

The economics are different in selling consumer products than when developing software for enterprises—UX matters more for consumer products. Jeff Bezos cares if users know how to click the button that puts money in his pocket more than Larry Ellison cares about any button in Oracle software. Larry makes money even if people can’t use his software. Oracle sells support contracts and professional services to fix things customers don’t like. Amazon and other online businesses can’t operate like that. They have to get the UX right, or they go out of business fast. User experience factors rarely get the same level of consideration when the end-user is not the same person as the paying customer ^[3].

Agile teams and UX problems

I’ve encountered two problems common among agile teams when helping them improve the user experience of their products or services:

1. UX work is frequently overlooked during the release and sprint planning efforts.
2. Teams often fail to measure the UX impact of their iterative efforts.

These two problems become more serious when combined.

When UX work goes undone and the impact is not measured, the team doing the work has no idea what is going on. The feedback loop is broken. Both agile and UX methods emphasize iteration, but productive iteration requires good feedback loops.

You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user. The User Experience Integration Matrix (UXI Matrix) addresses these problems by tying UX to the project backlog.

Integrating UX into the product backlog

Scrum (one of the most popular variants of agile) advocates you create a Product Backlog, a collection of stories that describe user needs. The team iteratively refines the requirements, from rough (and often ill defined) to more specific. This is achieved using stories from a user’s perspective, which have conditions of satisfaction associated with them. This concept is adapted from UCD’s scenario based design methods. In my view, this is far better than other traditional approaches to documenting requirements that are often detached from user’s goals.

Various agile gurus ^{[4, 5]} discuss how to break down requirements from high-level stories to user needs targeted at specific users. Even if your team follows Jeff Patton’s story mapping method ^[6], (which I highly recommend) to create structured hierarchical representations, you’ll often find you want to analyze the stories by different factors as you groom your backlog.

I’ve worked with teams who want to analyze stories the following ways:

1. Order of dependency or workflow (self-service password reset depends on user registration)
2. Criticality (which of these stories must be done so customers pay us next month)
3. How much work will they take to complete (show me all the epics)
4. What related stories do I have (find requirements with related UI patterns)
5. By role or persona (show me all the stories that impact persona X)
6. What stories have a high impact on the UX, so we can focus on those?

If the project is small (both in number of team members and number of stories) you might be able to get away with rearranging story cards on the wall. However, in my experience, things inevitably get more complex. You often want to consider multiple factors when reviewing the backlog. A UXI Matrix helps you track and view these multiple factors.

Creating a UX Integration Matrix

The UXI Matrix is a simple, flexible, tool that extends the concept of the product backlog to include UX factors normally not tracked by agile teams. To create a UX Integration Matrix, you add several UX-related data points to your user stories:

With these columns added, your product backlog begins to look something like the spreadsheet in figure 1.



Figure 1: UX Integration Matrix, a simplified example

Advantages to using the UXI Matrix

The UXI Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process.

Groom the backlog

During release and sprint planning you can sort, group, and filter user stories in Excel:

• Group by themes or epics, or anything you want to add via new columns
• A primary persona, a set of personas, or number of personas associated (more = higher)
• Stories you’ve verified via user research or ones you need to verify
• Stories you’ve completed but need to refine based on metrics
• Export stories into a format that can be used in information architecture work
• Explore related UX deliverables like personas, mockups, and research findings via hyperlinks to them

Note the summary rows near the bottom of the example in Figure 1. Those values can help you prioritize new and existing stories based on various UX factors.

Reduce design overhead

Perhaps my experience is unusual, but even when I’ve worked on teams as small as seven people, we still had trouble identifying redundant user stories or personas. My heuristic is that if a story shares several personas with another story in a multi-user system, then that story may be a duplicate. Grouping by themes can also help here.

Another useful heuristic is that if a persona shares a large list of user stories with another persona, it’s likely the personas should be merged. Most of the time personas that do the exact same things with a product can use the same design, unless of course they have very different skills or something, which becomes evident when reviewing the personas or conducting user research (which all good personas are based on in my view).

Facilitate collaboration

Another major benefit of the UXI Matrix format is you can share it with remote team members.

Listing assigned staff provides visibility into who’s doing what (see the columns under the heading Staffing). Team members can figure out who’s working on related stories and check on what’s complete, especially if you create a hyperlink to the design or research materials right there in the matrix.

For example, if there’s a Y in the Design Complete column, you can click the hyperlink on Y to review the design mockup. I’ve worked with teams who like to track review states here: work in progress (WIP), draft (D), reviewed ( R ), etc. (instead of just Y or N).

Track user involvement and other UX metrics

The UX Integration Matrix also helps track and share key UX metrics. One key metric to track is team contact with real end users. For example, if you’ve talked to real users to validate a persona, how many did you speak with? Another good metric is, how many users have been involved in testing the design (via usability tests, A/B tests, or otherwise)?

You can also capture objective, quantitative UX metrics like task completion rates, click/conversion rates, and satisfaction rates by persona. It makes it easier to convince the team to revisit previous designs when metrics show users cannot use a proposed design, or are unsatisfied with the current product or service. It can also be useful to track satisfaction by user story (or story specific stats from multivariate testing) in a column right next to the story.

Review UX metrics during sprint retrospectives

Scrum-style reviews and retrospectives are critical to improving both the design and team performance. However, few teams consider UX metrics as part of the retrospective. During these meetings, it’s helpful to have UX metrics next to the stories you are reviewing with the team.

I ask the team to answer these UX-related questions during the retrospective:

1. Did we meet our UX goals for the sprint?
   1. Does our user research show that what we built is useful and usable?
   2. Are users satisfied with the new functionality (new stories)?
   3. Are users likely to promote our product or service (overall) to others?
   4. Do we have product usage metrics (via site analytics) that meet our expectations?
2. Is there existing functionality (stories) that need to be refined before we add new stuff?
3. What user research should we do to prioritize stories going forward?
4. Do we have enough staff with UX skills to meet our objectives?
5. Going forward should we:
   1. Work a sprint ahead to ensure we validate UX assumptions?
   2. Do a spike to refine a critical part of the UX?
   3. Refocus UX work on select user stories or personas?
   4. Improve our feedback mechanisms to capture factors we are missing today?

Figure 2: The UX Integration Matrix inserts key user experience activities and context adjacent to user stories into the product backlog.

Improving your team’s design decisions

Once you start tracking in the UX Integration Matrix it becomes easier to have informed discussions during reviews and retrospectives. I use the UXI Matrix to set UX goals with the team, help prioritize stories in the backlog, track UX work in progress, and to help answer the classic agile problem “what does done mean”; not just for the entire product or service, but for individual stories.

I’d be curious to hear from others who would like to share their experiences with variations of the above or similar methods. On the other hand, if you’re an agile guy that thinks this all is very non-agile, I’ll ask “can you really prove your method creates a better UX without this stuff?”

Start using the UXI Matrix in your next sprint. Download and customize this Excel template to get started:

• UX Integration Matrix template (33kb Microsoft Excel .xls file)

[1] Larman, Craig. Agile and Iterative Development: A Manager’s Guide. Pearson Education, 2004.

[2] Sutherland, Jeff. “Agile Development: Lessons learned from the first scrum”. Cutter Agile Project Management Advisory Service, Executive Update, Vol. 5, No. 20, 2004: http://www.scrumalliance.org/resources/35.

[3] Cagan, Martin. Inspired: How To Create Products Customers Love. SVPG Press, 2010.

[4] Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 2004.

[5] Cockburn, Alistair. Agile Software Development. Addison-Wesley Professional, 2001.

[6] Patton, Jeff; “It’s All In How You Slice It”, Better Software, January 2005: http://www.agileproductdesign.com/writing/how_you_slice_it.pdf.

This case study shows how the ComputerWeekly user experience team integrated with an agile development group. It’s important to note the methods we used do not guarantee getting the job done. People make or break any project. Finding and retaining good people is the most important ingredient for success.

The brief

In 2008, we were tasked with resurrecting a tired, old, and ineffective site. It was badly out of date, and the information architecture was decrepit to both users and search engines.

Our goals were:

1. Make content visible and easy to find
2. Create an enjoyable and valuable user experience so users would return
3. Increase page impressions to bring in ad revenue
4. Allow site staff to present more rich media content
5. Give the site more personality and interactivity

The UX team created personas from ethnographic studies, online surveys, and in-depth interviews with users. The data gave us a clear idea of the user’s needs and wants. We also gleaned data from analytics that told us where users engaged and where the bounce rates were highest.

At this point the development team maintained the site with an agile process. They created features for the new site in parallel to ongoing site maintenance, but this work was outside the normal maintenance sprints. The new site was considered as an entirely new project with a separate budget and scheduled into longer term.

Boundary Spanner

As the User Experience team gathered data key team members were recruited. The diagram below shows the key team members needed to produce this large scale site, their specific concerns, and their methodologies.

To bring these teams and disparate elements together requires a launch manager or ‘boundary spanner’. Rizal Sebastian wrote about boundary spanners in Design Issues in 2005¹. The boundary spanner needs to be aware of the individual issues the project faces. He need not know the detail but needs to know the cultural context of the collaborative environment.

Do people get on with each other? Are communication lines clear? Are there any personality clashes on the team. To throw developers, interface designers, business analysts, SEO experts, and usability guys together and expect them all to gel is optimistic but unlikely. It also requires those people devote all their time to just one project and that is unrealistic for a large operation where several projects are underway simultaneously.

They are more than a project manager because the user— and not the project—is at the heart of their concerns. He is responsible for delivering and continually developing a quality product. He is not just monitoring the features on a checklist. The user is at the center of all decisions on the design and development of the site. This is the only way you can ensure the user will be heard throughout product development – to employ somebody who listens to user voices and never forgets what they said. They must also ensure that SEO and business requirements are satisfied, and a well-defined strategy is in place. The boundary spanner owns and clearly communicates the vision until the whole team understands.

The boundary spanner’s strength is that they are core to the product and not a department or team known for their skillset (like a UX team for example). In many cases it is a product manager, but in this case it was the website editor who was responsible for synchronizing the teams.

Defining a process

To assist this user focused approach, the IAs produced set of deliverables that ensured the launch manager’s vision could be realized and developed.

Diagramming the process using a concept model engaged key stakeholders with the project by communicating the vision of what the UX team would achieve with the speed and clarity of an elevator pitch.

Information gathering

A content audit revealed broken links, redundant content, and poor usability plagued the site. It also revealed how much content became lost the second it moved from the home page. The high value research papers were impossible to find.

30 interviews, 20 ethnographic studies, and 950 responses to an online survey. created six personas. With the content audit, personas, and business objectives (what we wanted them to do on our site), we began creating the taxonomy.

Analytics

During this project we were very fortunate to work alongside the web analytics manager who provided insight into user behavior, including high bounce rates from visitors arriving from search engines. He also provided a scorecard that showed where the site failed in terms of traffic and user engagement. We knew what users were searching for, and pretty quickly could tell why they were not finding content we knew we had.

By looking at web metrics we were understood usage patterns and popular and unpopular areas of the site. The depth of information enabled us to quickly formulate a plan.

Persona driven taxonomy

As we knew our user base were industry experts, we also knew their vocabulary was related to specific areas of their markets.

The taxonomy was created by gathering as many industry sources (websites, journals, white papers), breaking these down into unique elements, and clustering these elements together to form categories for our content.

The CW taxonomy formed the basis of the navigation, content categorization, and highlighted areas for future development. It also ensured our search results served up related content in context.

We defined four main areas by looking at the community of users.

News was an obvious requirement, defined by their particular area of interest within the sector. The need for knowledge was evident, and we created an in-depth research area where case studies and white papers could be easily accessed. Tools and services, RSS, email news alerts, and newsletters reflected user needs to be kept up to date and in tune with their specialization.

Finally, although the CW community was secretive and did not divulge information amongst their peers, they were very interested in expert opinions. This need gave rise to much more integrated blog postings.

Interface development

The navigation scheme defined the elements of the page the users would use to move to other areas in the site. It clarified the naming of those items on the page.

We then considered the prioritization of information and content for each page, and this facilitated the production of wireframes that represented the culmination of all research, showed the interface and interactions for elements on the page, and were a working document that changed as we iterated the design.

Core and Paths

We used Are Halland’s method for ‘designing findability inside out.’²

• Prioritize and design the core – Satisfy user goals using prioritized content and functionality.
• Design inward paths to the core – Consider how users will arrive at the page from search engine results, facets, menus, search, RSS, aggregation, email, etc.
• Offer relevant outward paths from the core – Ensure that the site delivers both user and business goals through clear calls to action and completion of interaction tasks.

For CW.com, we focused on the cores for the home page, a channel level homepage, and a news article page and looked at key content such as lead news story and the editor’s picks or the best from the web aggregated from external sources. The key functionality and supporting content also had to be included and prioritized on the page.

Next we considered the inward paths, which are the channels that our users are likely to utilize to arrive at the page.

Inward paths included search engines, blogs, bookmarks, syndication, aggregators, RSS, and email subscriptions. Considering inward paths helped us focus on the marketing channels we needed to drive users to the relevant type of page. It also focused on the keywords and themes that users are likely to use and helped us optimize pages for search and online marketing campaigns.

Finally we designed the outward paths that helped users complete online tasks for our business objectives.

These outward paths include:

• Newsletter sign-up
• Inline links to related articles to drive page consumption
• Sharing, printing or emailing of news articles
• Related content types such as video or audio
• Stimulating community participation in forums or blogs
• Contextual navigation to aggregated content or the editors best bets
• Subscription to an RSS feed
• Prioritizing the content



Once the wireframes had been approved, the content was organized so the most commercially valuable and user focused content was pushed to the top of the page. As the design went through user testing, certain elements changed, as with any iterative process, but through team collaboration, the solution remained true to the initial vision from concept to design delivery.

The development cycle

The wireframes were handed over to creative, and they began designing the interface and graphic elements. The development group released some functional elements to the old website before the relaunch.

These agile methods allowed the old site to feel the benefits of the new widgets. However, as the site changed so radically in the new design, we still had to release the site in an old style ‘big-bang’ manner. This is perhaps where agile has its problems as a methodology for new launches. It’s focus on many small releases is a great tool to implement incremental changes but not for a completely new site.

As the html flat pages were passed to the team, the SEO requirements were defined and built into the site. By the time the site launched it, had been through four major pieces of testing.

A holistic solution

Providing user experience deliverables like the concept map and wireframes ensured more comprehensive requirements were delivered to the design and development team. This approach addressed marketing, editorial, sales, and business requirements next to the needs and wants of the user. The vision was aligned with an achievable delivery from the IT team that ensured we delivered the site we wanted to give the user.

The core IA work enabled the new site to be future-focused and versatile. The structure and design of good sites should be able to adapt to change.

User-centered design and agile can work alongside each other but what is more important is having people who can tie all the loose strands of a website design and development cycle together. The concept map, wireframes and the IA strategy document that listed the rationale behind the design decisions helped ensure the product vision was correctly communicated to the development team, so the product that was developed through their agile processes was in line with the overall product vision.

¹http://www.mitpressjournals.org/doi/abs/10.1162/0747936053103020? cookieSet=1&journalCode=desi

²http://www.slideshare.net/aregh/core-and-paths-designing-findability-from-the-inside-and-out

Unfortunately, the enthusiasm I had for my new job waned after six months when an executive was appointed Head of Product Development — who insisted he knew SCRUM¹ better than anybody. As the Creative Director, I deferred authority to him to develop the product as he saw fit. I had worked with SCRUM before, done training with Ken Schwaber (author¹ and co-founder of the Agile Alliance) and knew a few things from experience about how to achieve some success integrating a design team within SCRUM. This required the design team to work a “Sprint” (month long iteration) ahead of the development team. But the new executive insisted that SCRUM had to be done by-the-book. Which meant, all activities had to be included within the same sprint, including design.

Requirements came from the imagination of the Head of Product Development; design was rushed and ill-conceived as a result of time pressure; development was equally rushed and hacked together, or worse, unfinished. The end of Sprint debriefing meetings reliably consisted of a dressing down of the entire team by the executives (since nobody had delivered what they’d committed to i.e. they had tried to do too much, or had not done enough). Each Sprint consisted of trying to fix the mess from the Sprint before or brushing it under the carpet and developing something unstable atop the code-garbage. Morale languished, the product stank, good staff began to leave… it was horrible.

This is an extreme example of where SCRUM went bad. I am not anti-Agile although I’ve been bitten a few times and feel trepidation when I hear someone singing its praises without having much experience with it. Over the last eight years, I’ve seen Agile badly implemented far more often than well (and yes, it can be done well, too). The result of this is mediocre product released in as much time as it would have taken a good team to release great product using a waterfall approach. In this article, I will describe Agile and attempt to illuminate a potential minefield for those who are swept up in the fervor of this development trend and want to jump in headlong. Then I will present how practices within User Centred Design (UCD) can mitigate the inherent risks of Agile and how these may be integrated within Agile development approaches.

Where did Agile come from?

Envisioned by a group of developers, Agile is an iterative development approach that takes small steps toward defining a product or service. At the end of each step, we have something built that we could release to the market if we choose to and therefore it can assure some speed to market where waterfall methods usually fail. Agile prefers to work out how to build something as we go, rather than do a waterfall style deep dive into specification and then finding out we can’t build parts of the spec for some reason e.g. a misjudgment of feasibility, misjudgment of time to build, or changing requirements.

A group of developers such as Kent Beck, Martin Fowler and Ken Schwaber got together to come up with a way to synthesize what they had discovered was the most effective ways to develop software – The Agile Alliance was born. It released a manifesto² to describe its tenets and how it differs from waterfall methods.

Agile can be thought of as a risk-management strategy. Often developers are approached directly by a client who does not know what a user experience designer, information architect or user interface designer is. Roles such as these usually interpret what clients want and translate it to some kind of specification for developers. Without this role, it’s down to the developer to work out and build what the customer wants. Because Agile requires a lot of engagement with the client (i.e. at the end of every iteration, which can be as little as a week) it mitigates the risk of going too far toward creating something the client doesn’t want. As such, it is a coping mechanism for a client’s shifting requirements during development as they begin to articulate what they want. To quote the Agile Manifesto’s principles “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Why do people rave about it?

At the heart of what makes Agile attractive is the possibility of quicker return on investment for development effort, because we can release software earlier than we would have otherwise. In the short term, this is typically borne out. In the long term it can be too, though only when the team hasn’t fallen victim to temptation (more on that later).  Agile is also good at generating momentum because the iterations act as a drumbeat to which the team marches toward manageable deadlines. The regular "push" to finish a sprint ensures that things move along swiftly. Agile is also good at avoiding feature bloat by encouraging developers to do only what is necessary to meet requirements.

Because it emphasizes face to face contact for a multidisciplinary team, Agile tends to encourage contribution from different perspectives. This is generally a positive influence on, pragmatism, innovation and speed of issue resolution. The team is empowered to make decisions as to how requirements should best be met.

The Minefield

In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.

Mine 1: An unclear role for design

In the best cases of business approaching developers to build some software, some of those developers may have design skills. But that’s not a particularly common scenario. Many developers have also had bad experiences with designers who don’t know what they’re doing. It took a long time for the design profession to come to grips with designing for complex systems and there is still a deficit of expertise in this field. “Business people and developers must work together daily throughout the project” is another principle of Agile. Where does the designer fit into the frame?

Mine 2: The requirements gathering process is not defined

Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.

According to Ken Schwaber, SCRUM intends to be a holistic management methodology and leaves space for activities other than programming to occur within the framework of iterative cycles. But when organizations adopt SCRUM, too often the good parts of a waterfall process like research and forming a high-level blueprint for the overall design become the proverbial baby thrown out with the documentation bathwater. As the Agile Manifesto says, “Working software over comprehensive documentation.”² Many latch onto this and don’t want to do any type of documentation that might outline a vision, even if in a rudimentary sense.

Mine 3: Pressure to cut corners

Implementations of Agile that put design activities within the same iteration as they must be developed, ensure designs are achievable in code. But they also put tremendous pressure on the experience design team to ‘feed the development machine’ in time enough for them to implement their vision. This can and does lead to impulsive design. So, what’s wrong with that? Well, nothing if you’re not adhering to user centric principles which suggest you should test ideas with end users before committing them to code.

Some assert that there are plenty of examples of best-practice interfaces to copy out there. So, why reinvent the wheel? Surely we can save time that way? Sometimes they’re right, but how will we know which best-practice interface works best in context with the user’s goals, with no time to test with the user? How can we innovate by copying what already exists? Before Google reinvented internet search, other search engines assumed a status quo which behooved the user to learn how to form proper search queries. It was institutional knowledge among the other search engines that this is how searching was done and customers simply had to learn to use it. Most people’s search results were poor at best. Then Google came along and realized what is now obvious. People just want to find what they’re looking for, not learn how to drive a search engine first. I’m not suggesting the other search engines could not have done what Google did sooner, but I am pointing the finger at a mentality which meant they missed the opportunity. Interestingly, Google is not known for its designers. It’s mainly a development house, but lots of those developers can clearly put a design hat on too.

There is absolutely nothing wrong with using Agile to produce results quickly; that is, if you don’t intend to release them on your poor, unsuspecting user without some usability testing. Just don’t be fooled that this is going to save you a lot of time if you want your new product to be right, because you will have to iterate to arrive at an appropriate solution. Alan Cooper has argued that this creates a kind of ‘scar tissue’ where code that has to be changed or modified leaves a ‘scar’ that makes the foundations of the program unsound.⁴

Mine 4: The temptation to call it “good enough”

Invariably when we have release-ready working code at the end of each cycle, even if it’s sub-optimal, there’s a strong temptation to release it because we can. Agile condones releasing whatever we have so long as it works. Sometimes, that means doing what we can get away with, not what is ultimately best for the user. Equally, if we do decide that a feature isn’t right yet, it’s amendments get fed back into the requirements backlog where temptation strikes again. Should we spend time in our next iteration on a feature that we’ve already got a version of? Or shall we develop something new instead? Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.

Mine 5: Insufficient risk-free conceptual exploration time

Iteration “zero” (i.e. a planning and design iteration prior to the first development iteration) can be used to do this and other planning activities. However, depending on how long this iteration is, the level of rigor applied to exploration may be insufficient. An argument used by some Agile practitioners asserts that a working example of a solution is the best way to validate whether it is the right one through exposure to the market. This ‘suck it and see’ approach bypasses an activity called “concepting.” Concept activities dedicate time to sketching different solutions at a high level and validating them in the rough with users before digging into detailed design or code. “Suck it and see” would have us just build it, launch it and see if it flies. This way, we’ve wasted time building something we will probably have to take apart or rebuild. The counter argument is: if it took as long to build as it would have to research and design before laying a line of code, then we break even. This statement is a stretch in practice because development itself usually does take longer than well-managed design research and conceptual exploration. Also, there has to be some level of design regardless  of which methodology is used, and this adds days to the timeline.

Mine 6: Brand Damage

Let’s just say that design and research takes the same amount of time as development for argument’s sake. In the worst case, we completely miss the mark with the non-researched and designed solution and we have to start all over again. Then we’re back to the same total duration after developing it a second time, but there’s no guarantee we’ll get the solution right the second time either. All the while we’ve repeatedly foisted a botched product design on our users and adversely affected our brand. Many companies succeed on the back of their reputation for producing consistently appropriate products and services. When a company releases a flawed product or service, then their image in the customers mind (i.e. brand) is tarnished. Brand damage takes far longer to mend than it does to make. Software creators that fall victim to the temptation of "good enough" and fail to innovate through conceptual exploration put their companies revenues at risk. In a competitive market, repeated failure to meet user needs well leads to serious brand and subsequently financial repercussions, as other companies who do get it right take the business.

Agile is good for refining, not defining.

If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.

But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.

User Centered Design

UCD requires iteration – design, test with users, refine, test with users again, refine… repeat till it’s right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming you’ll need to change things, and that’s a good thing when it comes to refinement.

Uncovering requirements to form a strategy

User Centered Design (UCD) is not about answering requirements alone, but also includes defining requirements. When we practice UCD end-to-end, we pretend we know little. Little about what the solution to a problem should be; little about what the problem actually is because assumptions close us off to new possibilities. We prefer to allow some design research to create a viewpoint and then form a hypothesis as to what we might build. In this regard, we cross into the realm of product managers, producers, program managers, business analysts and the like, trampling toes with gay abandon and meeting resistance all around. Facing confinement to defining the boring old business need (distinct from the user or customer need), these folks would prefer we constrain our UCD work to usability testing on designs meeting the requirements they set out. They’d prefer we stick to just helping with development… and if we can do that quicker using Agile? Wahey!

Is it always appropriate to do extensive research before starting design? That’s a good question and one that Jared Spool’s Market Maturity Framework⁵ helps answer. Sometimes, just getting something off the ground, regardless of how precisely we meet user’s needs with it is all we can afford to do. Once we graduate out of this "Raw Iron" stage into "Checklist Battles" focused on getting the right features and then beyond, research is a core ingredient to putting our feet in the right place.

After researching what the user and business requires, we can make the “Strategy” tier of Jesse James Garret’s Elements of User Experience³which underpins everything we do during the project. Do this well, and you really shouldn’t come up with something that’s fundamentally wrong. Agile doesn’t account for this beyond a planning phase (i.e. iteration zero), which may well define a strategy of sorts. But does it really define the correct strategy? Surely, that’s created through careful consideration of three things:

1. Empathetic qualitative research that uncovers the user’s context, needs, goals and attitudes i.e. user requirements. Cooper suggests that the customer doesn’t know what they want and advocates a role of interaction designer as requirements planner.⁴ This would avert building to the wrong requirements in the first place, but the time to do this must come into the development lifecycle somewhere. It involves talking to users, preferably visiting with them in their environments to create experience models and user personas.
2. A thorough appreciation of what else in the big wide world exists in terms of products, features and technology that can be emulated somehow (not necessarily addressing a similar situation to ours).
3. A clear articulation of the business problem, objectives, success measures and constraints. Business people sat in a room discussing what they think should be done must be informed by all these things if the right strategy is to emerge. Agile doesn’t preclude that kind of consideration, but it does not mandate it either.

Concept Development

If we manage to built something usable and reasonably intuitive without research or strategy, did we succeed? Most MP3 players fit this bill but none took off like the Apple iPod. Leaving interface usability aside, the iPod had a service concept behind it which included digitizing, replenishing and managing your entire music library with iTunes. This was part of the iPod concept from the outset and in combination with good marketing and design, continues to eclipse the competition over seven years later. But that concept needed to be sketched and iterated at some point. If we don’t explicitly build this into our Agile methodology, we can miss that thinking time.

The best of both worlds

UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go. 

A shared vision of the interaction fundamentals

In good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms, i.e. not each and every navigation label, task or tool but rather the interface and interaction patterns that will persist. This produces something rudimentary to test with users to see if we got the big picture right. Following this roadmap sketched on the back of research and concepting prior to development activity, ensures consistency and cohesiveness when each component is coded separately to each other later. In many cases, the concept will need iterating to accommodate lessons from the journey. But we’ll at least have some indication of direction at a macro scale. Then, when in the midst of Agile iterations working out the details alongside our developer brethren, a level of expertise and experience is required of the designer because what we design will be built before we’ve had a chance to second-guess ourselves. Domain knowledge and an understanding of interface paradigms that work is also a big help. But to build new projects from scratch without a shared vision is a mistake.

Risky interfaces that are new or significant improvements on what has been seen before, are best tackled as design-only activities in a sprint prior to when they will be developed (i.e. do involve developers, don’t try to produce code). This circumvents the pressure to deliver something before proper thought, reflection and user testing, which ensures you’re not wasting time and effort. Sometimes most of the product will be done this way and that’s fine so long as developers and designers are still working together and talking every day. The first development iterations are an important time for the developers to lay the architectural foundations based on the vision. Designers should use this time to get a jump on any high-priority tricky interfaces so the development team isn’t waiting for something meaty to start on when it comes time to build features.

Most important to success, the business needs to accept that some things won’t be right the first time around and commit to iterating them prior to release i.e. not be led into the temptation to release something that’s not right yet.

Conclusion

In summary, dogmatic attitudes about each of these approaches should be avoided if they are to be combined. Remember, Agile does not mandate how to define concepts or overall design direction, but it is a great way to execute on solid design research and well laid plans. UCD needs to be flexible enough to respond to the reality on the ground when the implementation team encounters issues that mandate a different design solution. Document only what is needed to get the message across and co-locate if at all possible, because cross-disciplinary collaboration and face to face communication are vital. Working a sprint ahead of the development team is helpful in allowing the design team enough time to test and iterate. If these rules of engagement are followed, the two approaches can work very well together.

Notes:
1. Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle

2. Manifesto for Agile Software Development

3. The Elements of User Experience by Jesse James Garrett

4. Extreme Programming Vs. Interaction Design. Interview with Kent Beck and Alan Cooper

5. The Market Maturity Framework is Still Important – Jared Spool

My company conducted a best practice study to examine the development practices of in-house teams designing web applications—across multiple industries, in companies large and small. Some teams were large and highly specialized, while others were small and required a single team member to perform multiple roles. We identified and validated best practices by measuring user satisfaction levels for the applications each team had designed; the higher the user satisfaction scores for the application, the more value we attributed to the practices of the team that designed it.

We did not find any correlation with user satisfaction and those teams with the most specialized team members, one way or the other: some teams with the most specialization did well, and some teams did poorly. What we did consistently observe among teams that had high user satisfaction scores, was one characteristic that stood out above all the others—what we began to call shared, holistic understanding. Those teams that achieved the highest degree of shared, holistic understanding consistently designed the best web applications. The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment—a holistic view—the more successful the project. In contrast, the more each team member was “siloed” into knowing just their piece of the whole, the less successful the project.

All of the members of the best teams could tell us, with relative ease, the top five business goals of their application, the top five user types the application was to serve, and the top five platform capabilities and limitations they had to work within. And, when questioned more deeply, each team member revealed an appreciation and understanding of the challenges and goals of their teammates almost as well as their own.

The members of the teams that performed less well not only tended not to understand the application as a whole, they saw no need to understand it as a whole: programmers did not care to know about users, user researchers did not care to know about programming limitations, and stakeholders were uninvolved and were considered “clueless” by the rest of the development team. These are blunt assessments of unfortunate team member attitudes, but we were surprised how often we found them to be present.

We also observed that the best teams fell into similar organizational patterns—even though there was a blizzard of differing titles—in order to explore and understand the information derived from business, users and IT. We summarized the organization pattern in the diagram below. We chose generic/descriptive titles to simplify the picture of what we observed. In many cases there were several people composing a small team such as the “UI Developer(s)” or the “User Representative(s)” often with differing titles. Also fairly common were very small teams where the same person performed multiple roles.

Fig. 1 — Teams tend to organize in similar patterns in response to the information domains they need to explore and understand

Even this simplified view of the development team reveals the inherent complexity of the development process. The best team leaders managed to not only encourage and manage the flow of good information from each information domain, but they also facilitated thorough communication of quality information across all the team members regardless of their domain. Here’s how they did it.

Five Key Ways to Promote Shared, Holistic Understanding

1. All team members—all—conduct at least some user research

Jared Spool once wrote that having someone conduct user research for you is like having someone take a vacation for you—it doesn’t have the desired effect! On the best teams, everyone, from programmers to stakeholders, participate to some degree in user research. A specialist on the team often organizes and schedules the process, provides scenario scripts or other aids to the process, but everyone on the team participates in the research process and thus has direct contact with actual users. There is no substitute for direct contact with users. Interviewing living breathing users, ideally in their own home or work place, makes a deeper impression than any amount of documentation can duplicate.

2. Team members participate in work and task flow workshops

Designing applications to support the preferred work and task flow of the users—providing the right information, in the right features, at the right time—is one of the hallmarks of applications that get high user satisfaction scores. The best teams devote enough whiteboard-style collaborative workshop time to explore work and task flow (including in the sessions actual users when possible), until all team members truly understand all the steps, loops and potential failure paths of their users.

3. Team members share and discuss information as a team

A simple practice, but one which is often overlooked, is taking the time to share and discuss findings and decisions with the entire team. Too often teams communicate information of significant importance to the project through documentation alone or through hurried summaries. Even if it is not possible for the team to participate in all user research or in mapping out all work and task flow on a whiteboard together, at a minimum, the team should go through the results of these processes in sufficient detail and with sufficient time to discuss and understand what has been learned.

Direct participation is the most effective way to learn and understand. Full and relaxed discussion with team members is the second best. Reading documentation only is the least effective way for team members to retain and understand project information.

4. Team members prioritize information as a team

Not only is it important that all team members be familiar with information from all three domains (business goals, user needs, and IT capabilities), but it is especially significant that they understand the relative importance of the information—its priority.

My company developed what we call a “Features and Activity Matrix”, based on our own experience designing applications, and from the practices we observed in our study. The features and activity matrix accomplishes two things:

1. It forces teams to translate business goals, user input and IT capabilities into specific proposed features or activities that a user would actually see and use at the interface level. We have found that if an identified user need (for example, the need to know currency conversion values) isn’t proposed as a specific feature (say, a pop-up javascript-enabled converter, tied to a 3rd party database) then a potentially important user need either gets lost, or is too vague to design into the application.
2. The features and activities matrix allows team members to prioritize the proposed features and activities from the perspective of their own domain through a process of numeric ranking. Business ranks according to the importance to the business, IT ranks according to “doability” (measuring budget, resources and schedule against each proposed feature and activity), and the user representatives rank according to their assessment of what will make users most satisfied.

The numeric ranking for each feature or activity, from each domain, is then averaged to arrive at a consensus prioritization of every feature and activity proposed for the application. If, as is usually the case, the team is already aware that they cannot do everything that has been requested or proposed, this is a very effective way to determine which features and activities are not going to make the cut and which ones have the highest importance.

Fig.2 — Features and Activities Matrix. Note that we used a ranking scale of 1-5, 5 being the most important.

5. Team members design together in collaborative workshops

Once information from all three domains is gathered, analyzed, shared and prioritized, the remaining—and most powerful—practice to promote a shared, holistic understanding is to conduct wireframe-level, whiteboard-style, collaborative design sessions. Your session participants should include a solid representation of users, business and IT but not exceed roughly 12 people. In these workshops teams can work out together the basic layout, features and activities for most of the core screens needed for a project. These sessions can, and should, require multiple days. We have found that between 10 and 20 core screens can be considered, discussed, iterated and designed in 4-5 days of workshops.

Make sure everyone is fully engaged: business cannot be half committed, and IT cannot say that they will determine later if the screen can be built. All team members should be prepared to make real-time decisions in the collaborative design session. Inevitably there will be a few things that simply cannot be decided during the session, but the greater the shared, holistic understanding that already exists, the fewer things that will require processing and final decisions outside the session.

A well prepared collaborative design session both promotes and leverages the team’s shared, holistic understanding of the project. Even though they are time consuming, collaborative workshops eventually save time because the team ends up needing less iterations to refine and finish the design. Collaborative workshops also insure higher quality; there are fewer missteps and errors down the line because of the shared understanding of the design. Finally, collaborative workshops create great buy-in from business and IT. It is far less likely that some—or all—of the project will undergo unexpected or last minute changes if the goals and priority of features is clearly established during the design process.

Whatever the size and structure of your team, and no matter how many or how few specialists it has, your outcomes will be better if everyone shares a holistic understanding of the work at hand. Taking the extra time as a team to develop a shared holistic understanding pays off in greater efficiency in the long run—and most importantly—in greater user satisfaction and overall success!

I have participated in, led, and suffered major website redesign efforts. Whether at process-heavy consultancies, notable product companies, or design studios, all teams experience the same points of pain: late feedback, lack of common design vision, and complaints that individuals or teams didn’t have enough input.

No matter what your design process is during the early phases, most interaction designers and IAs complain that requirements aren’t clear or specific enough. Product managers are anxious to get started and have high hopes–expecting product innovation, timely delivery, and no negative impact on the site. Engineers are frustrated because they are not solicited for input. Finally, to complicate matters, the approval process becomes mired in team dynamics and politics.

The traditional software development “waterfall” process was first described in 1970 in a paper by Winston Royce. He postulated that as the project moved from requirements gathering to implementation, specialized disciplines would create specific deliverables and then pass them off to the next discipline. For example, interface designers would hand off low fidelity schematics to visual designers, who would design the look and feel before delivering to web developers.

Figure 1. A frequent and frustrating consequence of the waterfall process is late feedback.

Over the years, I have developed a framework that I call “Collaboration Sessions.” Collaboration Sessions encourage multidisciplinary collaboration while creating a unified design vision–all within a compressed time frame. The benefits of this tool include increased participation, increased understanding of the value of each discipline, and consequently increased buy-in from the team.

What are Collaboration Sessions?

Collaboration Sessions are highly interactive meetings (or more accurately, work sessions) with representation from each discipline. These meetings address everything from strategic planning to the design of site sections and page details. For example, a team working on the Travel section of our site used this technique to brainstorm a new line of business and then used it to help design page details. This method is most helpful for redesigns, new features, and controversial or strategic sections of a site (e.g. the home page). Typically, an interaction designer or product manager leads the meeting at the beginning of the Design phase.

Figure 2: Collaboration Sessions are excellent tools, especially during the design phase of a project.

A project manager is designated as the central point person, responsible for inviting the required and optional representatives from Sales, Marketing, Product Management, Interaction Design, Visual Design, Web Development, and Engineering (or whatever your particular departments/functions are). The meeting request should include an agenda and describe the purpose of the meeting. The request might also encourage the team to send in ideas and innovations or ask them to present their new ideas to the group at the beginning of the meeting. If it makes sense, prior to the Collaboration Session, the interaction designer conducts due diligence and a heuristic evaluation of the current site. For a new feature, the designers might look at competitors or research best practices.

Collaboration Sessions are most effective when attendees understand the project goals, the design problem to be solved, the roles and responsibilities of individual team members, and the business context. The facilitator starts the meeting by explaining the purpose of the meeting, the type of contributions encouraged, the ground rules for the session, and the desired outcome. The facilitator also assigns roles: time keepers, notetakers, final arbiters, and scope police (who call attention to scope creep). It might be helpful to assign these roles before the meeting. The product manager (or participant with the most domain knowledge) should provide the team with the historical, business, and competitive context. Scope boundaries can also be identified. For example, when a page will be completely redesigned and rearchitected, the product manager will state the purpose of the pages and the current design challenges.

With a blank wireframe template pasted on the wall, the facilitator turns the team’s attention to page level design. The focus is high level, not pixel level. Figure 3 is an example of “Search Results” with an accompanying “Notes” page. Advertising requirements are identified in pink. The primary focus of the page is the search result set, noted in purple. The secondary call to action, identified in blue, is “Modify Search.” The Post-It notes provide general placement for the page components but do not dictate design. However, some design decisions may be requirements; for example, the Sales department may specify that all ad units have to be above the fold.

Figure 3: Next to each page or site section, the Notetaker documents issues, to do’s, questions, assumptions, and major decisions.

As issues and questions arise, they are captured in real time by the notetaker on a “Notes” page taped next to the page being designed. At the end of the meeting, the To Do items are assigned to specific people. After the Collaboration Session, the interaction designer distributes the Notes. The team can then use the session output to start working on a more detailed design, creating wireframes that use the accompanying Notes documentation. When answers are found, the Notes page is updated; Notes pages should be living documents, shared by team members.

What Collaboration Sessions are Not

The process should not be “design by committee” but rather design for common understanding. When the designers provide solutions during the meeting, these are meant to foster discussion, not offer a final solution The focus should not be on granular elements like interface widgets or pixels. If you are debating whether something should be a drop-down or not, then you are wasting people’s time. Remember, if you have representation from each discipline, these are costly meetings. The facilitator should not try to provide real-time solutions or answers. Collaboration Sessions identify the requirements (i.e. what needs to change, the current design’s problem areas, current traffic pattern, what competitors are doing). The designers should take this information and ultimately present solutions to the problems. The session output serves as the foundation for design rationales.

Benefits
Collaboration Sessions enable teams to compress the development cycle by accomplishing the following:

• Establish a common design vision. Encourage early collaboration.
• Generate ideas and innovations for release and/or inform product roadmap.
• Identify questions, issues, and to do’s.
• Encourage full team contributions and subsequently ensure team buy-in.
• Document assumptions, design rationales, and changes.
• Enable parallel development (i.e. mobilize each discipline).
• Improve scoping, estimating, and planning (e.g. number of impacted pages, new pages).
• Inform process flows and page level design.
• Can improve credibility (by identifying design problems and having designer recommend solutions). Can change perception of user experience design from “pair of hands" to more "strategic partner."
• Define the design problem within its historical context.
• Establish regular check-in meetings.
• Allow User Experience team to present recommendations, design solutions, and design rationale as a unified voice.
• Identify opportunities and innovations at a strategic level.

Best Practices
After running Collaboration Sessions over the past couple of years, here are some best practices I recommend:

• Prep the meeting room the day before.
• Encourage one representative from each appropriate discipline to attend. Cross-functional representation deepens the understanding of the problems, encourages more holistic solutions, and fosters collaboration across the team.
• Start each meeting by allowing the business owner or the person with the most experience to provide context on the competitive landscape, current design, or any useful and relevant information. Also, identify roles: timekeepers, final arbiters, scope police, product manager as hub, design manager as process filter.
• Make adaptations or customize the format of Collaboration Session process after each session if needed. Encourage the team to be flexible, nimble, and adaptive.
• Summarize, capture, and distribute the notes from each Collaboration Session within 24 hours.
• Involve key stakeholders before the session, and have them buy in to the participants, agenda, and meeting objectives. If relevant, send out any homework, such as links to competitors, before the meeting.
• Send out “Issues and To Do’s” immediately after meeting.
• For major innovations, package ideas and “sell up” to key decision makers afterwards.

Testimonials

After the first one:

“I just wanted to say I thought the first collaboration session went really well overall. Lots of focused participation from different disciplines. Discussing and agreeing on goals and priorities at a page/template level is really going to help communication throughout the design process. It’s often a big leap from presenting documents to one another to solving problems together and getting design work done in real time.”

Contract content strategist with 8 years experience.

After project was done:

“Super proud [of the redesign]. Collaboration sessions were pain in the ass to attend, but extremely valuable to the process” “Very proud and pleased with the end result.”

Product Manager.

“Best process at Yahoo I’ve seen, in 5 years. Smoothest redesign to date I’ve worked on.”

Senior Engineer.

Invitation from another team

“Our goal of this meeting is to have you lead us through a Collaboration Session…. I remember how helpful this process was in designing pages for our previous product….I think our team could really benefit from applying this tool.”

Senior Product Manager

Sasha Verhage is a Senior Design Manager at Yahoo with over 10 years experience in software, internet and professional services industries. He is passionate about leading fast paced and high performing teams to successful outcomes. In his not so spare time, he makes award winning wine under the Eno label.

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.

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.