Pluralsight is a SaaS based e-learning platform that provides an array of products to up-skill tech workers. I worked as a product designer that was tasked with finding solutions for inefficient processes in content creation software. In the end the solution included an array of complex feature sets embedded in brand new functionality.
I worked as product designer within the 'content assessment tools' squad. Our squad included a product designer (myself), product manager, and four engineers. I was tasked with identifying problems around inefficient work flows for Pluralsight content creators (authors) and internal content production editors (PEs).
My goal was to find solid solutions that would increase author's 'time to production', satisfaction working with Pluralsight, and improve production editors overall work day. After 4 months of discovery, iterations, and testing, the solution not only solved the obvious work flow problems, the designs were able to completely replace three separate applications. The new tool became a centralized interface where authors and production editors can work collaboratively in real time.
Pluralsight has a product called ‘skill assessments’. These assessments are taken by millions of people via mobile devices and the web. The assessments help individuals better understand their level of expertise in any given topic and can suggest learning content based on your gaps in that topic. The assessments are usually around 25 questions. Those 25 questions come from a pool of 250 questions of the same topic that are written by industry experts, also called authors. Authors work directly with a team of Pluralsight production editors.
Together, they develop a long term working relationship. On average, the author creates 250 questions, and the production editor audits those questions and if a question needs editing, the production editor provides feedback to the author. The process takes weeks and sometimes months. Simply put, writing and editing 250 questions is hard.
The process that authors and production editors use was outdated, bloated, and frustrating for both of them. The business was starting to become impacted by the time it could take to write a set of questions.
The PM and myself were already under the assumption that whatever solution we found, we would be deprecating the existing legacy software that was being used to import questions in our assessment question database. The backend was hacky, layered with technical debt, and had poor usability.
Early in the project, with the little knowledge I had, I had already developed an assumption that I would be able to design a web application that would completely change and optimize the way editors and authors worked with each other.
Research was a shared effort between myself and my PM. We scheduled face-to-face interview sessions with the team of production editors. We also sent out surveys and interview invites to hundreds of authors. Responses were plentiful.
We wanted our research efforts for both types of users to answer similar questions. We needed to know all the intricacies and nuances of their workflow, and understand their major pain points and frustrations while working with Pluralsight. Some of the initial sessions immediately revealed just how frustrated they were.
Some major takeaways from our in-person and zoom sessions:
- Both authors and production editors were frustrated with the usability and bugs of the legacy tool.
- Each production editor has their own process of managing authors. This made it difficult for repeat authors because they had to learn multiple workflows.
- Different authors also had their own writing processes. Some were using Google docs, code editors, or notepad.
- Communication of progress was turbulent, slow, and resulted in missed production deadlines.
After many days of research, I needed to answer an important question:
Should we build a new product, buy or subscribe to project management software, or is there a solution that exists by tweaking the existing workflow?
To answer this question, the PM and I worked through some exercises to determine each option’s opportunity cost. We ended up deciding that the best path forward for our users was to build a new project management tool that was focused on writing and managing large quantities of questions.
It should be noted that I worked with the engineering team often to share all iterations for helpful usability feedback, and also to discuss the technical feasibility of all new functions and features. Without the engineering team's constant collaboration, the designs might have taken much longer to reach a final state of maturity.
I decided that journey maps would be a really helpful tool to facilitate deeper conversation with authors and production editors. We spent many hours in zoom calls and in-person sessions. I also participated in observation sessions where I would watch over production editors' shoulders. I also lead a group workshop to create a common sentiment of emotional responses to all the steps in the process. The journey maps would also help us prioritize solving some of the major pain points.
The existence of the Pluralsight’s robust design system made prototyping fairly simple and efficient. I was able to focus most of my energy on the experience and not think too hard about the UI. I prioritized minimizing the amount of custom UI components the engineers would have to build.
The interface would need a large amount of new and complex features. Some of the 'must-have' features were:
- Rich text editor
- Markdown options
- Data visualization
- Commenting
- Filtering
- Visual progress indicators
- CSV uploads and downloads
The first interfaces I created were focused on the author’s needs. From our research sessions we knew authors preferred using tools like Google sheets or Excel because of the scannability that one giant table provides. I started experimenting with an open cell table design. I pulled influence from tools like Sheets and AirTable.
Quickly after initial testing with the production editors, it was obvious that the adding production editor features to the cells would cause issues with scalability which would lead to poor usability. I started in a different direction, one with a more project management tone.
That turned out to be the right choice. The user testing was smoother and people were getting excited about what they were seeing. One concern that was raised multiple times throughout interviews were questions around how to manage and navigate quickly through hundreds of questions.
The designs started to solve all the major points we found early on as well as solving any frustrations during testing. This version tested extremely well with both authors and production editors.
For reading simplicity, you'll find an example of only the production editor designs below. The author designs are very similar.
Now that we had an iteration that had reached its MLP (minimum lovable) status, the team knew that building the new designs would be a massive and time consuming effort for the engineering team.
We needed to take a wholistic look at everything and break down all the functions to see if there was any feature that should be prioritized to help solve any of the major points. The easy answer was the CSV uploader. Having a CSV uploader would fix the most manual, repetitive, and inefficient step of the entire question writing process. The production editors on average would save around 5 hours of time with this one function.
Below are some iterations of what that CSV uploader looks like. There are two version of each screen here. This is to demonstrate the iterative implementation process. Starting with simplistic confirmation screens, they then evolve into functions with CVS validation features. I also had fun with adding some illustrations to make a typical CSV uploader more pleasant.
With the creation of a tool that solved a plethora of our users frustrations, it was an easy decision to deprecate our existing internal question writing tool. The new designs also fostered a new way of editors and authors working together. I was able to replace multiple software tools and many workflows with the new designs I created.
Production editors were now able to:
- See an overview of multiple project's progress
- Leave comments and feedback in context of the question
- Only review content that was ready to review using filtered views
- Edit questions within the interface
- See multiple question previews at once
- Use visual indicators to quickly glance at the question writing progress
- Assign authors to specific groups of questions ready to be produced
Authors were now able to:
- See an overview of multiple project's progress
- See a to-do list specific to their tasks needed to complete the set of questions
- Respond to comments and feedback within the interface
- Mark and send questions to production editors as 'ready to review'
- Write in markdown
- Write questions in a full screen editor
- Review other author's progress and question writing styles for inspiration