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 it turns out, there are a lot of different things that people 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 in the context of each problem type.
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 feel like a conversation. It would need to feel as though the form was listening and responding to users to help guide them through the process.
Making it conversational
1. Identify the basic essentials
The first step was identifying the basic information we would need 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 these 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 needs 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 need something removed from the road led to asking them what needed to be removed: animals, trash, trees or limbs, etc. If the user responded that they needed information, the form gives quick links to the right spots elsewhere (hopefully preventing the need to submit a request altogether).
Once the user told their need, the rest of the form continued the conversational tone. In asking for their location after they specified a pothole, it doesn’t ask “Where is the problem?” but rather “Where is the pothole?” When they got to the details, the context of the need drove 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 and form choices (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 layout. 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 that ask for a location assume you know the street address and ZIP code. In some of our cases, users often weren’t as familiar with the area, particularly not enough to give an exact address. Instead, we asked them to show us on a map roughly where they were and extrapolated out the address. We also used geolocation so that they could tap a button to have it pinpoint on the map where they currently were. We then gave them the opportunity of writing down nearby landmarks or intersections to help crews find the right spot.
When asking for details, instead of only filling in a big text area, users could upload a file. That way, they could take a photo of a road problem, which would give even more context than writing something would.
5. Provide smart shortcuts
One of the advantages we gained from the heaps 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, users could give their geolocation with a single tap. This allowed them to quickly narrow the search area to places near where they currently were. (They could then drag the marker around the map to further pinpoint the right spot.
6. Test it and iterate
Throughout the whole process, 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 better understand the follow-up questions they’d pursue. Again, we iterated and tested to find the right balance between customer service needs and user understanding.
Wrapping up
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 the 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: