IA Summit: Wireframes

by Luke Wroblewski March 25, 2006

The Wireframes: A comparison of purposes, process, and products panel at IA summit 2006 provided an overview of the pros and cons of different methods for creating wireframes.

The Wireframes: A comparison of purposes, process, and products panel at IA summit 2006 provided an overview of the pros and cons of different methods for creating wireframes.

Todd Warfel: Adobe Illustrator

  • Wireframes are used to communicate behavior, explore design options, and test ideas (paper prototypes).
  • The audience for wireframes is primarily developers and visual designers.
  • Evaluated flash/html/illustrator and settled on Illustrator for wireframe creation.
  • Important considerations include: creating a template system, maintaining a document index, keeping a version history, and including a side panel for specifying behavior.

David Heller: Flash

  • Wireframes are important for Design, Development, and Documenting (as a record of work done).
  • Interaction designer are designing time. They are primarily concerned with how to manipulate it.
  • Storyboards don't exist in time: they are flat representations.
  • Interactive prototypes (XHTML or Visual Studio) are all about the static moments of interaction. You can’t draw within these programs and there is no timeline.
  • Flash is a design environment: you can draw, it has a timeline, embedded behaviors, and lots of UI components.
  • Flash does not work well for documentation as it does not print very well.
  • Tips: draw in basic colors (16), layer in iterations on top of original.

Anders Ramsay: Semantic XHTML

  • Use Web standards (XHTML & CSS) to create wireframes with semantic mark-up.
  • Not about using HTML as an artboard. More about separating structure from design through semantic mark-up.
  • This allows you to leverage the separation of content and presentation.
  • In this process, the information architect defines content structure with XHTML while the visual designer works on presentation.
  • Pros: rapid, reusable, single-sourcing, fewer annotations, knowledge transfer, portability, prototyping ability
  • Cons: requires knowledge of XHTML & CSS, requires early involvement with visual designers, not well suited for rich media, content/presentation/code separation is actually kind of fuzzy

Jeff Lash: Word Documents

  • Uses written UI specifications to document a complete product
  • First a prototype is used to get feedback and evolve over time.
  • The end result is a Word document with screen shots of that prototype. Each page includes screenshot, description of purpose, ui widgets, user actions, and error scenarios.
  • Pros: document all necessary details, platform for communication, serves as formal record of rules and decisions, can be understood by everyone, separates design decisions from presentation, printable
  • Cons: long time to make, hard to mange variations, not easy to change, size can become unmanageable, editing needs to be managed closely, can overlap with other documentation, duplication and consistency needs to be closely monitored
  • Best for stable projects and when you need a written record and commitment.
  • Not a good method for agile teams

Laurie: prototypes

  • Using prototypes instead of wireframes
  • Pros: shows holes in design, allows developers to see what items are/do, potentially decrease documentation time, potentially increase development accuracy, gets you up and running.
  • Deciding what to use depends on: fidelity, speed of development, reusability, level of interactivity, level of edit-ability, portability

The question I really wanted to ask this panel (but they ran out of time) was: “given how mature your wireframing templates & libraries are, do you find you have a tendency to respond with design solutions that utilize those templates rather than to develop innovative new solutions?” From my experience, it is often easier to apply a solution for which you already have documentation, templates, and code than to start from scratch and test, iterate, and vet something new. Any design team in a fast-paced environment is likely to face a trade-off between: get it done fast or try something new. Does this result in stale solutions or successful products?