Designing the User Experience at Autodesk

Making Things Simple can be Complex

by Mark Jamieson

Software designers repeatedly face the challenge to make their products usable. One important and often overlooked principle is to make their products simple, which is harder than you might envision.

A simple software application is easier to learn. It makes the software user feel in control, reduces uncertainty while making their actions more deliberate, and efficiently accomplishes tasks. Simple software applications are, in my opinion, also more pleasurable to use.

Complex software applications are harder to learn and usually get more complex, making it increasingly difficult for mainstream users to differentiate between the core features (most used) and the peripheral ones (less used). Experienced users are often surprised to discover newer, more efficient features (several versions after their introduction into the application), because the older variant of the feature that they use daily, co-exists with the new one.

If simplicity isn’t considered as a key component of the design process, then software applications become increasingly complex as more features get added. We’re really good at adding new features but not so good at eliminating or retiring stuff.

Giles Colborne has thought a lot on the issue of simplicity as it relates to usability and proposes four basic strategies for designing for simplicity in his book, Simple and Usable.

1. Remove – Eliminate unnecessary or obsolete features entirely from the interface so the essentials that are core to your target audience remain. This isn’t an easy task, and will often be met with resistance both with your customers and internally with a variety of stakeholders. However, if you track feature usage in your application automatically, you’ll hopefully have a set of data analytics that can aid in making the business decision for a feature’s removal less emotional and more objective.
2. Organize – Arrange items into manageable groupings or “chunks”. This effectively puts multiple related items into categories thereby reducing the number of things a customer has to view or remember at any time. Items can be organized by related purpose, hierarchy, layers, colors, size, location, alphabetically etc. Organize is a frequently used strategy to make software applications simpler and easier to use.
3. Hide – Place features out of immediate view but still make them easily accessible. Features that are used infrequently are often good candidates for being hidden. For example, preferences are something that can usually be hidden since they are used so infrequently. Features can also be designed to progressively disclose more controls to further extend a simple feature so it suits the needs of expert users.
4. Displace – Move features to another location entirely. In his book, Colborne uses the DVD remote control as an example, whereby instead of having many “hard” buttons on the remote, it displaces these features to “soft controls” on a menu on the TV screen, simplifying the remote as a result.
   
   Displacing may involve moving some complex features from a mobile device to the cloud, thereby reducing the complexity of the mobile application and take advantage of the strengths and power inherent to the cloud. Displacement can also involve combining related features into one general tool. For example, a tool that combines move, rotate, and scale capabilities would be efficient in a 3D software application since those operations are often done in conjunction with each other.

Which of these four strategies could be employed to simplify this toolbox mockup?

 

One solution groups and hides tools. The icons displayed below the dashed line indicate hidden tools accessed from a drop-down list containing other similar tools for that category.

The strategies that were used:

• Organization - Icons were grouped into six main categories: File management, drawing, graphing, view management, image rotation, and locking.
• Organization – A default icon from each grouping was chosen to represent each category based on what a typical software user might require.
• Hide - A small triangle graphic was added to the lower-right corner of each icon position to indicate that additional hidden tools are available. This is a common convention that many existing applications employ.
• Remove or Displace - The gear cog icon was removed entirely. The preferences it represents are accessed by incorporating the preferences in each tool or by displacing the preferences feature to a suitable menu/location within the user interface.

Simple products have repeatedly been proven to have a profound impact in the market place. It’s our job as designers to make a case for making products more usable and simpler whenever and wherever possible.

Practice Giles Colborne’s strategies by simplifying another of his examples.

Participatory design charrettes: can they build consensus in a diverse group of users?

by Roxane Ouellet and Ian Hooper

What do you do when your product is used by an animator for a small game studio, a marketing manager for an aviation/engineering company, and a visualization specialist for a massive infrastructure corporation? How do you identify and prioritize requirements for such a diverse set of users? That is the challenge we face with 3ds Max, and to help solve it we invited twelve of our most vocal customers to come to our office in Montreal.  We bribed them with the promise of good food, city life, and the chance to contribute to the design of a key application in their workflow.

We wanted to give 3ds Max users from a diverse set of industries the chance to tell us what they need in the product.  We were also curious to see if they could all agree on what Autodesk should focus on for the next few years.  Would each camp stand their ground for their team?  Would some kind of consensus be attained?  Let’s see what happened...

At first, we gave users some time to “vent” in an unscripted fashion.  Then we got down to business and asked them to write down requests for 3ds Max on post-its - as many as they could fill for 15 minutes.  This produced a LOT of requirements and feature requests.  After unifying the duplicates, we conducted an open-sort affinity grouping exercise with everyone chiming in.  This went surprisingly well, with people quickly settling on a common set of categories into which all of the post-it ideas could fit.

This wall of ideas was great, but far too big for us to tackle as a group in the brief time we had together. We needed a way to reduce the number; but how could we identify the most important ones?  By asking our users to vote!  We gave stickers to each participant to put on the ideas/issues they wanted us to work on the most.  Knowing human nature, we devised a simple mechanism to avoid people voting only for their ideas: only three stickers out of twelve could be used to vote for their own ideas (they were color-coded and initialed…).  Seven stickers could be used to vote on other people’s requests, and two red stickers to veto requests that made no sense to them.  The voting was a success except for one thing: no one used their red stickers. It was probably because their initials were on them and they did not want to offend others, or that they could not bring themselves to remove a feature that may be vital to someone else.  Was this the sign of a group dynamic emerging?

The post-its with the most votes were singled out, combined, and grouped again to identify four themes to be tackled in the next step. Interestingly, two themes were more industry specific, while the other two were related to UI, usability, and features that could be beneficial to all.  Together, the group identified a series of requirements to create a Design Brief for each theme.

Then the main group was divided into four breakout teams, which also included developers and QA.  Simulating a design charrette, each group took their design brief and worked to further refine the requirements.  High-level design solutions were sketched.  One representative from each group then presented the work to the whole group, where everyone worked to refine the concept and clarify the goals and requirements.  In a second breakout, the design was developed with more detail, incorporating the feedback from the group.

In the end, this participatory design activity helped the design team identify the most important areas to address in future releases. But, it also served to make these vocal users aware of the process we have to go through when choosing what to work on.  We may not have achieved complete consensus amongst everyone in the room, but we did discover a great way for the many voices of 3ds Max to be heard.  

Method 25 of 100: The Monetary Method

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

by Chauncey Wilson

The monetary method is an individual or group technique for prioritizing requirements by asking users and stakeholders to “buy” requirements from a “wish list” given a fixed (imaginary) budget of say “$1200”. Each requirement is described briefly, and a relative cost is associated with developing that feature.

This method for prioritizing requirements forces potential users to think carefully about what requirements are most critical. You can do this online without play money by just sending out the list and asking people to choose up to $1200 of items by checking cells on a questionnaire (and setting things up so no one can overspend).

Conte (2004) uses a variation on the monetary method as part of a rapid task analysis. Conte had a group of users write down, in 10 minutes, all the tasks that define their work on index cards - one task per card. The users then grouped the cards into different categories of work and listed task frequency (low, medium, high, really high) and task importance for each item (low, medium, high). Then the participants were given $1000 in fake $100 bills and everyone was asked to pin one or more of the $100 bills on the tasks they wanted the new product to support.

When to Use:
You can use the monetary method to:

• Prioritize requirements
• Learn what general sets of requirements, features, content, or other items provide the most value to different groups
• Get users to make clearer distinctions about what requirements are essential
• Make tough trade-offs when you need to drop features  

Strengths and Weaknesses:

+ Low cost, and minimal training

+ Fun and engaging

+ Can be conducted in person or online

+ The process of asking people to buy a set of requirements on a fixed budget provides a clear differentiation between important and “nice-to-have” requirements

+ Data analysis is simple

– You need a large sample of potential users

– Some companies worry about doing this online since it could reveal something about future products to competitors

– This method gets more complex if you have to consider dependent requirements

Procedure:

The basic monetary method procedure is:

1. Describe a small set of core requirements that will definitely go into a new version of software.  These “must have” requirements are guaranteed and not included in the list of requirements that users can buy. 
2. List a set of proposed requirements with clear descriptions and the relative costs to develop those features. For example, features that were easy to develop (e.g. 1-2 weeks) would cost $100, features that required a moderate development effort (e.g. 3-4 weeks) would cost $200, and features that were complex and difficult to develop (e.g. more than 4 weeks) would cost $300.  The figure below is a monetary method form that contains core requirements, instructions, and example requirements.
3. Brief the participants about the meaning of the relative costs.  For example, you might say that $100 requirements take 1-2 person-weeks to develop, $200 requirements take 2-4 person-weeks, and $300 requirements take more than 4 person-weeks of development effort.  
4. Give the participants play money and tell them that they could “buy” any combination of features as long as they don’t spend more than the allotted funds.  
5. Have users buy a requirement by circling (or choosing if online) the value in the Relative Cost column and put the money for that requirement aside. The amount of play money will depend on the number of features you present to the participants.  If you gave each participant $1200 in play funds, this means that they could buy four expensive features at $300 each, six medium priced $200 features, or various combinations of low, medium, and expensive features – as long as they don’t go over $1200. I generally give people enough money to buy three to five of the major features, though you can vary the amount of money to restrict the number of choices.  Another rough rule for assigning funds for buying requirements is that participants can’t buy more than about 30% or so of the total number of requirements with their funds.
6. Tabulate the results.

References:

Conte, L. (2004). The color of money – an agile technique for the prioritization of requirements. Proposal to the Boston UPA Miniconference. Natick, MA.

Gray, D., Brown, S., & Macanufo, J. (2010). Gamestorming: A playbook for innovators, rulebreakers, and changemakers.  There is a method in this book called the “$100 Test” that is similar to the monetary method.