Your 20 Minute Prototype

This post introduces the process of prototype in a practical fashion- so practical that with a little practice you can do a thoughtful prototype in 20 minutes. I recommend working out your Personas, Problem Scenarios and User Stories before diving into prototyping but there’s no single right approach.

We’ll cover:

1. When, why and how to prototype
2. Leveraging and matching best practice design patterns to your application
3. Creating a prototype with in a mockup environment

Here we go.

When, why, and how should I prototype?

Personas encapsulate your understanding of the customer, Problem Scenarios your opportunity, and User Stories how you’re going to deliver on the opportunities. If you have a handle on those, you have a solid idea of what you want to do and (more importantly) why. Now you need to figure out how to do it. If you’re (one of) the lead(s) on figuring all this out, it’s probably a good idea for you to participate in that process (vs. blindly delegate it to ‘the design people’ and/or the ‘developers’). Sketching out a prototype is a great way to show everyone what you had in mind so that you can have a productive, directed discussion about how to iterate on possible solutions.

You should err on the side of prototyping whenever you have a new product idea with a user experience component. Prototyping has a surprising power to help people understand what you mean, a power which is generally under exploited. It also shows people you’re serious and that you’ve really thought through your idea. If you’re short on designer time and/or pay for it by the hour, getting in the habit of early prototyping will keep you from throwing good money after bad/misaligned ideas. Best of all, it’s not that hard (really; truly).

Assuming you’re at the ideation stage, my advice is to keep your prototype simple. Over-attending to details will a) distract your audience b) likely waste your time because you’ll want to change things anyway and c) get you over-invested emotionally in your concept when you need to be most open to dramatic and fundamental change. Your ideation process around product UI should probably look something like this:

Please Note: This is distinct from your ideation around the business overall- chapters 1 & 2 of ‘Starting a Tech Business‘ are better resources for that. This is more of a Chapter 3, product design item.

For step 01, please see the related sections in the Venture Design Intro. We’ll cover 02 in the next section. Steps 03-04 depend a lot on your environment and available resources. It’s a great idea to draft up at least two approaches- if nothing else it will help get you thinking in terms of alternatives which is how things work in this area. On step 05, there are folks who will test paper prototypes or static mockup’s. I personally try to get to HTML/CSS/Javascript based mockup’s- stuff that works but isn’t necessarily talking to a real back end. For step 06, the basic idea is to prompt your users through stories using your prototype- given them a goal and see if they get there on your UI (or alternative UI’s). Then- pivot or persevere in Lean Startup style.

Before you dive into prototyping, I recommend poking around some existing design patterns. If you’re looking for inspiration, it’s a great place to start. If you’re full of ideas but want to make sure you have something that’s actionable by a developer, it’s helpful on that front as well.

Why should I look at existing design patterns and how do I do that?

There’s a kind of self-fake-out I get with some startup’s: ‘We’re going to do something disruptive so we need a disruptive design.’ Usually, you don’t. With a startup, you want to be innovative in your core area and stick to known best practices in every area. No difference with user experience (UX). Use existing design patterns as your starting point.

The table below describes some of the most popular:

PATTERN RESOURCE	NOTES
ui-patterns.com	This site’s great in that it offers lots of explanatory depth.
patternry.com/patterns	Another site with a lot of explanatory depth- good also as a tutorial in how to structure and execute against user goals.
web-patterns.net	Another good topical site with background explanation.
patterntap.com	Zurb, the company behind Foundation (a responsive front-end framework, kind of like Twitter bootstrap) maintains this site. You can search by functional pattern or just browse for inspiration.
mobile-patterns.com	While this site implements a different approach, it’s similar to the above but with a focus on mobile phones (surprise).
smileycat.com/design_elements	This site strikes a nice balance of structure and direct access to more tactical elements (like: ‘I think I want to do breadcrumbs- show me a bunch and then let me click over and see them in situ if I like them’.)

Many thanks to Laura Klein– I supplemented and validated this list based on a best-of list she presented at a Lean Startup meetup.

You may find yourself a little overwhelmed by this work of looking at existing patterns. Not to flow this, but I highly recommend working out a few user stories and then thinking about design approaches with those as the backdrop. This will also make your work more readily discussable with your collaborators.

Let’s say at this point you know what you want to do, why, and you even have some ideas on how to do it based on patterns you like. Now it’s time to build some prototypes!

How do you prototype?

First off, prototype with a purpose- have user stories and the personas to support them. Second, unless you’re sure you need a highly novel interface, color inside the lines and build on existing design patters (see above). The tool I based this example on, Balsamiq, does a good job of balancing the use of existing patterns with user freedom.

Your primary job is to show what you mean- we all underestimate the extent to which we really understand what we’re thinking and we all grossly overestimate the degree to which we’re understood by others. Prototyping helps us work through our faulty wiring. Beyond that, be an experimenter- don’t get too married to any one idea; think of the exercise as a creation and test of a set of alternatives.

Again, this example uses Balsamiq– but there are lot of great tools out there including a pencil and paper.

The basic steps are:

1. Place Page Elements/Controls
   Also a good place to look for existing patterns. Make a list- ‘I need a gallery, product purchase page’, etc. and look for existing patterns for inspiration.
2. Annotate with Notes
   Make sure it’s readable for others and linked to your user stories.
3. Make Interactive (for testing)
   If you want to use the wireframe for usability testing, you’ll also want to make it interactive, which you can do in Balsamiq.

The example we’ll walk through below supports the following epic user stories for a fictional company, Enable Quiz, that builds technical quizzes for staff and job candidate assessments:

‘As the HR manager, I want to create a screening quiz so that I can understand whether I want to send possible recruits to the functional manager.’

’As the HR manager, I want to try out the screening quiz so that I can make sure it works as I expected and that I’m ready to both give it to candidates and share the results with the functional manager.’

‘As the HR manager, I want to give the screening quiz to a job candidate so I can assess their skill sets against the needs of the position.’

‘As the HR manager, I want to share and explain the results of our screening with the functional manager so they can decide who they want to interview.’

Getting Started with Balsamiq and Placing Elements

This tutorial is based on Balsamiq. There are other choices and many of those are fine. I use Balsamiq because it strikes a nice balance between ‘coloring inside the lines’ with standard UI elements and creating something that looks like a sketch for discussion purposes (vs. a specification).

Balsamiq offers a local app for Mac & Windows as well as a Google Drive app- both have free trials. In most the examples below, I’ve used the Google App, though the experience is pretty continuous between the two.

The screenshot below shows a fresh screen with one navigation element in it. The tabs at the top organize different types of elements you may want to use. To use one of the elements, you just drag it to the screen area, which is what I’ve done with the element ‘Vertical Tabs. A single click on the element will show you its properties, shown below:

Two clicks allows you to edit the item’s text, show here:

The annotations are available under the tab ‘Markup’. You’ll notice the items ‘Links’ in the properties box above- that allows you to link to other Balsamiq files/screens (only one page/screen per file with Balsamiq).

Using the Sample Balsamiq File

Here is a link to a sample file:

BALSAMIQ SAMPLE FILE

If you’re using the desktop version you can click on the top menu and download the file and you’re off to the races.

If you’re using the Google App’s version (which I mostly use now), the process is a little awkward: Download the file and then upload it to your Google Doc’s. Then you can open it normally. There may be a better way, but in the time I had to test and fiddle, I didn’t find it.

Making Interactive Prototypes

In this example below, I have four mockups. The button navigation (for example where you see ‘Results) links to one of the other mockup’s when the file is in ‘interactive’ mode. You’re just creating a set of static links between items. In the example below, I’ve clicked on the ‘Results’ button and in the right panel selected the ‘Results Screen’ mockup in the menu called Link (you can’t see it because it’s covered by the drop-down in the example below).

This link won’t work until you’re in ‘presentation mode’, which you can do by clicking in the grey button in the upper right. Another options is to go to the ‘Project’ menu and select ‘export to PDF’. In the PDF, your links will work as well (and you can email it, etc.).

Once you have something you think is ready, go into presentation mode button and you can see your links work. In the sample above, the buttons ‘Change Layout’ and ‘Preview’ buttons work. The breadcrumb navigation that reads ‘Quizzes > Software Engineer: Web Apps’ goes back to the ‘Base’ mockup (home).

Happy trails! If you want to take 30 minutes to establish your prototyping skills but don’t have something immediately in mind, you might do a mockup of an existing application. It’s a very valid way to think through the endeavor of prototyping.

Note on Using in Testing

If you’re going to use the native Balsamiq facility (vs. export to PDF), make sure to turn off ‘Link Hints’ and ‘Big Arrow Cursor’ (see below). These are good for showing a collaborator what they can do with a prototype, but are leading if you’re assessing usability in a usability test. In the current version, you can reach these parameters through the gear icon in the upper right:

Note on Prototyping for Mobile

I haven’t recently played with Balsamiq mockup’s on a mobile, either via Google Drive or a PDF. Last year, I had a student team in my Software Design class who found that on the iPhone they needed to use a 3rd party PDF reader for the links to work.

If you find you’re having trouble getting that to work well, Flinto has a nice service for building interactive prototypes from image files. In that case you’d export your images as PNG files from Balsamiq and link them and present them in Flinto.

Talk Back

I’d love to know about your prototyping experience, particularly if it’s your first one. Just like everyone I else, I learn by working with great people. Here are a few specific points you might hit if you’re interested in responding:

• What did you want to prototype? Why?
• How did it go? How long did it take you? What took the most time- using the app., figuring out what you really want to sketch, making notes, packaging it up?
• What happened afterwards? How did you use the prototype? Who did you show it to? What did they think?
• Are you going to do it again? Do something different? Why?

If you’d like to respond on Twitter, I’m @cowanSF and the applicable tweet is here.

If you’d prefer email, drop me a line at acowan@alexandercowan.com.

You can also comment directly with Disqus (below).

Example A: HVAC in a Hurry Example

Intro

HVAC in a Hurry (HinH) is a fictional company I use in various examples here and on my Coursera course on agile. HVAC stands for ‘heating, ventilation, and air conditioning’ and the company services this type of equipment for businesses. The software team is currently focused on standardizing and automating their business process with software. Most of the ‘action’ in the business deals with the relationship between a customer who needs something done, the dispatch office which takes the calls and prepares a technician, and the technician who does the work on site.

User Stories

One area they’ve decided to focus on is the process by which the technician (we’ll call him ‘Ted’) finds out about getting replacement parts for HVAC equipment where he’s found that’s necessary. An epic user story for this might be:

‘As Ted the HVAC technician, I want to identify a part that needs replacing so I can decide my next steps.’

Here’s a storyboard that describes the epic:

The child stories under this epic might be something like:

STORY	TEST CASES
I know the part number and I want to find it on the system so I can figure out next steps on the repair.	Make sure it’s possible to search by part number. Make sure descriptive info. appears as the search narrows (photo?) to help avoid error.
I don’t know the part number and I want to try to identify it online so I can move the job forward.	Make sure it’s possible to search by make/model of units Make sure it’s possible to search by type
I want to see the cost of the part and time to receive it so I decide on next steps and get agreement from the customer.	Make sure it’s possible to dispatch a request by email to the customer in case they order their own parts and/or carry their own inventory of spares. NOTE: How would the customer respond so we can help structure the next steps as we would otherwise?

UI Comparables

Once the team has stories they feel are clear and investable, they should be asking themselves ‘What established interface pattern that our users knows will map most naturally to these narratives?’. Answering this question requires exploration and disciplined experimentation.

The team comes up with the following four ideas on functionally comparable areas:

1. Online Shopping: This has the comparability of searching and selecting items based on both relatively general and relatively specific criteria.
2. Used Car Purchases: This is somewhat similar to the above, but has more structure/similarity between items, which we think may be more comparable to HVAC parts searches.
3. Photo Search: The team knows that all the searches have a visual component- even if the tech knows the part number, they want to (or should) validate the part visually against what they have in hand.
4. General Record Search (CRM, Email): This might be interesting since it’s very robust relative to searching lots of records.

They question they’re trying to answer is: What patterns and comparable’s are applicable to our user stories?

Starting with area #1 (online shopping) they study major online shopping destination, looking at common patterns to determine what users are likely to expect:

A few things they notice across sites and which you can observe, for example, in the Amazon screen shot is the ability to see and modify the search while you’re looking at a list and the default of sorting items by popularity:

In fact, they observe many of those same patterns but with more structure/similarity in the used car shopping examples you see below. From this, they get a few ideas about how to tighten up their search ideas since HVAC parts will have much greater consistency than the breadth of items in a general purpose online retailer.

Now, the team wants to execute at least two distinct directions so now they move to area #3, photo search. Just to draw attention to the contrast with the used car search, they search for cars (Ford Focus) on these photo sites:

Parallel Prototypes

At this point, the team feels like they good breadth so they start sketching ideas. At this point, the question they’re asking relative to the user stories above is: What concepts might provide the right signifiers and experience to the user?

Their first direction ‘concept 1’ is focuses on structured search and the kind of list views you might see in online shopping. The Balsamiq mockup’s below show a progression from initial search, to a list of results, to a detail view of a specific item:

The second concept, ‘concept 2’ focuses on a more visual approach:

The team might detail more concepts- two is a reasonable start but three to four is also typical. From there, they might dot vote on ideas and pick a couple to make interactive (see above) and then put through user testing to compare their effectiveness at delivering on the current user stories.

For static mockup’s of the two concepts, see this Balsamiq file: Parallel Prototyping at HinH.

For an interactive mockup of ‘concept 1’ from the work above, see: Interactive Prototype for HinH.