Project Background

In the summer of 2017, I was working at a web development and data analysis firm in Olympia, Washington. My main task for the summer was to build a new corporate website from scratch. When I heard that I would be developing a completely new site, I was excited by the opportunity to create great user interfaces that are self-explanatory and rewarding to use.

Definitions/Explanation of Goals

What is an “interface that is rewarding to use” you may ask. My idea of a rewarding interface is one that never leaves you questioning whether you’ve made a mistake or not. The user should never have to question if they accidentally missed the button or if the application is just loading. Interfaces that give clear feedback to user action help the user feel more confident in their actions. If you’re into UX, or have been reading about similar topics, you’ve probably heard of this concept before.

Part of designing the website called for designing a contact form. These are everywhere, I’m sure you’re familiar with them. But what do you feel when you think of contact forms? You may think of a screen full of a bunch of input boxes, and you probably feel the urge to quickly move your cursor towards the back button in retreat from the mental effort of filling in your address for the quadrillionth time. So what can we as designers do to spice up this experience? We want the user to be EXCITED to interact with us! Lets explore some options.

Main Focus for Form Design

Create a simple, rewarding form experience

Provide meaningful UI feedback

Usable on any screen size

Retain functionality above all else

Now that we have our goals defined, lets examine the contact form on the current site the company is running to see what we can improve on.

The contact form I got to redesign

The one thing going for this form is the simplicity. Just a few boxes and a submit button. Don’t get me wrong. This field definitely works and gets the job done. It has clear labels and a clear submission method. Again, my goal for this form was to make it more enjoyable to use, while still being fully functional.

What are some of the things that could easily be improved?

Before reading further, have a look at the next photo, and try to identify which input fields are required and which are optional. Did you notice that the designer of this form used bold lettering to indicate which fields are required? If you missed that detail, I don’t blame you. This technique is too subtle for some users, and it would be better to be more obvious about this. A very common convention is to indicate required fields with the ‘*’ character. Let’s see if we can work this into our final design somewhere.

Not-so-obvious visual cue to indicate which fields are required. Can you spot it?

The visuals could also be vastly improved with some quick spacing adjustments and styling changes. Let’s make sure to do this in our final design.

Another point to consider is where the contact form is located. While not directly apparent in the screenshots, the old contact form is hidden in and only accessible from its own page. If we wanted to encourage client feedback straight through our web interface, we should include this in a more prominent and easily discovered area of our website. While we want our users to be aware of the contact form, we also want to make sure we aren’t screaming at them or getting in the way when its completely unnecessary. Let’s tap our users on the shoulders and let them know we’re here and then see if they choose to proceed further, instead of boldly slamming the entire contents of our form in front of the user.

Alright. Enough. Lets get to the final design!

Final Design

So how’d we do? First off, I was really excited with how this turned out. I think that this form really demonstrates some good qualities of UX design. Don’t those micro-interactions just make you want to keep playing with it? I really focused on the feedback that the user was getting. If the field being filled out is not yet valid, the bar beneath the text glows red. As soon as the field data is valid, the bar turns green, and once all of the required fields are green, the submit button becomes enabled. The contact form is located on the homepage, and it is tucked away into a compressed space, inviting the user to expand the content. All of these design choices have implications that are readily-obvious to the user.

Notable Components

All in all, there were a few aspects of my form that I was particularly happy with. These include:

Drawer opening/closing animation

Label mechanism

User feedback upon proper valid input

Graceful state changes throughout the process

One thing that I thought about a lot while designing this interface was how to cleanly inform the user about the state of their input without throwing error messages in their face. My goal was to create an overall interaction that was very easy to use and required no explanation. I did this by using common signifiers of valid/invalid such as the green and red, and familiar visual web object states to let the user know when the form is completely valid and ready to submit. Let’s discuss these in detail.

Label States

When the user first approaches the form, they are confronted with a few input fields that are signified with an underline and a label. I wanted to design an interaction that avoided the common practice of labeling contact forms with placeholder text that disappears once the user starts typing. This practice is clearly problematic because it can potentially cause the user to forget which box is for what input value. This problem is exemplified when the form inputs are non-standard and especially if the input fields are in a non-familiar order. I was sure that I wanted the labels to always be present. I had a few options such as statically placing the label underneath, above, or to the side of the inputs, but I really wanted a consistent feel to the form. Since the contact form is revealed through a lightweight sliding animation, I decided to go with the same theme with the labels. Here, when a user clicks the form, the label smoothly slides up and to the left of the contact form. The animation is subtle enough as to not be distracting, but smooth enough to add a hint of sophistication.

This animation also gives me an extra tool to solve the problem of how to let the user know when the form is complete/valid, which I will discuss in greater detail later on.

Submit Button States

Invalid user input state

The next problem I wanted to solve was how to restrict the user from submitting a form that was invalid or missing required fields. Again, with the goal of subtly in mind, I was striving for a system that required no explanation and was obvious and rewarding when the state changed. To do this I knew that I had a whole library of web standards I could draw from that the majority of web users would be intimately familiar with. I decided to go with a submit button that was built off of the standard button styles I had introduced earlier throughout the site. At the bottom of the form underneath all of the inputs, I placed my submit button. I needed to signify that the form would not be submitted if any of the criteria failed to be met, so I decided to go with the disabled button style that users are aware of already. The standard is just a grayed-out button that does not have any hover effects such as changing the cursor. For the invalid form state, I essentially implemented this web standard directly using my established styles by increasing opacity and letting the button blend into the form environment, while still making sure the button was discoverable and obvious. I like the disabled button style over the method of displaying error messages when a user attempts to submit an invalid form because not only does it physically prevent the user from clicking the button when data is invalid, it also provides another tool to signify to the user the validity state of their data.

Valid input state

Once all of the user input had been validated, I wanted to smoothly transition to a state where the button could be used, while again subtly drawing attention to this area of the form so the user would instantly know that they are good to go.

I wrote code that validated user input instantly as the user typed, so the moment when all of my form criteria was met, I could activate the submit button transition.

The button gets a thick, bright green border drawn on, and the hover animations that are present on the other buttons on the site are instantly enabled and the button becomes active. This design requires no explanation of how the submit functionality works, and it should feel intuitive and rewarding to the user when the green outline animates in (ooh, yes! I completed the form!). The moment the criteria is no longer met, the button transitions back to its disabled state.

Drawer States

When the form has not yet been revealed, it hides inside of a retracted drawer that is opened at the click of a button. I wanted to ease the user in and out of the form comfortably while leaving an impression of sophistication. I had a few states of the drawer to consider in this stage of the design: Opened, Closed, and the transition from closed -> open and open -> closed.

Transition from Closed to Open

For this stage there are a lot of potential micro animations to work with. Exciting! Let’s begin this discussion at the moment the user clicks the button to pull out the drawer. At this point in the development of my site, I had a lot of time to just mess around with the UX of this form, so I really felt like going all-out and putting extra effort into attention to detail. The average user nowadays spends a lot of time interacting with applications on a smartphone. These mobile operating systems often have smooth and low-profile elastic (bouncy) animations throughout the system, and application designers have adopted this style of animation for interactions such as opening an accordion menu or refreshing a feed by pulling down at the top of an application and releasing.

I wanted to create a similar feeling interaction here, both when opening and closing the drawer. On my form this animation is especially subtle, but I added it anyways!

When the user reveals the form, the drawer slides down (and bounces at the bottom!) and reveals a new section of the page. As this happens, I begin to fade in the inputs in order, one after the other until the submit button is present.

Let’s not forget about the button that originally revealed the form. What should we do with that? We could hide it all together and introduce a new button to retract the form, or we could repurpose this button to also retract the form when it is currently open. Using the button as a toggle sounds like a better idea, and it also provides an opportunity for an interesting animation. When the button is clicked initially, it slides out to the right, fades to red, and the text changes, indicating with both the red color and the text that the button has a new function.

All of these pieces come together to create a great, consistent interaction for the user. Now, lets move onto the closing interaction!

Transition from Open to Closed

The main goal here is to keep the interaction consistent with everything we have introduced the user to so far. Let’s keep the bouncy animation, and retract the drawer, while sliding the toggle button back to its original location and reverting back to the initial stylistic properties. This interaction ensures that there is symmetry between the open and close mechanisms, as they are both controlled by the same toggle button. The main consideration here is what to do with the form data that may have been entered before the user closes the drawer. I could run a function to completely reset the form instantly when the drawer is retracted, but the correct choice from the user-experience perspective would be to preserve the data, and just hide it within the drawer. Based on the location of the button to close the drawer, it seems unlikely that the retraction would occur by accident, but there is really no reason for us to clear the data, as it is easy enough to retain the information in case of a possible return.

Signifying Data Validity to the User

I have mentioned this topic briefly in the previous sections but let’s get into some more aspects of how the design effectively communicates the state of the data to the user in real time, instead of depending on error messages upon submission.

With the code I had written to track the validity of user input in real time, I had a great tool that I could use to trigger events depending on the information I could detect. Again, the goal with this is to instantly make the user aware of the validity of their data as they are entering it.

Previously, we discussed how the different submit button states were useful in letting the user know when the form is valid or not. However, this transition only informs the user about the validity the entire form. What if we wanted to unobtrusively let the user know about the state of each individual field as they filled out the form?

My solution to this quandary is simple, yet pretty and practical. When the user initially focuses in on an element, the once gray and unassuming underline turns into a red glowing status bar, and the label also reflects this change! As the user begins to enter data, the status bar and label will turn green when the input becomes valid. For the first and last name, company name, and message fields, this turns green as soon as any data is entered (it turns out some people have one-letter names!). However, the feature really shines when it comes to the email field where the status bar glows red until the user’s email satisfies all the requirements.

The glowing bar effect is especially strong, so I decided to rescind the bar once the user had moved onto the next input. This is where labels come in to be especially handy — they retain the color that signifies the validity of the field even after the user has moved on, so they can be aware of all the fields without being overwhelmed by multiple glowing status bars.

Wrapping Up

Upon entering valid input for all required fields, the user is rewarded with an active submit button. The journey is over — we’ve made it!

Let’s quickly review the main strengths of this form. Looking back at our goal of creating an intuitive, practical, and rewarding form, we:

Created a welcoming initial interaction after the user slides the drawer open by providing smooth, sophisticated animations that highlight the essential elements of the form

Provided clear user feedback in real-time as data was entered that made clear the status of each individual field as well as the form overall

Implemented fun and useful visual effects that rewarded the user

Blocked the submission of an invalid form by physically disallowing a button press

Used design standards that users should be familiar with not only from other sites but that were also consistent with their experience using a smartphone

Now wasn’t that fun? Let me know how you think this form could be improved!