Consider Rapid Prototyping for Your Next Software Project
Fail Early: Save Time and Money
If you’ve ever had a project fail, you may be wondering what you can do to avoid wasting time and money in the future. Guided by one governing principal – Fail early. – rapid prototyping is a way of designing new software or new features for existing software cheaply and iteratively, testing your work with users as you go. You don’t have to gamble your limited assets on building something you don’t know will work. Rapid prototyping prevents you from wasting your money building something nobody wants or needs.
Rapid prototyping is the process of understanding a domain, defining the problem you aim to solve, then trying many potential solutions as quickly as possible before finally deciding on a solution to invest your limited time and energy in building. By working iteratively on a design using inexpensive design methods and frequent user testing, rapid prototyping reduces the risk of your project’s failure. You validate the usefulness and usability of your product as it evolves and adjust your assumptions along the way.
Signs you should invest in rapid prototyping:
- You want to identify the optimal use of a limited budget.
- You want to be able to change direction quickly. Since rapid prototyping uses cheap design methods at the start, starting over from square one is not an expensive proposition when you learn something isn’t working.
- You want an innovative solution to a known problem. Sometimes there are several existing solutions to a problem, but none of them are particularly elegant. Working in phases can quickly identify new ways of thinking about old problems.
- You want to streamline a critical workflow (like buying a product) to optimize conversion rates or make a repetitive task easier or more pleasant to use. By testing several variations of a product purchase form, for example, you can identify points in a process where potential customers give up and streamline those points.
Preparing for the prototyping process
Prepare: Become fluent in the problem’s context
In order to provide meaningful solutions to the problem at hand, everyone involved must learn as much as possible about the context in which the problem exists. In the user experience design world, this is known as the deep dive. If you’re designing a solution for a client, read as much about their business as possible; talk to experts; spend time with existing users. Become fluent in the language surrounding the problem at hand.
Keep shared knowledge in collaborative documents where everyone on the team can view and edit. Centralizing information provides the team with a single source of truth, or a single point of reference that officially describes what the team knows. This helps onboard new players quickly and keeps everyone on the same page. Here are a few ideas for living documents you might produce:
- Glossary: a great way to make sure everyone on the project is on the same page about important terms and ideas.
- Reading material compilation: helps keep track of key insights learned from various media sources. Digest and outline important details to explain details to other members of the team. Keep a link to the source for easy reference later.
- S.W.O.T. analysis: In a two-by-two grid, enumerate your team’s Strengths and assets, Weaknesses and deficits, external Opportunities to exploit, and outside Threats that could derail the project. Cross-reference facts in these cells to systematically generate insights.
- Competitor analysis: identify competing products. Analyze the software from the perspective of usefulness, usability, and pleasantness. Make note of things the software does well and what it does poorly. Take screenshots of important interfaces, mark them up and annotate the details. If you have just a little time, analyze 3–5 to start. But there’s no upper limit. Keep adding to the document as you encounter more competitors.
Prepare: Define problems as clearly as possible
Sometimes, problems are obvious and don’t need much or any testing. Sometimes they’re complex and systematic and require multiple attempts at a solution. Do whatever you can to identify the problems you want to solve in as simple language as possible. Expect your understanding of these problems to change and grow throughout the project. More problems will be discovered later. Priorities may change. Roll with the punches.
If you have the time, observe people interacting with similar products to learn what problems they encounter and any workarounds they have found for those problems. Job shadowing is a great way to encounter common workflow problems in the wild. Workarounds are especially useful as they can identify tedious tasks, unintentionally clever solutions, and missing functionality.
Prepare: Define the project scope
Before you begin working on the solution, reach an understanding between all stakeholders about how you will be spending your time, how you will define project completion, and how the scope will change in response to new insights and changing priorities. Depending on your stakeholders’ needs, this agreement may or may not include specific features. Either way, explain that rapid prototyping requires some degree of flexibility. Prioritizing some problems or features over others may mean that less important features are simplified or dropped from the project. Transparency is a critical part of maintaining trust between all stakeholders.
A great starting point for defining project scope is to collaborate with stakeholders on an exhaustive feature backlog. Create a shared document that organizes every conceivable feature that might be a useful part of the product. This isn’t a realistic outline of the product’s future, but rather a living document that ensures everyone’s ideas are heard and recorded. Trello is a great way to sort and organize these features. Or even bullet points in a Google Doc may be enough. Modify and amend this throughout the product definition process to keep everyone on the same page about what comes first.
A feature backlog is one of the first things we created for a client wanting management software for their line of mass notification alarm units. At the start of the project, we spent a couple days immersing ourselves in the domain of centralized alarm control systems: reading articles about the flexibility requirements of large campuses, watching tutorial videos for similar software, and learning about the technology used in the field. From this research, we compiled an exhaustive list of potential features, working with the client to fill in gaps and cross off items that didn’t reflect their vision for the product. Sorting this list from most to least important gave us a prioritized plan of attack.
Due to project constraints, we ended up choosing just a few features to prototype for a tablet device, but the prototype was enough for our client to take to a trade show and gauge interest. The feature backlog was very useful not only in defining the project’s priorities, but also in helping our client to envision what the product could become.
A Prototyping Process
No two problems are the same in terms of complexity. So no two processes should be the same. Use your best judgement to decide what methods are going to be valuable for your project’s unique needs. Here is one possible process for a moderately complex problem.
Prototype: Find potential solutions by sketching and wireframing
The purpose of sketching and wireframing is to find testable solutions before investing time and money in a fully-fledged prototype.
The fastest and cheapest way to try ideas is with pen and paper. This is great for thinking about solutions and as points of reference while you discuss ideas with your team. However, sketches may not be detailed enough to learn anything from testing them with users. You can produce a lot of sketches very quickly and narrow down to a few that you want to explore in higher detail.
Wireframes are higher quality sketches usually produced on the computer. They’re ugly, but tidy representations of the high-level structure of one or more screens in a product or service. Wireframes can be black or blue outlines with text in Comic Sans, or they can be grayscale and Helvetica. The important part is to reach a level of detail that is good enough to communicate your solution. Do what works for you, just don’t spend too much time making it look pretty. No sense in polishing a design solution that you aren’t sure is appropriate.
Test your wireframe by walking potential users through important tasks. Repeat the wireframing process until you have found one or more solutions you are confident in. Don’t be afraid to scrap all or parts of the wireframe if user testing shows it doesn’t work. You didn’t spend a lot of time on it after all.
The specifics of user testing are beyond the scope of this blog post, but here are some things to keep in mind:
- Observe users in a natural setting. Sterile rooms tend to make users uncomfortable and cause them to behave unnaturally. Meet them in a coffee shop, or in their usual workplace. Keep it casual and explain that there are no wrong answers.
- Focus on tasks. Instruct users to complete certain tasks. If a user can successfully and comfortably complete that task in a reasonable amount of time, move on.
- Focus on the obvious: you can only address so many problems in the time you have to produce the next prototype. If you can pick three obvious problems to address in the next round, that’s better than a thousand minor glitches.
- Ask users what they are thinking. If a user is stuck or looks like they are in thought, ask them what they’re thinking. This is a great way to keep users thinking aloud.
- It doesn’t have to be scientific. If you have a limited amount of time to spend on user testing, a few successful sit-downs with users trying out your wireframes and prototypes is better than nothing.
Prototype: Plan the solution with a prototype
Once you are confident that a wireframe solves your problem, you are ready to plan every detail of the interface by making a prototype. A prototype is not a fully-functional product. It’s a quick and dirty facsimile of the final product with just the parts necessary to confirm that there are no major gaps in task workflows. However, it’s important to capture the look and feel of the final product, from aesthetic design details to interaction patterns.
If the important tasks are primarily navigating between pages and doesn’t involve a lot of moving parts, a hotspot mockup may be enough. InVision is a great, easy way to communicate the movement from page to page using flat images and clickable areas that link between pages. You can even annotate specific areas on the design and other collaborators can reply to your comments in context.
Hotspot mockups are a great way to communicate navigation on content-based websites and web apps with simple workflows. I have seen firsthand how hotspot prototypes reduce the amount of back-and-forth communication. Our clients can tell how their websites will work since they can navigate the website naturally, instead of interpreting a folder full of screenshots.
If the core feature of the solution is highly interactive or data-driven, it may be appropriate to involve developers in creating a quick and dirty code-based solution. The whole prototype doesn’t have to be code based. You might choose a couple tricky interfaces to make in code. Involving developers can be risky as development takes drastically longer than you expect. Have your developers work quick and dirty, and be prepared to scrap all the code and start from scratch when you begin creating the real thing.
Choose the right level of detail for your prototype.
Rapid prototyping is a better bet
Rapid prototyping is a more fun, interactive, and transparent way of collaborating with your software team and your potential users. How users react to your prototype may prove to you that you shouldn’t invest more money in it. Or it may prove that it’s a silver bullet. Or it could reveal a better problem to invest in halfway through the project. Flexibility and continual discovery are rapid prototyping’s greatest strengths.