As designers of interactive media, we’re often faced with the task of asking users to provide information. Usually this results in a basic form with a set of fields and (hopefully) labels. As we need more information, our forms become more complex and completion rates drop.
“Design is a conversation between designer and user, one that can go both ways, even though the designer is no longer present once the user enters the scene.”Don Norman
On a recent project, we needed to build a web interface for users to report road problems throughout the state. As you might guess, there are lots of different scenarios that users might want to report: potholes, things (trash, animals, trees, and more) in the road, missing signs, broken signals, etc. We had to distill a very complex series of options into something that felt simple and quick.
We started by listening. We sat in on phone calls between customer service agents and citizens calling in to report various problems. We made note of where agents had trouble getting the right information over the phone. We pored over spreadsheets looking at the most common problems and what data was necessary for the context of each problem.
It quickly became clear that this could not be a simple form. The more we listened, the more we realized that our form would have to be conversational. It would need to feel as though the form was listening and responding to users to help guide them through the process.
How we made it conversational
1. Identify the basic essentials
The first step was identifying the basic information we needed regardless of the problem. In this case, we knew:
- that citizens had a reason for visiting the form (their problem or question)
- that we would need to know where the problem was occurring (for most reasons)
- that we would need to be able to contact the citizen to potentially get more information or inform them of the status
- that we would need further details for the user to provide more context
Once we had the basic framework, we were able to build our conversation around those major areas: Need, Location, Detail, and Contact. The result was similar to a software wizard, where each step in the process had its own screen.
2. Make it reactive
Next we wanted to ensure that we were only gathering the information necessary based on the request. Was it a problem to be fixed or a question to be answered? For things that needed to be fixed, what would the service crew need to know to do their job?
The first screen started with the Need of the user. Did they need a road repaired? Was there something in the road that needed to be removed? Did they need signs repaired? Did they have a general question instead?
As they selected their need, contextual questions gave an opportunity to add more depth. Selecting that they needed something removed from the road led to asking them what they needed removed: animals, trash, trees or limbs, etc. If the user responded that they needed information, we were able to provide quick links to the right spots elsewhere (and hopefully prevent the need to submit a request altogether).
Once the user told us their need, the rest of the form continued the conversational tone. In asking for their location after they specified a pothole, we didn’t ask “Where is the problem?” but rather “Where is the pothole?” When they got to the details, we used the context of the need to provide further prompts: “How big is the pothole?” vs. “Tell us more about the debris you saw.”
When we tested the form with users, the reactive nature of the form led many of them to remark that they felt like the form was listening to them.
3. Write like you talk
Another key of making the process more conversational was writing as though the user were listening to someone and responding. We addressed the user as “you” in questions and labels while their answers (especially dropdowns and radio buttons) used a first-person context. For instance, the form opens with How can we help you? and the answers are I need a road repaired, I need something removed from the road, etc.
We wrote the script before creating a single design. We would often read it aloud while writing to see if it felt natural to say something. We used nested bulleted lists and then eventually a spreadsheet to keep track of what questions affected other questions and how.
4. Show don’t tell
Sometimes words aren’t the right way to ask for information. When writing a question about drainage problems, the customer service team needed to know if the problem was related to a ditch, culvert, or drop inlet so that field agents would know what equipment to bring to fix the problem. Do you know what the difference is between those? We didn’t and neither did the users. Rather than add more complexity by trying to describe the differences, we simply added pictures of each.
Most forms asking for a location assume you know the street address and ZIP code. In many of our cases, users often weren’t as familiar with the area, particularly not enough to give a street address or ZIP code. So instead, we asked them to show us on a map roughly where they were and extrapolated out the address. We then gave them the opportunity of writing down nearby landmarks or intersections to help crews find the right spot.
And again, when asking for details, instead of only providing a big text box for the user to write in, we also provided an opportunity for them to upload a file. That way, they could take a photo of a road problem, which would hopefully give even more context than their text possibly could.
5. Provide smart shortcuts
One of the advantages we gained from mountains of previous request data was knowing the most common types of problems and the most common data points within them. So for instance, we knew that dead animals were reported more frequently than debris in the road. Furthermore, we knew which types of animals were reported most frequently. We used that information to determine the order of our options for question responses. We listed the more common responses closer to the top.
When asking for the location of a problem, we allowed the users to opt in to providing their geolocation. This allowed them to quickly narrow the search area to places near where they were.
6. Test it and iterate
Throughout the whole process of building the system, we ran users through it repeatedly. We learned where they got confused or looked in the wrong place. We asked them to envision different scenarios to go through. We asked them to report problems on the road they’d seen recently and would actually consider reporting. Then we iterated where we saw problems and updated the conversational cues.
We ran through it with customer service agents to make sure we were gathering enough information for each type of request and to get an idea of follow-up questions they’d pursue. Again, we iterated and tested to find the right balance between customer service needs and user understanding.
Do you have a flow or process in your app that’s complicated and overwhelming? Would a conversational approach make it easier for your users? Start with the basics, then build out reactions. Write your copy first and read it aloud to make sure it feels natural. Show your users complicated things rather than over-explaining them. Give them opportunities to do the same. Give them smart shortcuts by using data available to you. When possible, give them smart defaults to save them even more time. Make sure to test and iterate repeatedly until your conversations feel smooth and natural.
Here are a few other resources to help you get started: