As the UX Clinic team, we ran a workshop on Rapid Paper Prototyping during, our annual SummerTalks. We were quite surprised as to how much this technique could help developers to create a better user experience.
Here’s what we learned.
Four Easy Steps
We planned a Rapid Paper Prototyping (RPP) workshop in four stages,
We let the participants do semi structured interviews so they could start the process by listening! The lesson here is to be empathetic with whomever you’re questioning. Instead of an interrogation, we want a conversation.
Each team had a discussion around what was the real problem to solve. Sometimes we think we know how to solve a problem, yet we don’t know what’s behind it. We end up making assumptions, but that is not enough.
Each team chose which situation they would focus on. Then they started the prototyping process using only paper and ink to create a functional test scheme for potential users.
A usability testing session was held with potential users. We encouraged the teams to ask users why they viewed things as they did while interacting with the paper prototype.
This was the sole most valuable part of the workshop.
Talking to users is no easy feat, and, as our participants learned, it’s about letting them lead the show. The designers’ job is to take their feedback to validate whatever they were testing.
For this workshop, we didn’t build a full-featured demo, yet we identified which improvements were the most urgent. Each team presented their results so we could all learn about the real problem, how users responded, and what their final conclusions were.
During the four-hour event we worked with multidisciplinary teams, mostly composed of developers. The design team was surprised to find that developers were great at prototyping too. Everybody had something to teach us.
Here are a few takeaways from the workshop.
Head First into The Workshop
Some of the developers were skeptic about the effectiveness of this method. They were reluctant to accept that something this low-cost could bring about high quality results.
To convince them we used an analogy,
Imagine that instead of developing an app, you were building a house.
Right away, you hire an architect to draw the plans.
That won’t work!
The first step should be to understand the mindset of the people who are going to live in it. You would ask them all sorts of questions to discover their expectations. As a nice side-effect, this would create trust between you and them that will come in very handy later in the process when things go bump in the night.
Only then, you could start laying out the plans.
The same goes for a software product. Understanding your target audience is key.
Boulevard of Broken Paper Dreams
During the workshop users crushed the developers’ mockups.
They got really tired and frustrated with the number of fields they had to fill in. The developers realized that they were asking for too much before users got anything back.
Avoid Offending Your Users
One user even got offended by the UI.
The developers had chosen to indicate progress with smiley faces. They never thought that users might perceive this as offensive, particularly when their weight is far from ideal. This became the subject of a heated discussion, to put it mildly.
In the end, this team switched to using a timeline to indicate progress towards a weight goal.
The smileys were out!
Some teams struggled more than others. In the end many ended up with really cool ideas and even screenshots on how they wanted their product to look.
But before investing in the final product, they had to build a prototype.
These are some of the available tools,
Listen, Listen, Listen
Your team must first get input from your potential users. RPP is a great methodology for this, but there are many more.