In last week's post about "going small" for success with Web projects, I stressed the importance of agility.  In short, carve up Web projects into small doable pieces, release them, get feedback, and then proceed on based on that.  Making it easier to go agile is one of the things Percussion CM System is all about - content elements and templates are reusable and interchangeable, the Web delivery tier is decoupled architecturally, existing and third party applications are thus easily integrated.  

When it comes to the Web or UI design, however, agility is often a distant concern.  Designers typically mock up pages with the idea that content and function are well known.  Most design processes start with extensively mapping out the information architecture.

Example "Traditional" Web Design Questions

• How many sections and subsections are there? (and how can we reduce this to something manageable?)
• What are the key options you want to be only a click away?
• How many downloads of product information do you plan to have?  How many article pages are typical in this section?
• How many bloggers are you going to have?  How frequently do they post?

But in today's Web, content and function are increasingly found outside your organization.  You might discover a blogger, or a YouTube channel, or some very useful tweets or comments almost anywhere.  A third party might release a new Web application that makes total sense to "mashup" with your own.  As you no longer are the sole source of content and features, the answer to most of the questions above is "how ever much it takes."

Instead of monolithic page mock-ups, customers should ask designers for visual treatments in the abstract, and ask questions that presume change.

Example Agile Web Design Questions

• Do you want a consistent look for "Events" (news, etc.), or a consistent look for any content you decide to put in a given area of the page?
• What choices do you need to have for displaying comments and quotes, both inline and on the sidebar?  Are all pull quotes visually the same?
• Shoud there be a consistent visual for showing external content wherever it ends up on the page?
• How would you like the page to look in the case of zero, ten, or fifty (posts, events, articles, comments, etc.) live?  Is including less relevant content or excluding relevant content worth the look and feel benefits?

Adopting a more agile Web process means getting design deliverables that better reflect today's Web of interchangeable parts, constant testing, and moving target audiences.  That finished "painting" of the site, may wow the review team, but a palette of interchangeable "design treatments" that you can use, as well as some guidelines on how they do and don't fit together will go a lot further toward success.