Hi I’m Perre. I design fun, easy to use products.
On this site you’ll find case studies from work at UCLA, Movieclips, and on Harry Potter.
A Form Was Never Just a Sheet of Paper
Escaping a black hole in form design
15 min read
Lead User Experience Designer
Topics covered: user-centered design, experience flows, forms, strategic design thinking, iteration, education
In a 2014 usability study at the University of California Los Angeles (UCLA), a graduate student used a damning metaphor to describe her experience submitting a digital form:
“Applying online is like throwing a paper airplane into a black hole.”
— UCLA Graduate Student
Forms have not been our favorite part of the web. Like the paper forms that inspired them, they can be difficult to read and seemingly impossible to fill out. This is where the new form building technologies target most of their attention. But in her metaphor, our student didn’t focus on the filling-out part. True, she spent time folding a paper plane just so, but then poof! It disappeared. Into what? A placeless place from which nothing escapes.
Students rarely experience a form as an efficient step toward a goal. After leaving her hands, a one-page form can take weeks to wind its way through a bureaucratic institution—all the while a student has little understanding of its progress or how “processing it” could take so long.
Since the bar is so low with forms, we didn’t have to do much to improve a user’s experience. We could apply Wroblewski’s best practices as we transposed the form fields into an online web form, or use a brilliant third-party form creation service. Done.
But let’s imagine that a form was never really a sheet of paper. If you’ll pardon the pun, let’s wonder what’s hiding beneath that paper’s surface. Beneath it, we found work. By studying and designing for the experiences of each person involved in this hidden work, could we shift the form’s heavy lifting off their shoulders?
And for our student, could we shorten the duration of a form? From two weeks to, say: one day?
In fact we could.
Porting paper forms to digital
We don’t tend to think of it like this, but the main gateway into anything a university does for its students, staff, or faculty is a form. Need a grant? Or paternity leave? Want to waive your right to sue for track-and-field injuries? Fill out a form. From admission to graduation, we collect our information onto pages—digital or otherwise—and push them into an abyss.
Universities and colleges the world-over struggle to carry their paper forms into desktop workspaces. With the advent of the web, the easiest route to keep them in circulation was to scan the paper form—unaltered—into a digital file (PDF) meant to be printed, then run between offices by hand. One form in circulation on our campus until 2014 was typed in 1984 on what looks like an electric typewriter. Over its thirty year life, this paper-based form witnessed the birth of the internet, yet didn’t really make a transition to digital. To this form, the advent of networked computing was simply the advent of a fancy, central storage closet.
As these forms began showing their age or needed revisions, someone would reproduce the data entry fields found on the paper form using a desktop publishing application like MS Word, then store it on the web or behind an intranet where they had previously kept the scanned version.
Eventually universities and colleges began rebuilding forms as interactive PDFs which included dropdowns and text fields and conditional logic. Over the years, as each web browser began shipping with its own PDF reader, these interactive PDFs stopped consistently functioning—almost never on touchscreens. In the last decade, schools began converting individual forms into one-off applications, or they’ve been turning to third party survey- and form-builders to handle the front end data collection.
Throughout this history, when porting paper forms to digital, the tendency was to approach it as a 1:1 conversion. If there were eleven data entry fields, then eleven appeared in the digital form. We tended to put them in the same order, or in the same layout as the paper form, so people familiar with the old form wouldn’t be surprised by the new digital one.
But by starting from a 1:1 conversion, we narrowed ourselves before we began. We treated the first person to use a form as a data entry worker and the form itself as a data collection tool. This metaphor even relegates the people who later sign off on the form to “signature fields”.
That metaphor of a form as “a sheet of paper for data collection” led us into a trap. It led us to great improvements in data entry and data management, and sometimes beautiful WYSIWYG tools for building the front-end. But it leaves users on the hook to just keep doing all the non-data entry work people always did outside the piece of paper. That’s also the form. Without turning our attention to that hidden work, we’re leaving our users to do some painful, time-consuming heavy lifting.
A student’s experience of a form
At the start, I conducted hour-long interviews with a half-dozen students to unpack their experience of a “form”. A student whom I’ll call Emma was in her third term in one of UCLA’s PhD programs. Emma’s father lives in Vietnam, and suffered an injury that required Emma’s temporary but full-time support.
Emma’s first question was an anxious one: “Will I have to withdraw from UCLA?” Next she asked, “Can I defer, or is there another way I can take time off from graduate school temporarily?” She searched Google using the language of her concerns, guessing at the name of the policy or form: “withdrawal”, “temporary time off”, “leaving graduate school”, “sick leave”, and “deferral”. Emma said she knew she could have read through UCLA’s grad student handbook, but then added: “Seriously though, who reads those?” So after her quick Google search, she asked her advisor who sent her an email link to the web page for graduate students wanting to leave school temporarily — the Leave of Absence (referred to by staff as LoA).
Once Emma opened the link, she scanned for the form, but it wasn’t anywhere obvious on the page. The first place she clicked was on an anchor tag that jumped her to another part of the page. The second thing she clicked looked like a button. It wasn’t. It was a section title which looked more like a button than the text link below it.
Next up for Emma: figure out if the rules applied to her, print the PDF, fill it out, sign it, and walk it to her advisor’s office. If Emma had already left campus for an emergency leave, she would have had to do it all remotely: scan her completed form back onto her computer, then upload it as an attachment to an email.
From the PDF form, Emma saw five signature fields which she hoped to gather over the next few days, or if she hustled, in the next few hours.
Her application took five weeks to wind its way from submission through the University’s mysterious approval process. A second form we studied took an average of three weeks. A third form averaged two weeks.
Why the weeks-long wait? Staff and faculty across the university put important yet invisible time into her application. More on that in a moment.
Partway through these approvals, Emma took a call from one reviewer asking to meet. The international advisor informed Emma that because of US VISA requirements, an application to take a temporary leave from the University (which had secured her the VISA) required a note from a doctor verifying the illness or injury of her family member. So she called her family in Vietnam, asked them to get a note from her father’s doctor indicating the severity of the injury. The Doctor faxed it from Vietnam to the international center. It was in Vietnamese. So after picking up the doctor’s note, she translated it. The international center did their best to verify the note, then stapled both the original and the translation to the back of the form. Then Emma walked it across campus to leave it at the office of the next reviewer.
Unfolding a form: User Experience Flow
As I conducted interviews and usability studies with UCLA students, staff, and faculty members, I documented their experiences in user experience flows. These document the experiences of each person who touches a sheet of paper, and what each person does in response. In total, I mapped out three forms; the example here is the Leave of Absence form.
From left-to-right you see columns representing people who touch the form on its journey across campus: the student, a student’s advisor, faculty members authorized to sign on behalf of a student’s program, a chairperson for her doctoral committee, an international advisor, funding staff, academic staff, a director, an associate dean, and someone from the registrar’s office.
Interviewing these folks, I documented: criteria a reviewer used to gauge if a student was eligible to make this request, where they looked up eligibility criteria, calls to other offices, searches on Google, how long it took to complete tasks, who walked it across campus, who scanned something, how each person approved a student, how they dealt with a financial hold on students, who was informed when a student was denied or approved, who reviewed it next.
We learned that while forms collect data, they are not, fundamentally, a data collection tool. A single form begins well before a student fills in some fields, and a student’s act of submitting a form is a flash that triggers a chain of complex human-computer and human-human events.
How staff and faculty members experience a form
Receiving a form from a student is no guarantee anyone gets to it ASAP. Staff and faculty have real, hard deadlines all year round. Tasks associated with pressing deadlines take priority, so it can be days before anyone in an often understaffed office has time to review a newly submitted form. The most hectic and busy period for most of the campus is admissions season, which has consequences for the unfortunate student who submits a form then: it’s going to take a while.
A staff member might receive five different student forms that day, each demanding her to perform a different sequence of tasks. Balancing priorities, it’s stressful to even try carving out time to review.
Once the first-tier reviewer read over Emma’s submission, it took a full 30 minutes to check online student records to evaluate if this student’s GPA, enrollment, etc. met the minimum criteria for approval. If her student didn’t qualify, she’d consult a Department Chair to consider writing a request for a special exception.
Once signed, a reviewer either personally walked it over to the next reviewer’s office, or contacted Emma to pick it up and carry it to the next reviewer across campus.
Below is a cutaway from the user experience flow above. Everything viewable in this cutaway shows people manually comparing a student’s data in computer databases to a policy document to determine if Emma meets qualifications to use the form: Are all required fields filled out? Is Emma’s GPA high enough? Was Emma enrolled last term — unless last term was the optional summer term in which case was she enrolled in the term before that? Has Emma taken a previous Leave of Absence—if so has she taken more than the allowable 3 terms? And on and on.
The three prominent columns look similar because all three people are conducting almost identical checks into student records—opening the same windows, logging into the same resources, navigating to the same screens, scanning for data in the same fields.
What struck us is that the majority of time reviewers spent with the form was time spent manually checking computer databases. This is, in a word, “lost time” — lost because it’s work humans are doing that computers were historically designed to do: compare data.
If we were to have approached this form in the typical way, thinking of a form as data entry, and trying to design a product for that, we’d solve it by putting an existing paper form online with data entry fields. In other words, we’d have tried to solve only data entry for the student: What’s your first name? What’s your last name? What’s your student ID number? What program(s) are you in? In what term would you like your leave to begin? For how many terms? What address will you be at during your leave?
Instead, we met with users, documented and studied their experiences. We empathized with each person’s plight. We discovered situations where users were doing things—busy work—that computers were literally designed to do. In sum, we approached a form as an entire workflow and review cycle. That’s how we learned the scope of what we could solve.
Would it be worth our time and financial investment to tackle this? We made a case for it by roughly figuring out how much time people at UCLA lost every year to one form.
Without this button we lose 11.25 weeks a year
500 students submitted a request for Leave of Absence in 2014. Of those students, about 90% met all eligibility requirements. This meant that a full 450 students should have been green-lit to be approved easily—with almost no time taken from people to review them. Yet staff did the same research on all 500 students, not just the 50 who needed detailed consideration.
On receiving a form, a reviewer proofed each item on the paper form against a policy checklist, looking up each item in student records. But it wasn’t straightforward. Each reviewer had to open windows into up to three databases, each with unique student record information. If not logged into each, the reviewer did so, then she navigated between screens numbered 405 and 320 or to screens named with long-forgotten acronyms like GPD.
The first-tier staff member spent 30 minutes-per-application reviewing a student’s qualifications. Three more tiers of reviewers checked subsets of what the first reviewer checked, spending an additional 10, 5, and 15 minutes.
Let’s add up the time spent by all reviewers for one student’s application: 30+10+5+15 = 60 minutes. Multiply that 1 hour by the 450 applications that had no issues = 450 hours.
450 hours / 40-hour work week = 11.25 weeks.
To be clear: collectively, UCLA’s staff lost 11.25 weeks every year checking 450 student records for a form that should go through cleanly.
The data we were checking is all in student records. It’s just data. For years though, we didn’t think of it this way. Schools tend to have a mindset that our systems are too antiquated to test a student’s qualifications. So tacitly, each of us, in our silo, manually searched student records to check a student’s eligibility every time a new form crossed our desk. UCLA’s graduate technology team changed that with a single button pressed by a student: Check your eligibility.
The logic behind this button was really hard to get right — a story for another time.
The most advanced methods of creating a form online results in the same loss of time. The best commercially available form builder enables us to make—and a student to fill out—a beautiful, intuitive, easy-to-use front end interface. But had we chosen that route alone, I think we would have never uncovered the hidden, outdated activities that forced each reviewer to waste her time looking up a student’s eligibility in various databases.
How can a university lose all that time on one form? By thinking of a form as “a piece of paper passed between people”. By making a digital network behave as a single piece of virtual paper—a sheet of paper whose presence in an online world is reduced to the function of photocopying.
The metaphor of paper combined with the solution of data entry didn’t make space for computation to handle complex information.
Before-as-now, forms were never just a piece of paper passed between people. Forms are a meeting space, and by this human-centered approach to going digital, our new button could now call the meeting.
The scope of UCLA’s Form Engine
- Emma, our graduate student, securely initiates a request to do any number of things: see if she can go on leave this upcoming quarter, or attend a different university for a term, or pay reduced tuition during her final year.
- Instead of staff and faculty members checking student records to see if Emma meets eligibility criteria, Emma presses a single button that securely checks her eligibility before showing her the form. If she qualifies, Emma can proceed, if not, she’s provided with the reasons in plain language, and what she must do to qualify.
- Our Form Engine manages notifications and secure logins for every person who is expected to review (or sign off on) the form. Each reviewer sees details necessary to make a decision on the application.
- The number of reviewers varies depending on this particular form’s policies, and it depends on the type of student Emma is. If for example Emma has a doctoral committee, her committee members are added.
- Only the qualified, green-lit students are sent through to be reviewed. If any of the form’s policies have wiggle-room, then a non-green-lit student can request an exception so her file is flagged for more in-depth review.
- A selected button expands with more info to tell students or reviewers what that choice means, and its consequences. So people unfamiliar with the policies learn what they need to learn in context, rather than referencing a second page or manual to understand mysterious terms.
- The moment Emma submits her form, she sees its progress. It shows her who is reviewing it currently, and who it’s going to next. The form collects time-based history, so it can estimate for Emma the average time this form takes to complete its rounds.
- Once our first form is launched, tested, and vetted, then the Form Engine can quickly create any new form that relies on combinations of the same eligibility checks or that relies on the same types of features.
- Our Form Engine is built on a single codebase that updates all existing forms whenever a bug is fixed. When updated with a new function or eligibility check, the Form Engine allows that new feature to be turned on in any form previously deployed.
My Director Chris Testa and I developed and co-delivered pitches for and demos of our new Form Engine to key stakeholders — groups as small as six to as large as forty — to sell the idea across the university, and to modify the project based on their input and needs.
Where are we now?
In the Fall of 2015, we launched a new UX-driven, mobile-first, student-centered website capable of hosting our Form Engine.
Meanwhile, a team made up of Graduate Vice Provost, the Assistant Vice Provost, the Information Technology Director and I, conceived of and pitched a method of extending our nascent Form Engine to output a student recommendation system. For this, we won UCLA the Council of Graduate Schools’ prestigious, peer-reviewed, and bureaucratically named Award for Innovation in Promoting Success in Graduate Education.
Of the three forms we studied, our Form Engine initially built two: Leave of Absence (detailed above) and Filing Fee (a tuition discount for a graduate student in her final term). So far one is live.
In March 2016, we entered beta for the first form in our Form Engine, the Filing Fee. This form normally takes two weeks from submission to final approval. The first student to submit in our beta witnessed her form reviewed by four faculty and staff and receive approval in 3.5 hours. This isn’t something to celebrate as if it were the average time (I’ll add statistics into this article once we have a meaningful sample). But submission-to-approval in 3.5 hours is miraculous in that it happened right out of the gate. We created this ridiculous thing that round-tripped a student’s request in a reasonable amount of time.
Our student witnessed no black hole—she saw an average time for review and she could monitor who was reviewing it now. Our student didn’t have to run from place to place, nor be on campus, to get it done. For staff and faculty: none had to waste their time cross-checking this student’s eligibility against computer databases. The Form Engine did this for them.
We continue to do usability studies with students, staff, and faculty, and we find ourselves squashing bugs and adding new features throughout our sprints. Full release will roll out by June 1st. Once up and running, our team will begin rolling out the Form Engine’s next form. And then the next.
Forms are a pervasive part of the web, and they constitute a fair amount of activity within all types of organizations. While we’re excited about our approach, we know it is only one of the many ways to uncover and solve hidden aspects of forms. We’ll see soon our if our effort to design our way out of this black hole has a lasting effect. We’re hopeful it does.
Anything I missed? Anything you have questions about? Let me know.
Designing a Video Player That Knows Its Place
5 min read
Lead Interaction Designer
Topics covered: startups, early responsive design, video players, anticipating change
When I came aboard, they had signed the major studios to multi-year licensing deals. 12,000 clips were live. You could search across them by director, actor, or by a favorite quote: “Always be closing.”
I designed the Movieclips video player. I collaborated with the company’s founders Zach James and Rich Raddon, and with heads of tech and operations Philip Southam and Brandon Folkman. To code our player, I recruited and oversaw a developer best known for hacking Hulu’s streams so users could watch on desktop in an Apple TV-like interface.
There wasn’t a standard video player in 2010. If a writer wanted to embed a video clip on her blog or news site, she’d specify the width and height which told the player to scale its fixed dimensions down or up to those sizes. When the embedded player was a different aspect ratio than the video expected, it either stretched the video to a weird aspect ratio, or a smarter player might display black letterboxing to mask the area it couldn’t fill. The interactive elements like the timeline, play button, and fullscreen options were bitmap, and would scale with the embed. If not embedded at the originally-designed size, each interface element risked appearing pixelated.
Competing video sites maintained at least four video players: 1. home: a full-featured player on their own destination website (i.e. on Hulu itself), 2. embedded: a lightweight version with limited capabilities that users could embed on their blogs, 3. partner: to display on partner sites with unique features turned on or off, 4. social: to display a player on emerging social networks like Facebook. Fixing a bug or adding a new feature required updating and testing multiple codebases.
As an energetic startup, we saw these as conventions that were holding back the industry. We took the opportunity to build a player from scratch. We paired that with a realism about our circumstance: we thought our site was a fun destination, but we were like any new website: a small fly out in the midst of an enormous web. Or maybe we were a tough little spider. Anyway, if ever we were to become a destination site, we had to have a presence across the web: on our users remote sites and across social networks. That’s where people who loved films could discover us: friends of theirs or trusted voices sharing video clips.
So we set out to build a video player on a single codebase. We built a player that was easier to embed, that adapted responsively to its context, a player that had all the features everywhere (rather than just on our site), that was all vector so it scaled beautifully, and a player that anticipated that users would eventually change or update their blog templates so it grew with you as your site grew or changed.
When a user chose to share a video clip, our embed settings defaulted to “scale to fit”, which hid quite a lot of complexity. When loaded on a remote site, our player asked: how wide am I? Based on this and the aspect ratio of the video it was about to serve, it dynamically reconfigured its layout. It showed, resized, and repositioned all vector interface elements, and start-and-finish-screens. In a large embed, our finish screen showed six recommended videos and in small embeds, there’d be four, or three, or just one, depending on how small. If you embedded it into a super-small context like 280 px wide, our player adapted to be a single play button and video. This context-awareness was a first for video players—launched two months before Ethan Marcotte made the first public case for responsive web design.
Paste a link into Facebook? A player appears, having reconfigured itself to render the interface clearly and unobtrusively in each of Facebook’s viewing contexts. Embed a clip on your blog, then change your blog’s dimensions months later? We designed the player to anticipate this, so it doesn’t break or stretch your videos when you do something commonplace like change your tumblr or Wordpress theme.
Ours was the first online player to render all films at their original aspect ratios. We sourced our videos with this in mind, embedded their dimensions (1.85:1 or 2.40:1, etc) in each file’s metadata, then read that data to configure our player’s view area, dynamic height, and embed options.
What if you want to trim down to just a single quote? Tap “Trim Clip”, and trim handles appear on each end of a timeline. On drag, the trim handles show time codes and the viewable screen shows the exact frame, enabling you to fine-tune your starting and ending points. You’re now two taps from sharing a favorite quote with friends.
An extended version of this product enabled users to mash up our clips. It became a 2011 TechCrunch Disrupt Finalist.
Designing the Marauder’s Map
6 min read
Lead Interface Designer
Topics covered: prototyping, user study, delight, collaboration, navigation, movie websites
In the world of Harry Potter, the Marauder’s Map enabled mischievous young wizards to travel secret passages, find hidden rooms, and track anyone on Hogwarts campus.
In 2004 I began designing the magically unfolding 3D map you may be familiar with from three generations of HarryPotter.com. The Webby Awards gave it an Honree nod the following year. Here’s a short view into conceiving and building it.
Most teams behind a film website never get to read a script, nor see an early cut of the film. Our assets tend to be limited to previously public content: trailers and a few variations on the movie poster.
For Harry Potter and the Prisoner of Azkaban, the Creative Director, Art Director, and the three design and engineering leads were invited to an early screening with unfinished effects. The music was filler. Unfinished scenes were blocked out with storyboards. And the magical creatures that weren’t real were still being built of polygons and textures. We also benefited from having the popular books available. The production studio sent us confidential, pre-release stills from the film and stills meant for the poster, and they told us we could put in requests for props we’d seen in that early cut.
From all this, I sketched an idea for using the Marauder’s Map as a way to get around the website. I storyboarded the experience, saw excitement from my art director Anette Hughes, then drew rough wireframes to identify assets and resources and to establish scope.
Soon my team received low-res scans, faxed from the lot, of the original film prop.
With these scans, I prototyped the interface in Flash, seen below as stills, as proof of concept. To catch errors in the interaction design, I silently observed as people across the company interacted with the prototype. Occasionally I’d ask questions, then refine it when I saw confusion points or if something felt too slow, awkward, or unnatural. Once refined, we shared these with our stakeholders: senior executives at Warner Bros., the filmmakers, and finally: J.K. Rowling.
Meanwhile, we were creating eight casual games based on quidditch, a team-based stadium game played on broomsticks. But when the original prop map finally arrived from set, we found it had no quidditch pitch. Improvising, I spent the next night fast forwarding through the previous two movies taking digital photos of various views on the game. Our lead visual designer Blake McWhirter took these away and in three hours had designed a near perfect quidditch pitch that looked like it was pulled from the map.
I scanned the original prop map at a high resolution, and prepped each map leaf as textures to apply in a 3D model. I oversaw 3D of the map unfolding with graceful, unique animations from each section to every other section: 1-to-4, 4-to-3, etc.
From a final rendered 3D video (several generations after the one embedded above), I isolated and optimized each frame for web, and created easing animations between all sections. Our in-house illustrator Byron Hudson created objects for the map that sprang to life on user interaction: the leaky cauldron, dueling wands, the sorting hat.
All put together, it functioned properly as a map to navigate to games and activities hidden around Hogwarts Castle, its grounds, and on the Quidditch Field. As a treat before the fifth film—for one day only—the map revealed footprints as Professors Snape and Dumbledore wandered the halls.
Harry Potter represented our largest launch to-date, with a pre-built fanbase dwarfing typical web stats. On the day the Marauder’s Map went live, we jumped from our average 1.1 million unique visitors daily to 7 million. And by the film’s release date, we reached 12 million daily uniques. This includes full-site translated versions in 17 languages on as many country domains.
Our website for “Harry Potter and The Prisoner of Azkaban” was a 2005 Webby Award Honoree. The map remained a navigational centerpiece through three films and three site iterations.
See 80+ portfolio stills by connecting with me on LinkedIn.
00 + 1 + 323-304-6232
Earlier movie and entertainment experience design
Most of my design work was for feature film and media properties including Batman, Warner Bros., Warner Independent Pictures, Gemini Division, Tinkerbell, Hanna Barbera, and more. Many of these are mentioned on LinkedIn. To see stills of everything, connect with me there.
If you’re curious about the books...
In 2008, Chen Design Associates imprint CDA Press published my first book. In it I help teach your cats to do their business as people do: by jumping up to the toilet. It’s called Kick Litter: Nine-step Program for Recovering Litter Addicts.
My latest book is about how to prepare an upside-down pound cake out of Harry Potter’s most beloved magical creature. The Hippogriff Cookbook is available for iPad and iPhone in the App Store.