Problem
InCrowd Interview users did not have an easy way to reuse screeners they wrote for crowds in the same project or for crowds in other projects.

Project
We needed to create a way for users to import and export screener questions. 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.

Brainstorming

After a sprint planning meeting where the product and development teams discussed the user problem of not being able to reuse screener questions, my manager and I each started brainstorming and sketching solutions on our own before coming together and sharing our ideas. We found that it was very valuable to first digest and process the information individually first and then work together to bounce ideas off each other to define what direction we were going to take. First, we compiled a list of requirements taking elements from our planning meeting and details we thought of on our own. We wrote various levels of requirements, from the MVP to the most robust product we could think of. After that we both started sketching an idea we had, fully explaining why we made certain decisions so the other person could easily expand on that idea. My manager and I typically set aside an hour to thoroughly go through all the possibilities and decide what few ideas we were going to keep developing.

Low to High Fidelity

After I mocked up the few directions we chose to continue exploring in Sketch, my manager and I met with developers and stakeholders to present the InVision prototype to show them what we had done so far. We would take their feedback into account when iterating on the work we had done. After a first round of meeting with developers to determine what would be technically feasible for the MVP, we decided what direction to further iterate on. 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.

Favoriting
The main problem our user's were describing was that once they don't want to retype screener questions. After talking to our Crowd team who had talked to a lot of our users, it seemed that typically they would have a few sets of screener questions that they wanted to reuse all the time. The optimal solution we thought of was having a flagging system, so users would be able to favorite a set of screeners by selecting the star next to the crowd name or the option in the three dot menu. For the MVP, the favorited screeners would only appear in the import screener questions modal. 

Importing & Exporting
For a crowd that doesn't have screener questions yet, a new import screener questions button would be next to the already existing add screener questions button. For a crowd that already has screeners, the option to import & export screeners would be in the three dot menu. 

Export & Import Modal
The UI of the export & import modals are almost exactly the same. The only difference is that the import modal has section that shows the favorited screener questions. Originally we had included the favorited screeners in both modals, but after thinking more thoroughly about the workflows, we realized a user would never export to a crowd with favorited screeners because that would override them. The first element in the modal is the current project the user was viewing. It is already expanded so the user can see the crowd them are importing to/exporting from (the grayed out option) and all the other crowds within that same project. Beneath the current project in the import modal, there would be the section showing all favorited screeners. It would show the project already expanded and the favorited crowd from that project only. The last section in both modals is a list of all of the user's other projects. They would have to click on each project to expand it and view the crowds within it. After a user selects something, they can then select the import or export button to complete the process.

Confirmation Pop-Up
Once the modal closes and returns them to the project they were viewing before. We designed a confirmation pop-up that would say questions were exported or imported from a certain project to another. The project names would linked so the user could easily reference what changes they just made.

Defining Requirements

Once we felt we the design and functionality of the MVP was ready to implement, we started discussing more defined and specific requirements so I could write the tickets for the developers for the MVP. I learned the correct way to format tickets with a user story, success criteria, and linking anything necessary for development. I also learned how to talk to stakeholders and developers to assure the MVP was on track with product requirements.

Outcome
This project helped me gain experience working with difficult problems that don't have clear solutions and gave me more practice working on pre-existing products. A lot of the times in school, you are told exactly what you have to do for a project and only work on things from scratch. It is a lot harder to make changes and updates that fit well into an already existing system. I also got more exposure how Agile works with large teams, specifically designer to developer handoff. It was very helpful for me to learn how to write tickets because it made me aware of links or assets to always include and what I needed to specify so the developers would be able to start working right away just from reading the tickets.