Minimize Risk: Rapid Prototyping to Maximize Learning

Wireframes and spec docs don’t tell a story.

Static wireframes or spec docs don’t do a good job of capturing a customer story, whether that’s illustrating a pain point to Product or showing a customer what the company has in the pipeline. That’s why I usually make clickable prototypes with Keynote to show customers new designs we’re thinking about (without any actual development time) or help my team understand usability problems customers are having.

For the most part, clickable Keynote prototypes work for me. But recently I’ve been experimenting with coding up simple prototypes using Twitter Bootstrap 3 and Zurb Foundation 5. Both of these responsive frameworks allow you to build beautiful full-fledged websites that many businesses use. But I’ve been learning how to use them to tell stories. Here’s why.

Kickoff with spec docs and product theses. Use prototypes as you progress.

Spec docs and product theses are a result of user research, customer feedback, sales data, and support cases. While these are great guiding documents for early validation, I think what separates a good experience and a great experience is iteration — minimizing the risk you have by building something and fine-tuning it. The problem is I think teams rely too much on spec docs and product theses to solve new issues that crop up during the product development process.

Docs and product theses should be used to kickoff projects, but as the teams build and receive feedback on the product, these docs and theses should be replaced with clear customer feedback and prototypes that help illustrate what the final product could look like.

By prototyping, you use production-ready code to run through the gauntlet with people to see if what you’re building makes sense at all. A lot can go wrong from translating spec docs to usable product.

Why Foundation and not Bootstrap

Both frameworks are great. But I found Foundation to be more style-agnostic, which in my opinion is better because you can de-emphasize styling and focus on functionality and flow when you’re talking to people. For me as a researcher, this is great because there are less distractions when people are commenting on interactions or

If you already have a working basis for brand identity and design style guides, Bootstrap will work great if you can integrate your CSS files to pull your appropriate existing styles.

Foundation provides handy HTML prototypes that mimic websites or apps that you could be trying to validate. There a bunch of components that come with it and even more you can find.

A prototype is a pretty broad term, but any prototype will help you identify problems before you decide to build something potentially stupid and useless.

What I could build in 3 hours

I wouldn’t call myself a front-end engineer or a UX designer. I have some HTML and CSS familiarity, and that’s about it. I decided to see how easy it could be for me to prototype something.

I wanted something simple to try out without worrying about the visual design or interactions, but still get the point across of what users should be able to do.

Squarespace Homepage

Squarespace’s homepage is pretty minimal. It’s composed of:

• background image taking up the whole page with carousels
• a top menu with the logo, tour, login, and menu
• headline
• sub-headline with CTA
• Link to watch video ad in lower right corner

The only tricky thing I thought would be to really do is the menu since it flies out.

Since this was going to be a prototype, I decided that I would not really focus on the visual/interaction elements like getting the carousel to work or getting a video to show when you clicked the button. I wanted to see if I could layout something similar and effectively communicate the Squarespace experience in a short amount of time.

Here’s what I was able to do in 3 hours from not knowing how to use Foundation at all (and also a very basic understanding of HTML and CSS):

I don’t think it’s too bad for what I could do. There are some CSS styling issues like top bar not being transparent with the background image and the sub-headline styling, but I think it conveys the basic function of the site.

Twitter Homepage

Twitter’s homepage is pretty simple as well. I decided to take a stab at it after Squarespace after feeling more comfortable with Foundation.

The Twitter homepage has:

• Top bar with Twitter logo and language drop down menu
• Headline
• Subheadline
• Rotating tweet and background images
• Two forms within their own areas
• Footer with links

I decided that laying out the elements without visual design would be a good attempt. It doesn’t touch on the visual or interaction design like my Squarespace prototype, but communicates what the page is trying to do.

Here’s what I was able to do in 2.5 hours:

My prototype doesn’t include the rotating background, but has the essential elements for sign up.

Here’s the real and the prototype side by side:

Prototyping with code also lets me realistically see what this looks like on any screen type. And if you use Foundation or Bootstrap, you’ll be able to just change your window size to see what that looks like.

Here’s the Twitter homepage on a medium/tablet screen with the real and prototype versions:

As you can see, my CSS isn’t perfect. This prototype isn’t perfect, either. The logo and language drop-down isn’t aligned when I resize my screen and the footer starts getting mis-aligned. However, I think this is a pretty good representation of what a prototype could be without me being fluent in HTML and CSS.

If I prototyped something like this for KISSmetrics, I think this would definitely work as a starting point for testing with people or for our design team to consider tweaks. Research gets to go test this out in the field. Engineering gets to check whether or not this code would work with our current framework. Design gets to tweak visuals and think about interactions. Every team is able to validate and minimize risk while collectively we all get to learn from customer feedback on whether this makes sense or not.

Should Research Include Prototyping?

I’m not sure if I (as the researcher) should be doing the prototyping yet, but from my short weekend learning how-to I think it’s definitely do-able. Here’s what I learned:

1. Spend Just Enough Time Prototyping

Limit sketches to half and hour or an hour to figure out a few pages and flows. Forget pixel-perfect mocks at this point for your idea. If you’re going to do a Keynote prototype, spend no more than 1–3 hours building it. Coded prototypes like this one using Foundation should be limited to 1–2 days. I was able to build a pretty accurate homepage in a couple of hours. A basic website or app with a few pages could reasonable take 1–2 days.

These time constraints are important because you want to learn as much as you can in the shortest amount of time. If you end up taking a whole week to prototype, you’ve already lost your momentum and the whole point of prototyping. Learn more and iterate fast.

2. Get Feedback

Prototypes are for testing. They are a medium for getting feedback. Go use prototypes (whether they are hotspotted-up in Keynote/Flinto/Invision/etc. or coded) to figure out if your concept makes sense, if your flows help users towards their goal, and if any interactions you have at this point are well-received.

3. Iterate and Make More Prototypes

Did you get good feedback? Build on that and figure out more concepts now that you know have something going. Build out some visual elements with your design team.

Prototype had a bunch of problems? Make some changes based on what people said and go back to same customers to see if you’ve solved their problem.

By doing this prototype-feedback-iterate or build-learn-build loop, you’ll be able to progressively know whether you’re building something that’s good versus something that’s great. I’m going to try building out more prototypes in Foundation into my process to see what works. Has anyone bothered coding out prototypes early on in the process or are they built only after Keynote prototypes? Does the research team handle this or does design handle research prototypes instead? Let me know.