Prototyping on Paper
The concept of a prototype and its use is something most understand. Much of that is due to prototype’s permeating their way through all walks of life. If you’re writing something, building something, etc… they’ll always be an early version that won’t see the light of day. Knowing that, how can a prototype be maximized for both usefulness and efficiency.
Low-Fidelity vs High-Fidelity
Most know a prototype is a rough draft in general, which makes the separation between low and high fidelity prototypes a little strange. Some may feel making it high-fidelity is a waste of time and presents difficulties when trying to redesign. Others may think a low-fidelity prototype doesn’t allow you to see the real issues with a design. So what’s the answer? Well...
Prototyping at the wrong fidelity is one of the top prototyping mistakes. Unfortunately, there isn’t a one-size-fits-all solution. Instead, you should evaluate it based on each individual scenario. For speed and flexibility, low-fidelity prototypes may be best. If you’re already working off customer feedback and want to gather more data on specific areas, you may choose high-fidelity prototypes. The most important thing to remember: Just like you’d never listen to the same rock ‘n’ roll song for every occasion, you shouldn’t default to the same level of fidelity when prototyping.
Despite both being prototyping methods, high and low-fidelity versions serve completely different purposes. If you’re building an app from the ground app, with little competitor’s to base the design off of, you’ll probably need to make a low-fidelity version to get a better grasp on the general layout. If you’re redesigning a well-known app such as Spotify, you may want to go right to a high-fidelity version to see how the more minute user experience issues are addressed. Every design is different, so understanding what needs to be the area of focus early and designing your prototype around those needs will make it far more useful in terms of enhancing your end design.
Prototyping Methods
Continuing on with my project of creating a companion app for the town of Doylestown, I made a low-fidelity prototype of what the app may look like. I choose low-fidelity, as there’s no app to base the design off of. Town apps are also not very popular, so there wasn’t a clear competitor to draw inspiration from.
Using a pen and ruler, I sketched out 30+ different screens for this app prototype
In terms of how the prototype was designed, I decided between a few options. Typically, I would create the prototype using an app like InVision. However, while that can be efficient, I felt like it will still drag a little for how many brand new screens I would have to create. To address that, I actually choose to make a paper prototype instead. Compared to a digital program, paper has some clear advantages, as described by Justin Mifsud of Usability Geek
User involvement at an early stage Cost-effective Encourages creativity No design or coding skills needed Rapid evaluation and testing Endorsed by several usability professionals
Despite an increasingly digital age, paper prototypes are still used today, with reasons above being why. Even if everybody can get used to an app such as InVision or Figma, EVERYBODY can draw. The drawings don’t have to be perfect, as they’re simply quick sketches that can help present the idea of the app. It should be legible though, as well as have a clear flow from one screen to another
Destination Doylestown
With my method now clear, I started making my paper prototype. Realistically, these drawings should be done on grid paper, allowing more precise measurements. I didn’t have grid paper available unfortunately, so I lined them up as close I could using a straight edge.
How one of the screens looks when cut out and placed in a sample phone holder
As I found in my research, these apps should be relatively simple, as visiting/new residents will be a large part of the audience, as well as older users. Knowing that, I tried to make the app very simple, not going to many pages deep and allowing users to quickly find information. This meant many pages being simply lists of information, forms, and/or pictures, allowing users to grasp the whole of a page’s content quickly. I also choose to not add features such as user profiles for that reason, as it would unnecessarily complicate the app
Compared to my original information architecture, it remained mostly the same. I cut down on a few sets of pages, such as the library and museum section, but otherwise the general structure of the app remained intact. Overall, the app is like a cliff notes version of the site, providing most of the essential visitor and resident info in quick bursts.
