The biggest mistake I’ve made this year
A good part of each day has me working on a little project called ImageKind that intends to provide a community for converting digital imagery into actual wall art. Doing this project has revealed a lesson that I won’t repeat again. It’s the necessity for wireframing.
Most projects I’ve been involved in had written specs in a word-doc type format. More complex projects, like www.theplatform.com consist of chapters and chapters of detailed rationale for various product features and the associated schedules in formats like MS Sharepoint. But, unless you’re building the simplest of brochure websites, you need to wireframe.
I suspect a good portion of the people who read my blog already know that a wireframe is a skeletal rendering of every click-through possibility on your site - it is a simple visual mapping of each decision, path and feature that the project will consist of. The whole point of the exercise is to help clarify the IA (information architecture) of the project which tends to be the most difficult aspect. Getting IA exactly right can make a good idea very, very successful. Getting it wrong can take a bad idea and send it straight into oblivion.
My initial thinking was that I already had a clear idea of the logical and business functions for the project and that I would start mocking up graphical components very early in the process. This was a bad decision. By wireframing, you flesh out many of the things you don’t know that you didn’t know before the project started. Even if you understand the purpose of your project and the features you want to implement, you couldn’t possibly identify all the entry and exit points that users will experience as they try to use the application. You couldn’t have forseen all the steps necessary to implement logical consumption of the features you feel so strongly about. I’d suggest that great software products aren’t about more features. They are about your ability to logically consume and utilize the product without frustration.
The wireframe process is not a technology discussion. In fact, you wireframe first, before a single line of code is written and before any decisions are made in regards to design, navigation and content. The process is a discussion with other constituents in the company as well as respected external resources who are good “what if” type thinkers. The process should help the site work better by asking a lot of “what if” questions right up front. What if a user wants to sign up right away and clicks over here…what happens? What if a site visitor is not yet registered but wants to start buying? Do you let them buy with a guest account? A simple registration? What information will you ask for? Will product pages share other elements from other parts of the site?
The process is a bunch of questions, followed by a discussion, which results in subsequent decisions which finally results in a very simple, non-technical set of “wireframes”…simple pages that reflect page functions and flow…not design. I started with design and managed information architecture during the design process. That was dumb. Had I done this, I certainly could have saved more money and shipped faster. Plus, it allows developers and designers to be better at their own jobs. And finally…the product is just going to be better.
This isn’t a short-cut I’ll be inclined to explore again. Every new project has way more unanswered questions and unknowns than there are knowns. Wireframing helps catch a good chunk of that stuff up front. I knew it too. Biggest mistake of the year.
comments
One Response to “The biggest mistake I’ve made this year”
Leave a Reply
You must be logged in to post a comment.
-
Rainbows
-
Vanishing America
-
Friends from Monaco
-
Cadillac
-
Old stamps
I concur; no short stopping the wire framing process!