Problem
Trivia questions appeared in multiple parts of the Well app, but the experience was far from standardized. There was also a lack of context when users answered questions. 

Project
Standardize the trivia screens for all question types and create a more contextual experience that provides more feedback and education.

My Role
I was the main designer on this project. I worked directly with a product manager to define requirements and also got feedback from my direct manager and greater design team.

Defining Requirements & Brainstorming

The project manager I collaborated with had worked hard to get this project on the Q4 roadmap, so she already had a basic idea of the project's goal written out on Confluence. Before meeting with her to brainstorm and define specific technical requirements, I did a lot of research of how trivia is conquered in other digital experiences and split them up into two main types, those with automatic check and correction and those with a gated answer check.

I then created a slide deck to share with her that broke the trivia question into different parts; button UI, contextual answer banners, and having one fluid screen with an animation or 2 distinctly separate question and answer screens. I looked at apps like Duolingo, Khan Academy, and HQ to see how they treated these specific aspects. 

For each feature, I broke down what its goal was and suggestions as to how we could improve it, followed up with screenshots of examples from other apps, ones that worked well and experiences I thought we should try to avoid. At the end, I wrote up some ideas of where Well could take its trivia. I presented the deck to the project manager and my direct manager and we talked through the examples I pulled and had a great discussion about next steps and overall direction.

As with many projects, one of the project manager's initial requirements was to have a solution that would not be too much of a heavy development lift. While I try to never let that limit design, I knew that we needed one experience flow that would be adaptable to all question types. The first step I took after our meeting was listing out all of the question types and further dissecting the existing flow to understand what worked and what didn't.

The current version required the user to select an answer option and tap the continue arrow. Then they were taken to a screen that displayed the correct answer with some educational text. The user was not given a contextual response or any feedback at all. Immediately, I realized that we would have to have a gated answer check. Even though it is so seamless to eliminate the "continue" or "check" button and not have that tap, that flow would not work for multiple select questions, so it was no longer an option.

Prototype Iterations

Each iteration of my design moved further and further from the original version of our trivia. I originally only started with mockups of the single and multi-select questions, but as I made more progress, I expanded to all of the question types since they were variations of the main two. After each iteration, I would discuss the changes with my manager and the project manager, as well as having critiques with our full design team and UX writer.  

The first change I made was eliminating the required photo on the answer screen. After building many Journey's on various topics, I ran into the challenge many times where the answer was an abstract science term and it was almost impossible to find a fitting photo. Having a required photo felt forced and took the focus away from the educational detail pushed down below it. I also moved away from the solid-colored background and towards a patterned background that added more dimension and felt less clinical, since trivia was the supposed to be the "fun" aspect of clinical Journey's. 

Button UI

Since the original selected state for answer buttons was a filled in bubble with a check mark, I had to create a new default selected state that did not connote correct or incorrect. I wanted to provide users a contextual interaction so they would know if they got the question right or wrong and then learn why. 

I had to translate this UI to all of the question types and make sure that the meaning wasn't lost when it came to more complicated questions, like the multi-image select.

We also decided to have the "check answer" button appear only after a user select began selecting. Then once a user tapped it, the screen would animate so the incorrect answers selected (if any) faded out and would be marked with "x" while the correct answers were marked with a "✓" while all remaining answers collapsed.

Banner & Answer Explanation Card UI

Early on we decided that having banners that congratulated or encouraged users would be a necessary addition to the trivia experience. A lot of these questions are very personal (like challenges about a new healthy habit) or serious when talking about chronic medical conditions. Banners were a way to add more context, whether encouraging a user who said no to taking on a challenge or celebrating one who got an answer to a difficult medical question correct. I went through many variations, but ultimately went with the white banners so they could be used in all parts of the app and weren't color dependent on the Journey.

I followed a similar style for the answer explanation widgets, so the focus would be the content and not the UI of the card. There is a reusable illustration to identify the widget as a trivia answer, which can be changed if necessary. A photo can also be added to this card for answers that may benefit from a diagram, but it is not encouraged to use for just stock imagery.

Final Iteration

After many discussions and critiques I felt like I was headed in a good direction. I fully mocked up the main question types and then animated them to show to our entire product team for additional feedback before handing off the development. 

Single Select (Correct)

Multi Select (Incorrect)

Outcome
Going into this project I thought it would be short because it seemed like a small-scale overhaul, but I quickly discovered the many intricacies that it consisted of. I learned to pay even closer attention to details, because every detail no matter how small, can still affect the overall experience in a positive or negative way. I also learned how to advocate for design with project managers who have to advocate for the development team and learn how to find balance between a good experience and a manageable dev timeline. It was also great experience to learn how to present my work to people who are not designers.