Posted By Tench Forbes
October 27, 2013
Abstract:This post contains Q&A with Jim O'Neill, creative director of Above the Fold, which summarizes the discussions during his workshop on creating Practical Prototypes for software products. This workshop was held on October 11, 2013
Category: Planning, Analysis & Strategy
The October 2013 workshop continued the BPMA’s series on defining winning product development processes. Jim O’Neill, provided solutions for communicating product ideas effectively to a team of designers and developers through prototyping software tools. During this interactive session, Jim provided techniques for more quickly, easily and clearly communicate and collaborate visually with your team on product UI decisions.
Below, we review some of the questions that came from the audience and others about this topic:
1). Using prototypes to convey product ideas has been used for many different kinds of products for a long time. Why has "Practical” prototyping for websites and UI become such an important topic now?
In the software world, up until recently, the people who could build a quick prototype of a product were mostly the same people who could build the real thing – developers who have the programming chops to rapidly execute something that works. But in recent years, low-cost tools like Balsamiq Mockups have become widely available that make it extremely easy for anyone with very little technical expertise to mock up a few UI screens at low fidelity and link them together so they can be used in a realistic way. So essentially, it's never been easier for product managers – or anyone who works with developers and designers – to use prototyping in this way to communicate ideas quickly and accurately.
2). How do you decide what type of products should use "Practical Prototyping” versus other prototyping methods (eg. high fidelity), or no prototyping at all?
At Above the Fold, we're big fans of using whatever technique is right for the task at hand – using the minimum level of fidelity possible to clearly communicate the idea in a way that your recipient (client, team member, stakeholder) will understand. This is an idea from the "Lean UX" toolkit. So if you need to sell your board of directors on the vision of how a final product will look and feel, don't use Balsamiq – take some time to create high-fidelity eye candy. On the other hand, if you can effectively convey your point by scrawling on a whiteboard, do that instead.
Usually you hit the middle ground when you have a sequential interaction, involving several steps, which would be hard to convey via hand sketching – Balsamiq and similar software handles that type of task really well.
A good question to ask is, "Do I need to be able to quickly sit someone down in front of this thing and test how it works, without having to give them a lot of context?" If so, low-fidelity prototyping is probably a good answer.
3). What are some of the key mistakes or traps that people can make in this kind of prototyping?
Well, one common pitfall is to forget the "low-fidelity" part and get sucked into thinking too much about colors and visual styling. Finding the right balance can be tricky, but at the end of the day, there's a reason Balsamiq and its brethren force you to use chunky lines and Comic Sans – you should be focusing on layout and functionality, not colors and fonts.
The other quintessential problem, in my experience, is biting off more than you can chew. These prototyping tools work best when the scope is fairly small – a few interaction states with a few possible pathways through each one. Once you start wiring up prototypes with many divergent pathways and decision points, the complexity will quickly spiral out of control. We made that mistake on a client project once, when we really should have upgraded to a more robust tool like Axure, or used real code. We ended up with hundreds of Balsamiq files, and managing file naming conventions alone was a nightmare.
4). "Practical Prototyping” sounds intuitively as though it would be less expensive, but do you have an ROI model or template that could help "sell” this process?
Low-fi prototyping is an easy sell – as long as you're working with folks who appreciate the concept of validating an idea inexpensively before committing more resources to it. Before you spend lots of time & money designing or developing a feature, it pays to be able to answer the question "Is this feature usable?" or even "Is this idea worthwhile?"
What you're really doing is mitigating 2 big risks. On the one hand, if the way you communicate product ideas is too abstract – think written requirements docs, or purely verbal communication in meetings – you run the risk of building something that ends up not being what you wanted. On the other hand, if the way you communicate product ideas is overly specific – think high-fidelity visual mockups for every screen – you run the risk of burning through many person-hours of effort before discovering that your idea needs to be changed or scrapped. Low-fi prototyping allows you to navigate straight down the middle between these 2 risks.
5). You mention that interactivity is a key attribute of this process. How does Practical Prototyping encourage and/or improve interactivity with key stakeholders?
Anytime you have a tangible design artifact to look at and discuss, it improves the conversations with stakeholders many times over. In May of this year, C Todd Lombardo posted a sketchnote from a workshop with the design firm IDEO, which contained the quote, "A picture is worth 1,000 words, but a prototype is worth 1,000 meetings." And it's very true – being able to actually experience an interaction, evaluate it, and iterate rapidly is so much more effective than the drawn-out processes that many organizations are used to.
Low-fi prototypes are useful for quick usability tests, which we do a lot of at Above the Fold. We're fond of saying that there's no quicker way to get your executives excited about making product improvements than to have them watch a real user sit down with the product, try to use it, and fail. So from that perspective too, these prototypes are good for aligning the whole team, including high-level stakeholders, around what needs to be done.
6). You have used Balsamiq Mockups as your key prototyping tool. Do you recommend any other tools that would accomplish the same practical prototyping?
Balsamiq has a whole slew of similar competitors, some desktop-based and some web-based; the two that usually come to mind for me are Mockingbird, an ultra-slim web-based version of the idea, and UX Pin, also web-based, which folds their low-fi prototyping component into a whole suite of other UX tools and resources. In a pinch, you can even use PowerPoint to do the job, to some extent – it's a little more labor, but it is the native tongue of many organizations.
Two other great tools that I should mention are Axure, a more robust, professional-grade prototyping tool that's better at handling many complex interactions; and InVision, a web-based app that lets you link up clickable prototypes from JPG or PNG images – for those times when you need a Balsamiq-esque prototype but with high-fidelity visual designs instead of rough wireframes.
And finally, I encourage everyone not to be afraid of sketching by hand – it's not as daunting as many people seem to think. In fact, there's a whole method called "paper prototyping," which is similarly useful, great for collaborative sessions, and a lot of fun.