Autodesk Data Platform (ADP)

ADP is Autodesk’s next generation big data platform. By combining datasets from across the company into a single warehouse, ADP offers unparalleled insight into customer behavior.

ADP was built on foundations from many earlier iterations. By 2018, the complexity of these foundations was beginning to impact the user’s experience to the point where creating a simple data pipeline required intense, custom guidance.

Embedded within the Data Platform Strategy and Engagement team (DPSE), my role over the summer of 2018 was to research, conceptualize, and design a system to improve the user experience of ADP.




10 weeks


Conner Hunihan
Product Manager, UX Designer
Kristen Zhou
Product Manager
Carlo Liquido
Data Engineer
Daniel Chen
Data Scientist

Personal Skills

Workshop Facilitation
User Research
Concept Development

Empathizing with the Difficulties of Big Data

To develop intuition around the knowledge challenges facing ADP, user research was conducted including over 20 interviews, two workshops, a community survey, and countless whiteboard diagraming.

Distinct user groups

The community survey revealed distinct user groups within ADP, each of which had their own data needs, technological proficiencies, and preference for learning.

Matrix of ADP Users

As a data platform, ADP contains an ecosystem of users, each with their own distinct needs and values. Identifying "user buckets" allowed the DPSE team to prioritize efforts and develop an intuition of project impact.

Identifying Resource Gaps

An audit of the existing ADP knowledge bases was conducted to target most troublesome areas. While knowledge gaps were discovered throughout the entire ADP process, it was the uncertainty at the beginning stages of engagement – when a business team investigates capabilities of the data platform – that offered the most potential. A team cannot use the platform if they don’t know what it can do.

Audit of Existing Knowledge Sources

Rows are knowledge sources, columns are steps in the process of engaging with ADP. Yellow denotes missing or out of date sources, while red indicates large knowledge gaps.

Articulating User Needs

Interviews with data engineers, data analysts, product owners, and team leads suggested that knowledge needs varied significantly across teams. Whereas individual contributors commented on the need for step-specific, detailed instructions, teams spoke of the need for high-level value proposition – how can they build a project around ADP?

"My biggest complaint about ADP is that no one knows what data is in there."

– Data Analyst

"Understanding the process and contact points would have cut the time in half."

– Data Engineer

Defining a Project Scope

How might we

Building on key insights uncovered during research, a How Might We Statement was created to frame the objective of the project:

How might technical, process documentation communicate the value of ADP?

Defining prodcut specifications: what is ADP?

In collaboration with the DPSE group, as well as a consulting team from Fjord, ADP functionality was divided into four distinct prodcut packages: Analytics, Data, Core Services, and Support.

ADP Product Packages

Analytics represent the off-the-shelf analysis products, data represents the raw material, core services stand for the engines of action on the platform, and support is help offered primarily by the Learning and Development team.

Designing a single product experience to scale across the suite

The Data Modeling & ETL product within the Core Services package was chosen as the experience to design because the ETL process touches nearly every role on every team that engages with ADP.

A solution that improved the user experience of running an ETL on ADP would serve as a template to be extended to the rest of ADP products.

Choosing a Specific Product Experience

Within the Core Services package, Development & ETL was chosen as the product expeience to desgign for because of it's criticality to the platform: every project requires extraction, transformation, and loading of databases.

Project Plan

With key insights uncovered and a design objective defined, the final project scope was now in focus and a project plan was also created to track progress throughout the rest of the summer:

Project Timeline

The project was divided into four phases: research, synthesis, propose and presentation.

Phase 1: Create a Structure for the ADP Portfolio

Finding a place: The data portal

A centralized Data Portal platform already existed, however, the Portal was created alongside an earlier generation of ADP. As such, information was outdated and did not address the capabilities and processes of current ADP offerings.

The Existing Data Portal

The Data Portal was managed by the Learning and Development team, but ultimately maintained by a contracted web design firm.

Creating a home: Information Architecture

Card sorting exercises were conducted with a Data Engineer, Data Scientist, and Product Manager to refine an intuitive categorization schema.

Card Sorting Exercise

The exercise refined not just taxonomy of the site, but terminology, as well.

The resulting knowledge hierarchy emphasized ADP value at the highest level, gradually funneling users into progressively technical explanation.

Lateral movement across ADP offerings allows for technical users to drill directly into the content they are searching for.

Conceptual Knowledge Framework

Defining the hierarchy of knowledge for the site allowed a distinction to be made between high-level ADP value (which appeals to Data Readers and Team Leads), and low-level product details (which appeal to Data Analysts, Engineers, and Scientists).

The conceptual knowledge hierarchy was operationalized into a comprehensive restructuring of the Data Portal’s information architecture.

Data Portal Information Architecture

A comprehensive mapping was created that outlined the total content required and where existing content is located.

Mockups of the Data Portal with the revised information architecture were created for the Learning and Development team to share with contractors who manage the site.

Data Portal Mockup

Phase 2: Design an ADP Product Experience

Mapping the User Journey

A service design blueprint synthesized research and visually represented paint points, dependencies, and areas of opportunity that exist throughout the process of using the “Data Modeling & ETL” product.

ETL Service Design Blueprint

Mapping of process, pain points, dependencies, and areas of opportunity involved in the ETL process on ADP.

The exercise suggested that technical users required three distinct pieces of knowledge throughout their engagement with ADP:

An overview of the process required to use the various softwares of ADP

Detailed explanations of permissions, points of contact, and use case-dependent instructions

Notes of what works and what didn’t for teams that have gone before

Initial Prototypes

Early prototypes were tested with users to refine the design of a boilerplate webpage for ADP products.

Low Fidelity Wireframes

A rough prototype was created to validate if the prioritization of content was accurate and relevant to users.

Usability Testing with Data Engineers

Mockups of the restructured Data Portal and ADP Product page were tested with Data Engineers.

Users praised the high-level overview and guidance that the site would offer, but commented that many of the details required to actually run an ETL are not documented on any source.

A wiki rennovation was being simultaneously conducted by the Learning and Development team to address this concern, but maintenance of the technical knowledge base was acknowledged as a crticial assumption to the design’s overall success.

Final Deliverables

High Fidelity Mockup

Comments from usability tests were incorporated into a final, high-fidelity mockup that was delivered to the Data Strategy and Experience team.

Lessons Learned from Big Data Design

Working on the Autodesk Data Platform was a unique and invaluable experience in many ways. I learned much that, were I to run the same project again, I would do differently.

Personal Strength: Synthesizing

The project was interdisciplinary from the very beginning, crossing boundaries between user experience design, research, data science and business, and I realized a personal strength in synthesizing and communicating across those team and boundaries.

Personal Passion: Consulting + Service Design

I discovered a tremendous passion, not only for service design, but for working in the capacity of a consultant.

As a platform that facilitates team-based big data explorations, designing for ADP required more than a list of needs and a few personas. It required an understanding of the working relationship teams have, and of how data helps facilitate that relationship. I discovered a passion for mapping processes, measuring across dimensions. and prioritizing efforts.

Professional Realization: Process, process, process

An ambitous project on a tight deadline required clear direction at all times. School and previous projects had exposed me to pieces of an overall process, but the ADP project helped me realize how a comprehensive process enables true innovation.