Starting in 2017, I designed and oversaw the deployment of a new version of PERRLA’s core feature: the Paper View Editor. This project began with an insight into how our users naturally approached paper writing.
While refining our user persona, I found a clear distinction between how users thought about writing papers and how we let them write papers in our product. I updated our product’s information architecture to better fit how users naturally thought about writing papers. In the end, this process allowed us to better integrate many of our existing features and it identified a gap in our product’s goal of helping students write APA & MLA papers.
PERRLA’s original paper editor (referred to as the Legacy Editor) allowed students to write an APA or MLA paper in the PERRLA web app without Microsoft Word. When it was built, the developmental needs of the platform drove its layout and design. At that time, PERRLA didn’t have an official in-house designer or a consistent design or research process in place.
The Legacy Editor was built as a single page with nine tabs. Each tab was used for a specific feature in the Editor and most of those used text fields as their primary interface. There were separate tabs for the Title Page, Abstract, Body of the paper, References, and the built-in productivity features. Each tab was specialized for its particular section of the paper and process. Once the paper was written, the student could download their paper as a Word document to their local computer.
While this layout may already seem unintuitive, writing a paper outside of Microsoft Word was a new endeavor for PERRLA and there were business and technical limitations to how it could be built. As a result, the Legacy Editor was built in a way that the product owner was comfortable with.
Consequently, this meant new users faced a fairly steep learning curve on two fronts. First, they had to learn how to operate our product using its non-standard interface. Second, they had to integrate their own paper writing habits into our product’s abilities. (Yes, I do recognize how terrible that is.)
The challenges this setup posed to students led to a slow adoption rate for our online platform and increased Support requests coming from users. Having just finished our customer persona, the failings of this design and approach to development were plain to see.
Before starting, I laid out three specific goals:
1. The new design had to be intuitive for students.
2. We should try to utilize as much of the current code as possible.
3. The design should give students the ability to see the benefits of the product as soon as possible.
During my time with PERRLA, I had become quite familiar with the Legacy Editor. So, as a first step, I had to distance myself from my perspective on the Editor so I could more objectively explore its problems.
First, I reached out to our Customer Support team. Together, we worked to create a list of some of the largest pain points within the Legacy Editor. After talking with them, I had a much better picture of the problems our users were actually facing – not just the problems I faced using it. In addition to these conversations, I also explored our incoming Customer Support requests so I could hear our users talking about the platform in their own language.
Second, I reviewed our core user persona. Although I had just finished creating the user persona a few months before, I hadn’t reviewed it specifically with the Legacy Editor in mind. Reviewing core research, even older research, can provide valuable insights when viewed in a new situation.
Third, I needed to engage with non-user students. I could interact with some of our existing users about their experience learning to use the Legacy Editor easily enough. But, more importantly, I had to interview students who hadn’t used PERRLA and weren’t relying on digital tools (beyond a word processor) to write their papers.
If we hoped to create a product that could convert new users into paying customers in larger numbers, we would need a design that appealed to students who weren’t familiar with technological solutions to writing a paper.
To accomplish this, I conducted two rounds of interviews: one with Legacy Editor users who had submitted support requests and another with students at a local university. The first round of interviews tended to be older students who were returning to school later in life. They also accounted for the majority of users currently using PERRLA. The second round was with more traditional undergraduate and graduate students who were younger, familiar with current software, and made use of a wider variety of tools to write their papers.
During my discussions and research, I found three major insights into how our users were using the Legacy Editor and how they wrote papers.
First, students expected to interact with their paper in a format that looks like a paper.
All of the students I interviewed shared this one common expectation. No matter what word processor they were using to write their papers, they felt comfortable with an interface that looked like an actual sheet of paper.
Students used the paper image as a framework for understanding how much they had written, where they needed to break paragraphs, and how much they still had to write until they were finished. By not having this basic frame of reference, students couldn’t accurately assess how far they were in their assignment causing them to panic and lose the sense of momentum that comes with successful writing.
Second, students using the Legacy Editor would frequently export their paper to see how it looked.
The separation of the different parts of the paper in the Legacy Editor allowed PERRLA to build the Editor in a way that made sense for development. However, it didn’t provide the feedback that users needed to feel assured their paper was being formatted correctly.
The APA and MLA formats have very strict formatting requirements for every part of a paper. The Legacy Editor wasn’t following all of those formatting guidelines within the Editor – even though all of those pieces would be formatted correctly when it was downloaded in the end.
For example, although the Editor showed users a list of the References they were using in their paper, it didn’t show them an actual Reference page. Instead, the Reference page was built when the paper document was downloaded at the end. Because students were concerned about the accuracy of this crucial part of their paper, they would download their paper to view the Reference page each time they made a significant change.
Third, all of the students followed a similar paper-writing process.
This insight had started to emerge while I was building our user persona. However, it was only when I re-analyzed that research and validated my suspicions with new interviews that I felt confident in making this claim.
As someone who spent 8 years in undergraduate and graduate programs, I felt like I had a solid grip on what it took to write a paper. However, I hadn’t realized that the way I organically approached my papers was also used by students across disciplines, generations, and mediums.
The writing habits of students can be broken into four major parts. First, students have to manage their paper as an assignment. Second, they have to collect and organize their research so it’s available as they write their draft. Third, they’ll write and edit their paper, drawing on the research they’ve collected. And finally, they have to prepare the document for submission and then turn it in.
Across these four steps, each student works in their own unique manner. Some use purely digital solutions for every part of the process while others prefer to only move away from pen and paper when they absolutely necessary.
At this point, I felt confident about the type of design we needed to pursue. But, I wasn’t sure how we would be able to move past the technical limitations PERRLA first encountered when building the Legacy Editor.
In conversations with our developers, I began to ask about the type of text editor we were using and how we were implementing it. As they became curious, I walked them through the insights that I had discovered.
At this point, our front-end developer shared that while fixing a bug, he saw an update for the text editing software we were using. It took the plain text fields we had been using and put it in the context of an actual sheet of paper. This was a huge breakthrough that would open the door for us to implement each of my user insights.
After doing some research, we discovered that we could implement the updated software while still being able to use the majority of the Editor code we already had. With the question of technical capability behind us, the driving force behind the design could be our insight into how students were already approaching paper writing.
PERRLA’s Legacy Editor contained a number of features. However, most of them were rarely used because of how they were laid out in the Editor.
These features included:
- The ability to edit a paper’s details
- A suggested writing plan based on the paper’s start and due dates
- A to-do list that was associated specifically with this paper
- Create and organize an outline
- Edit the content of the title page
- Ability to add and write an abstract
- Write the body of the paper
- Add references and create citations
- Download your paper
As I mentioned before, these features were spread out across separate tabs. The new Paper View Editor (named for the fact that you could actually view your paper in the Editor), would continue to use a tabbed layout, but we would consolidate our features into only four tabs – each focused on one part of the writing process I had identified.
The first tab – Overview – allowed students to manage their paper as an assignment. Using the features already available, it allowed students to edit their paper’s details, create and manage a paper-specific to-do list, and view their suggested writing plan. Besides relocating each of their features from their own tabs, there were only minimal UI and text adjustments needed to create this tab – a big win for our developers.
The second tab – Outline/Organize – allowed students to record their research with PERRLA and then organize it into an Outline. It would eventually be called the Organize tab as users adapted to the new terminology.
In the Legacy Editor, the outline was only visible in its tab and was only a series of text fields that could be arranged and organized. This was inadequate for addressing the needs of students as they worked through the second phase of the writing process. PERRLA needed a way to incorporate the process of recording their research into its design. To fill this gap in our product, I designed a complementary feature to the outline: Research Notes.
We split the tab into resizable halves with the existing Outline editor on one side and an amended References tab on the other for “Research Notes.” In Research Notes, students would be able to add their references, then create notes (cards) for each piece of information they wanted to use in their paper. They could then drag it directly into their outline on the right side of the tab. Best of all, any citations they added to their notes would follow the note into their outline or into the body of their paper as they used it.
The third tab – Write – contained the updated Editor that allowed users to see their paper as a paper. Instead of separating out the Title page, Abstract, Body, and References into individual tabs, each of these sections were visible and editable directly in their paper. Students no longer had to export their paper in order to see how it would be formatted; everything looked exactly as it would in their final Word document.
In addition to this change, we added a menubar across the top of the Editor to further mimic the look and feel of traditional word processors. Consequently, we were able to condense the icons we used in our toolbars to only the most important functions, while still ensuring every feature was still available through the menus at the top.
The final tab – Export – remained largely unchanged for this project. Students still needed a way to download their paper and choose the content and format they wanted for it. Although we didn’t make any significant changes to this tab for this project, there are a number of improvements we already hope to make in the future.
Since the new editor’s implementation, we’ve seen consistent growth in usage of PERRLA Online over our desktop software (that runs with Microsoft Word). Users who start Free Trials are more likely to convert to paying customers and our Support Team is experiencing far fewer requests from confused customers about how to write papers.
In fact, the Paper View Editor has been invaluable for Support as a viable option for users who experience trouble with their desktop software (which is showing signs of trouble and is being rebuilt on a new platform currently). Because it follows a similar mental model as traditional word processors, even users concerned about using a web-based editor find it to be an easy and intuitive solution. Many of them will even stop using their desktop word processors because of the additional features (like Research Notes) that are directly integrated into our platform.
Overall, PERRLA considers this design to be one of the most successful updates its rolled out in years. By being able to adjust the way we organized the features in the Paper Editor, and with the help of a timely update, PERRLA Online’s Paper View Editor is poised to become our most popular product with active users seeing over ### papers written with it each month.
As we continue to roll out further improvements to our products, the lessons we’ve learned in this process have reverberated across the entire company and our newest designs and updates reflect the importance of putting user’s mental models first.
