Fresh paint or new drywall? The cost of changing IA or design mid-project

Brian Dillard, Monday, June 16, 2008 @ 4:53 pm

We software engineers - and our clients - tend to think of visual design as a coat of paint. The arrangement of elements on a screen seems like a purely decorative concern, something that can be applied to the bare walls of an otherwise functional application at the very end of the development process. Anybody who's ever spent much time coding at the view layer knows differently. If effective visual design planning doesn't occur early in a project, there's often a hidden cost. Reskinning an application is more like installing new drywall than applying fresh paint.

The PR wizards who launched the web standards movement have propagated the idea that if you just mark up your content and code semantically, then it's a trivial concern to alter its appearance. This is true up to a point, but most sites have a large number of person-hours invested in their stylesheets, images and other purely "decorative" assets. Because browser vendors haven't consistently implemented existing web standards, even the most well-meaning programmers must litter their code with hacks, filters and nested containers to achieve visual fidelity. The hooks for achieving a given look-and-feel often penetrate deep into the view-layer code. Altering that look-and-feel often requires changes to those hooks, which adds risk to a project and almost always breaks lots of tests.

To complicate matters, we engineers often conflate visual design with information architecture and interaction design. We leave all three until the very end of a project, when the change costs have increased exponentially. As we iterate on an application, we charge ahead doing "useful" things like building core functionality. We think it'll be easy to go back later and "clean up the view." By then, our code is riddled with assumptions about how that view will be rendered. Change is rarely as fast or as cheap as we expect.

When working with clients, I find it's helpful to frame design questions the same way I frame questions of development platform. Decisions about Rails vs. J2EE vs. .Net vs. LAMP are rarely taken lightly. The same care should be taken when choosing visual design, information architecture and interaction design. Platform changes carry a cost, even when the platform is a UI model rather than a programming language.

Every time this subject comes up on a project, I return to "The Elements of User Experience" by Jesse James Garrett. Six years after publication, this excellent primer could probably use an update. Some of its precepts could use a more agile spin. It would also benefit from a more explicit acknowledgement of today's increasingly complex interaction models. Still, I can think of no better introduction to Garrett's famous "five planes" of UxD.

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment