Fall 2019

We were tasked with adding a new feature to the InCrowd Interview Platform that would allow users to create a project using their own "pre-validated list" as a type of custom crowd. This would allow users to target a specified group of people, even if they are not part of InCrowd.

In certain situations users wanted to use the InCrowd platform to send out a survey to a specific list of people they already have target details who aren't necessarily in InCrowd's crowd (ie. the sales team within their company).


We needed to create a way for users to send out a survey to a list of people and target details they provided and confirm that they have permission to contact them. We created an InVision prototype to handoff to development.


My Role
I worked closely with my manager to brainstorm solutions and create initial workflows. I was mainly responsible for the high fidelity mockups and prototypes.




This new Pre-Validated List feature was in the product pipeline way before I became a part of the InCrowd team in September (it was actually called BYOC, Bring Your Own Crowd when I joined). Therefore, the main part of PVL that I was involved was the UI and integrating it into product workflow. Since there was already another type of custom crowd, List Match, we decided that they would be grouped together, so when a user is creating crowds for a new project they would have to choose between a standard crowd, which is sourced from InCrowd's crowd, or a custom crowd, which will then lead them to a choice between List Match and PVL. My manager and I first brainstormed on our own and then came together for a brainstorming session where we narrowed our thoughts down to two main options. One option would be listing both types of custom crowds under the custom crowd tab on the new project creation page, so before committing to a custom crowd they could read a blurb about each type and then select one, which will open the prospective modal. The other option would be to have a only one custom crowd modal and a toggle between List Match and PVL in the modal. Once the user selects one then the form would adapt to their selection. The main downfall we found for this option was that it was a lot more clicks than the first option. If we didn’t want to have the form default to one of the custom crowd types, the user was unsure they would have to select each one to read more about them. After considering this we decided it was a better solution to have more of the information upfront so the user could make an informed decision with less difficult back and forth navigation.

Low to High Fidelity

After roughly sketching, I moved to sketch to mockup our solution so we could easily show developers and stakeholder when we were asking for certain missing requirements and for feedback in general. After a first round of meeting with developers and discussing the prototype, they began to work on the back-end functionality of the feature as we continued to iterate on the UI of the prototype. We had to meet with stakeholders multiple times to eventually get the exact business information we needed to include. Everytime we made changes to the prototype, we would make sure to continue to meet with developers and stakeholders to assure we were on the right path. We also had to meet with our Product manager and a stakeholder several times to finalize a client-facing name for the feature since we did not want to market it as "Bring Your Own Crowd." Since "List Match" is a standard term in the market research industry, we wanted to include similar terminology since they are similar features. We also wanted to emphasize the fact that the company must have gotten communication consent from everyone on the list, so we decided on "Pre-Validated List."


When a user is creating a new project, they have to start creating participant groups, also known as crowds. When they get to this step they have the option to toggle between Standard Crowd, which is sourced from InCrowd's network, or a Custom Crowd/List Upload, which includes List Match and PVL. We added a tooltip to explain the custom crowd options to when users hover over that tab they can learn more about all of their options. If they click on custom crowd, they will be able to read a short blurb about what custom crowds are and then additional blurbs that differentiate List Match and Pre-Validated List. The modals for both options are very similar as well, the main difference less information is required because clients are providing contact details for everyone and they have to validate that all the individuals have consented to third party communications. 


After the user completes the process and their PVL is approved, then every time they go to create a new project they can just select their crowd from the drop down under Use an Existing Custom Crowd, just like they have been able to do with List Match. Our solution to integrating PVL keeps the main workflow intact so there will be a short learning curve for all of our users.

Email Communication


The first project I worked on during my time at InCrowd was redesigning all of their emails that went out to responders. We created a cohesive design system so if there were needs for any new emails they could easily be created. Due to the fact that the Pre-Validated List feature is contacting people who have at some point given consent to third party communication, they might still not know who InCrowd is. To avoid being reported as spam, we created a whole new set of emails to introduce these new users to InCrowd and get a higher response rate for projects using a custom crowd. I finished the new illustrations for the icons in each email and our Product manager wrote preliminary copy, which we edited. We also worked together to establish the flow of emails and when each one would be sent during the PVL process, for both sides of our platforms (surveys and interviews). We then had three meetings with stakeholders and people from other departments in the company, like Marketing, Sales, and the Crowd team, to finalize the copy. Since most users primarily use their phone, we made sure that once developed the emails would be an excellent experience on both desktop and mobile.  


This project helped me learn how to better look at experiences as a whole, from the UI to how users are contacted. It was especially interesting thinking about how we could contact people we have permission to contact but aren’t in our network and make it not seem like spam. I also got more experience learned how to add features into an existing framework, focusing on not disrupting the current user flow.