PERRLA’s Contact Support page was outdated and confusing for our customers, and it was causing problems for our support staff. We redesigned the form by removing confusing content, displaying proper field information, and updating the UI.
These changes made the form easier for users to fill out and prompted them to provide better information to our Support team – which allowed them to diagnose and solve user’s problems faster.
In early 2018, we were wrapping up a fairly ambitious project to overhaul PERRLA’s Help Center with the help of Zendesk. In this project, we had spent a great deal of time ensuring that our new Help layout and articles properly addressed our user’s questions.
But then we remembered this.
While our new Help Center was working better than it ever had before, our Contact Support page was still stuck in the past.
Not only was it out of style, it was wholly inadequate for handling questions about our shifting product lineup. Many of the questions were concerned with matters that could be helpful to our Support team, but were beyond what most of our users knew how to answer (like their exact OS or Microsoft Word version). In some instances, the options that a user could choose from were out of date and no longer available.
The form also failed on a number of modern, accessible heuristics. Required fields were not distinguished from optional ones. If a required field was missing when a user tried to submit the form, the missing information wasn’t highlighted for users to fill in. When it was submitted successfully, the form would just reset without a noticeable success state – causing numerous users to submit their Support Requests multiple times since they weren’t sure if it went through.
In essence, the form was clunky, outdated, and functionally broken.
Outlining the problems with the existing page and creating a new design to address these issues was fairly easy. Most of the problems themselves could be fixed by updating the page with the custom Bootstrap & Vue frameworks we used on other pages, and then providing better text for the missing pieces. However, there would also be other design challenges to face off screen.
This page already functioned as an important point of communication between users and our Customer Support team. We would need the buy in of our Support manager and team for all of these changes to be successful.
Because this was the first place for a customer to give us information about the question or problem they faced, the mindset had been to try to get as much information up front as possible. However, we should be able to obtain the information necessary for our Support team automatically by detecting the OS and browser used to contact us.
I was now ready to meet with our Customer Support Manager to hear his perspective on the form and earn his buy-in on any proposed changes.
I started our meeting by reviewing the current state of the form and demonstrating the problems I had identified so far. Before discussing the ways that I was hoping to address these problems, I asked him to share his thoughts on how the form was working and what issues he would want any update to address.
To my surprise, he began to explain how many of the fields that I had found troublesome myself (but hadn’t shared with him yet) were also problematic for our Support members.
For instance, in the existing form we gave users the ability to select both the version of Microsoft Word they were using and their OS version. This was originally intended to allow users to provide some clarifying information up front. However, both the Word and OS version fields tended to hinder our Support Team more than help them.
Our typical customer was usually only aware they were using Word and if they were on Windows or Mac. Instead of leaving that field blank, they would pick an option randomly. When our Support Team would respond, they would include instructions for the versions the user had selected. However, more often than not, the user would write back saying the instructions didn’t work. It would only be a few emails later that we’d discover we were giving them instructions for the wrong version of Word. As a general rule, our Support team was told to generally ignore those fields completely and only rely on the basic OS system they had selected.
The only secondary field that was actually helpful to our Support Team was the dropdown where users could select the type of problem they were having. However, most of the options left in that list were out of date. Together, the Support Manager and I created a new list of options that corresponded to the new Help categories available to users in our new Help Center.
Even with these discoveries, the Support Manager was hesitant to remove some of these fields completely. However, he acknowledged it was probably best. We agreed to try removing the fields in the new form. After two weeks, if Support Responses were slowed down by a lack of information or the Support Team wanted them back, we would add them into the form once again, albeit with corrected and up to date options.
At this point, I felt I had enough information to start putting together a design.
Drawing on our existing style-guides and the information I had gathered, I started to lay out the basic elements we would use to create the new contact form. There were three large changes that I made to the contact page.
First, I removed any superfluous and non-support content.
On the original page, a sidebar offered some of the important details about Support availability paired with an attempt at humor. While the quality of the humor is up for debate, its placement on this page is troublesome. Users only end up on this page if they are either having trouble with our product (so their frustrated) or because they have a question about potentially using our product (potential sales). In both cases, humor is the wrong message to send.
There is also the problem that the most important information was placed in a sidebar outside the main flow of the page. This not only created problems visually, but it would also be problematic for anyone using a screen reader. The information about when and how we respond to Support Requests wouldn’t most likely never be reached because it would come after the form itself.
Second, I rewrote the text on the page. I was able to condense the text and give it a better layout for readability. Before, it was a large paragraph that blended into the top of the form. This had the effect of causing users to skip the text altogether (as verified in mouse tracking data).
I wanted to make further changes to the way we were showing this information, but was unable to due restrictions on the project by the final decision maker.
Third, I updated the fields so that they followed best-practices for usability. Each field was given a clear title that explained what the field was for. Required fields were marked as required - taking the guesswork out of when a field could be submitted. I updated the error-state text for each field so it explained why we asked for that information and how it would let us better help users.
In addition to the form’s empty and error states, I also redesigned the form’s success state to make it obvious that the form had been submitted, rather than just refreshed. Now the entire form would be replaced with a success message that also informed users how they could expect a response. This gave them a clear notice of the submission and reminded them that we’d respond via email.
I also made a number of smaller updates that brought the form into alignment with the UI guidelines we were using in our online tools.
After a few weeks of using the new form, I sat back down with our Customer Support Manager to assess how the transition had been for the Support team. He said that our Support members were encountering fewer submissions with misleading information, fewer duplicate requests, and were having to ask for clarifying information less frequently.
The automated inclusion of the OS and browser version gave our team enough information to provide helpful feedback even when the problem couldn’t be solved in a single response. This meant that even when multiple rounds were needed, users were taking fewer failed actions as a result of our incorrect diagnosis. The updated dropdown options that allowed users to self-identify their issue was also particularly helpful.
Overall, the final design allowed us to make substantial improvements while minimizing the effort required by our development team.
Due to development and business limitations, I wasn’t able to make all of the changes that I would have liked in this round of updates. However, there is one adjustment that I’d like to see.
The amount of text on the page could be further refined and better displayed. While we describe when and how our Support team answers questions, a more proactive approach could better educate users about that process.
For instance, PERRLA only provides support via email between the hours of 10am and 10pm Central Time (US). A dynamic display that would change based on the time of day could let users know the state of our support team.
For instance, from 10pm to 10am (while we our Support team is off), we could let users know we are currently off-the-clock but will respond to their request via email tomorrow morning. During the work day, a similar notice could tell users we are actively answering requests via email for another # hours. During the final hour of availability, we could adjust again to let users know that we are trying to answer any remaining requests tonight, however if they don’t get a response tonight, they can expect one first thing tomorrow morning.
Overall, the progress made on this page was positive and helpful for our team and users. Continuing to make these smaller scale improvements as we have the resources will help make our troubled users feel more confident in our software and ability to help.
