Matt Phillips

Perma.cc

In this case study we'll walk through the process used define the interface that displays web archives at Perma.cc.

This feature was implemented in 2017 in the Harvard Library Innovation Lab in Cambridge, MA.

Create your own web archives at Perma.cc.

Perma.cc logo

Context

Perma.cc is a web service that helps scholars, journals, courts, and others create permanent records of the web sources they cite.

Perma is used by more than half of the law schools in the US, has been used by a US President and the Supreme Court.

Perma's core service is simple - input a URL and receive an archive in return.

Your archive is stored at your library and is available forever. No more 404s or shifting content.

I led the Interaction Design effort on the feature described in this case study, and across Perma generally. I also functioned as a full stack developer by contirbuting Python and JavaScript.

Perma.cc capture page illustrated in a phone display

Enter any URL and Perma.cc will generate a web archive for you

Problem

Presenting an archive of a webpage can be confusing. The biggest concern centers around the URL in your browser's address bar. Under normal use, you'll see a Perma.cc URL in your address bar but the conent of the browsers will be from another site, say Wikipedia..

Keeping user confusion low is a signficiant challenge - we must clearly label the archive so the user knows they're viewing a backup and not the site of the original publisher.

We need to avoid user confusion and also avoid being a host for content that is normally stored behind a paywall. We don't want to steal views from creators while trying to keep content stable as the internet shifts below.

Perma.cc capture page illustrated in a phone display

The web page Perma.cc shows you is a recreation of the original. An archive.

Solution

Presenting an archive of a webpage generates a number of competing concerns.

The user that followed the link to the web archive wants to see the archived webpage - they're after the original content.

Perma needed to clearly let the user know that they were viewing an archive at perma.cc/some-guid even if the contents clearly originated elsewhere. Perma could be used as tool to avoid paywalls and direct traffic to the original content provider. The interface needed to offer a lot and still stay out of the users way.

Perma.cc capture page illustrated in a phone display

The end result of this design process and the interface currently in production.

Process

This process will help us explore a broad range of paths forward - we're working hard to avoid local maximums.

We'll end up with a bunch of bad ideas and hopefully, a couple of good ones. It's important to move quickly through these steps.

We'll dig into each step below. The high level is about same process I use for most larger interaction design efforts.

Perma.cc logo Avoid local maximums through wildness

Step 1

Generate wild ideas. Good and bad.

Gather two to a few people around a table and set a timer for 3 minutes. Each person fills out as many wild ideas as possible on a stack of index cards.

Very little filter. Almost all bad ideas.

Works individually, but is more productive and fun with a group.

Output stacks of cards

Design process step 2 described as organized index cards on the wall

Exploring wild ideas for Perma.cc features with Harvard colleagues

Step 2

Connect wild ideas. Push for new possibilities.

Synthesize and make legible Organize the wiildness a little so that it’ll spark discussion Repeat step one until it feels tired. Three or four rounds of tow or three cards per round is a good mark to hit. Cull those ideas down to a handful. In the group, synthesize and flesh out.

Output stacks of cards taped or pinned to a surface

Design process step 2 described as organized index cards on the wall

Three features with a wide range of possibilities. Loads of paper taped on paper.

Step 3

Sketch low fidelity interfaces. Examine prior art.

Develop potential directions Low and medium fidelity prototypes. Examine prior art.

Look at prior art after you've had original thought. Incorporate patterns and clear wins.

Make lo-fi sketches that can be tossed around internally. These should be pencil and paper or balsamiq wireframes that do nothing more than present the new interaction.

If an idea feels potentially promising, up the fidelity just a little bit with a balsamiq or InVision

Output = stacks of paper loaded with lo-fi sketches

Design process step 2 described as organized index cards on the wall

Many low fidelity sketches are wireframes are generated in step 2

Design process step 2 described as organized index cards on the wall

These wireframes should be loose, quick and wild

Design process step 2 described as organized index cards on the wall

Wireframe of interstitial page. An approach dropped at this step.

Design process step 2 described as organized index cards on the wall

Wireframe illustrating the user of a thin header with archive details. The approach we implemented.

Step 4

Refine and focus.

Refine and focus Canvas power users, coworkers, test partners and friends to play with sketches. This step not only refines and stress tests potential directions, it gets the team on the same page. It clarifies. It provides focus on the best path forward.

Output wireframes, user feedback, focused plan

Step 5

Prototype and build out

Prototype and test Prototype and revisit the users from the previous step Friendly users see an InVision style mockup. If that's touch, they see the feature branch that's been built out by the engineers. Take lessons learn. Iterate on any deal breakers and roll out the feature. Build support docs and help the communications team get the word out.

Output high fidelity wireframes, feature and user feedback documentation

Design process step 2 described as organized index cards on the wall

Finish

Stay connected as developers, UI designers and product teams begin to focus and deliver the new feature to the users. Move onto the next challenge on Perm,a.cc - helping users organize archives across organizations

Thumbs up. Thanks, giphy.

A team

I worked within a team of seven people on Perma.cc - one project manager, one UI designer, one communications person and three full stack developers.

Our team was led by the brilliant Harvard faculty member, Jonathan Zittrain. He initiated the effort, found funding and guided the vision for this web archiving service.

I wrote the text, drew the illustrations and took the photos that appear on this page. The source for this portfolio can be viewed on GitHub.