One of the projects that I’ve worked on recently is the redesign of a fairly simple form. All it did was gather feedback from people who wanted to report a broken website from within the DuckDuckGo browser extension.

So what you would do was that you’d click on the “Report Broken Website” button on the extension, and then a new tab would open with a form that you would then fill out.

• 

• 

Forms aren’t all that exciting to be honest, but there’s room for creativity in designing them. Just take a look at the thoughtfulness put into Stripe’s payment checkout form or the range of ideas that you can find on Dribbble.

So with this project the main issue that we wanted to solve was friction: Can we increase the number of people reporting broken websites if we made it easier to do so?

Understanding the problem

People already had ideas on possible solutions and user flows before I even started on the project. So my job at the very beginning was to listen and understand the scope of the problem and the goals of the project.

For me that often meant grabbing a bunch of paper from my co-working space’s recycling bin to write down design ideas and to sketch out some possible solutions.

• 

• 

A part of the design process for me is also figuring out the copy and the tone and voice that we want in the UI. We figured that in this case we’d want to show empathy to the person reporting (because it sucks to run into a broken website) and to communicate that we’re not going to be harvesting all their personal information behind the scenes (because we don’t).

After I felt like I had a good handle on what I needed to do, it was time to go on Sketch.

Iterating on the designs

Forms are really just a bunch of input fields. Figuring out what sorts of fields to put in there, however, can take some time to figure out. The first set of designs that I made had multiple elements:

• A select element for indicating the type of breakage.
• A textarea element for people describing their problem.
• A checkbox element for people to opt-in to debugging data.

But after a few discussions and a couple of design variations later, we figured that we could reduce the form down to just one element. First, we got rid of the checkbox because the submit button is how people opted-in to sharing their data. (In lieu of that, we added additional information that we weren’t going to get any of their personal information.) Second, we figured that we already had the debugging information so there was no need for people to explain what went wrong.

This greatly simplified the form, and made it faster for people to report a broken website.

Another part of the design that I had to look into was how people got into the form itself. What most some people do when a website is broken is that they toggle the extension on and off to see what would happen. We wanted to reach out to these people by asking them if they were toggling because they found a broken website.

The initial designs that I made used modals that imitated how smartphones would show notifications. I loved this idea because this sort of notifications could be used to help and guide the user when they encounter different problems throughout the extension. But we agreed that right now it’s a bit of an overkill solution so we went with a simpler inline version that comes up right below the toggle.

Coming together

Now that the main parts of the project have been designed, it was time to create a user flow that shows the different scenarios that a user could get into when trying to open up this form. This is great for communicating design to developers and other stakeholders so that everybody is on the same page.

Then we also asked Matt Anderson to create an illustration for the form and we all ended up liking this broken bike design! At this point, it was time for the developer to implement the designs.

• 

• 

All these changes are now live! So if you ever run into a broken website on the DuckDuckGo extension (I hope not!), you now know how that reporting page came to be.