Help guide them through Directed Discovery

Duration of project-4 weeks
Pluralsight’s website

For those of you don’t know Pluralsight is a technology learning platform. Their mission is to democratize technology skills to literally everyone (except maybe the Sentinelese). Pretty cool.

Plurasight uses a design process called Directed Discovery which consists of 4 parts. Currently they are Personas, Voice of the Customer, Customer Preference Test, and Customer Confirmation Test. Because of rapid growth in the company they are hiring a ton of people. They have seen a problem that some teams are not using Direct Discovery or skipping crucial steps and they have seen that there’s siloed research resulting in redundant data.

Problems and Complications

To begin our project we had a kick-off meeting with Angela Payne, a Sr. Product Manager at Pluralsight. She gave us a high-level overview of the Directed Discovery process and told us some of her concerns with the actual application of the process on experience teams. One of the slides in her presentation said the following:

Pluralsight is in a time of rapid growth where our platform learning experience is rapidly evolving. Our current design thinking process that supports our ability to deliver user-centered experiences, called Directed Discovery, is manual and siloed. We need a proposed prototype for a web-based tool to centralize, automate and support cross-functional collaboration of experience design and validation testing.

Much of what she said resonated with our own experiences in conducting qualitative customer research. It can be very difficult to keep cross-functional teams consistent during customer interviews. And customer interview notes also tend to get buried in Google Drive folders that are difficult to synthesize and track. We formalized these hypothesized problems into the following three statements:

1. The inconsistent application of Directed Discovery within experience teams can lead to poor results.
2. A lack of experience within some experience teams can cause an improper use of Directed Discovery.
3. Siloed data from Directed Discovery can create repeated research between different experience teams.

Existing Software Solutions

Our studies of existing software solutions that might help Pluralsight with Directed Discovery led us to RealtimeBoard, Milanote, and Notion. We looked at:

• Note taking capabilities of these products since so much of Directed Discovery involves capturing quality notes on customer feedback.
• Notifications systems.
• Collaboration abilities since Directed Discovery is a team sport.
• Project sharing abilities across teams to avoid siloed data.
• Assignments to individual team members.
• Document archiving to replace the need for hundreds of Google Docs.

Milanote and Notion both have potential for Pluralsight. For the sake of the project, we decided to also consider what the optimal web-based solution might look like.

Our Methodology

Step 1: Mapped out Directed Discovery process

Using the pain points from above as a frame of reference, we spent our first working session building out a customer journey map for UX designers, product managers (PM), and engineers during the Directed Discovery process (see Figure 1). This journey map helped us identify potential weak spots where things could break down.

Figure 1: Flow chart of the journey map for UXDs, PMs, and engineers through Directed Discovery.

Step 2: Created paper sketches of potential designs

In order to avoid groupthink each member of our team took time to sketch out their own vision of the potential software solution. At this stage, we kept design ideas flexible and allowed each person to create their own vision of the end product. Because we kept these initial sketches low-fidelity it enabled our team to quickly iterate through different ideas. We each took a day to create our own paper sketches.

Step 3: Voted on our favorite feature ideas

We came back together as a group and took turns showing each other our rough drawings. It was interesting to see the variance between each person’s designs. Since we had all gone through the paper prototyping process independently, we had begun to develop different opinions about which features mattered in the software solution. After some group discussion we voted on the features that we preferred using a cluster analysis (see Figure 2). The top four features were: templates, some sort of progress indicator, access to past projects, and a dashboard view.

Figure 2: Cluster analysis of our feature ideas, which was taken from elements in the paper prototypes.

Step 4: Prototyped two different low-fidelity versions of our solution

We broke into two smaller groups and each team took the time to build out a low-fidelity clickable Figma prototype of the potential solution. Both prototypes contained all of the preferred features. If we had completely followed the GV Sprint process, we would have taken these prototypes and tested them with Pluralsight experience teams in order to glean additional insights and customer feedback. We showed the designs to Angela Payne and Dr. Derek Hansen, two experts in the ux research process, as a proxy.

Solution Prototype

Problem 1: Inconsistent application of Directed Discovery

From what we can gather as outsiders, it seems that experience teams across Pluralsight are sometimes inconsistent when applying the Directed Discovery process across their projects. To mitigate this problem we designed a project page that will highlight the Directed Discovery process and make it easier to organize project data into sections that align with each step of the process.

The projects have four tabs that project data can be organized into:

• Overview — This tab gives a high-level overview of the Directed Discovery project and allows teams to stay informed about the latest research (see Figure 3).
• VOC — This tab should enable teams to group all of their Voice of Customer research data, if applicable.
• CPT — This tab should enable teams to group all of their Customer Preference Test research data, if applicable (see Figure 4).
• CCT — This tab should enable teams to group all of their Customer Confirmation Test research data, if applicable.

Figure 3: Project homepage “Overview” tab of mid-fidelity prototype.

Because flexibility is important, we imagine that additional tabs could be created as alternatives or additions to VOC, CPT, or CCT. We tried to strike the right balance between forcing some level of consistency and supporting project-level customization.

Figure 4: Project homepage “CPT” tab of mid-fidelity prototype.

Problem 2: Lack of experience with Directed Discovery

Templates can be created by team leaders for any part of the process and can be edited at any time and saved back to the template. Like the product Notion, the user can pick a template to use and immediately start inputting data into it. For example, a “Customer Preference Test Interview” could be designed to look like Figure 5 below.

Figure 5: Customer Preference Test template of mid-fidelity prototype.

We imagine that templates would be created using a markup language. This would allow employees to customize templates to a high degree. For example, an “interview protocol” template could be created for a specific project that may include questions and text entry fields for people to enter in their notes and data. Alternatively, an “A/B Testing” form may allow employees to upload two versions of an interface along with data from the results of a live A/B test. Templates could easily be modified by employees to create new templates for different, but related projects.

Problem 3: Siloed data & repeated research

In order to reduce siloed data and repeated research, findings will need to be made available to the whole organization. Therefore, a research page (see Figure 6) was integrated into our prototype. Teams will conclude their findings at the end of each section and project. These findings will then be cataloged into a database and made searchable across the whole organization. This new tool can reduce duplicate research and promote cross-team collaboration.

Figure 6: Research page of mid-fidelity prototype.

The research page is also designed to enable file sharing of research notes and documents across different experience teams, which should yield greater innovation.

Conclusion

To recap, Pluralsight needed a solution that would solve the potential problems and complications that are a part of the Directed Discovery process. To best solve those problems, we created a prototype of an online web app that would help guide each team. The project page in the design highlights important parts of the process, such as VOC (Voice of Customer), CPT (Customer Preference Test), and CCT (Customer Confirmation Test). It also includes an Overview for every project so that project members and managers know exactly where their team is at and where they are going. Each part of the process includes templates that leaders can edit for their particular projects. Lastly in the web app, teams have access to a searchable database that holds every research topics that anyone in the entire company has completed. This way no one research will need to be duplicated without prior notice.

Those core design ideas create a flexible structure and learning platform for multiple experience teams at Pluralsight. By using the full prototype, users will be guided through the entire flow of the Directed Discovery process.