March 19, 2013

Live Wires: Better prototyping

By Travis Gertz

Let’s face it. Web design has traditionally been a pretty wasteful and uneconomical process.

How many hours do we whittle away adjusting site map templates, dilly-dallying in wireframing applications, picking apart prototype frameworks, and feverishly massaging Photoshop comps only to throw them away when the next project phase begins? How many more hours are spent converting those formats to something else?

I’m not even talking about time spent actually designing, I’m talking about everything in between. The slicing, dicing, adjusting, revising, and refactoring that comes purely from working in our potpourri of traditional design formats. It’s easy to miss the full impact when we’re used to receiving an asset in one form, analyzing it, converting it to our desired format, then handing it off to the next station in the assembly line.

For years we’ve been building disposable avatars of a finished product. How much better would our finished products be if we could turn those hours into real design thinking and execution? We can give our clients a much bigger bang for their buck with a little change in our perspective and a big change in our process.

Instead of creating a series of disposable deliverables, let’s look at the web design process as an evolution. Everything we build should in some way take us closer to a final product with as little waste as possible.

We’ve been making adjustments in all other areas of our work process, but today I’m going to focus on an area that has really gone off the rails in the last few years … wireframing and prototyping.

BACKGROUND ON WIREFRAMING

The proliferation of UX as a field has yielded a staggering number of wireframing methods and tools. Some of them are online apps. Other methods involve repurposing old tools like Illustrator or Fireworks. I’m making a bold declaration that they all stink. Yup. Every last one of ‘em.

Here’s why:

Designing with them

  • You are limited to the available palate of UI elements.
  • Designing interactions is troublesome or not even possible.
  • They are often cumbersome, buggy, and time-consuming to use.
  • It’s easy to forget pages like search results, sign-ins, sign-outs, and 404s.
  • The fidelity is too high for such an early stage. Decisions get glossed over and too easily paint designers into a UI corner (e.g. adding social media icons in a wireframe causes a client to focus on design elements instead of content types and organization).

INTERACTING WITH THEM

  • Most aren’t responsive.
  • They don’t effectively mimic a true browsing experience.
  • The aesthetics are often not suitable for client presentation (intentionally ugly UI’s aren’t always obvious to clients … looking at you myBalsamiq).

Worst of all, with every single app, we spend hours creating something that we inevitably need to translate to another medium, then throw out. Not cool—and not economical for anyone.

Many folks have began to use frameworks like Twitter Bootstrap or Zurb Foundation to build their prototypes. While I think there are great elements within these frameworks, they have their own sets of problems when used as a whole:

  • The fidelity is far too high for early prototyping.
  • They make too many decisions for the designer.
  • They are bloated and complex. Too much time is spent stripping, overriding, and trashing.
  • You’re trapped into their way of thinking. It’s far too easy to get sucked into the “Bootstrap look.”
  • Often you still need to throw out a bunch of work by the time you’re ready to move past the wireframing stage.

The proliferation of UX as a field has yielded a staggering number of wireframing methods and tools. Some of them are online apps. Other methods involve repurposing old tools like Illustrator or Fireworks. I’m making a bold declaration that they all stink.

I’ve always been a fan of really low-fidelity wireframes. Remember Jason Santa Maria’s grey box method from almost ten years ago? It feels exactly right for designing basic content organization. It demonstrates basic layout for our content and there’s little mistaking it for a final product. Most importantly, it doesn’t pin you to a UI wall. This stage should be about quick approximations that are easy to adjust and give an idea of how the site works on its most basic level.

image
_JSM’s grey box wireframe example._

Grey boxes were great in the old days of fixed-width layouts, but today the approach is too limited. How do we communicate how things work at different screen sizes? How do we show dynamic interactions like hidden drawers or navigation elements? And once again, we’re spending valuable time creating a series of assets that get discarded later.

INTRODUCING LIVE WIRES

In response to the lacklustre options and approaches out there, I rolled my own wireframing toolkit called Live Wires.

Live Wires is more of a philosophy than a framework. It’s designed to be as simple and un-opinionated as possible. It’s not ugly, it’s not fancy or colourful, and it uses simple HTML & CSS (actually SCSS). It has a couple simple examples of common UI patterns to use as starting points, and a few nice SCSS variables to make things easy. This is why I like it:

DESIGNING WITH LIVE WIRES

  • Experimentation is quick and easy.
  • I’m not limited to the available library in a wireframing/prototyping application.
  • We can pull in core messages when we’re ready to design to help keep page goals in focus.
  • Because I’m placeholding much of my “content” using background images, I can set the stage for production-markup without filling it with junk that I throw out later.
  • It’s fast. I’ve already included some simplified designs of common patterns and standard elements which speed up coding. It’s just a matter of dropping them in and adjusting as necessary.

INTERACTING WITH LIVE WIRES

  • We can serve it anywhere and share it with anyone.
  • It’s responsive. I can preview wireframes in all my devices.
  • It’s not ugly, but not handsome enough to be mistaken for a final design.
  • Nothing replicates the browsing experience like clicking and interacting with actual web pages.
  • Omitting text separates content from layout and helps make it obvious that the wireframes are just that … wireframes.

OTHER ADVANTAGES

  • There are no monthly fees or additional expenses to worry about.
  • Clients won’t see partial wireframes and can’t be confused about site navigation, page stacking, or page orientation.
  • I’m not wasting time creating assets only to throw them out later. I’m setting the foundation for actual production code.
  • The organization is so low-fidelity that you’ll have the freedom to change elements in design without throwing client expectations.
  • It’s more difficult to forget pages when you can truly interact with the whole site. I added some commonly forgotten templates to ensure they’d be included.
  • It is the perfect first step towards designing in-browser. I know you don’t believe me, but this is the way of the future.

HERE’S HOW IT WORKS

Live Wires is an attempt to capture the spirit of the grey box model and bring it into the browser. What we end up with is a standard set of neutral styles, and a flexible, quick n’ easy way to build out prototypes in the browser without creating waste.


_Heating up some Live Wires_

See an example of Live Wires.

As I’m building out my Live Wires, I work directly with a content strategist to help define content types and organization. Design decisions should be influenced by the type of content used in each section. Good design conversations will influence the content itself—it goes both ways. Designers need to be working directly with content strategists. Collaboration is critical in this stage.

Live Wires is an attempt to capture the spirit of the grey box model and bring it into the browser. What we end up with is a standard set of neutral styles, and a flexible, quick n’ easy way to build out prototypes in the browser without creating waste.

CONSIDERATIONS

  • You need to know a bit of HTML & CSS (Learn it. It’s easy).
  • At first, you may not be able to prototype this way as fast as you did with other tools. But consider the time you save by not transferring designs over to another medium which also force you to deal with software quirks. You’ll get faster as you go.
  • While writing your CSS, keep your wireframe-specific styles separate from your layout styles. The idea is to be able to drop as much as possible into the next stage of design or production.

FORK IT, TRY IT, MODIFY IT

You can fork the toolkit from the nGen Github account, but please recognize that it’s really the philosophy that’s important, not the product. Customize it to your own needs and workflow. Hope you find this approach works for you and let us know if you have any feedback!

NEXT: BROWSER BASED DESIGN

Next post, I’ll be exploring how we can be more efficient designers through a browser-based design approach. Ultimately, this approach is about designing systems, not pages. Once you’ve tried it, I’m sure you’ll see how effective it can be at eliminating wasted comps and tightening your design process.

Comments

There were no comments.

Post a Comment

commenting is disabled.