AUTODESK
Restructuring Team Settings
ROLE
Experience Designer
SKILLS
Experience Design
User Research
TIMELINE
June - July 2025
TEAM
Experience Designer(Me)!
Product Manager
OVERVIEW
Manage Autodesk is the Central Admin Platform used by over 1.5 Million users every month
During my internship, I collaborated with the PSET team to restructure the Team Settings page, within Manage Autodesk Platform with the goal of making it more scalable, meaningful, and aligned with admin mental models.
Autodesk Account is where organizations control everything related to Autodesk software like users, teams, admin roles, licenses, product access, billing, and activity. It is used by IT administrators and program managers who manage access for hundreds of engineers, architects, designers, consultants, and contractors across projects.
OUTCOMES
Created a scalable framework for Team Setting
Defined categories that give every new and existing setting a clear, logical home.
Improved admin discoverability and usability
Made it easier for admins to find, understand, and manage settings without confusion.
Enabled alignment across teams and stakeholders
Provided a shared structure that different teams can follow, reducing ambiguity and overlap.
THE PROBLEM(S)
The Team Settings Page has grown without Strategy or Ownership
Over time, each setting has been added by different teams with little coordination or documentation, turning the page into a dumping ground of controls.
The Lack of Structure Makes it hard to Scale
As more settings are added, stakeholders like designers and PMs lack a consistent framework for contribution, leading to overlap and confusion. For admins, this results in increasing difficulty finding and managing the right controls.
Why it Matters?
For Stakeholders
Without a framework, new settings get added inconsistently, making collaboration harder and slowing down product development.
For Admins
A cluttered and unstructured page means wasted time searching, misconfigurations, and reliance on support.
For Autodesk
The lack of strategy risks higher support costs, slower adoption of new features, and reduced trust in the platform’s usability
MY APPROACH
How I tackled the Challenge
To address the messy and unstructured state of Team Settings, I approached the problem step by step. I began with an audit, explored multiple strategies, and gradually narrowed down to a framework that was both scalable and validated by real admins
Current Settings Audit
My first step was to carefully review all the current settings to understand their function, purpose, and how they fit within the page
Realization 🫣
After reviewing the settings myself, I realized that just knowing what existed was not enough. To understand the background, I spoke with the stakeholders who owned each setting, including product managers and Designers.
Audit Notes
IDEATION
Exploring Possible Directions
After gathering insights from the audit, I explored different strategies to organize settings. My goal was to test what structure could scale and still feel intuitive for admins and stakeholders.
Click the cards to know the reason of not going forward with the Ideas 👇
The Problem with direction was that usage frequency data was not available for all of the settings. SO I had to stop going towards this direction
01
X
REARRANGE THE SETTINGS BASED ON THEIR USAGE FREQUENCY
This was the best option possible , but due to constraints I was not able to work on this Idea
02
HAVE GLOBAL TEAM SWITCH WITH CONTEXT BASED SETTINGS
I had to go with this idea because it was the most feasible option
03
CATEGORIZE THE SETTINGS BASED ON THEIR PURPOSE
But how did I categorize them? 🤔
From Settings Dump to Information Architecture
After exploring possible strategies, I moved forward with categorizing the settings. I grouped them into clear, purpose-driven categories so every new and existing setting could have a logical home.
My first pass was about finding natural clusters
Settings that shared a function, an audience, or a workflow. For example, login-related settings under one bucket, resource-related ones under another
My Figjam File Screenshot
This is how I sorted the Settings
Identity and Access Management
Resource control & Licensing
User Consent
Reporting and Notifications
TESTING
Testing it out
Once I had an initial set of categories, I wanted to check if they actually made sense to admins and matched their mental models. To do this, I tested the categorization.
The Closed Card Sort
Admins sorted settings like SSO, Directory Sync, and Default Assignments into predefined categories such as Identity and Access Management, Resource Control & Licensing, and Reporting and Notifications.
DEMOGRAPHICS
ADMINS
AGE
10
COMPANIES
Goal : To check whether my categories aligned with admins’ mental models and spot any confusion.
Results
The results showed a strong alignment with my proposed structure:
SSO (92%) and Directory Sync (72%) went into Identity and Access Management.
Default Assignments (52%) and Subscription Usage Policy (76%) went into Resource Control & Licensing.
Report Scheduling (96%) and Inactive Users Notification (88%) went into Reporting and Notifications.
User Role Policy (88%) was clearly placed under Identity and Access Management.
What This Validated
The categories I defined matched how admins naturally grouped and understood the settings.
There were no major mismatches, which gave confidence that this IA could scale as more settings get added in the future.
The results confirmed that a purpose-driven framework is much easier for admins to navigate compared to the old “settings dump.”
Stakeholder Buy-In
After validating the categories with admins, I presented the proposed framework to designers, PMs, and other stakeholders to align on naming and scalability.
The stakeholder Presentation
The initial name I used for one category was “Reporting & Notifications.” During feedback, the Delivery team shared that they were planning to add more Email-related settings in the future.
This meant that the original name might not scale well as new functionality was introduced 🤷♂️
Based on this input, I updated the category name to “Email Notifications” so that it more accurately reflected both the existing settings and those planned for the roadmap.
UI
Designing the User Interface
After validating that my categories worked well for admins, I shifted focus to the user interface. My goal here was to translate the new information architecture into a UI that felt scalable, easy to navigate, and consistent with Autodesk’s design system.
My Figma File Thumbnail
Current Layout
At present, almost every setting is placed under one broad label called User Management, which turns the page into a long list rather than a structured, scalable system.
As Chris Caddell said "This page looks just like an index of Settings"
Before creating new UI layouts, I reviewed older interface explorations that had been tried by a teammate in the past.This helped me see what patterns had already been tested, what strengths I could carry forward, and where gaps remained.
Previous Explorations
The screen comes after user clicks a particular team
My Final Designs
I went through a lot of Iterations before reaching the final version of UI Design for this page before coming to the final Ui
My Figma file with lot of Iterations
