This is something I've done multiple times during client work, and thought it would be a fun read for those of you who enjoy UX/UI design. We're going to piece together a survey that walks folks through picking a pet. For the sake of simplicity, we're limiting the parameters to dog/cat, size, and fur length. Ready?
We need to begin by identifying the inherent steps/decisions within a survey, and the typical problems in presenting one effectively to your audience. These help us predict our "user path" through the experience. This should happen before pen ever touches paper, or a single line of code gets written. Fortune favors the prepared.
This one is pretty simple. Surveys are typically a group of questions used to identify either specific user responses or to generate trend data. The typical decisions during a users survey experience are as follows:
This can happen any number of ways, but typically involves an email, a banner ad or some kind of "large net" acquisition strategy. We won't be covering this part of the survey experience because it is more marketing-focused, and we're playing in the UX/UI arena right now.
This step occurs once a user has become sufficiently interested in the survey to click on a link to it. It's important to realize that this does not mean that they've committed to taking the survey yet. Because of this, we need to make it attractive to them to finish the quiz. There are two avenues we could pursue here - either drop them right into the quiz, or present a landing page style approach with a brief encouraging statement. Both carry benefits, but we're going to go with the second option as it offers a filter for non-committed users and a value prop for those that will actually take the survey. Dumping users directly into the survey does not offer this - and while this eliminates the friction of having to read the intro sentence and click the begin quiz button, it also creates a disconnect between the user and the intended result of the survey.
This one should be relatively obvious. The entire point of a survey is to get answers to your questions. If you missed this one, well... UX isn't for you.
That being said, this area is the main point where we get to control the User Experience, and will warrant some more discussion when we get down to actual execution.
This is where things get a little less obvious. We aren't walking an imaginary user through our process—we're attempting, through research, experience and testing to predict the obstacles that will prevent our users from completing the survey. If we can anticipate these obstacles, we can design the survey to avoid them. Some examples:
It's important to realize that obstacles are not always obvious immediately, which is where the value of A/B Testing is found. When in doubt, TEST.
So the very first step in designing a survey is to identify the goal. Our goal for this survey is to provide a suggested pet for the user based on their responses. Simple enough.
Next, we need to identify the specific questions that guide the user towards that goal. As mentioned before, we're keeping things really basic by letting them pick dog or cat, fur length and size. A real survey would probably be more in depth than this, but we're primarily after the UX part of things.
The questions that we're using are as follows:
Now, you might think we're done writing content. You'd be wrong. Our survey generates a response for every single combination of answers possible. We have three possibilities for size, three possibilities for fur and two for species. 3x3x2 = 18 possible responses. Aren't variables wonderful?
We won't go into each response here—suffice to say that they're all written. Some are even funny!
Most surveys that you will see present their questions one at a time. The purpose of this is to bring focus to the question at hand, and to keep the questions from running together. This is the presentation that we will be using, but with some specific improvements.
An issue I've noticed with this approach is that many surveys will load each question on a new page, which causes a slight disturbance in the UX of the survey because of the page reload. To resolve this, we're going to load all of our questions on the same page, and reveal them with a sliding motion, one at a time. We'll also slide the landing screen up and out of the way to reveal the quiz when the user begins, to further smooth out the experience, and keep them on the same page.
I've also never thought that the "multiple choice" format was ever the ideal way to present questions with more than one answer. It tends to require more words on the page than simply placing the choice buttons within the actual question—which is what we're going to do. This approach also keeps the natural language of the question as prominent as possible, and eliminates some of the confusion associated with 'word problems'.
Now that we've addressed the survey experience, how should we handle the results?
Since we're receiving answers and then inferring a recommendation based on those, we need to show both the pure results and our subsequent advice. We're going to use natural language again, and include variables within that language. The first sentence will provide the results, and the second, our recommendation.
The first sentence will be in the following structure:
"You prefer **size variable** **breed variable** with **fur length variable**."
An example would be "You prefer large dogs with short fur."
The second sentence is much more free-form, case-by-case, and less dynamic. It needs to be out of necessity to be because otherwise we're talking about a much more in-depth bit of JS (which I may very well tackle for fun at some point).
We're not going to cover the coding of the survey in this post, since I'm concentrating more on UX—feel free to check out the Codepen to explore that. So without further ado:
Thoughts? Questions? Rants? Start a thread in the comments below.
Did I help you out?