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.
Tools
- Balsamiq to create wireframe
- MS Excel to analyze usage data
- Autodesk Inventor and XML to customize the menu for testing
Role
- Analyze usage data
- Produce prototypes and wireframe
- Product owner for backlog grooming
- Partner with a user researcher for usability studies
Timeline
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:
- Is it actually beneficial to the uses to offer this?
- Which commands should go into the radial portion of the menu?
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.
- 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.
- 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
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.