Web design projects are funny.  Especially when a lot of people are involved, a lot of time during a project often gets spent talking about what the thing you are trying to build will be.  We like to have meetings, conference calls, and send/receive seemingly countless emails.  We like to talk, and talk, and talk some more.  Why do we do this?  My guess is that it is all about fear.  Fear that we are building the wrong thing.  Fear that we will not get what we set out to when we started.  Fear that some detail will go horribly awry if it is not painstakingly discussed and managed.  The talking place in a project is safe, after all, and for some, the idea of dwelling in this space for as long as possible is seductive.

The problem with talking, though, is that talking is not building.  Plus, when you are just talking about a project you are living in a fantasy world, a world without restraints.  Anything is easy to talk about, no matter how hard it would actually be to build.  We can add all the features we can possibly imagine, talk about how great what we are going to build will be, and we can talk about how happy our end-users will be once they get to bask in the design-genius that is our group.

Now, I am not trying to say that all discussion about a project is bad, quite the contrary.  There is a place for academic/theoretical discussion with any project.  Often, in the laboratory of discussion, we can catch the big problems with what we are trying to do.  We can quickly gather a multitude of opinions, and achieve consensus on the big goals surrounding what we are trying to do.  Talking about a project is great, and quite necessary.  However, talking is not what gets the project built.

As I mention elsewhere on my site, I am amazed at how mature the web design and development tools we have today are.  Never before has it been easier, faster, or cheaper to build real-live digital products.

This ease extends to building prototypes too.  And because of how easy it is to build things now, it can often be incredibly valuable to get to the prototype process of a project sooner rather than later.

As a designer, I know my perspective on a project shifts when I actually have to build something that has to look/feel similar to the final product we are all aiming for.  Feature-sets and user stories are great, but it is something altogether different when you actually sit down and try to communicate features, function, and content on an actual page.

Actually building things is not an artificial world.  This is a world very much of restraints.  You have the restraints page size, you have the restraints of too much copy, and you have the most important restraint, user attention.  Attention is a currency you, as a designer, have to be very careful trading in.  Most attention you receive from a user will have to be earned, and it is your job as a designer to tell a compelling enough story to earn the attention of your users.  And, it is very hard to tell if the story you are trying to tell is compelling without a nearly-full representation on the screen.

Plus, if you are working with a large group, often people will react far differently when they actually see what the screens look like.  “Oh, I didn’t know it would be like that, can we do this instead?”  By getting to the prototype stage, you can gather feedback (both internally and with potential users) that is of a much higher quality than if you only have wireframes or storyboards.  The more you can take the reliance of imagination out of any process you are trying to get feedback on the better.

The most important thing any project can do is get to launch, and at least it has been my experience that having a healthy, active prototype process (a process that allows for quick and frequent iteration), can aide in achieving this in a way almost nothing else can.

 

Photo Credit: Kitestudio/Zazzle