I recently read a book about prototyping. While it was an interesting read, I am still unable to somehow really understand what the sense of a prototype is or what to prototype for.

For example I have to build a page where the target audience is between 45-60 years old.

Should I know have to find members of the target audience and make some usability tests using a prototype? (seems rather pointless to me). Or should I build the basic page structure as prototype, click through it and look out for something missing in the "experience"?

What information can a prototype give me that I can't know by common sense or through reading studies?

  • Try doing it and you will see how much you learn which is common sense, but you just didn't think about it before you sat down to actually build the prototype.
    – Rumi P.
    Oct 31, 2013 at 10:23

6 Answers 6


In an ideal world, there is an inverse relationship between the amount of time/effort you spend in developing and visualizing an idea versus what stage in the development process you are in. In other words, early on in the process you want to be able to very quickly iterate over a large number of ideas. So the idea is to spend not very much time and only capture visually the important parts. Prototyping is a way to do that.

In more business terms, it is a tool for risk mitigation to help make sure you are actually building the right thing before wasting lots of money. In the traditional waterfall development process the product is never tested/evaluated until development is done (this is simplistic but roughly accurate). It's not unheard of for developers to spend months or years on implementing something based on poor user requirements only to find out it wasn't the thing that was actually needed/wanted by users.

What is important to capture? At CHI 2010 I attended a great course given by Jonathan Arnowitz and Dirk Jan Hoets called Developing an Effective Prototyping Strategy. They talked about a matrix of fidelity in your prototyping - that is, if you want to quickly convey visual design ideas then your prototypes might be non-functional but very visually polished. But if you want to convey interactive ideas then you might do wireframe-level visual fidelity but go deeply into the mocked-up interactions.

I apologize, the link they gave three years ago appears to be dead. Here is a link to a similar book by Arnowitz: http://www.amazon.com/Effective-Prototyping-Software-Interactive-Technologies/dp/0120885689

Sorry I didn't answer your whole question. Given your target user group I would say it's probably a good idea to get prototypes of varying fidelity in front of at least a handful of potential users. Both interactive as well as visual fidelity should be tested, since users in those age bands may have issues with fine motor control and/or degrading vision.


Prototyping is a communication tool between your idea and reality. In fact, you should start to interview with your target group to understand the needs and even try to understand whether they are going to use an internet page for their needs.

A good prototype;

  • Make easier to understand the real needs of your target group rather than listening a dictation.
  • Give you a better ground that you can show some evidence that which way you should follow.
  • Make you realize new points and problems that may occur and reduce general "experience".
  • Help you to communicate well with other stakeholders of the whole project.
  • Make it easier to divide task into iterations.
  • Errors can be detected much earlier.
  • Fast feedback cycle compared to real product development

If somebody is repeating a general signing and registration flow again and again in his/her prototypes, what he is doing is not a prototyping. Testing standards will not bring you that much added value.

Prototyping is only activity that you should continue from exploring, synthesizing till the end product. It should generally start with a pen and paper, to the polished end product. Even you reached the final product, it will be still a prototype to make your service/product complete in the next version.

Architectures will make a scaled mock-up for their project. Product designers will use a 3D printer to see how it ll look and validate their cad drawings.Service designers will create diagrams to check the overall flow. They are all different forms of prototyping from different domains.


Common sense "ain't all that common" and general studies and reports are just that...general.

Both are valuable, of course, but testing your specific solution with your specific audience is going to return data that you will not get any other way.

As to how you define what a prototype is, there is no specific definition. It might be sketches on paper (paper prototyping). It may be working code (Agile development). Or anything in between.


You build prototypes for the same reason you sketch, wireframe, etc.: to learn about the problem your solving. The best way to get to understand a problem is to try and solve it. Therefore, your first try at solving any problem will fail or at least be less than optimal. Prototypes allow you to fail a few times before committing resources to a final solution.

If you're honest and critical about your own work you don't need to test prototypes against target groups. However, seeing someone actually use any product will reveal a wealth of interaction you could not have concieved (or read about). Again: prototypes allow you to have a go at a solution, fail, and improve.

To further answer your title question: you need to prototype whatever it is you need to learn more about. And you need to prototype it in a way that will help you in that aspect. What is your hypothesis? If your hypothesis is that there's probably "something missing", build for that. There is no guidance here except your own.


Using prototypes is important because you are creating a customized experience customized for a specific group of people - and not all groups behave the same. Until you actually test and get feedback, you are running on assumptions and stereotypes. Also, your target audience may not be as computer savvy as you are, so your "common sense" may be something that is unheard of for a majority of the users on your site. For example, 25-30 somethings would already have a sort visual vocabulary built around online interactions like dropdown navs and minimize buttons. A grandma who lives in a rural area and has little experience with the internet? Not so much.


There are some good answers here, but I'd like to add that the more complex your project is, the more important it is to prototype. Something simple, say a single web page with minimal interaction, can be designed completely without needing a prototype. More complex software can't be designed completely because there are too many unforeseen issues that are only discovered by running and interacting with the software. So a prototype version of the software enables one to discover these unforeseen issues before a more refined and expensive version of the software is built.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.