A document viewing mode that visualizes changes made between construction document versions.
During my Product Design internship at Autodesk, I worked on Autodesk Construction Cloud (ACC), a software for the construction sector. Specifically, my team builds and maintains Specs, a product that makes data from project specifications easily accessible across multiple workflows and project team members.
Specifications (specs) are the project playbook for all what and who based questions. They’re dense, text-heavy, legally binding, documents that can be hundreds to thousands of pages long.
Specs are used from the beginning to the end of a project and are frequently revised by various people. Construction teams need a way to track changes made to specifications.
It's crucial for all members in a project to know what’s in the up-to-date spec as they set project requirements, mange liability, and foster the relationship between parties.
There has been an overwhelming demand for a version comparison feature in Specs similar Sheets. Sheets manages blueprints and has a compare tool that looks like this:
Sheet's compare tool lays one drawing over the other. But overlay comparison is not the best idea for text documents (ie: specifications) as you can see...
As a result, users resorted to opening up versions in separate windows, laying them side by side and cross referencing them for changes. This method is extremely time consuming and a lot of changes end up getting missed.
A version compare viewer that allows construction teams to clearly view the changes made between two versions of a project specification. Teams can easily extract the information they need to stay up to date with changes and successfully execute their projects.
Play with the prototype ↗To kick off my design process, I started by auditing various content editors and viewers that feature version comparison tools. This initial research helped me grasp the existing patterns and interactions that users might already be accustomed to, ensuring that my designs would be aligned with their expectations.
Key Takeaway
Unified view
Document editors like Google Docs and Microsoft Word typically use a unified view that highlights changes made in relation to the current version, with a strong emphasis on identifying who made each revision. However, in the context of Specs, users need the ability to compare any two versions, not just the current one, and tracking the author of each change is less relevant.
Split view
GitHub's split view, mirrors how users typically compare documents side by side. By displaying old content on one side and new content on the other, it makes it significantly easier to pinpoint changes.
Develop a version comparison tool for construction specifications that streamlines project workflows and enhances collaboration.
After gaining a better understanding the competitive landscape, I collaborated with my PM and project lead to establish a set of product principles that would guide the direction of the version comparison experience.
When speaking to users about their current process for comparing two versions of a specification, the two most significant pain points are:
No indication of a change
Users rely on side-by-side PDF viewers to manually spot differences, as there are no visual cues to highlight changes. This requires them to carefully examine each document and identify changes without assistance.
Scrolling through pages and getting lost
The manual process of scrolling through each document separately makes it challenging to track changes. Users often struggle to maintain their place between the two versions, leading to frustration and inefficiency as they repeatedly lose their place and must retrace their steps.
The first pain point was addressed through the use of color-coded highlights, a feature common in version comparison tools. Changes were marked with distinct colors: red for deleted elements, green for added elements, and purple for modified elements. This color-coding, accompanied by a clear legend, was designed to align with existing ACC platform designs, ensuring consistency and enabling users to quickly and easily identify changes.
The second pain point was resolved with a central scroll bar that can be locked and unlocked. When locked, it allows users to scroll both versions simultaneously, preventing them from losing their place while comparing documents.
The central scroll bar also provides a high-level overview of changes by displaying color-coded blocks that visually represent the size and location of modifications. This feature helps users quickly grasp the extent of changes at a glance.
After conducting some informal testing, it was revealed that users didn’t immediately recognize the central element as a scroll bar. While they understood it as a visual representation of the document with color-coded highlights indicating changes, they didn’t perceive it as interactive and didn't realize they could use it to scroll.
Given that the scroll bar is a key feature of the version compare viewer, it was essential for users to understand its purpose and functionality. That said, this single element went through a lot of iterations.
What began as a flat, bulky, and static element evolved into a sleek, interactive scroll bar that users could easily recognize and engage with.
Given that Sheets already features a compare tool, I chose to reuse as many of its design and interaction elements as possible where appropriate. This strategy preserves design consistency across the platform, enabling users who are familiar with Sheets to easily transition to the new feature.
It also accelerates the design and development process by leveraging established patterns, reduces risk through the use of proven components, and ensures a seamless connection with other tools on the platform, resulting in a cohesive user experience.
With the same icon and placement as in Sheets, users can access Specs Version Compare from the top right corner of the screen, ensuring a seamless and familiar experience.
To select the two version to to compare, I utilized existing design patterns and components as well.
After completing my initial design iteration, I spoke with a panel of users to gather insights and move forward in my design process. This feedback validated many assumptions, while also challenging others. Here's just one example of how user input directly influenced my design iterations:
Version 1
I designed this modal based on the assumption that users would want the dropdown to be as simple as possible.
However, user feedback revealed that version nomenclature can be confusing, and construction teams often rely on the issuance date to identify versions.
Version 2
Based on this insight, I included additional information such as the issuance date and full version name to make it easier for users to accurately identify versions.
Looking at the example below, Page 3 content in Version 1 is now located on page 5 in Version 2 after 4 pages of content were added.
For the first launch of Version Compare, I chose to go with option 1—text search—since it required minimal engineering effort.
Option 2 was ruled out as adding blanks could create more confusion than clarity. While option 3 was the ideal solution, after discussing with engineers, we determined that its implementation would be complex and costly.
Starting small with option 1 allows us to deliver immediate value and gather user feedback, with plans to iterate and push for option 3 in future updates. This approach emphasizes the importance of building on a solid foundation and refining features over time.
After deciding that search was the way to go, I began iterating. Since there are two documents, search functionality is a bit more nuanced. The simplest design option would be to have two separate search bars for each document:
While implementing this feature would be straightforward, as Specs already includes a basic search bar component, a common use case involves searching for the same word in both document versions to align them. Having two separate search bars would force users to do everything twice.
What if the search function could also be locked and unlocked, similar to the scroll feature? This would allow users to search for a word and navigate through both documents simultaneously, saving time and effort by streamlining the comparison process.
After careful consideration, I realized that the need for an unlocked search function was minimal. There were few use cases where users would need to search for different words in each document simultaneously. Implementing a locked/unlocked search feature would unnecessarily complicate the user experience and increase the engineering efforts.
That said, I decided to move forward with the search function in it's "locked" state, with the option to revisit and add an unlocked search feature in a future iteration if a need arises.
Just like the other compare tools in ACC, open Version Compare in the top right corner and select the two versions that to compare. For convenience, the current version is selected as the newer version by default.
Navigate through your document using the central scroll bar. The lock button in the tool bar indicates the status of the scroll sync. When locked both sides would scroll simultaneously. When unlocked, the two sides scroll independently from one another.
Search for specific parts of your specification using the advanced search functionality. Unlike a regular search bar, it lets you quickly locate exactly what you need by typing in a keyword to search both documents while navigating through results separately.
See changes in a filterable, searchable list is embedded to the document. When clicking on a list item, the document will navigate to the corresponding change, and vice versa.
When it came time to hand off my work to the engineers, I made sure the design files were detailed and well-organized. These included states, interaction/animation notes, and design specs, ensuring that the final product aligned perfectly with the design vision. This attention to detail helps bridge the gap between design and engineering, leading to a smoother workflow and a more polished end result.
The next step would be to integrate spec changes into other parts of the construction workflow such as submittals. A submittal is a document that contractors or suppliers submit to the project team (ie: architects, engineers) for approval. For example, if the spec was changed from Steel X to Steel Y, a contractor would have to draft a submittal for the approval of Steel Y. Being able to link spec changes to submittals gives the approver more context for decision making and can let the spec reader know "a submittal has been filed for this change". Taking it a step further, imagine if version compare can identify those changes and automatically draft those submittals for you!
Although red and green are universal colours for "delete" and "add", unfortunately, they are two of the most troubling colours for common colour blindness (as you can see on the left).
Future Considerations
1. Implement a supplementary visual indicator (ie: + or - icons)
2. Give users the ability to set their own colour palettes.
Engaging with construction teams for user feedback, engineers and PMs for scoping and feasibility discussions, and executives with limited context for decision-making, highlighted the importance of tailoring my communication to each audience. This experience deepened my ability to adapt how I convey complex design concepts in a way that aligns with each stakeholder's goals.
My design process was not just about creating a standalone version tool; it required a constant consideration of how my designs would seamlessly integrate with the broader ecosystem of Autodesk tools. My work revealed a larger opportunity to develop a solution that could be seamlessly applied to all text-based comparison opportunities across the platform. Recognizing this potential, a significant aspect of my design process involved creating a scalable and adaptable design. This experience fostered a systems thinking approach, reinforcing my ability to design within the intricate ecosystem of a large organization like Autodesk.
EmailLinkedin