Wireframing in a Web 2.0 World

Originally posted on project eric.com

It’s not hard to realize that the days of static wireframes are coming to an end.

The increasing prevalence of dynamic applications, embedded Flash, AJAX-based menu structures, all make page-centric wireframes hard for business stakeholders [and sometimes developers?] to comprehend.

If Morpheus were here right now, he might say something like, “There is no page,” to which Neo would reply, “I know Kung Fu?”

So why can’t we just continue on our straight-and-narrow path, churning out page-level wireframes in our favorite application (e.g. Microsoft Visio for most) showing key animation milestones along the way when AJAX is involved?

The truth is, most of the stodgy Fortune 500 companies still do. My full-time employer is a classic example. The tried-and-true page-level methodology – attacking the interactions in Visio and the copy in Microsoft Word – reflects where we are in Web design conceptualization, not where we’re going.

Where we are

If you’re a web designer, you probably already know the drill:

1. A business stakeholder involves a design team in a high-level business challenge
2. A requirements document is developed (with or without design consultancy) to solve that challenge
3. The design team takes the requirements and begins to churn out wireframes
4. The designers return to the stakeholders, present the wireframe concepts, then engage in a back-and-forth iterative process until the detailed wireframes are narrowed, then approved. The copy generally follows the same process.

So what’s the problem with this? Nothing (arguably) if there aren’t any AJAX or dynamic interactions involved with your wireframes. They’re all “page” centric. It’s quite easy to create a static wireframe for the Home page, then the About Us page, then the Offerings page, and so on, and so on ad nauseum….

But what happens when you throw in an AJAX-based shopping cart with Adobe Flex in mind; how do you visualize a dynamic interaction in a static wireframing environment?

If you’re using a tool like Visio, chances are you don’t (it can be argued that Visio is capable of handling complex visual representations of AJAX-based interactions but I’ve found that few utilize the complex capabilities). And if you’re like me, you capture the key points of, say, an animation tween and put those “screen shots” down in the wireframes. You capture the key frames (not to be confused with keyframes) but you don’t capture what goes on between the frames.

And it’s not just animation that you might not be capturing. It’s the total experience. How do you visually represent what you did prior to the interaction, what happens during the interaction, and what happens after the interaction occurs? In short, how do you illustrate an effective prototype-like use case using a one dimensional tool?

Is this what we’re stuck with? Luckily, not anymore.

Where we’re going

New technologies (and old) allow for more scalability, ease of updating, sharing among stakeholders, prototyping, and most importantly, illustrating a Web 2.0 world.

iRise
Let’s start with the Cadillac of wireframing tools. iRise is more than just a wireframing tool. It’s a client-server model that incorporates real-time updating, user permissions, instant HTML-based prototyping, the works. The benefits: it’s the whole package. iRise has left nothing to the imagination in terms of allowing design teams to create applications, big and small. Using stencil templates, iRise helps to prevent the all-too-common re-invention of the wheel when it comes to design for multiple projects. In other words, you build a widget once and use multiple times, sharing your designs at the server level, not the client (workstation) level. Bye bye email attachments. The drawbacks: iRise has not yet developed tools for AJAX-based wireframing/prototyping per se. So you can’t yet develop an entire animation sketch of that neat JavaScript based menu drop-down you’ve been thinking up. Word has it that it’s coming in an April 2007 release. iRise is also incredibly expensive and not for the freelance designer. Think Wachovia – they adopted iRise last year.

Axure
Axure is a step down from the powerful server-side functionality of iRise, but it offers a unique offering at a smaller scale: instant prototyping. Visio’s major downfall is that it can’t give stakeholders a true browser-oriented view of a given conceptual design. Much like iRise, Axure allows its users to generate an instant HTML-created vision of the wireframes, interaction and all. However, Axure does a better job than iRise of easily letting the user document use cases as the wireframes are being built.

The key feature between the two are similar though: Axure also takes an element-oriented approach to design. So, rather than creating one wireframe page where elements (like a header bar) must be copied and pasted throughout every page in a document, Axure manages elements through libraries. Design once, use multiple times, make changes at the library (i.e. template) level. The benefits: at its given price point (less than $600 for each individual license), Axure can’t be beat in terms of element scalability. The drawbacks: Axure isn’t server-based, so as far as I can tell, Axure won’t let you share libraries. That’s pretty inefficient if you’re working among a group of designers and want to share library elements. And again, heavy AJAX-based interactions aren’t yet integrated into the software (although it’s easier to show how an AJAX-oriented interaction might function using an instant prototype than with a page-centric application like Visio).

Microsoft PowerPoint
Are you kidding me!? PowerPoint!? Yes yes, I know. Most design veterans might consider this option to be a last-resort method of documenting conceptual designs, or simply not consider it at all. But before you report my blog to the this-guy-is-a-total-hack forum (is there such a thing?), read on.

Let me preface preface by saying that PowerPoint was never meant to be a documentation tool; yet, I see businesses constantly use it as such, presenting their work on slides using 11-point font size and adding cheezy animation to impress, well, no one really. To be honest, I find that most still use PowerPoint like it’s 1997.

Benefits: so what makes it such a good design tool? First, it’s a common application. Businesses don’t get much done in today’s Microsoft-dominated world without Office. Second, it hasn’t changed much over the years. I can’t speak yet to Office 2007, but PowerPoint itself has kept the same basic configuration since the late 90s. Finally, it’s just freakin’ easy to use. For instance, if you wanted to show your stakeholders and developers how you envisioned your accordion-style menu structure to work, simply add in some very basic, GUI-driven animation, maybe a bit of VB, and you’re off to the races.

Drawbacks: Obviously, PowerPoint design comes at a price. It’s not client-server driven like an iRise app, you can’t add a whole lot of visual complexity to your work (although it can be argued that that’s not the point of most wireframes), you run the risk of users not having PowerPoint on their machines and PowerPoint Viewer is a POS, and most notably, PowerPoint is simply not built for demonstrating the power of Web 2.0, or the Web itself for that matter.

All that being said, PowerPoint can be an effective demonstrator of dynamic interactions if you know what you’re doing. In a later blog, I’ll demonstrate a few tips and tools on the subject.

Let’s wrap it up

There are many other wireframing/prototyping tools out there. Intuitect, a Visio add-on, is one of them. In a later blog, I’ll touch on some others.

The key to wireframing is this: remember who you’re presenting them to. Business partners don’t care about the details, like how the show/hide layer onClick is supposed to function. They simply want to know that it’s there, it meets business requirements, and it’s pretty. But developers want to know all that.

Second, remember that no matter which application you choose, your design work should be precise, scalable, and repeatable without much effort. So make sure your “weapon of choice” allows you to easily document your work, is configurable for projects large and small, and keeps you from having to re-create that navigation bar 500 times.

Trinity: Neo… nobody has ever done this before.
Neo: That’s why it’s going to work.