Restoring historic satisfaction with version history

Context

'Version history' was often requested and when asked about reversing major changes, most had a story to share.

“Once you press save there is no going back, without calling support”

Technically restoring past versions of content was seen as a straightforward feature to add. Considering our goals and the feature's simplicity, it seemed like a quick win for the team. So as the development team worked on the backend logic for the feature, I explored common patterns for version history.

Development and user experience design

I first looked at the giants Google Docs, Office 365 (Word), and Figma. This was because the users who edited course content were either in-house learning designers or university staff, both commonly used Google Docs and Microsoft Word. Finally, with the help of users, I looked at other online learning platform’s attempts at version history.

This approach aimed to ensure the feature would meet user expectations, which would be shaped by their familiarity with similar features from other platforms.

Usability concerns

Discovery and restoration process

Mitigating concerns

Finding how they find it

I conducted interviews with both our internal users and external ones and focused first on whether they could easily find this feature. The responses varied, with some finding the feature without guidance and others struggling. I noticed variations in the time it took users to find the feature and their approaches, but overall, users if aware of the feature’s existence were able to find how to access the feature.

Since our platform lacked a feature to highlight and educate users on new updates, provided we made our release notes and support documents clear, accessible, and well-distributed, we would be able to minimise the risk of the feature being overlooked by users.

Activities not included

Our bank of activities was a key feature and while the version restore feature could track the presence and placement of an activity, it couldn't track the content within it because it is part of the text editor.

From my interviews, users valued access to activities as much as they did the rich text editor content. However, our support logs showed no requests to revert changes to activity content.

My findings suggested that not including both the text editor and activity content in the version restore would likely disappoint users. To them, it seemed like an incomplete solution. I recommended clear communication at launch to manage expectations and prevent confusion.

Your history is limited

Our decision to limit history to the last 50 saves was generally well-received. I had concerns about users potentially spam-saving and losing earlier versions, but after a review, we found that pages were saved on average 20-25 times. So, setting the limit at 50 appeared to be a reasonable choice.

Load version/restore version

Although it wasn’t how I would have liked it to happen, the user first had to look through the catalogue of versions before loading that content into the text editor, once that had been done they were then able to restore that loaded version. The version selector had a basic preview but even on load, not all content showed as it would after restoration.

If you look at most version history features, most do not make the user perform and complete the entire workflow on two different screens. However, I lamented that that was what I designed and that my hands were tied because of technical constraints. Feedback around this workflow was positive so things being what they were, I had concluded the designs and approach were acceptable.

Outcomes

I neglected to follow up on my recommendations for setting realistic expectations of the feature, leading to dissatisfaction among our internal learning design team due to the absence of activities. However, I did play a key role in resolving the resulting conflict between them and the product team, by talking to both heads of departments getting their perspectives and relaying the other’s perspective.

Following a positive beta test, we proceeded with the release, which was received favourably overall. The feature's objective was to enhance customer satisfaction which became evident in conversations involving our managing director, head of product, and our customers. Additionally, my direct engagement with users and incorporating their feedback into the final product contributed to their overall satisfaction.

Conclusion

What I enjoyed about this project was my frequent interactions with the development team, the design and delivery cadence almost naturally was about two weeks in advance of stories being worked on. I got their feedback every other of day (we were working remotely) which allowed us to figure out what features they would build next, what might change based on user feedback, and what needed to stay fixed.

The main challenge was designing around the system’s technical limitations while trying to focus on user needs rather than what was easy to implement. My initial designs were too ambitious, but regular feedback from developers and users helped refine what was delivered into a practical solution that balanced ease of implementation with usability.

The feature, by its nature, wasn't revolutionary, given it offered functionality expected of most document editors. So I think given the timeframe, scope and value I spent an acceptable amount of time testing it with users before it was built.

Gaining insights into user’s expectations of the feature I had input on the release strategy so that we built the right expectations up with our users and did not create an environment for disappointment to grow.