Prototyping 101: Basic Steps Towards Effective Prototyping

Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.

Hi there,

Something that I wanted to write about since a while now is a sort of introduction into the process of prototyping. A couple of weeks ago I wrote an article about the reasons for which you should be prototyping. And since that article proved to be a popular one, it’s only natural for me to continue with some basic steps on how to get started with prototyping.

The basic and fundamental reason behind prototyping is communication and getting to an agreement over a to-be-built software application or website. The effectiveness of a prototype is measured by how many of your client expectations are fulfilled. First of all you need to know what your client wants and needs. So, first things first…

Plan Your Prototype

Depending on the complexity of your project and team, you might do this yourself or together with some other members of your team, like project managers or business analysts. Gather as much information as possible and as needed before diving into prototyping. Build feature lists, do site-maps, sketch if you like (and you should like that! ). Draw user work-flows and see how complicate they get. There are many factors that will influence the structure and the content of your prototype.

plan

For instance, a complex website with complex workflows will require a complex navigation system. You’ll have to choose from the existing set of navigation patterns (top or side navigation, drop-downs, bread-crumbs etc.) or come up with new ideas. This will affect either the invested time or the structure of your prototype pages or both.

It’s important to get a good feeling and image of the desired result and start to have at least a couple of alternatives in mind for the most sensitive features. There are several ways to do the same thing and it’s essential to investigate as many as possible alternative paths before sticking with one of them. This means that your hydrodynamics should be pretty high in the particular problem your software is trying to solve.

Sketch and Draft

Prototyping is in many ways similar to programming. It has to be interactive, thoughtful and well structured. And while is not actually coding (if you’re not doing coded prototypes), it is nevertheless more expensive than whiteboard or paper sketches, for instance. That’s why prototyping is not always the first stage in product design process. There are other less expensive ways to start visualizing things before actual prototyping.

sketch

Paper sketches are, for instance, a great way to clear your mind and to focus on the big picture. I personally find it to be very effective for me to take my notebook and then step away from the computer to take notes or draw something, either in another room or even outside. I am lucky to live just across a little park, full of noisy kids. So when I take my kid there in the afternoon, I almost always take a pen and a notebook with me.

Whenever attacking a new subject, I always find it better to first visualize the boundaries of the problem on the table. Either when it was a college exam or, later, a big development task, I always felt more comfortable by knowing upfront how far I need to go before diving into the details of a very specific subject. Even if only superficially, being aware of the existence of a particular item will most certainly make you take better decisions and be more efficient.

So be sure to make one or two drafts first. Give your prototype a first consistent shape and get feedback. Or even if you don’t go the client to ask for feedback with your drafts, you will at least be facing something that is starting to resemble the final product and is already posing some problems: “Will this login box actually fit there?” or “Aren’t there two many links in this navigation side-bar?”. This type of questions arise fast when prototyping, while they may not necessarily be that obvious while sketching.

Dive Into The Details

When time comes, you need to get you yourself wet and step into more and more corners of your prototype. Depending on the time-frame and initially established purpose of your prototype, the level of detail will differ. Nevertheless, make sure that you identify and address those sensitive aspects that have the most weight in your prototype. Navigation, the above mentioned example, is something that significantly influence the structure of the prototype.

wet feet

Be sure you are conscious of how much you are hiding behind generic text as “Lorem ipsum”. While generic elements are good from keeping your audience focused on what you want them to focus on, be aware that there’s also a danger that you are not offering them a chance to tell you something important (which eventually come later on, or when it’s actually too late tone taken into account), or to offer precious feedback.

And remember that details are not necessarily only visual. The entire apparatus behind a label or a number you put on a page may heavily influence important planning decisions. Small details like the number of similar products on a product page, or the number of comments of a user etc. have their development cost. So if you are filling space with such details and product management decides to take them out, you’ll have to be prepared and find ways to maintain the consistency of your prototype and its sense of completeness without those elements. The bigger the changes, the better you’ll have to adapt and come up with new solutions and reconfigure portions or entire pages.

Limit Yourself

Prototyping should be fast and cheap. A great way to maintain momentum in a project is by doing things at a constant and fast iterative pace. Prototyping is not, by any means, an exception. Spending too much time by yourself prototyping, decoupled from the rest of the team will only increase chances that the project will slightly go off track. Especially when someone else is waiting for you to deliver, the client or the stakeholders or the development team. Think carefully about how much you really need to put in a prototype. Half done parts will raise lots of questions. Be prepared to answer them or simply take out that part until you’ll be ready to provide answers.

limit

Improvise and be as flexible as needed to achieve the desired results faster. Even if not everything is fully functional, most of the time is just O.K. Just do the bare minimum required by your audience (some types of audiences will need more than others, that’s true!). Remember that most of the time, prototypes are throw away artifacts. In the rare cases when you’ll do coded prototypes you might just reuse some of the code, but even then the code will quickly evolve and change. And in the end this is not the point of a prototype, to produce production quality code. It’s just a proof of concept and should be threated and priced as one. You will not ask lots of money for a prototype so don’t spend lots of time building it. Be pragmatic.

Should you identify other important aspects of the prototyping process or have things to share with us, please be sure to leave a comment and let us know!

Thank you!

Share and Enjoy: