01 / OVERVIEW
Making history useful in the moment.
The goal was to give teams a way to keep track of evolving files, review proposed changes, and return to earlier versions. I began with a wide scope: one version control experience for documents, PDFs, images, audio, and video.
As the first design took shape, feedback exposed a more basic issue. People had trouble finding their way through the workflow. The screen that appeared first was a timeline of activity. It explained what had happened to a file, but did not make the file itself or the next action clear.
02 / THE FIRST DESIGN
A system built around its history.
V1 opened in a Review Room with the timeline selected. Upload, pending reviews, and version history were separate destinations. This made sense as a map of the system, but it asked people to interpret a history of events before reaching the document.
Too many file types
The same versioning idea had to account for many formats and different ways people work with them.
The wrong first screen
A timeline was useful for looking back, but did not answer “what am I working on?” or “what do I do next?”
03 / FEEDBACK
The problem was bigger than navigation labels.
The feedback was that V1 felt complicated and difficult to navigate. I looked at the first screen and the breadth of the product together. Changing a label would not resolve the underlying order of the experience: it still led with the system’s history rather than the user’s document.
I decided to reduce the scope to editable documents only. Other file types are excluded from the redesigned version control workflow. That gave me a clearer object to design around and a more coherent path from editing to review.
“Start with the document. Bring in version history when it becomes relevant.”
04 / RETHINKING THE FLOW
From files and events to people and decisions.
I mapped the relationship between an owner and contributors on a whiteboard. The questions included whether version control should apply to one document or a folder, what a contributor could submit, how an owner would review a proposed version, and what should happen after approval or rejection.
That exploration helped define a more legible workflow: a contributor proposes a change, the owner reviews it in the context of the document, and the decision becomes part of its history. Comments and reversion remain available when needed.
Propose a version
Give a change a title and description, attach the revised document, and send it for review.
Make a decision
Inspect the proposed changes, discuss them, then approve or reject the submission.
05 / KEY DECISIONS
Three shifts shaped the redesign.
Design for editable documents
Concentrating on one kind of work made the review and version flow easier to define. The new design does not include other file types.
Open the document first
The current document is the anchor. Its details and recent activity remain visible, while the fuller timeline becomes a destination for looking back.
Bring decisions closer to the change
Reviewers can inspect a submission and comment, approve, or reject in one flow rather than treating review as a disconnected activity list.
06 / THE NEW EXPERIENCE
One document, with its work around it.
V2 centres the document and organizes the supporting actions into Home, Review Changes, Commit Version, Timeline, and Settings. The surrounding panels keep the current version, contributors, and recent activity within reach.
Begin with the document
The document opens as the primary view. Highlighted changes and a side panel connect the content to its version details and recent activity.
Evaluate a proposed change
A review item expands to show the submitted document. The reviewer can comment and make an approval decision alongside that submission.
Explain the next version
The version form asks for a title, description, attached document, and reviewers. These fields give a proposed revision a reason and an audience.
Keep the past accessible
The dedicated timeline brings together status, author, comments, and reversion controls for moments when someone needs to inspect the document’s history.
07 / REFLECTION
The first screen defines the mental model.
This project taught me to question the order in which a product reveals its complexity. Version history is central to the system, but people need to see the document and understand their task before a timeline is useful.
The redesigned concept addresses the feedback through a tighter scope and a document-first flow. A next step would be to test V2 with people completing specific tasks—finding the current document, reviewing a proposed revision, and returning to an earlier version—to see where uncertainty remains.
This case study documents the design process and qualitative feedback on V1. No measured outcome for V2 is claimed.