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. Specfically, 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. 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.
Specs are used from the beginning to the end of a project and are frequently revised by various people. Construction team need a way to compare versions and track changes made to specifications.
There has been an overwhelming demand for a version comparison feature in Specs similar Sheets. Sheets manages drawings and blueprints for construction projects and has a Compare tool that looks like this:
Sheets' Compare tool lays one drawing over the other, with one drawing in red, the other in blue - it's most commonly used to understand how different systems will interact with one another in a project (say, you want to see how the plumbing system lines up with the electrical system of a house).
But overlay comparison is not the best idea for text documents (ie: specifications) as you can see...
That said, we offered no way to compare text documents like specifications. 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 from specifications to stay up to date with changes and successfully execute their projects.
Check out the prototype ↗
Like most design projects, I began with research. I audited 5 different content editors/viewers with version comparison tools to understand the patterns and interactions that our users might be familiar with.
Document editors like Google Docs and Microsoft Word use a single document/merged view that showcases the changes that were made with respect to the current version. It also has a stronger focus on who made the revision. In the context of Specs, users need to be able to compare against any two versions, not just the current version, and there wasn't much significance in indicating who made the change. That being said, this merged view was not a good fit for our solution.
Github's version compare piqued my interest when I saw the "split" view that mimics the way that users are currently comparing documents side by side. It shows old content on one side and new content on the other side, making it a lot easier to see exactly what’s changed.
Takeaways:
To align my designs with the rest of the platform, I audited similar Compare features across Autodesk's suite of tools. I identified consistent interaction patterns and design system components across all of our Compare tools which I plan to implement for Specs once I begin designing.
Compare tools are triggered using the same icon button located in the top right of the screen.
Once triggered, modals and dropdowns are used to select the two entities that will be compared.
Red is used for deleted elements and green is used for added elements. Legends are used to inform users what each colour indicates.
After gaining a better understanding the competitive landscape and existing products on our platform, I generated a set of product principles with my PM and design mentor to help us guide the direction of the version comparison experience.
Next, to understand how Version Compare will be used by various team roles, I outlined different use cases based on existing Personas and research.
Following this, I began to brainstorm some features that support these use cases.
After scoping our feature set, I started sketching and wireframing. The split view stood out as my favourite as it mirrors how teams naturally compare specifications – opening them side by side in different windows.
Soon after, I spoke with a panel of customers to ask questions, get feedback, and ultimately gain insights that can help me move forward in my design process. Here are some prime examples of how customer feedback shaped my iterations ↓
Version 1:
Based on the assumption that users would want the dropdown to be as simple as possible.
Version 2:
Turns out, version nomenclature can get confusing and construction teams heavily rely on Issuance Date when identifying versions.
Added Issuance Date
Explicitly indicate most current version
Explicitly indicate full version name in each dropdown option
Version 1:
All changes are classified as additions or deletions, even when individual words are being replaced.
Version 2:
Users explained that changes made to a spec are almost always on a section or page level and rarely ever on a word or character level. They want a way to clearly distinguish between these three use cases:
A. a section has been added
B. a section has been deleted
C. a section has been modified in some way
Changes are indicated on a line level rather than a character level for higher visibility
A third highlight colour (purple) was added to indicate modifications
Challenge:
When several pages are being added or deleted, it's hard to know which pages are associated with each other from one version to the other.
Example: Page 3 content in V1 is now located on page 5 in V2 after 4 pages were added.
Option 1:
User searches the two versions by a keyword or phrase.
1. Search and find “Concrete” on page 3 of V1
2. Search and find corresponding “Concrete” on page 7 of V2
Easy to technically implement
Requires manual work from user
Option 2:
Adding "blanks" to align mismatched pages.
Provides a visual sense of page alignment between versions
Can cause more confusion than clarity (what happens when half a page of content is added? or just a line?)
Option 3:
"Link" all the text in V1 with its corresponding text in V2.
1. Click on “Concrete” on page 3 of V1
2. System automatically scrolls to corresponding “Concrete” on page 7 of V2
Seamlessly integrates into workflow
Requires minimal effort from user
Requires a lot of engineering effort
Just like the other compare tools, users can trigger Version Compare in the top right corner. A modal appears to select the two versions that they would like to compare with the current version selected as the newer version by default. Then, the split view is displayed, comparing the two versions side by side, where different colours indicate the different types of changes being made.
Users can scroll through the documents 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.
Users can see also changes in a filterable, searchable list. The list and document is linked so that when clicking on a list item, the document will navigate to the corresponding change, and vice versa.
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!
Users also expressed concerns with the accessibility of the highlight colours scheme. 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).
Some ideas:
In other tools in ACC, users can "markup" their documents by leaving notes, highlighting, adding shapes, etc to their documents. In the future, users should be able to annotate specs in the Compare view. This will be really helpful for teams as they can give other team members more context (ie: X was changed because of Y), and to increase readability (ie: star symbol can bring more emphasis to a change).
Throughout my internship, effective communication played a pivotal role in my role as a designer. Engaging with diverse groups, such as construction teams for user feedback, my team of 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. The skill of translating design language into stakeholder language has proven invaluable, ensuring that my ideas are not only understood but also resonate with the specific needs and objectives of my audience.
The design process was not just about creating a standalone version compare tool for project specifications; it required a constant consideration of how my designs would seamlessly integrate with the broader ecosystem of Autodesk tools. While the origin of this project stemmed from the specific need to compare specifications, 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, adaptable, and universal design. I learned to consider not only the immediate application of my designs but also their potential implications across different areas of the platform. This experience fostered a proactive and holistic approach, reinforcing my ability to strategically think big picture within the intricate ecosystem of a large organization like Autodesk.
.png)
Equipping internal teams to scale with the the rapid growth of Mercury.
Read case study ↗
Transforming an outdated liquor supply chain process into a digital one.
Read case study ↗
EmailLinkedin