A Form Was Never Just a Sheet of Paper

Escaping a black hole in form design

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 simply 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.

1984–2014: Application in circulation for thirty years. Note that since 2000, each person filling out this form had to cross out the pre-typed date: “19______”.

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.

No call-to-action. The page above is a result of a client-centered approach, that is, what staff/clients think students/users will need, and when: “They should read the policy first before downloading the form”. In usability studies, students were lost. The link to the form—a PDF—was effectively hidden, buried as a text link midway down the page after a policy grid. When students found the link, most clicked the section header in bold, above it, thinking that would launch the form. It looked more like a button than the link itself.

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 members 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.

User Experience Flow documenting the three-to-five week life of a single form on UCLA’s campus. Beneath the paper’s surface hides a surprising amount of meticulous work by staff and faculty.

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.

A cutaway (about 1/12) of a user experience flow for a one page paper form.

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 people who used our products, documented and studied their experiences. We empathized with each person’s plight. We discovered situations where staff and faculty were forced to do busy work. 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.

War Games: the classic 1983 film showed students hacking into their high school’s “mainframe” to inflate their grades. Today staff joke unironically about still having to navigate and review student records on screens like this.

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 lost / 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.

“Check your eligibility”: One button can save an ineligible student weeks of uncertainty waiting to find out if she’s eligible, meanwhile saving University staff a ridiculous amount of lost time manually checking various databases.

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.
Before file upload, during upload, and after. As our starting point, we designed the Form Engine for mobile. This enabled us to focus users only on the single task-at-hand, to remove clutter, to make the interactions lightweight.
  • 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.
Left: the “Outside Employment” button expands it to tell you policy within the button you chose, so you needn’t reference a separate document. Right: Same view, but because the student chose a retroactive leave in a previous question, this limits (conditional logic) her choices in the following question that you see here, disabling some buttons and adding additional description text.
  • 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.
“Look! No black hole.” On submission, Emma sees her status view (left) telling her the average time it takes, who is reviewing it now, and how many others will view it after. If Emma checks three days later (middle), she’ll see it’s now in for review by the Graduate Dean. The status view acts as a progress indicator.
  • 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 pilot 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 pilot 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. Public beta release will roll out in early May. Once up and running and standing on its own, 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.

This article saw extensive collaboration and editing from Chris Testa, Ben Leeds Carson, and Derek Thorn.