Autodesk Inventor is a manufacturing CAD application whose first release was at 1999. Its example customers are Joy Mining, Park Manufacturing, Huntair Inc, Viking Yacht Company, etc. The software went through the phase of feature war, vying for the top of the market. The result is classic story: Large, capable software that is very complex.

As it hits the limit for the features that it can have, we turned around and realized the value of ease of use. Adopting marking menu was the part of the initiatives to bring the product to the modern age and improve the ease of ease.


  • Balsamiq to create wireframe
  • MS Excel to analyze usage data
  • Autodesk Inventor and XML to customize the menu for testing


  • Analyze usage data
  • Produce prototypes and wireframe
  • Product owner for backlog grooming
  • Partner with a user researcher for usability studies


It was one year release cycle that includes initial envisioning, 6-months development, and 6-months stabilization and beta release.


Understand the problem

Like any other enterprise level software, Autodesk Inventor has a long menu contents, which can typically take up the entire height of the screen. The basic layout of marking menu accommodates the eight radial portions for primary commands.

The questions are:

  1. Is it actually beneficial to the uses to offer this?
  2. Which commands should go into the radial portion of the menu?
The challenge: Converting the average context menu to the radial menu layout

The challenge: Converting the average context menu to the radial menu layout

Bring out insights from usage data

We analyzed the usage data from the past release to identify high usage commands and coverage of those commands. It showed that top 20-30 commands in the workspace of Inventor takes 80% of workflow. This result supported the single level of menu instead of hierarchical menu, while identifying the commands that we need to put in.


Explore concepts, define framework

The analysis result answered following questions.

  1. Is there a common elements that can be repeated across the product? The analysis shows there are repeatedly used commands across all task-based environments in Inventor. This guided us building a framework.
  2. What layout best fits the trade off between the workflow coverage vs ease of learning? I was able to quantify the hierarchical menu system vs single level menu system based on the usage data. Hierarchical menu did not add much more coverage, while trading off the learning curve. With that, we decided on the single level menu system.

Iterate with feedback

the release schedule and UX activity

the release schedule and UX activity

One hour sessions with 6-5 users every sprint

During the development process, we conducted regular usability studies in sync with the development sprints. In each cycle, we have talked to 5-6 users, often including 1-2 internal people to reduce recruiting overhead. We either tested with a prototype, which doubled as a specification, or tested with the working code. If the results invalidated our design direction, the change is fed back to the following sprint.

Longitudinal study with an alpha build

When we decided that the project was good enough to gather feedback with long term use, we have sent the alpha build to ~10 select customers who were willing to give it a try. We interviewed them after every two weeks. The feedback was surprisingly positive, given the fact that expert users tend to be critical of changes in UI.

Beta survey and follow up

After it was released, we have sent the survey to the beta participant. 150 people responded to the survey and we identified top 8 issues with the marking menu, most of which were addressed before the release.


RESULT: High Adoption Rate

The change of user interface has high impact to users, especially the product used by many design professionals who pride themselves with proficiency with the application. 

The adoption rate turned out to be fairly high and the trend kept on consistently.

adoption rate