Research Phase
This tool had very limited external references available, but I could see it's potential to make a significant impact for both our clients and our internal team. When presented with this uncharted territory, I thought to myself, "What a cool opportunity to be a part of something new!"
At the start of the project, my primary objective was to gain a thorough understanding of the product itself. I collaborated with current users of the internal tool to identify their needs and requirements, using their valuable feedback to develop solutions that would meet the needs of our clients. Through this approach, I was able to create a product that aligned with our clients' expectations and helped streamline our internal processes, improving efficiency across the board. Here is a small view into that process!
Project Overview
A few guidelines and pain points were identified in the initial scoping project:
♡ Users would not be able to export external data (only MRI-Simmons data). This challenge would require that we create pretty extensive permissions around the product and reworking of the APIs.
♡ There should be an internal employee view and external client view. This challenge required that the feature have two different user flows for the same feature.
♡ We wanted to create a "21+ respondents" button for internal users to be able to filter respondents. This was a big ask as we needed to filter our study list to allow our internal users to do this.
Once these rules were established, I created a scope document so we could discuss with all parties involved the expectations of the project and see if there were additional limitations that needed to be put in place.
Stakeholder interviews, Personas, Structure, and Sketches
With the scope of the project defined and research finished, it was time to go to the next step in the UX process. For the next step, I interviewed our stakeholders and identified with them what were some pain points they faced. I really wanted to hone in on the things they loved and the things they didn't love as much about V1. Based on the research gathered with them, I created a basic persona for our clients who use this feature and created a list of the things they wanted to keep and things they wanted to improve.
Ideate and Designing Phase
For this feature, I needed two different flows. I decided to build out and test a few variations of the app. After multiple rounds of testing with both internal and external users, I finally found a flow that made the best use of our permissions system. If you were an internal user with access, you'll be able to see the full studies and customize as needed. However if you were an external user, we would adjust the permissions so you can only go through the normal customization flow.
Overcoming Challenges & Pain Points for the user
As with any project there are challenges. One issue the user faced was deciding how they wanted their export to look and the impact it would have on the data visually. They needed to be able to see and feel secure with what the data would look like before committing to a several-hour-long download. Unfortunately, V1 didn't have a way to address this issue.
After some deliberating, I was able to come up with a solution! We decided it would be a clever solution to build out a responsive dummy data set using fake data. This would make things easier on the developers and sped up the user experience of updating answers. Win-win! Now, users could modify their data set themselves, which wasn't possible before.
Another pain point and challenge was flow. We had two types of users, internal + external users. The internal users needed to be able to export full study data or pull in large sets of data, where the external users on the other hand would only have access to the Composer (or data builder tool) and the export options. The challenge was making these two flows compatible.
The solution became Admin Permissions and combining the flows. Internal users who would have access to Internal RLD, would see their own view, be able to choose clients as they needed, and to be able to export full studies. In this full study mode, they would be able to export full studies and markets as they did before, and be able to take advantage of the export options builder.
Planning Phase
While there ended up being lots of things we addressed, for the sake of brevity, I will move on to creating the pages and planning the sprints.
I broke each feature down, building a list of questions to answer with the stakeholders. I would come each week with a new part of the feature I had broken down. I would discuss with various groups (from developers, to data scientists, to account managers) the questions I had and would get feedback. Once those questions had been answered, I would write up developer tickets to be planned for future sprints, and we ended up with about 80+ tickets.
Next step on the list was planning out each sprint to ensure we were able to make our deadlines. I broke each section down into manageable sprint cycles, collaborating with developers to get an accurate read of the project.
Launch!
Finally after months of work, lots of collaboration and just a few tears, we were able to launch the new V2 version of Respondent Level Data!
Post Project Reflections
Post project, I continued to iterate and update based on feedback we got from clients but as a whole, the project was a success. Through testing and working with clients, we were able to launch this new feature and had an increase in sales because of it. I learned so much throughout this project but here are some of the key takeaways:
♡ Talk early and often with your stakeholders throughout the project. It will save a ton of time in the long run if you make good relationships with them.
♡ When you have multiple types of users in the same feature, utilize the permissions.
♡ Take notes. Record if you can.
♡ You and your team got this.
