- Writing Use Cases
- Creating Screenflows
- Designing Wireframes
- Storyboarding Your Product
- The Three Rs
- The Tools to Use
- Whats Next?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Designing Wireframes
When I designed the Sears Tower, I started with a nice blueprint. Actually, I didn’t design the Sears Tower. That was a blatant lie. But I have created a blueprint or two—or, as it’s more commonly known in the web world, a wireframe. In fact, I wireframe all sorts of things. (Wireframe is often used as a verb, much like how you google directions to Bourbon Street when you need a vacation.)
A wireframe is basically a line-art version of the layout for a screen or part of a screen. Before spending days on end creating detailed mockups of the exact design of a screen, you can throw together a wireframe in just a few minutes to quickly illustrate the basic composition of an interface. The best time to create a wireframe, arguably, is after you’ve written a use case for an interaction. The fact is that wireframes are faster than graphical mockups, but use cases are usually faster than wireframes.
With wireframes, you tend to fall into the same traps you fall into with graphical mockups. For example, once you start creating a wireframe, you can lose hours of your life tweaking small things in the design, such as the exact alignment of every item in a screen, and end up spending way more time on it than you hoped. But this is somewhat necessary, because unless you’re also the graphic designer for the project, you’re likely to pass your wireframes to another person, and you want to make sure the wireframe is self-evident enough that final artwork can be created from it with minimal effort. But keep in mind that you’ll likely change the wireframe multiple times before it leaves your hands, so don’t obsess over it too much. Do what you can, and let it go. The minutia can be worked out later.
I usually create several wireframes for a single interaction or application. I start with a wireframe of the whole application or application state, and then create at least one additional wireframe for each of the individual interactions that can occur within that application state. You may find it tricky, however, to create a static image of an interaction. (Those two concepts are in direct conflict with each other, so it’s understandable.) So, after you create wireframes of screens in their static states, you have to switch gears a bit, and illustrate your use cases with a storyboard.