Defining and Developing a Web Prototype Design: Part 1

I’ve had a few calls recently from bloggers and writers with requests to clearly define web prototype design. Broadly speaking, all product prototypes are living versions of the idea you have in your head. These tangible prototypes need not be perfect but should provide enough detail to be able to adequately test the idea.

Web prototyping or rapid web prototyping, as it’s sometimes called, is the process by which a web-based model of the end product is constructed for the purpose of outlining how a website or web application will look and behave. In the world of web prototypes, the process of developing a prototype might be more important than the end product.

The web prototype, whether it’s on a whiteboard, paper, and online is a test site that will include some content, all primary navigation, and possibly images and key functional elements.

What a web prototype is not

In our experience, we don’t think of a web application prototype as just a mini-site. If it’s a moneymaking application then it’s essential that the prototype be close enough to the end product that your business and revenue model assumptions can be tested. A few scraps of paper and some wireframes do not constitute a prototype. These things are however essential to the planning and development process.

How to plan your prototype

Even if you’re not particularly good at drawing the best place to start is with pen and paper. Sketch out the basic elements starting with the user experience in mind. Use basic usability questions to direct your thinking. What will the user see first? How will they know what we do? Where should we direct their attention? How will they register? There is a lot of debate about using personas or use cases to define the initial designs. Although in some complex applications we develop use cases we generally find there is only one primary persona for each successful design. If you have too many personas or use cases you either need additional applications or you need to get some focus.

At this early stage less is more – only focus on the essentials. Do not be tempted to fill in all the gaps and fill up space on the home or landing pages you are sketching. That level of detail will come later. Drawing out the site pages helps everyone involved to visualize what you are doing. Getting everyone on the same page, literally, is critical to understanding where the design will succeed and where it needs more help. In 90% of our designs, the first sketches happen on the whiteboard and are then transferred in more detail to paper or wireframes online.

Who should be involved in the prototype?

If you’re doing this for yourself then you may only need to include your business partner/s and a competent web designer. If you’re a design firm the client’s core team and your core design team will be involved. Ideally, you want the prototyping team to be as small as possible. Inviting more people doesn’t invite better input.

Once you have your prototype sketched out get feedback and sign-off so you don’t end up going in circles. This can be difficult if the client needs additional team members involved to get approvals. Try educating your clients that this process is not to secure approval on the aesthetics or functional elements but rather on the layout and navigation of the future site or app.

From sketch to actual web design

Although it can be useful to start testing your sketched designs with real users at this point we don’t recommend it. In the 200+ projects, we have done using prototyping we have found it’s faster to get a more coherent design together before starting the testing. User testing is not expensive if you adopt the methodologies set out by Steve Krug so it shouldn’t matter either way.

To achieve the speed of execution our clients expect we move directly from sketches to Photoshop mock-ups. The client reviews these mock-ups and any changes required are made immediately. Because we publish the designs to the web via Basecamp, we find progress is only limited by the speed at which we can get feedback. In some cases, we’ll move from sketches to HTML/CSS immediately so we can make updates even faster. This can only be achieved if you have signoff on a template or you are working on an existing design template that doesn’t need to be updated.