Empowering new editors
PART 1 | PART 2
In late 2016, Fandom, a wiki hosting service, surfaced 'Add a new page' entry point to new users in order to increase the number of contributions. Many readers wanted to add new content to their favourite wikis.
Unfortunately, the process proved to be too complex for near 80% of them.
I was part of the team tasked with empowering inexperienced editors and decreasing the gap between the number of started and finished pages.
note: because of my non-disclosure agreement, I have omitted confidential information in this case study, including exact data and some elements of the design.
My role
I led design work of enhanced editing experience, including user research and data analysis, and user journey mapping.
I worked together with the development team to plan and conduct agile experiments in the page editor and roll back unsuccessful changes.
Challenges
The wiki editor in 2016 was already a legacy product. What is more, there existed more than one versions of the editor: the visual editor and source editor. Both originated from media-wiki editor, used on Wikipedia.
Our team had to work within the constraints of the existing tool and make sure that changing the editing experience won't affect negatively the power users.
Initial assumptions:
Creating a typical wiki page from start to finish is difficult and confusing for new users.
Existing editing tools are filled with sharp edges and the new users
die by death of a thousand cuts.
Existing editing tools are filled with sharp edges and the new users
die by death of a thousand cuts.
Gathering context
In order to analyse the user flow, I set out to map a journey of a user creating new page on a wiki.
10 inexperienced users were given a task to recreate a typical wiki article. The development team also took the challenge to walk a mile in users' shoes.
The testers had to recreate a wiki article of a given structure:
1.
Text body, two paragraphs with sub-title.
10/10 users completed the task.
10/10 users completed the task.
2.
Infobox with a title and several entries.
8/10 users completed the task.
8/10 users completed the task.
3.
Image placed in the infobox.
2/10 users completed the task.
2/10 users completed the task.
4.
Mixed media gallery.
7/10 users completed the task.
7/10 users completed the task.
These experiences were analysed and mapped on a journey map posted on the office wall. As an additional data point, we recorded users' sessions in the editor using Inspectlet and found several more pain points
Article to be recreated (handout)
Journey map, printed and displayed in the office
Journey map, detail
Post-interviews brainstorming
Persona
Jenny
a long-time fan of science-fiction, Jenny is currently fascinated with the new HBO show Westworld. Seeing that Westworld wikia is behind with adding new content, such as episode descriptions, Jenny attempts to create episode page herself, following UI patterns established across various wikis.
Problem statement was almost identical as the one in PART 1 of the project, as the motivation and the context remained the same.
As a fan who never before contributed to a wiki, I need to be able to create and edit wiki pages quickly and securely, so I can share my knowledge and experience with a wider community.
Experiments
User interviews and journey mapping, coupled with insights from Inspectlet videos, helped us identify most severe pain points. We've decided to launch several guerilla-like experiments on high-traffic communities and monitor the uptake data closely in order to roll back changes quickly and didn't work out.
Most pain points from Inspectlet videos concentrated at the beginning of the flow, when users entered the editor - a surprisingly large number of users left the page without writing a single word. The other problematic part was adding an image to infobox.
Experiment 1: full page view in the editor
The wiki editor initially showed "tank-visor-like" area.
The assumption was that inexperienced editors do not feel confident enough to start editing such a limited space, so I decided to expand the editor's area to show the whole page, not just the first line with a caret.
This resulted in a significant spike in the number of new saved pages on popular wikis and the experiment was rolled out on 100% wikis.
Experiment 2: pre-filled page template
Acting on assumption that new readers prefer editing pre-existing content, we've prepared a set of pre-filled templates that would populate the editor once the user clicks on 'add new page' button.
Unfortunately, this experiment didn't affect any numbers and was reverted.
Experiment 3: Adding image to infobox
Adding image to the infobox involved providing a full URL path to the file. Experienced wiki editors were not using UI for this, but edited infobox templates in source code.
To make the task easy for new users, I opted for a simple solution: a button to add any image from the user's local drive.
The change proved very successful, the engagement with the button was high and corresponded with the number of created pages.
IMPACT
In subsequent user tests 10/10 new users created a whole wiki article with little to no issues.
Once the changes were released to production, we observed steady increase in the number of new created pages.
In comparison to the same period in the previous year, the number of successfully saved pages increased by 106%.
Total number of clicks in the edit area increased by 4,7% from month to month.
The changes in visual editor were later adapted in the new Fandom version of the editor, which included experimental WYSIWYG infobox creator, inspired by our simple but effective change.