a blog on prototyping by pidoco°

This is the first of several blog posts on application prototyping. The series is aimed at prototyping beginners that wish to get a quick start into the field and gain a better understanding of what they should be paying attention to when prototyping.

 

What is prototyping?

Prototyping is a well-established product design and development method used in various fields from mechanical engineering to software development. Prototyping involves creating partial realizations of a planned product that are used to gain early insight into technical feasibility, user needs, and market preferences, by soliciting feedback from various stakeholders, such as end users, developers, engineers, marketers, and domain experts. The ultimate goal is to minimize risks arising from areas like implementation, production, market acceptance or even customer support by spotting potential problems early on.

Aside from reducing project risk due to their early availability, common additional advantages of working with prototypes include:

Iterative refinement: Since prototypes are often comparatively inexpensive to produce (they can omit certain functions or details or make use of cheap materials), you can create and compare several possible design variants or do multiple design rounds in order to refine the product design step by step with intermittent user feedback.

Time-to-market: One of the key challenges of software development is “getting it right”. Some of the most time-consuming activities occur at the end of the implementation stage and involve the correction of mistakes that occurred because of incomplete or unclear specifications. The more feedback and testing occurs during the design process, the more specification-solution gaps are discovered and filled, helping cut rework time.

Cost savings: Design faults that are caught at an early stage in the design process are usually much cheaper to correct. In software development, the difference between concept and implementation stage may constitute a factor 100 in cost.

Quality improvement: Multiple rounds of evaluation using prototypes can lead to dramatic improvements in product quality, which in turn may have a serious impact on support costs (e.g. fewer calls to the support desk) and market success (more customer acceptance).

Ownership: Prototyping allows users and other stakeholders to participate in the product design process, thus creating emotional attachment and goodwill towards the final product.

In this and the following posts, we will focus on prototyping of software applications, more specifically on UI prototypes, i.e. partial realizations of the user interface of a software application, such as a website or a mobile app. UI prototypes are usually concerned with the user experience (UX) in general or the conversion in specific, i.e. how efficient a website or app is at leading users to taking a desired action, such as purchasing a product or registering a user account.

Prototyping is a key element to the success of the well-accepted iterative development process and usually consists of creating and evaluating several iterations of successively refined prototypes that evolve based on new insights gained along the way.

 

Take, for example, a new mobile medication reminder app for senior citizens. Key features might include an automatic reminder when pills need to be taken as well as adding a new medication to the schedule by simply taking a picture of the packaging and setting the frequency and/or time. Leaving aside all technical and financial risks (e.g. can we build a system that will be able to identify a medication based on a simple picture taken, within our target budget?), you might start with just a simple sketch on paper, show it to lead users from the intended target audience to see if they understand the app and can easily use it (i.e. whether the product is “usable”), then work the feedback into the next version and test again. For this next round, you might already move on to a digital representation with some more details using a prototyping tool. In later versions, you might add more detailed visual design elements to test user preferences and assess whether potential buyers would actually be willing to pay for your app.

Prototyping isn’t a rigid process, though. It must be tailored to the specific needs of the project at hand. In the next sections, we’ll explain how.

 

How to use prototypes?

There are various prototyping techniques for different purposes and different stages of the design process, each offering their own advantages and each with certain limitations. Prototyping is done in a certain project context and is usually a trade-off with other tasks in terms of time and money spent. You should decide on a case-by-case basis how much effort you want to spend on prototyping in order to ensure that your prototyping activities will yield an overall benefit. In general, you should spend as much time as necessary, but as little as possible. If the overall project risk is small, prototyping should not eat up a lot of your budget. If, on the contrary, there are lots of uncertainties in your project, you should plan on prototyping more.

The following two parameters can be adjusted in each prototype to make the best use of available resources such as time an money:

Scope: Prototypes only represent a certain part of the product. In software development we can distinguish between horizontal prototypes that comprise several or all features at the same architectural level (such as UI prototypes) and vertical prototypes that consist of a fully functional implementation of only one single feature including the UI, logic and data levels. In addition, prototypes can of course selectively focus on only a certain subset of all features that pose a design challenge and omitting those that are obvious.

Fidelity: Prototypes usually use a certain amount of abstraction to guide attention to the most important aspects of a design problem. This means that prototypes usually omit certain details. Especially in the early stages of product design prototypes are often less detailed (low fidelity or low-fi), focusing on the overall concept or on specific risk factors. For example, an early-stage prototype of a mobile app may entirely abstract from visual design (e.g. colors, fonts) and focus solely on the layout of each screen. Abstraction often helps understand issues better since the amount of information that needs to be processed is lower. Of course, abstraction may also lead to an incomplete understanding of an issue or over-simplify a complex problem, so it is sometimes necessary to use very detailed prototypes (high fidelity or hi-fi). There are several dimensions of fidelity, including among others visual details (black/white vs. grey scale vs. color) or responsiveness (interactive vs. static) or data type (lorem ipsum text vs. dummy data vs. real sample data).

Interactivity: Prototypes can be static representations that merely give a visual impression of the user interface or allow the viewer to interact with them to get a sense of the look and feel. Interactions can range from simple clicks or taps that bring up the next screen (much like a slide presentation) to sophisticated simulations of system behavior that distinguish between various triggers (e.g. swipe gesture vs. double tap) and are able to precisely show how the future product would react to them (e.g. transitioning to the next screen by fading the old one out). This can be important when running user tests to identify potential usability issues.

Material & Tools: Finally, prototypes can be produced in a variety of ways. The biggest difference is between so-called paper prototypes, which are more or less sophisticated visual representations drawn on sheets of paper and possibly cut out to obtain tangible “interactive” elements, and digital prototypes that can be used on a computer or handheld device and as such are much closer to the final product. Digital prototypes can be created using anything from a design tool to specialized prototyping tools or can be directly coded or even done in a presentation tool like Powerpoint. This last parameter is primarily a question of preference or contextual restrictions (what tools do I have available, which tools am I comfortable with, are my testers onsite or do I need to “send” the prototype) and will not concern us further.

When you are working on an entirely new app, you may want to think about the general user flow and look at the bigger picture at first. In this case your scope should be relatively large, perhaps covering the most important user stories, but you will probably get away with omitting certain details at the screen level (low fidelity) and not worry about your prototype being interactive. In fact, these details may be entirely inconsequential at this stage. If, on the other hand, you are trying to work out how a certain feature should work at the interaction level, a single screen or two with lots of details and exact simulation of system behavior might be what you need, so your scope should be extremely focused while you will be working towards a higher level of fidelity and interactivity.

Of course, each parameter has a scale and depending on how these parameters are set, we can distinguish different types of prototypes:

Sketches (hand-drawn, low-fi, static): Sketches (also sometime referred to as “scribbles”) are very early, rough (low-fidelity), hand-drawn static representations of a future product. Usually, they are preliminary outputs to a first concept and used for ideation rather than actual feedback. While we list them here for completeness, we would argue that they are not really prototypes, since they are too far from being a “partial implementation”. Sketches can, however, be the basis for paper prototypes.

Paper prototypes (analog, low-fi, static to semi-interactive): Paper prototypes are easy to create and don’t require any specialized tools. Paper, pencils, scissors and some tape or glue are usually sufficient. They are also very flexible and can quickly be redesigned on the fly, even during a user test or workshop. On the other hand, they can only offer a very limited idea of the interactive behavior of a product (e.g. menus can be simulated by rolling out a folded strip of paper with the menu items written on it by hand) and cannot be easily modified, i.e. changes require creating a new prototype (or part of it). Usually they are hand-drawn and low-fidelity, unless printed designs are used as basis.

Wireframes (digital, low-fi, static): Wireframes are relatively easy to create, but do not include any visual design (low-fi). They are static representations of the product that focus on the layout of each screen and how the screens relate to each other. Wireframes are usually created using a graphics/drawing tool or specialized wireframe tools like Pidoco that are often more efficient or easy to use and allow for easy adaptation of the wireframes to changing requirements and user feedback.

Interaction/UX prototype (digital, low-fi to medium-fi, interactive): Interaction or UX prototypes simulate the human-computer interaction, i.e. how the application reacts to user inputs. They are interactive digital representations of the product and as such usually require more effort and time than, for example, simple wireframes, even though they usually do not include full visual design. Specialized tools are recommended, although sometimes readily available office software can do an ok job.

Design comp/mockup (digital, hi-fi, static): Mockups are static representations with near-finished visual design, but without interactivity. They are typically relatively time-consuming to create and require specialized graphics tools, which is why they tend to be used towards later phases in the design process when basics like structure and layout of the application have been sorted out.

Hi-fi prototype (digital, hi-fi, interactive): Hi-fi prototypes combine advanced visual design with simulated or even implemented human-computer interaction. Due to the high level of detail they are very time-consuming to create, but may evolve from earlier prototypes by linking up existing mockups or adding visual details to interaction prototypes. Hi-fi prototypes require specialized tools or can be implemented programmatically using HTML or other programming languages if such skills are present within the design team.

 

When to use which type of prototype?

Here are some common scenarios where prototypes can be helpful and some recommendations on how to get the most out of them.

Internal communication within the design/development team (exploration)

How can a prototype help?

Capturing an idea – especially an innovative one – in words, so that others can easily understand it, is often very difficult. Words evoke associations and it is likely that ten listeners will form ten different thoughts in their head. A visual representation in the form of a prototype helps manifest the idea and prevent misunderstandings in the early design phases. In addition, prototypes are “tangible” design artifacts that allow for a hands-on experience long before the final product becomes available for testing. Finally, they also help document progress and foster better discussions, since laymen can easily join the discussion, even if they don’t understand the design lingo or have no tech background.

What should the prototype look like?

The focus here is on exploring the design space, discussing ideas, coming up with – often innovative – solutions to key design problems, and expanding the solution space with controversial or unconventional approaches. Since these internal discussions occur among people familiar with both the general subject matter and design process as well as the specific project, prototypes can be less detailed. This means, you can work with a lower level of fidelity, working with placeholders instead of real images and copy, or omitting, for example design elements like branding or even color altogether. You should focus on core design issues and avoid wasting time on obvious parts of the design. By setting the right scope for the prototype, you can not only save time, but also focus the discussion on certain topics while steering clear of things you currently do not want to speak about. Interactivity can plan a role at this point, but often static or simple “clickthrough” wireframes will do the job.

 

What to watch out for?

It is easy to get carried away with your idea, especially when the prototype allows you to quickly make headway. But the entire idea of a prototype is that it can still change according to feedback (or even be scrapped entirely). So, don’t get too attached to your initial prototypes – they will change! Attachment may easily lead to improper decision-making. As a hint, try to keep it simple in the beginning: don’t spent too much time, don’t go into detail, use low-fidelity prototypes. And be open for honest feedback. It (almost) always makes your product (and your team) better.

Fidelity: Low – medium

Scope: Focused

Interactivity: Not a must

 

External feedback, e.g. usability testing (evaluation)

How can a prototype help?

Prototypes are concrete representations of the future product, which can help gather more reliable feedback from real users. Seeing a prototype and/or interacting with it gives a potential user much more context than just an oral or written description. In particular, a prototype helps validate or invalidate implicit assumptions the test subject may have about the final product.

What should the prototype look like?

The goal of gathering external feedback is to detect usability problems or to answer a specific question (e.g. “which navigation option works better?”), sometimes openly, sometimes implicitly through observation of users completing assigned tasks. Therefore your prototype should be optimized to answer that question. Depending on how familiar your test subjects are with product design, how much opportunity there is for explanations (are you doing a moderated or unmoderated test?), and what your test goal is, your prototypes should be self-explanatory and detailed enough for the evaluating person to understand them. Include as much detail (fidelity) and interactivity as necessary, but keep it as focused as possible. E.g. if you are trying to get feedback on the user flow of an app (scope), don’t bother with minutiae of the individual screens and keep the interactivity simple. If you are trying to figure out the best way to design a specific feature, don’t bother with unrelated features, but do take time to model the details of specific interactions if they matter. In general, if you are testing design variants, only vary one variable at a time – otherwise you will not be able to gauge accurately, which variation caused the difference in results. On the other hand, include all options (affordances) that may distract or mislead the user, if you are testing your design for usability issues. If your question depends on the visual design (e.g. color codes or button contrast), include visual details. If branding (e.g. logos, brand colors, specific UI elements) is critical, include it; if your question is independent of branding, leave it out to save time. In general, for a real usability test, we recommend starting with a simple low-fidelity interaction prototype and adding visual fidelity to the extent required.

Prototypes for user tests should be optimized to answer the specific research question at hand.

 

What to watch out for?

Prototypes are not the final product and hence require the recipient to use some level of abstraction. If possible, give the test subjects some background as to what the goal of the prototype is, e.g. are you looking for feedback on layout, conceptual questions, the user flow, a comparative rating of different solutions to a design problem, or the visual design of the product. Also, tell them the limitations of the prototype so they know what to expect. Prototypes are great for focusing on certain aspects of the product design, but if you don’t tell the testers what feedback you are looking for, you risk getting the wrong kind of feedback – or flat-out rejection. In general, focus on a small number of questions or tasks. (Find more information on user testing here.)

Fidelity: Medium – high

Scope: Depends on question at hand

Interactivity: Simple – Detailed (depending on test case)

 

Requirements engineering (specification)

How can a prototype help?

Enriching a specification with visuals helps keep risks and overhead at bay. A written specification can never be complete (at least, it would have to be excessively long) and therefore often forces developers to make assumptions or guess the intention of the author, leading to potential missteps, or ask lots of questions, which takes time. A picture, on the other hand, as the saying goes is worth a thousand words, due to its richness of information. Therefore it can convey lots of information in a very concise manner.

What should the prototype look like?

The goal of a prototype used for specification purposes is to give the developer(s) a detailed picture of what they need to produce. Prototypes should be complete, but there is usually no need for a finished design, as this is typically provided separately by the designer. In particular, the prototype should contain all details necessary for implementation, such as the layout of the screen (where possible with exact dimensions), any graphics inputs (such as logos, image files, etc.), links between screens, as well as behavior of the system following any possible user input. If interactions play an important role and are not obvious from the UI or contextual information, you should include them in the prototype. No specification will ever be complete, but you should try to minimize the amount of potential questions the developers will need to ask or guesses they will need to make during implementation. Your scope should be complete, but do not waste time prototyping screens that are basically copies of others; rather include references to other screens, which will also help the developers discover patterns and make their life easier. Remember, that the prototype will usually be accompanied by a written requirements document as well as a set of visual designs that will complement the specification, but check to make sure what information you need to provide in the prototype. A low-fidelity prototype may be entirely sufficient if visual design assets are delivered separately and referenced correctly in the prototype. Often, it is helpful to annotate the prototype to add information that is not readily visible, especially if you are sharing only screenshots of the prototype instead of the interactive prototype itself.

 

What to watch out for?

Don’t try to put everything into the prototype when you don’t need to. For example, don’t include visual design, if you know that there will be separate design files delivered. Rather, reference the files if you already know their names. All else would be a waste of your time.

Fidelity: Low – medium

Scope: Complete (but avoid redundancies)

Interactivity: Detailed (unless obvious from context)

 

Selling your ideas to decision-makers (presentation)

How can a prototype help?

Designing a great product is a real challenge. Convincing someone to buy a new product or sign off on a new idea can be just as hard. Prototypes can help you impress decision-makers because they basically allow you to travel in time to a point where the final product is already available, giving your audience a much better understanding of the full potential of your idea or product.

What should the prototype look like?

The goal here is to convince people to take an action. Either you need approval to move on to the next step in the design process or you want a client to give you the go on your design idea, or you may want to get a customer to make a purchase decision. Usually, decision-makers are busy and therefore impatient people. They may not have a lot of time to waste on understanding the goals and/or limitations of your prototype or abstract from the visual representation. Therefore your prototypes should be more visually refined (medium to high fidelity) and give a good representation of the final look and feel, i.e. include enough detail in the interactions to make them feel realistic. Since in a presentation setting (unlike in a user test), you tend to be in full control of the situation and therefore can tailor the scope of your prototype to the specific scenarios you want to highlight or show off. Make use of this advantage in order to spend your time most effectively and avoid wasting time on parts that nobody will ever look at.

 

What to watch out for?

Hi-fidelity prototypes may lead inexperienced viewers to assume that the product is almost finished and that it can be delivered soon or without much additional cost. Make sure not to raise unwarranted expectations. Explain that this is still a prototype and which steps are still required to leverage the full potential you have been showing off with the prototype.

Fidelity: Medium – high

Scope: Focused

Interactivity: Detailed

 

Summing it up

In this first of four posts, we took a look at what prototyping is, how it can be useful in various stages of the design process, and how to decide what your prototype should look like during certain project phases and to achieve certain goals.

In our next post we will be looking at how to turn paper prototypes into digital assets and use them for further research. So check back soon.

 

This blog series on prototyping was created in cooperation with Prof. Dr. Birgit Bomsdorf, University of Applied Sciences in Fulda, and is based on experiences gained from various prototyping projects as well as from lecturing and researching in the field of Human-Computer Interaction. It is a work in progress and we will keep updating and adding things. If you are missing something, have questions or want to share a different opinion, feel free to leave a comment.