Future-proofing Autodesk Handover’s readiness notification system
Role
Project Designer
Timeline
Sep - Dec 2022
Team
Autodesk Cloud Solutions / Build / Handover
Skills
User Research
Visual Design
Product Strategy
Tools
Figma
Dovetail
About my internship
I spent 3 months developing a status indicator framework for Handover, a platform for construction project lifecycle management. As the lead designer for this project, I worked closely with XFN (Engineering, PM, Design) and CSMs (Customer Support Managers) to prepare for an inaugural ship on Autodesk Build in the new year.
Emerging problem
The traditional construction project handover workflow is linear and leads to massive data blind spots. Time is often wasted due to a lack of transparency between speciality teams.
The background
Handover is a (beta) product in the Autodesk Construction Cloud ecosystem that aims to assist General Contractors in tracking and collecting documentation records throughout a project lifecycle to automate handover package development.
In the final stages of the construction project timeline, General Contractors must aggregate and organize project documentation in full to be turned over to Project Owners by closeout. Traditionally, General Contractors have experienced poor visibility into the status of their handover packages — closeout procedures happen only at the end of the project timeline, which raises the risk of exporting incomplete packages.
There is a desire for a more robust
submittal status system
that would provide users with greater visibility throughout the full timeline of a project, breaking down the barriers of the traditional linear handover model.
Thus, we asked
HMW
help users reduce ambiguity surrounding the readiness of turnover packages?
1/ Existing research
To start, I studied existing UXR studies to understand the current landscape of the 3 major user groups involved in project closeout documentation:
I sought to better understand the General Contractor workflow, the main user of Handover, by breaking down the pre-existing Autodesk Build experience for project tracking into 4 main steps:
In general, project closeout can be a demanding and stressful process for GCs looking to present their work in a polished manner. When project closeout is poorly managed,
GCs are left scrambling to track items down
to be organized, which emphasizes the need to start planning for closeout early and to track progress frequently. Construction projects should start with the end in mind and closeout should be a continuous process. Handover has an opportunity to power this workflow by communicating progress across its centralized software.
PROJECT GOAL
Design a robust document submittal status system to communicate to GCs how close they are and what needs to be done before closeout.
2/ Competitive audit
To kickstart the design process, I scoped out how other companies approached status indicators. I noticed how they established status hierarchy and leveraged design patterns. I took special note of how tree tables, the foundation of the Handover dashboard, were configured,
Data is distilled and easily accessible.
Pype Closeout, a platform for Subcontractors to directly upload their required docs, tracks submitted documentation through an activity log. General Contractors can view (1) a single item’s status or (2) an entire portfolio’s status to see exactly where their project stands.
Progress is visualized.
Jira Core, a process management system, assigns each project task a workflow to visualize project progression and ensure that no tasks or action items are left behind
Items float at the surface.
Tree views serve a different purpose than accordions; UI elements must not be nested and icons should have their own column distinct from the hierarchy.
3/ Pattern recognition audit
To leverage existing patterns and components in the Autodesk ecosystem, I conducted an audit of existing status notification systems in different parts of the Build platform, analyzing how each system communicates with users. While the Autodesk Build design system is equipped with a collection of components consistent with notification and status design patterns, various use cases exist across the platform that are not necessarily consistent in terms of styling and treatment.
Handover is intended to integrate primarily with Submittals, a feature in Autodesk Build for Subcontractor task delegation and documentation uploading. Therefore, to avoid inconsistent usage and lack of information hierarchy, the design approach intends to align with that of Submittals above other page styling to streamline these end-to-end user touch points.
Keeping the above findings in mind, the next phase focused on
identifying notification distinctions and use cases
that needed to be designed for. I generated a set of product principles with my PM to help the team guide the direction of the notification experience. Then, I began my explorative ideation phase.
SUBMITTAL STATUS SYSTEM
Framework Requirements
Establish the
classification criteria
and trigger for surfacing important information
Have a logical way of prioritizing information by using
UI patterns
and
visual hierarchy
to distinguish status severity
Determine if there are
associated actions
that would help remediate issues
Explorative ideation
was guided by revisiting the user journey to acknowledge user goals in alignment with the framework requirements at each stage.
Hypothesizing the design
A wide variety of approaches to effectively display system status
in the existing Handover tree table configuration were explored. As Handover expands and introduces more integrations, the tree table dashboard will change. However, considering Handover’s future in Build, the basis of a
status framework should be transferable
regardless of its parent component. I integrated status into the existing tree table configuration by generating ideas into these elements that lay the foundation of a submittal status system framework:
Element #1: position & reference
First, I explored different methods of conveying status, paying close attention to how each variation integrated with the Handover tree table configuration. To determine which options aligned best with the framework requirements, I evaluated each option against a set of qualitative metrics that address the principle user goals and use cases.
Evaluating the options, the icon indicator combined with dynamic text labels demonstrated strength in visual appeal, clarity, and scalability. With position and reference concerns addressed, the next two stages involve exploring different typographical variations and how color, symbol, and shape elements support their state recognition.
Element #2: label & semantic
A quadrant-based alerts model was leveraged to classify status indicators by their level of severity
. Severity is defined as a function of urgency and activeness, and can be categorized into high, medium, and low severity levels. Status use cases are defined along these three levels.
Alerts are classified by their
urgency
(if effective use of the system will be affected) and their
activeness
(if the user needs to take action)
I asked participants of an open card sorting activity to categorize different types of system feedback and status by their severity level. This helped to develop a taxonomy of status classification
according to the attributes of the quadrant model that could be assigned to the appropriate UI signal.
The activity guide the team with the following questions:
What verbiage matches the user mental model?
How do we communicate to users when a package is missing a file or when a package is ready for export?
What “completeness” values do users care about?
Should we display a status for collected items, outstanding items, or both?
What status signals are intuitive to users?
What UI elements map to the expected indicator signals?
Speaking with users, we learned that there is limited time on a construction project site to reference the status of all closeout package elements. Therefore, using
clear warning signs
to communicate that an element is not ready for export to the end user is crucial. Moreover, users want
simple visual cues
to inform the UI. The colors red, yellow, and green are already commonly recognized to in manual closeout package creation. Additionally, terms such as “submittal”, “RFI”, and “sheet” are recurring elements in a closeout package that project teams would want to bring awareness to with a status indicator system.
After reviewing user anecdotes from the card sorting activity, I confirmed a preliminary list of statuses and assigned a meaningful color, symbol, and shape mapping to each in order to express an intended UI signal.
Element #3: color, shape, & symbol
A quadrant-based alerts model was leveraged to classify status indicators by their level of severity. Then, a meaningful color, symbol, and shape mapping is proposed to express indicator signals in UI design.
Conclusion
As of March 2023, the feature has been released to internal beta! The Handover status system follows a set of Autodesk design guidelines on a high-level, and uses design principles to develop new component-level guidelines. An appropriate next step would be to test our assumptions made with Customer Support Managers on a greater sample of users to validate user experience decisions. After that, we can build out other crucial features such as implementing additional unique file type edge cases and, eventually, transitioning to a dashboard view for the future of Handover.
Key takeaways
For this project, I challenged myself to focus on building a comprehensive understanding of Autodesk Build’s customers via research and conversations before diving into the FIgma file. The endeavour emphasized that
establishing user experience principles
is key to scaling consistently to maintain familiarity across platform features (pre-existing design patterns are backed by research!). Due to time constraints, reaching out to a large sample of real users was not feasible, but this prompted me to connect with Customer Support Managers and Subject Matter Experts which helped to
uncover edge-case notifications
and establish a set of formal heuristics to make more efficient design decisions. Finally, participating in design team critiques and gathering feedback from cross-functional partners helped to
align on business goals and technical feasibility
to make this project launch successful!
