Prototyping Paper on iPhone, Part II

Published in

A Space to Create - FiftyThree's Blog

6 min readNov 17, 2015

In Prototyping Paper on iPhone, Part I, we discussed the vital role that prototyping plays at FiftyThree. In the final part of our series, we’ll walk through the steps we took to test and hone in on the final design for Paper on iPhone.

Beyond Drawing

From the start, we created Paper to help you capture your ideas. But until the release of Paper 3.0, those ideas were limited to writing and sketching. Time and time again we got the same feedback from fans: “I love your app, but I can’t draw.” At the same time, we knew iPhone was a great tool for capturing photos and typing notes. What if we brought new idea types, like text and images, into Paper?

We approached the new interface design as a “Compound Idea” in which Paper’s familiar ink canvas would live on top of an image layer, and text would be attached below. You could start with ink, text, or an image, and the layout would adapt to show you the best view. We went back to our existing Navigation and Canvas prototypes and updated them so that we could try out the new design.

For our Navigation prototype, we added text and photo content to our grid so that we could see how navigation would feel with various text sizes and content types.

In the Canvas prototype, we added navigation between the text and image canvases, and new functionality to test how drawing with ink would look on top of photos. We tested this with users as well, and verified that they were able to stay properly oriented and could move between the different canvases.

Refining Navigation

As we continued iterating the design, we discovered a way to improve our grid layout. Our original layout used a column-based grid in which each idea scaled to a standard width and was then placed in the next available column. However, when you try to reorder ideas in a column-based grid, it gets tricky: heights can vary significantly between ideas, making it hard to maintain the position of each idea in the context of a larger grid.

Being able to easily reorganize ideas is one of Paper’s prime features, so we knew we had to create a layout that would make this action frictionless. We came up with a row-based grid in which items are placed next to one another like English words on a page. To verify that it would be easy to move ideas around, we built and tested a basic prototype for reordering with a row-based grid:

Cleaning Up The Canvas

Up to this point, the ink canvas in our prototypes was nearly identical to the shipping version of Paper, except for the addition of the swipe-down-to-close gesture. As we continued testing the prototypes with our team, we learned that most users didn’t find the swipe down gesture. Existing Paper users would try the gesture, but were surprised that it closed the canvas instead of hiding the tray, as it does in Paper on iPad. We created prototypes to test three ways of closing the canvas, including swipe-down-to-close.

Because Paper on iPad used pinch-to-close as the exclusive gesture for exiting the canvas, we thought it would serve as a reliable approach for iPhone user tests with our colleagues. But, to our surprise, most of the testers did not even try the pinch-to-close gesture, even though they were familiar with the action based on past experience using Paper on iPad.

We set up a second prototype to test whether everyday users would have difficulty closing the canvas with the swipe down gesture. The test confirmed previous results — users struggled to learn the gesture, and most did not even try the gesture until we explicitly asked them to.

To test the most basic approach, we placed a Done button on the canvas. Every test user understood the button, and it ultimately trumped the pinch-out-to-close and swipe-down-to-close designs in discoverability.

Internally, we struggled with this decision. In general, we strive to create interaction designs that are simple, learnable, and enjoyable to use, but the gestures we tested didn’t meet those conditions. In this case, new users had an implicit understanding of how the Done button worked, so we integrated it into our updated designs. We kept the pinch-out-to-close gesture in place for users who knew it.

Bringing It All Together

By summer, the dust had largely settled and we started to finalize our design proposal. It made sense then to bring the prototypes back together for a final round of user testing while our development team built Paper 3.0 for iPhone and iPad.

This final prototype combines all the features from the Navigation and Canvas prototypes. You can tap into an idea in the navigation prototype and the canvas will open so that you can edit the ink, photo, and text. This was the first time we could test the full flow of the application, covering navigation, reorganization, and creation. Fortunately, user testing didn’t reveal any major problems.

From Prototype to Production

After our last round of user testing, our design was validated, and we were ready to build a shipping application.

In truth, the process of building Paper on iPhone started well before we finished building and testing the prototypes. As the “real” Paper improved, prototypes were used as references for how the app should behave. Soon, the production version of Paper became more functional than its prototypes, so that’s what we used for final rounds of user testing before our official 3.0 release.

With the release of Paper on iPhone, we were proud to see the product of a year’s worth of prototyping come to life. We’ll continue to use our prototypes as a reference point as we work to improve Paper.

Prototypes! What Are They Good For?

We spent nearly one year building a parallel version of Paper that, under the right conditions, could have passed for a shipping application. So why spend so much time building prototypes?

Simply put, the level of detail we covered was necessary. In our redesign, we replaced several beloved elements of Paper on iPad, including the journal view and gestures that our community was familiar with. We didn’t take these changes lightly, so through rigorous prototyping, testing, and iterating, we designed a new way to navigate the app on iPhone and iPad that preserved the heart of Paper as the place for your ideas.

Building the prototypes let us put our ideas in front of users early on so we could adjust every element of the app until it felt just right. The process of refining Paper never stops as we continually adapt to new environments. Over time, operating systems gain and lose functionality, needs evolve, behaviors change. Through these changes, our mission has stayed the same: to help get your thoughts down so you can take projects to the next step with tools that are at once familiar and intuitive.

Try Paper Now

Addendum: Prototyping Tools

At FiftyThree, we use a wide variety of prototyping tools. Often, the decision for what tool to use depends on who’s making the prototype, and the tools that the prototyper is already familiar with. New prototyping tools launch regularly, so we’ll often try new ones just to get a feel for them.

For the prototypes we covered in this article:

The People Centric prototype was written in Swift.
The Pocket Centric and Canvas prototypes were written in Objective-C/UIKit.
The Sharing Centric and Navigation prototypes were written in JavaScript. We run these prototypes in an application called Scout, which acts as a file loading system, and then uses the Ejecta and CreateJS libraries to run JavaScript natively on iOS devices.