Problem
The registration page for InCrowd was made before there was a single designer at the company, so we knew we had to redo it but didn't know where the worst pain points were. 

Project
Potential users who were attempting to register to become InCrowd responders struggled immensely with the multi-select section where they were asked to select their professional specialties.

My Role
My manager and I each looked at and analyzed 50 hotjar recordings of users attempting to register. From there we continued research on different ways to display multi-select questions, eventually creating a high-fidelity prototype.

Hotjar Data

Hotjar Recordings
After our 100 hotjar recordings were complete, my manager and I spent the next few days watching and analyzing them. We took note of the platform they were on, the browser they used, their operating system, the point they dropped off, and the profession they selected. It was important to see what profession they selected because not all professions have the specialty multi-select field. We also took notes about the users behavior and if they successfully registered, if it was a true attempt, and the duration and true duration of their attempt. My manager had previously analyzed registration recordings in May, so after completing these in September we merged all of the data together. 

Hotjar Analysis
After analyzing all of the recordings, it became obvious that the main pain point during registration was the speciality multi-select in the active physician form. Since all the categories and specialties were in one continuous list there was only a 80.95% success rate for users that truly tried to complete the registration process, and most of the 20% dropped off after they struggled with the specialty multi-select. Additionally the average true completion time was 2 minutes and 53 seconds. We started redesigning the entire workflow, but because we didn't have development bandwidth to work on such a large project immediately, my manager and I decided to first immediately change the multi-select in the current form because we did not want more users to have to struggle with such a bad experience and because active physicians are one of the most common user groups.

Brainstorming & Research

After my manager and I wrote up a document analyzing all of the Hotjar data collected over the year, my manager and I both explored the registration form to identify the main issues with current multi-select. The main issues we discovered were the lack of information visibility, the disorganization of the categories, and the bad experience for edge cases that selected more than a few specialties.

Next we started sketching some ideas for a solution to this problem. The first thing we did was write all of the criteria we had come up with from our research and things we wanted to keep in mind while brainstorming. One of our main focuses was making a solution that was optimized for mobile since the majority of our users use a mobile device instead of a desktop. We also considered the data that almost half of the users only select one specialty and another quarter select only 2 or 3. This is because users aren't browsing the specialty list but actively searching for their specific ones.

Show All Options In Bubbles
The first solution we sketched was to have all the categories and specialties listed and visible to the user at all times. After doing some research this was proven to be one of the best ways to display a lot of information. Selected items would change in appearance. Search could be implemented; all items that are not search results would be removed and only return when the search bar gets cleared. We also thought of potentially moving each selected item to the beginning of it’s category. 

Expand/Collapse Category List
All categories would be listed and can be collapsed or expanded to show all specialties in that category. Another variation of this would be to have two sections; one with the expandable/collapsible categories and a second section that displays all selected specialties, which would be removed from the second list if clicked on again. Search could be implemented, all items that are not search results would be removed and only return when the search bar gets cleared.

Modal Options
We thought of 3 different mockups that could involve modals:
1. Each category has its own modal that allows the user to select specialties within that modal. It could be searchable, so selected items will float to the top. Users would have to submit to commit selections, after the modal is gone it would show all specialities selected next to the corresponding category on the Registration page. 
2. One select specialties button would bring up a modal. The modal would function exactly the same as the show all options in bubbles solution listed first. Selected specialties would be shown in the main form under the select button once the user submits the specialties. 
3. Has the same principles as Modal Option #1, except instead of a modal it is an overlay with all selections for that category. User has to submit to save specialties which are displayed in the form near the categories.

Low to High Fidelity 

After sharing our brainstorming session with the Crowd team and listening to their feedback, we decided to continue developing the expand/collapse category list mockup. We chose to continue in that direction because we felt like it was the perfect balance between showing the right amount of information upfront and the right amount of clicks. One of the issues that the crowd team runs into is when users have an exaggerated amount of many specialties, so they showed hesitation around the option that showed all of the specialties to the user with no clicks. By having the categories collapsed and in alphabetical order, the user would be able to quickly identify which category they need to expand and then select their specific specialties, without an excessive amount of steps.

Prototyping
After meeting with stakeholders and deciding what direction we were going to continue in, I started creating a higher fidelity mockup in Sketch and InVision. We made sure to also make a full mockup for mobile to assure it would be a great mobile experience as well. After every iteration, we would meet with developers to check in and make sure everything was still feasible.

Outcome
This was the first time I got to use Hotjar and watch actual people using our product. Since in school there isn't much opportunity to get exposure to UX research, this was a very exciting opportunity for me. I learned how to analyze user behavior and use that to inform design decisions.