What Changed in My Document?

Role: Lead Designer
   Team: PM, ENGUser Research



Every year, financial professionals work feverishly to create and collaboratively populate government-mandated reports, like SEC filings. Over 65% of the Fortune 500 use Workiva's product, Wdesk Documents, to create and submit these reports. These individuals are operating under enormous pressure. An error during the filing process has enormous ramifications. As a result, Workiva's customers always need to be aware of changes made to their documents.

In response to this need, Wdesk Documents has a 'History' panel, which tracks changes made to a Wdesk document. The panel acts as an insurance policy, a way for customers to know that 'old data' is still accessible in the event of a potential error. Secondly, it enables customers to compare different versions, or "revisions", of their document to see what has changed. 

Because I was the lead designer for the redesign of Wdesk Documents, I also redesigned the History Panel (housed within Wdesk Documents) with real-time collaboration in mind. 

The History Panel (Gen 1)

The History Panel is a feature that allows users to view how their document has changed over time. Changes are tracked using Document Revisions, which are generated each time a user 'pushes out' their changes to that document. Each time a user presses the green 'Share' button, their changes are pushed out. 

Key Considerations for the Redesign

NO 'Share' Button

A significant change I had to account for was the absence of a "Share" button in the new version of Wdesk Documents. This mean that every change users made in a document was committed in real-time. Therefore, there was no primary user action (like pushing the Share button) to trigger creating a revision.  

Multiple Authors Can Contribute to a Single Revision

Because of the absence of the Share button, we decided to use a time-based algorithm to automatically generate a revision after a set period of time. This meant that if multiple users had made changes within that time frame, they could all be associated with a single revision. 

Certain 'Actions' Should TRIGGER a Revision

After combing through JIRA idea tickets and interviewing customers, it was clear that there were certain actions users took which should create a revision of their document automatically. Among them, actions like:

  • Any time a document is exported out of Wdesk (as a PDF, DOCX, XSLX, etc...)

  • When changes are made to who can access the document

  • When a spike in activity (edits made to a document) occurs

Rethinking the 'History Card'

Each revision in the History Panel is represented by an individual 'history card'. It contains metadata related to the revision and a dropdown to access additional actions. 

Anatomy of a Gen1 History Card

Initial explorations for A Gen2 HISTORY CARD

Viewing a Revision

My analysis of Gen1 History unearthed a couple key usability concerns around viewing a previous version (revision) of a document. I've documented them below: 


Holistic Design

I explored different layout patterns to ensure the History Card would work with not only Wdesk Documents, but also meet the needs of our Spreadsheets and Presentation applications.

high-fidelity mocks



I created interactive prototypes (with Axure & Principle) to demonstrate key interactions to stakeholders and for usability testing sessions with users.

Introducing New Types of History

In addition to redesigning the existing history panel / card, I also focused on exposing new types of history that we knew (from conversations with customers) would be valuable.

CEll History

One example of this was the introduction of Cell History, which allows a user to track how a single cell in a spreadsheet has changed over time.