Improving user experimentation with Undo/Redo
Overview
When building a webpage on Squarespace, if you made an error there was no way to undo it. Instead you would have to abandon all unsaved changes. This led to users saving their page after every single change to the page, which is an incredibly unpleasant way to build a website.
Adding undo/redo is a straight-forward, quality of life improvement that would still require a measured and thoughtful design approach.
Initial Design Questions
How do users want to use undo/redo?
What is the scope of undo/redo? Could we allow users to undo everything?
Where should the undo/redo buttons be placed?
What’s appropriate feedback to help users understand something was undone or redone?
How do users want to undo and redo?
To validate our approach to undo/redo I looked at a sample of 50 feature requests and categorized them based on how they were wanted to use it. Over 50% of them wanted to simply undo immediate actions while editing their site. Version History being 36% shows how important it will be to follow up undo/redo with auto-saving and reverting pages to a specific point in time.
Immediate - Undoing any recent actions while editing a page (block/section deletion, moving blocks, resizing blocks, etc).
Version History - Timeline mental model, undoing to a point in time, such as two hours ago. Often after the user has already saved the page.
Vague - User didn’t indicate what kind of undo action they’re expecting
Shipping Options - One user accidentally deleted all their shipping settings and wanted to restore them.
What is the scope?
In partnership with engineering, we evaluated what isn’t technically feasible to be undone or redone and clearly mapped what was out of scope.
In scope
Moving, adding, editing, and deleting sections and most blocks. Gif shows adding and undoing adding a section.
Out of scope
Undoing block edits like this Form Block Editor are out of scope because they have their own save state.
Early Explorations
Undo/Redo Button Positioning and Design
After much iteration and deliberation I arrived at positioning the button on the left because it has such a close relationship with saving and exiting editing mode (clicking ‘Done’).
Undo/Redo Interaction and Feedback
We could message to user what undo or redo action is occurring
Tooltip
Numbering
Toast
We could visually indicate and take users to where the undo or redo occurred
After many design reviews, I decided to go with the simplest option of having no visual queues or messages since most undos and redos will occur in the space the user is currently working in.
End Result
What I learned
No matter how simple a feature seems, its still important to do iterations to build confidence in the design direction chosen
Undo/redo is way more complex than I ever imagined and when it works well nobody notices its there
Exploring future versions that include auto-save and version history was helpful in deciding the current direction of undo/redo.