If you decide to build something as a part of your project, you might want to consider building a prototype. The software engineering module defines a prototype as ‘a simplified software system that is a subset of the eventual product’. In fact, a common aim of a project is to create a prototype.
This blog summarises different approaches to prototyping. If you use prototyping within your project, make sure you’re able to justify which approach you adopt and why within your project report.
It is also important to make sure that the different elements of your project are aligned together. If you choose prototyping, you should choose a project model that works with prototyping. The interaction design project model is one that emphases the building of prototyping, but you can also embed the building of prototypes within other iterative approaches to project management. You also need to consider any risks, any skills you need to develop, and any resources that you may need to apply.
Approaches to prototyping
There are two broad approaches: you can build a prototype which you later throw away; your whole object will be to learn something. Alternatively, you can build a prototype with the aim of incrementally refining it into a potentially usable product.
Through the process of prototyping, you can learn about requirements your product will need. You can do this by asking potential users (or stakeholders) what they think about what you have built. This is the process of evaluation. You should be able to learn new things with every new version of prototype you create.
Types of prototyping
There are two main types of prototyping: horizontal prototyping and vertical prototyping.
A horizontal prototype is a prototype that appears to show all the main functionality of a product, but not in a lot of depth. A horizontal prototype is all about breadth. It allows whoever is evaluating your prototype to get a feel for what a product does or looks like, but it might not work in any meaningful way.
A vertical prototype is a prototype that focuses on depth. It aims to only present a small amount of functionality in a detailed way suggests how a product may operate. In some cases, a vertical prototype may be implemented using software code. A vertical prototype is likely to focus on the essence of what a product does. Users of a vertical prototype will be able get a feel for how a product is likely to work.
Prototyping approaches
Broadly speaking, there are two prototyping approaches: low fidelity and high fidelity.
Low fidelity prototyping is prototyping where the design of a prototype may not directly or substantially resemble the final product. A low fidelity prototype is one that is likely to be thrown away. It is typically used to find out something about the problem. It may reflect an initial design that is to be refined further when it has been evaluated. A low fidelity prototype might not do much, or it might simulate the beginnings of potential interactions.
High fidelity prototypes, on the other hand, go some way to solving the problem. They might be interactive, or they might be a proof of concept demonstrators that has been created using a technology that is different to the technology used in the final version of the software product.
Low fidelity prototyping
Paper prototypes
When you think about paper prototyping, think about pens, paper, scissors and Sellotape.
Paper prototypes should be messy. Messiness is a virtue for a simple reason: they are easy to change. They can be put together quickly. If a design or an idea doesn’t work, they can be thrown away quickly.
If you have spent hours creating a detailed interface design that looks beautiful, your refined design will be harder to change, and throwing it away will become difficult. It is easier to change and to disregard something that appears to have little value. The value with paper prototyping as an approach lies with its scrappiness.
The interaction design text by Preece et al. show different types of sketches that can be considered, in one way or another, a paper prototype:
Storyboards: a simple sketch of the environment in which a product is used, which can be divided into cells, which show a sequence of interactions. The emphasis is on the ‘sketchiness’ of the sketch. Users or stakeholders can be represented using stick figures. The interactions that are depicted has value; the quality of the sketching does not.
Card-based prototypes: a set of options or choices that are made available to the user, shared on a card. A sequence of cards are used to get an understanding of the interactions that are embodied within the product.
Interface sketches: a sketch of a screen or a display. This might include labels or icons, as well as buttons and product logos. Everything is very sketchy. You might create a number of different versions, and carry out an evaluation to choose which of the interfaces is best. Evaluation will be discussed later.
Wireframing
Although paper prototyping has obvious and clear advantages due to its low cost and high speed, senior managers may become confused with the appearance and suggested chaos of a scrappy sketched out design. A middle way between a paper prototype and a high fidelity prototype lies with the creation of wireframes which can be created using dedicated wireframing software, or by creating simple mock-ups using tools that you are familiar with.
One approach to wireframing is to create a series of simple and unrefined HTML pages. Only front-end pages need be created, which can be linked together to suggest an interaction or a connection between different pages.
There are lots of wireframing tools to choose from. Three notable products are:
If you do choose a wireframing product, you need to explain why you have done so, and also explain what you hope to gain from applying it. You should also list it as a resource and say something about your skills.
PowerPoint
Sometimes tools can be used in combination with each other.
PowerPoint is, of course, a popular presentation tool. PowerPoint files can be read and opened by most devices. Rather than showing actual paper prototypes to potential users, you could instead take photographs of your paper prototypes and create a PowerPoint presentation with them. The advantage of doing this is that you could then create sequences of interactions. If you are skilled and confident PowerPoint user, you can also have users jump to slides which show alternative interactions.
You can also use PowerPoint to show a series of wireframes that have been created using wireframing tools, especially if your chosen tool doesn’t have the ability to share a series of interactions.
Wizard of Oz
Creating computer code is expensive. It can take a lot of time. If you want to see whether an idea works or makes sense, one approach is to ‘simulate’ the computer using a variation of the Wizard of Oz experiment.
Imagine you have a paper prototype. On its own, it doesn’t do anything. During an evaluation, you might ask a user the question ‘what are you going to press?’ When they have pointed to a bit of an interface sketch, you could replace one paper prototype ‘screen’ with another, fulfilling the action as if all your bits of paper was a working product. You become the computer, or the product that is to be designed.
High fidelity prototyping
Returning to our earlier definition of a prototype, ‘a simplified software system that is a subset of the eventual product’, a high fidelity prototype might be a bit of a bigger product, but the most important characteristic is does something. Your product might partially solve a problem. Relating back to earlier terms, your high fidelity prototype might be a horizonal prototype or a vertical prototype. Really good projects tend to be vertical prototypes, for the reason that they can demonstrate depth of skill and knowledge.
Physical prototyping
Some projects combine physical design and software design. This may be especially the case for students who may have studied a combination of design and computing. Physical prototyping (in the sense that it is considered here) can be considered to be analogous to paper prototyping. Creative mock artefacts can be created to embody some of the key ideas within a project.
The notion of physical prototyping has been discussed in an earlier blog, TM356 Prototyping Hackathon. Just as elements of paper can be Sellotaped together for a paper based prototypes, physical items can be glued or tied together for a physical prototype. Physical prototyping can add a second meaning to the notion of a card based prototype. A ‘low fidelity’ physical prototype isn’t going to realise any functionality; it is more about expressing and understanding ideas.
Evaluating prototypes
There are different ways to evaluate a prototype.
If you have access to users, you could do some usability testing. If you do this, do consider preparing some useful resources, such as a project information sheet to tell the participant what it is all about, a consent form, a script (to make sure that everyone is asked the same thing), a set of tasks, and a data collection form.
If you don’t have access to participants who are likely to be the intended users, you can always use what are known as ‘proxy users’. These will be participants who pretend to be the users. You might ask friends and family members, for instance.
If you don’t have access to anyone you can ask, it is possible to carry out your own critical evaluations. You could do this by applying techniques such as heuristic evaluations or cognitive walkthroughs. For further information about these approaches, do refer to the interaction design textbook which is mentioned in the resources section.
Resources
Requirements are important in all software projects. How you approach requirements will depend on the aims and objectives of your project. One of the strengths of prototyping is that it can help you to uncover requirements for what you need to build to solve your problem. The blog TM470 requirements revisited also offers some useful guidance. An important point is that how you treat your requirements will very much depend on the character of the problem that you are trying to solve.
An important recommendation is to look to the modules you have previously studied. Prototyping of interface designs is covered in some depth in the school’s interaction design module. The module also makes use of the following set text, which is especially helpful:
Sharp, H., Rogers, Y. and Preece, J. (2023) Interaction design : beyond human-computer interaction. 6th edition. Milton: Wiley. Available at: https://library-search.open.ac.uk/permalink/44OPN_INST/la9sg5/alma9953131933002316
This text also contains a lot of really helpful references, many of which you can find through the OU library.
You might also look to the web technologies module if you wish to create a simple HTML prototype.
Reflections
The project module is all about showing off skills and knowledge gained from earlier studies. Creating a series of prototypes is a really effective way to do this. The best projects that use prototypes show how product designs or software solutions are refined and developed over a series of iterations. Don’t dismiss low fidelity techniques, such as paper prototyping because they may appear to be unprofessional. It isn’t what they look like, it is what they can do.
One of the points I share is: do consider using some of the tools that are highlighted in the interaction design book. There are a lot of useful tools that could be used in addition to prototyping, such as scenarios, personas and use cases. The DECIDE framework is particularly helpful when it comes to making decisions about how to plan and run evaluations. I encourage students to apply tools in a critical way that makes sense in the context of their project.