BlogRefactoring a Document Input Form

A key part of the Barkpass experience is accepting documents from users applying for a dog park permit.

These documents act as veterinary certifications and typically have one or more types, like "Rabies" or "Distemper".

Each type has an expiration date.

In the initial build-out of the Barkpass application form, this was the document entry experience:

It worked, but it wasn't great.

I recently made some changes which resulted in this:

In this post, I'll go through how I approached refactoring this document input form and why I made the decisions I made.

Evaluating the old design

Let's take another look at the old design:

Here are a few things I noticed about this design:

Too much focus on "Name"

Naturally, a document needs a "name" when it exists in a database. However, these names typically take the form of Screenshot_10_02_2019_1gadb.PNG — not super useful to any human.

My original goal for including this field was to allow the user to change the name of the document to a sensible description of the document.

However, as we tested the form internally (and externally), we noticed that users weren't changing the name at all.

Additionally, it took up space as the first item in the form, giving it way too much priority.

Overall, the most important part of this form are the types and expiration dates, and having the name as a full-width input at the top did not reflect that.

Lack of context

If you have a pet, you probably know what "Rabies" means.

But what is "Distemper"? I certainly couldn't have told you at the start of this project!

This form lacks important context which would provide the user with clues when filling out the form. For example, it would be helpful to describe:

"Hey, here's what Distemper is... and here's how it might be labeled on your veterinary document."

The old design did not accommodate for this description, so I wanted to make sure the new design would provide a space for it.

Jumbly checkboxes and date inputs

^ This is a terrible heading, but stick with me.

The old variation includes checking a box, THEN entering a date input that appears below. This feels... off.

Additionally, it feels weird to have a chunks of inline words followed by a blocky input. This is especially true when the inline words varied in length, and the inputs ended up not being horizontally aligned:

Distemper document expires on: [BLOCK INPUT]
Rabies document expires on: [BLOCK INPUT]

Yuck.

This was the catalyst for the biggest change in the new version of the design, and I'm really happy with how it ended up.

The new design

Here's the new one again:

So, what did I do? And is it better?

Goodbye, name

I made the decision to disable document name editing. While it's possible some users would like to totally customize the way their documents exist in the system, my guess is that most of them couldn't care less.

Additionally, I can always implement document name editing later on, but maybe in a dashboard context where it's less important for the user to complete a major task (applying for a permit).

I didn't totally remove it, though. I left the name at the top of the document to act as a title. But an added bonus: I made it clickable. One sore spot of the previous design was that you couldn't preview the document in your browser while you were editing it (you had to close out the edit dialog and click on the "View" icon that exists in the parent component).

This, along with a floated "View" button, provide affordances to the user to let them know they can click to preview the document while they're completing the form.

A new "type" layout

I borrowed the card layout that I use throughout the Barkpass design and used it in this form.

Each type receives its own card which is equally tall and padded as its sibling types.

I've also decided to keep the date input visible instead of hiding it based on whether the document type is checked. This provides more visual clarity to the user as to how they might complete the task.

Instead of hiding the date input, I'm using box shadows to provide an additional affordance as to whether the given type is active and checked.

As an added bonus, once the user has both checked a type AND entered a valid (future) expiration date, the checkbox turns green which indicates that all requirements have been met. This is a pattern used in other parts of Barkpass - typically in tandom with a checkbox or a red 'X'.

Note: This is merely a progressive enhancement, because in terms of accessibility, a user may not be able to see the difference in color due to color blindness.

Finally, since we now expose the expiration date input to the user before they check the corresponding type, I wanted to ensure the user wouldn't forget to check the box before saving the document.

I had a couple choices here:

1. Disable the expiration date input until the user checked the type box
2. Automatically check the type box once the user enters a valid date

Option #1 would have worked, but it felt clunky: What if the user didn't see the checkbox up there? Requiring the user to follow the flow I had envisioned could have led to frustration.

That's why I went with Option #2! The type box automatically gets checked once the user has added a valid date.

---

Here's a screen recording of how it all works:

So that's about it! I consider myself a developer and not a designer, but it's pretty fun to dig into little design challenges like this to make incremental enhancements to the application.

Check out the live demo of the redesigned document input »