Contentions

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.

Now that we're officially out of a disastrous decade, we can make fun of one it's signature expressions "too big to fail."  The idea is that, regardless of whether we wanted to end up with them, some institutions are so big now that letting them fail would be worse than anything else we could do. (Who'd have thought that after ten years of our politicians' historic misuse of language, the biggest head-scratcher of the decade would come from some obscure finance industry regulator.)  

But as we bash our politicians for getting us here, we can learn something too.  How many of our own projects have we allowed to get to a "too big to fail" state of mind?  When something is complicated, like a Web project, the "big" solution is tempting, whether its the requirements "this time, we're going to get a real UI design!" the technology "we're going to build for high scale from day one!" to the commitment level "we're going for C-level buy-in from day one!" to the process "we're going to put everything through a real change request process this time!"  And still we find ourselves taking longer, doing less, spending more than we planned, and wondering how to go EVEN BIGGER the next time.

But with "too big to fail" now imprinted on our psyche, maybe we can finally realize that success usually means doing just the opposite - going small.  Really small.  As in, as small as you can possibly make something.  

Going small is not a new concept, but it's gaining speed.  Most notable, for software development at least, is the "Agile Process" which has been around for a decade or so.  (We've adopted it here at Percussion, first for our Solutions offerings, and now for all our software development.) But there is more here than a process revolution.  Witness the proliferation of Widgets and Gadgets, "app stores" and the success of products like Twitter built entirely as a "side project."  Each does one or two simple things, often without any ambition to ever do more.  Many end up being something totally different than even their developers anticipated.

Organizations are starting to learn that the problem with "going big" wasn't size, but hubris.  We think with more information, research, buy-in, debate and design, we can make better decisions.  But reality is closer to the Heisenberg Principle; it's not that we didn't know enough to predict, but that we cannot ever know enough - not until it actually happens. 

"Get it live, then decide" may seem backwards but it works. It is then that "going small" suddenly makes total sense.  It means you'll never build too much before you know whether it was ever going to work.