Sunday, January 14, 2007

Wireframing With InDesign and Illustrator

Practical examples of using wireframes ...

"There are a variety of tools used for interaction design. I’ve used them all and have settled on a framework using InDesign® and Illustrator®. It will require a series of articles to fully describe the framework I’ve developed. So, in this article, I’m going to focus on what led to the development of this framework and give you a brief overview.

With all the wireframing tools out there like Visio®, OmniGraffle®, Illustrator, InDesign, Flash®, Fireworks®, and HTML/CSS, why create a framework based on InDesign and Illustrator? Design solutions are about context. So, let’s start there.

My company, Messagefirst, provides research and design services for other companies. Our consumers are typically product managers, software engineers, and visual/graphic designers. Most of the time, they want something tangible to take with them, write notes on, and use to build their product or service. In our experience, a final artifact that is a PDF works best. It’s easy to post to project sites like Basecamp. It’s easy to email. And it’s cross-platform compatible.

We’ve tried all of the previously mentioned tools—some more than others. The InDesign/Illustrator framework I’ve developed meets our wants and needs best. Why not use HTML/CSS? Occasionally, when working on our own products or services or with a Web 2.0 company, we will go straight to HTML/CSS wireframes. But since most of our clients like something they can write on, we opt for the PDF route.

Our Needs
When selecting a solution, we based our decision on the following seven criteria:

• collaboration—We work on large, complicated projects. Our design solutions make the complex simple, but there are typically several hands in the mix. We need a system that allows multiple designers to contribute to one final source without overwriting each other’s work.
document management and versioning—We use an iterative approach, and our designs evolve over time. Hence, our documents are versioned. We need something that allows for versioning and provides a way to communicate the history of those changes to the product managers, software engineers, and visual/graphic designers—our consumers.

• separation of design and behavior specifications—It’s not unusual for us to use our wireframe decks as the springboard for paper prototypes. We need something that allows us to include behavior specifications with the illustrations, but we need to be able to turn off those notes for a quick paper prototype output.

• productivity—Call it lazy; call it efficient and working smarter—we don’t like to work any harder than we have to. We need something that allows us to work faster, smarter, and efficiently. We’re huge patterns advocates. We use them in our designs and in our artifacts, and we need a model that allows for that.

• useful, usable, and beautiful artifacts—We take a great pride in our artifacts. We have invested a significant amount of time and effort into making them useful, usable, and beautiful. Aesthetics are part of making useful and usable artifacts.

• affordability—To us, an application license of $1200–$12,000 per person isn’t affordable. Depending on its capabilities and how it fits our needs, $49–$299 is a fair price. But an application that costs several thousand dollars just isn’t affordable to us.

platform independence—This last part is critical to us, as we’re a Mac® shop, and our clients include a mix of Windows®, Linux®, and Mac. So, we need something that works regardless of what platform the consumer is on."    (Continued via UXmatters)    [Usability Resources]


Post a Comment

<< Home

<< Home