Pluralsight is an online technology learning platform. Their product has thousands of courses related to tech to help people grow their skills. Pluralsight is growing quickly which can present challenges as their product teams grow in number. Although they use Directed Discovery in all their product teams they’ve found that every team is implementing their own variations of the process and that the teams are also often duplicating research because of a lack of communication between teams. I have been tasked with 3 other designers to work on a tool that will house all the research their design teams do with Directed Discovery.
Note: If you’re unfamiliar with Directed Discovery, you can read about it here. https://www.pluralsight.com/blog/career/product-development-directed-discovery
To begin, my team and I started by doing competitive research on other UX research related tools. We found a lot of the tools that did similar things as we wanted out tool to do. We took note of the things that we thought these tools did well for later use when we would start prototyping.
We also did a lot of research on synthesis since this would be a massive part of the tool that most other tools do not do. We wanted to have a really good understanding of what good synthesis entails. This video of Danielle Green from Jane is an excellent summary of what we found.
Apart from interviewing our key stakeholders to get an idea of what their vision was for the tool and what they say as the main the pain points to solve, the best research we did was a survey sent to all the PMs and UX Designers at Pluralsight. We wanted to get an idea of what doing Directed Discovery at Pluralsight was like, and what their major frustrations were with the process.
After synthesizing the results of the survey, and combining our results with previous discussions with stakeholders, this is the list of problems we gathered that out tool needed to solve.
- Research is done in inconsistent ways. Everyone is doing their own thing
- Synthesizing data is not happening as much as it should be because it’s tedious and difficult.
- Research is often duplicated because the findings are all stored in different places.
- Maintaining a broad vision of the whole research and not focusing on one thing users said is extremely difficult when your data is scattered
From the research we also learned:
- The main methods users are using for research at Pluralsight are interviews and surveys
- Users are spending about 3 weeks per stage of Directed Discovery
- When users are doing a study, they’re usually interviewing 10+ people per discussion guide
We started by creating a journey map to understand the process our users were going through every time they Directed Discovery:
We also created a site map and an affinity diagram make sure we understood all the features that were going into the app and where they would live.
Once we had planned and organized where all the features would go we created a low fidelity prototype for user testing. The prototype can be seen here:
From a little bit of testing, and some conversations with our key stakeholders we learned that our initial idea was a little bit off. We had too much navigation in our initial prototype and we wanted to make it easier to jump in and start working. We also found that we had too much instruction, rather than just explaining to the user what they should do next with design. With those things in mind, we iterated and are currently working on this design:
This project, when implemented, is going to greatly benefit Pluralsight. They will be able to keep all of their research in one place, which will be searchable by every design team at Pluralsight, eliminating redundant research. They will be able to easily auto synthesize their interviews and surveys saving time and helping ensure that synthesis is done for every research study. Finally, design teams will be to stay consistent in the way they’re doing research while still maintaining the flexibility to meet specific project needs.