Integrating Agile and UX Design with Justinmind prototyping tool
Find out how rapid prototyping with Justinmind can help engage stakeholders, improve your UX Design and boost your Agile workflow
This month, Justinmind’s Product Development VP, Victor Conesa has kicked off a brand-new series of Meetups on UX and prototyping. In the first of the series, UX and Rapid Prototyping Expert from Systems Evolution, Inc., Tim Gagnon spoke about how prototyping can improve requirements definition, engage stakeholders and align everyone’s vision around the product.
Tim’s talk provides an in-depth look at prototyping in Agile, covering the rapid prototyping process, capturing and measuring its benefits, the levels of prototyping fidelity, as well as an Agile prototyping case study that used Justinmind and some important lessons learned.
So, what is a prototype?
As Tim has it, a prototype is a clickable mockup of the user interface (UI), usually created without coding. For those who are involved in the software development life cycle (SDLC), prototyping is a fast, flexible, portable and accessible way to capture requirements and present them visually to the rest of the team.
Download Justinmind now to align UX and Agile, fast
Why should you use prototypes?
“Prototyping enables teams to experience solutions much earlier in the software development life cycle.”
Tim talks about the strategic advantages of prototyping in that initial ‘Ah-Ha’ moment of any software project. The ‘Ah-Ha’ moment is that moment of realization when your software solution to your stakeholders’ problem becomes apparent.
Unfortunately, product teams often reach the ‘Ah-Ha’ moment far too late in a software project — sometimes as late as the testing or deployment stage. This opens the project and team up to copious amounts of rework, wasted resources and room for error.
By introducing prototyping into the SDLC, teams can reduce the risks of these roadblocks occurring. Why? Because with prototyping, if the ‘Ah-Ha’ moment is going to happen, it’s going to happen much earlier on, in the initiation or design phases of the project. This allows teams to experience solutions and clean up potential solutions much earlier in the SDLC so that they can focus on a strategy that benefits not only the business and user-sides, but also improves team workflows.
Prototyping is also used in sales and new product design to gather investment and more forward with development more smoothly. Apart from improving product teams’ workflows, prototyping can:
- enhance requirements and design artifacts
- align vision
- engage stakeholders
- decrease rework
- speed up time to delivery
What kind of prototype should you build?
This is a great talk on how prototyping should be integrated into the SDLC. Tim goes into depth about the different variations of prototypes — scenarios and low to high-fidelity prototypes -available and which should be used when.
- Scenarios — high level user tasks and how users will interact with the UI. They define the cognitive walk through of how users will complete a task and are the first step to building a great user experience. There are typically more iterations at this stage than later during the mid to high-fidelity stages.
For example, say a user wants to buy a product online. First, they will log into their account. Next, they will view a list of products, select what they want and add to cart. Then, they will reach the payment area and finally shipping.
- Low-fidelity prototypes — these map scenarios into a light-weight UI without exact data or design. The basic navigation is usually defined at this stage.
- Mid-fidelity prototypes — these build out the data elements and information architecture as well as finalize the navigation flow. The viewer should get a gain a good understanding of the look and feel of the final UI from these, as well as the user experience.
- High-fidelity prototypes — these are almost indistinguishable from the final website or application. The final design elements are in place and the prototype is clickable (functional) because interaction has been added. If done right, there shouldn’t be too many changes between the mid and high-fidelity models as errors will have been captured and corrected in the low-fi stage.
To go high-fidelity or not?
In Tim’s case, he only really uses hi-fi prototypes when he needs to convey precisely-detailed UIs, such as for product demos or user training manuals. His advice, and Justinmind’s, is to stop when the work is good enough. Don’t waste your effort on unnecessary UX design work when other product teams need to weigh in, i.e. developers. At the end of the day, it comes down to your team’s resources and the expectations of your stakeholders.
Measuring the impact of prototyping in the software development life cycle
Capturing the benefits of prototyping can be challenging. One way to do so would be do a project twice-over, one with and another without a prototype and measure the differences in quality and effort. But, as Tim jokes, no one in their right mind would double their efforts just to measure that!
Two helpful metrics for measuring the impact of prototyping are velocity: comparing the speed at which you can define your software with a prototype compared to with other methods, and by the sizing of requirements.
The benefits of prototyping in Agile
Tim then introduces the topic of Agile, and the idea of learning whilst defining software.
Agile in software works by creating user stories that make up the product backlog of tasks for each project phase, or sprint. By adding prototyping into the mix, Agile becomes even more effective, Scenarios contribute to the user stories in the sprint planning phase, low-fi prototypes can be used to test those scenarios prior to sprint kick-off, and mid to high-fidelity prototypes are then built out during sprint execution.
Lessons learned: prototyping for innovation
Tim ends his talk with a real-world example of how prototyping can reduce the need for rework in software development. A client of his was doing Agile, but wasn’t prototyping. Their question to Tim was, ‘if we’re already doing Agile, do we need to use a prototype?’ Tim’s answer? Absolutely.
The client was experiencing a lot of rework. Their ‘Ah-Ha’ moment was actually happening during the sprint demo, way after their product had been defined. This resulted in a backlog freeze, with many backlog items being fed back into the backlog — stagnant. After observing a few of these demos, Tim suggested they try introducing Justinmind into the project. He started rapid prototyping the new solutions and was able to unclog the backlog. The end result? Stakeholder alignment, clearer product vision, and less rework.
Read more on backlog grooming with Justinmind’s Victor Conesa here.
Look out for out next monthly meet-up on November 16th.
So what have we learned from Tim’s talk? Prototyping accelerates time to delivery, helps you avoid rework, and gets things right the first time. So can you afford not to have it in your software development life cycle? Download Justinmind now and prove us wrong ;)
