Bryant Peng
Published in

Bryant Peng

Evernote Scannable: Recovering scans

Protecting users from worst-case scenarios

People expected Scannable to backup their scans. They weren’t happy when they found out it didn’t.

Scannable was designed to be lightweight: scan your document, send it somewhere, never look back. It never stored your scans, because presumably, it didn’t need to. The original team figured you wouldn’t need the scans once a digital copy existed somewhere, and wanted to avoid the feature bloat common in other scanning apps.

Done actually means Start a new scan and delete this one forever.

Users saw it differently. Upon Scannable’s release, the App Store reviews were filled with horror stories. Some people spent hours digitizing hundreds of receipts, and when Scannable crashed because it didn’t have enough memory, all of their work was lost. Others scanned legal documents and threw them away, assuming that Scannable, like all other scanning apps, would act as a document library.

I led feature explorations that culminated in the release of Scannable’s backup feature. I wasn’t allowed to revisit the app’s structure, though it was based on an incorrect assumption. Working within that constraint, I developed a solution that reduced customer service calls, forum complaints, and one-star ratings, reaffirming Scannable’s status as one of the highest-rated apps on the App Store.

Involvement

As the sole designer, I led the entire design of the feature from ideation to release. I worked with a product manager and an engineer.

Process

  1. Research: understand the problem
    User feedback review
    User interviews
    UX evaluation
  2. Ideation: find potential solutions
    User flows
    Paper
    Low-fidelity designs
    Prototyping
  3. Iteration: refine the solution
    User testing
    Prototyping
    Repeat
  4. Execution: deliver and ship
    High-fidelity designs
    Implementation

A comprehensive solution — no more half measures.

Part of the original rationale against backups was that they’d take up too much space. Once the user found out, the thinking went, they’d feel betrayed and delete the app. The alternative was storing them in the cloud, which was expensive for an app whose main purpose was to acquire Evernote users.

A concept exploring the idea of a visual log, which would become the foundation for the final design.

Before investing in a backup feature, I tried simpler approaches: being more explicit about not having backups, or only backing up the most recent scan. I created interactive prototypes and ran user tests, but the feedback showed a clear user expectation for document backups — no more half measures, Walter.

I tried approaches that were explicit about not having backups. People still expected scans to be saved, testing showed, regardless of the wording.

With a clear path ahead, I iterated on a new direction that drew from previous ideas (the visual log) as well as new ones (a time limit on backups). After several cycles of testing, the Recents feature shipped in the 2.1 release.

Early explorations used for prototyping and testing.
I added a time limit on how long scans were stored to prevent the document library from growing too big.

--

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Bryant Peng

Bryant Peng

Free UX help for Ukraine donations. Let’s talk: youruxfriend.com

More from Medium

The First Impression on the Platforms

How important is digital literacy in our era?

How a video game inspired me to learn animation

How to save Netflix : Creating engagement using UX