Designing the User Experience at Autodesk

Bad design practices – Generalizing

By Lynn Miller

In my previous blog post I covered some of the factors that contribute to overdesign. There is one factor I would like to talk about in more detail: Overgeneralizing the problem.

Let’s say you own an old building that has been converted into apartments. During the renovations all of doors were modified to be a standard door height or higher, except one. One door at the back couldn’t be changed and is lower than the rest. People keep hitting their heads on this door and you would like that to stop as the liability insurance is getting expensive.

You bring in two designers who walk around the building observing everything, and who witness people bonking their noggins on the offending door. They go off and design their solutions.

Designer 1 comes back with a paper sign that she plans to affix to the top of the door. Then she will observe to see if it works and tweak wording and placement as necessary.

 

 

Designer 2 notes that one really tall guy needed to duck at all the doors, not just the low door, and that shorter people didn’t have a problem with the low door. So his solution is to put a sign beside every door that says what the clearance is (5’ 6”, 7’ 0”, 7’ 4”) so that the user can decide if they need to duck or not. This solution, he argues, works for all cases and makes the door signage consistent. He is so confident that he doesn’t think that testing is necessary and suggests you get 372 of these signs made right away in a nice walnut with copper trim.  He has even mocked up an example of what the sign should look like:

 

 

Designer 2 has overdesigned by assuming that a specific issue extends to a wider range of cases – in other words, by making the problem bigger than what has been observed. He has given equal weight in the design to the edge cases (very short or very tall people) even though there was no observed problem for them. If he didn’t actually see people having a problem at the other doors and has simply assumed there is one because of overgeneralization, then he is designing a complex solution when one is not required.  Not only is his design much more costly to implement, but because it is complex and doesn’t address the root issue (a low non-standard door takes people off guard) then it is not likely to even work.

There are many other issues with his design. Can you spot them all?

Bad design practices – Overdesigning

By Lynn Miller

This is the first in a series of blogs on bad design practices. I’m going to tackle overdesigning first since it very common, especially for new designers.

Overdesign is putting in too much functionality and too many options. This leads to the extra bits getting in the way of the most needed functionality, making it harder for the end users to learn and use the software.

Overdesign is sneaky in that it uses the designer’s enthusiasm for doing the right thing to weaken the overall design. In design, more is not always better.

vs

Overdesign not only complicates the user experience, but it also complicates the code, makes it harder for quality assurance testers (QA) to do their job and creates more documentation. Overdesign can also be a significant waste of a designer’s time if the design has to be cut back due to a lack of development time to complete the whole thing.

There are many contributors to overdesign. One common problem is when the designer does not understand the difference between something that could possibly be useful vs something that would probably be useful. If something is probably useful then it is almost certain that the majority of people want it and will use it. If something is possibly useful then you can think up a case where someone might need it. If you are adding possibly useful cases to your design then you are overdesigning.

A designer can think up a lot of cases that could possibly be useful. Other designers who review your design are also usually great at adding use cases and suggesting functionality. But smart designers make sure they only add in elements that are sure to be useful for most people. The only way to know the difference is to really understand your users and their workflows by doing research up front.

Another contribution to overdesign is pressure to support workflows that are common for in-house users on the development team. Developers, QA, and the designers themselves may have to frequently repeat certain actions that an end-user would not need. Or they may have a certain favorite workflow that they want supported that is not used in real production. Resist the temptation to expose these to the end-user.

The last contributor to overdesign that I want to talk about stems from Waterfall Development practices. If a designer has to completely finish the design before implementation has started and are not allowed to modify it after that point, then the tendency is to create designs that try to guess every possible usage situation. Once trained in this type of thinking, well-meaning designers can continue to overdesign even if they are moved onto Agile Development.

The solution to this, if you are on an Agile project, is to modify your design practices to fit with the agile iterations. Start with the most important user capabilities first and incrementally add complete but small piece of functionality until you pass the acceptance criteria. Then stop.

Are you guilty of overdesign?

Design Values: Complete Workflows over Long Feature Lists

by Lynn Miller on January 21, 2010

This is a follow-up article to John Schrag’s post on Design Values. The original post described the values we believe contribute to a healthy software design practice.  This post looks deeper into why we value Complete Workflows over Long Feature Lists.

As with the proceeding posts, stating that valuing complete workflows over long feature lists does not mean that we are against long feature lists. If you can get a long feature list added to a product and still maintain complete workflows – go for it!

However, implementing a long list of disjoint and disparate features does not serve the end-users well. Even implementing a list of coherent features is unacceptable if the final result doesn’t support a complete workflow. As in the image below, constructing walls and a door doesn’t make a livable house if there is no roof. I would think potential end-users of these houses would have traded off the windows-feature to get the roof-feature implemented.

Photographer: David Goldblatt
Incomplete houses, part of a stalled municipal development of 1000 houses.
Lady Grey, Eastern Cape, 5 August 2006

Long feature lists often result from gathering customers' proposed solutions. The customer requests, “I want a print menu” (a solution), instead of “I need to share my work” (a problem). But as Theodore Levitt of the Harvard Business School said, "People don't want to buy a quarter-inch drill. They want a quarter-inch hole."  If you implement features without understanding what the customer really wants, then you can end up with multiple solutions for the same problem, with none of them quite succeeding.

To get a complete workflow you need to understand what your customers end goal is. From this you can either design a complete solution that gets the user to where they want to go or you can identify the gaps that need to be addressed in your current solution.

The Kodak EasyShare digital cameras are a good example of understanding what users are trying to accomplish and providing a complete solution. Kodak recognized that their user’s end goal wasn’t to take pictures – but to share pictures. Their solution was to create an inexpensive digital camera that people could slip into a cradle, click a button, and share photos effortlessly through email. Kodak became the market share leader because of this.

Understanding your customers end goal isn’t very difficult. Talk to your customers about why they are asking for a certain feature, instead of blindly accepting the solution they propose. (Note: Their solution may turn out to the dead-on, but you are still better off if you know the reasoning behind adding the feature.) Try the 5 Whys technique – ask "Why?" until you get to the true cause of a particular situation or problem. Then you know that you are addressing the right issue – the one that will make your customers happy and won’t waste your development resources.

Design Values: Quality of Data over Ease of Data Collection

by Lynn Miller on November 21, 2009

This is a follow-up article to John Schrag’s post on Design Values. The original post described the values we believe contribute to a healthy software design practice.  This post looks deeper into why we value Quality of Data over Ease of Data Collection.

The first point that needs stating is that valuing quality of data over ease of data collection does not mean that we do not value Ease of Data Collection. It is important to make data collection as easy as possible in order to reduce the time commitment and financial costs, but cost reduction must not overshadow the need to use the right method for the data needed.

Let me give you an example.  A while ago, one of our product teams was trying to decide if they should continue to provide printed documentation to our customers.  The team created a survey which was sent out to the customer base. Surveys are low-cost and fast to create. At the same time, members of the product design team were on a string of customer site visits.  Customer visits are slow and fairly expensive. While at the sites, we looked around for the printed manuals or asked to see them. The results from the survey showed that 80% of our customers said they were using the printed documentation. The results from the customer visits showed that the majority of printed manuals were still in their original shrink wrap, locked up where end-users couldn’t access them, or were sitting in pristine condition on a shelf away from the users’ work area. The survey might have been low-cost and quick – but it got the wrong answer.  If we had continued to print the manuals based on the survey results, we would have spent far more money than the cost of the trips to the customer sites.

Getting quality data means matching the type of data collection to the type of data needed, and some types of data are harder to collect than others.

Gathering behavioral data seems to be most affected by the desire for easier data collection. Good quality behavioral data needs direct observation. Going for anything less than direct observation is sacrificing quality for ease of collection because of the factors that affect people when they are asked to self report their behavior.^1,2  When people are relying on memory, their answers can be distorted, incomplete, or biased.³

Surveys are the easiest form of data collection and thus the most abused. How often have you been asked to fill in a survey and found that you couldn’t answer a question and there was no way to indicate this? Sometimes it is just poorly worded questions, but often it is because the information should be gathered using a different technique.

For example, a well-known store sent me a survey a few weeks after I had made a purchase there. It had this question on it:  How many minutes did you stand in the check-out line? How could I possibly remember that with any degree of accuracy? If the store was considering making changes based on the data they were gathering, they would have been better off sending people into the stores to time the check-out line. Otherwise they might make changes based on my saying I stood in line for an hour, when really it only felt that way.

Quality data is data that allows you to make the right decisions. To get that data, UX professionals should be willing to put in the amount of work necessary and not be tempted to “get what they can” due to time or resource constrictions. Going for fast or cheap now can lead to expensive changes later on.

1 Blair, Edward and Scot Burton (1987). Cognitive processes used by survey respondents to answer behavioral frequency questions. Journal of Consumer Research 14: 280-288.
2 Bradburn, Norman M., Lance J. Rips and Steven K. Shevell (1987). Answering autobiographical questions: The impact of memory and inference on surveys. Science 236: 157(5).
3 Schacter, D. L. (1999). The seven sins of memory: Insights from psychology and cognitive neuroscience. American Psychology, 54, 182-203

Autodesk User Experience Talks at UPA 2009

by Lynn Miller on June 4, 2009

Autodesk is happy to be participating in the Usability Professionals' Association 2009 International Conference, Bringing Usability to Life.  This year’s theme is particularly interesting to us since so many Autodesk products are used to design the objects that affect our lives daily – from the buildings we work in and the systems that supply them, to the cars we drive, and even the computer games we play.

We have nine different sessions this year, so there should be something for everyone.

Chauncey Wilson will be presenting his paper, The Art of Style Guides: Process, Politics, and Public Relations, as well as appearing on the panel: Heuristic Evaluation: Use and Abuse. Both of these have valuable insights for those fairly new to the field. For novices and experts alike, Chauncey is also on the panel, The Difficult Quest for a Formal Usability Body of Knowledge. This panel will debate the purpose and future of the UPA Body of Knowledge project.

On the agile development front, Lynn Miller will be presenting Traits of Successful Agile UX Designers, and facilitating the workshop Best Practices of UCD in Agile. Desirée Sy is presenting Coherent Agile User-Centered Design: Create a Big Picture in 2-week Chunks, a must-see for all designers on agile teams.

Autodesk also has three case studies in the program. Teresa Bleser and James McElroy will present Infusing UCD into Product Development While Driving Organizational Change. Rebecca Richkus and Gregg Stanley will describe the useful methods they found for working together in Design Partners: a Tale of UX and Subject Matter Experts Designing Together. And last, but not least, Erin Bradner and Melissa Dawe will share real-world lessons learned conducting a usability benchmark on a large, complex software application in their talk: Parts of the SUM: A Case Study of Usability Benchmarking Using the SUM Metric.

Drop by a session and say Hello!

Coffee and Documentation

by Lynn Miller on April 17, 2009

For me, travel requires coffee.

So I was happy to see a coffee maker in my hotel room while I was at CHI – particularly since CHI starts at 8:15am. Being an upscale hotel, my room had an upscale coffee maker laid out nicely on a tray.

 

There was an instruction card propped up in the coffee maker. My guess is that the instruction card was created after the 500th call to the front desk to say that the coffee packs were twice the size of the basket they are supposed to go into and the cheerful front desk staff were getting less cheerful when telling the guests they should stuff it. (The coffee pack into the basket, that is.)

 

This got me thinking about the design of documentation.  Can you spot the missing step in the (unfortunately slightly fuzzy) instructions below?

Do you think that, even in the early morning, there are people who end up slurping coffee off the table top because the instructions didn’t say to put a cup in to catch the coffee? I rather doubt it.

I like the concept of not treating the readers of documentation like idiots. This little card gave me the information that I needed and couldn’t know ahead of time (how much water to use, the filter looks too big but is the right size, only push the button once) without wasting my time by giving me information that I either already knew or could easily guess (I can get water from the sink, I need to use a cup).

Can we use this concept in software documentation? What parts can safely be left out so that we are only highlighting the pieces that are really needed?  This is different than trying to reduce word count by using simple writing concepts (which I am a big fan of).

Back in the 1980’s, software documentation had to include instructions on how to use a mouse. This was dropped when mouse usage became part of the general knowledge people were expected to have -- just like catching the coffee with a cup is.  Are there concepts in our documentation that are just as obsolete, but we’re keeping them to be complete? How do we root these out?

Something to ponder.

Autodesk Sponsors CHI 2009

by Lynn Miller on April 1, 2009

I used to think that there was nothing better than going to a conference and sharing my discoveries with my peers while gaining new insights from them. But there is! Being in a company that sponsors the conference!

I am happy to say that Autodesk is once again demonstrating its commitment to the field of HCI by becoming a Champion Sponsor of CHI 2009. We are proud to help fund this important event and hope that we get to meet many new people, along with old friends, at our booth.

In case you haven’t seen our booth, it looks like this before the crowds descend on it.

We’ve got six people presenting this year (see Come See Us at CHI) who will be at the booth to talk to people about their presentations, what working for Autodesk is like, and to engage in lively discussions about the state of user interface design.

We’re also having a raffle at our booth! We’re giving away two copies of popular Autodesk software like Mudbox, Maya, or Inventor. You can sign up for the raffle by dropping your business card into the bowl at our booth.  The raffle will be held on April 9th, and you don’t need to be present to win.

We’d love to see you there!

Come See Us at SIGCHI 2009

by Lynn Miller on March 11, 2009

We at Autodesk are pleased to be having our largest presence ever at SIGCHI in 2009.  Not only are we a Champion Sponsor (more on that at a later date), but we have six people presenting this year on a variety of topics.

Lillian Smith and Greg Demchak are showing Project Chicago: Green Research in the Video Showcase on Tuesday, from 6:30 to 8:00pm.  Their video showcases a highly graphic, interactive technology concept for evaluating water and energy reduction, indoor environmental quality, and carbon footprint impacts and giving designers an immediate sense of the results of different building designs. This proposed sustainability dashboard concept is demonstrated on a 6’x3’ touch screen to explore its potential use as a collaborative tool. The dashboard is presented by Autodesk as a technology concept; it is not a commercially available product.

Lynn Miller and Desiree Sy are holding an Agile User Experience SIG on Wednesday from 9 to 10:30am. The goal of this SIG is to draw upon the shared experience of UX practitioners to uncover the best practices for agile user-centered design which facilitate optimal product development.

Lira Nikolovska, Greg Demchak and Matt Jezyk are presenting two papers as part of Designing for Discovery on Wednesday from 4:30 to 6:00pm.  The first paper, Simplified User Interfaces for Design and User Testing of Architecture Software Applications, describes the value of creating simplified user interfaces for use in early conceptual design phases. By simplifying the interface, the team was able to solicit specific feedback about new tools without the overhead or pre-conceptions associated with using an existing software platform. As a result, the team was able to iterate rapidly on specific problems. The second paper, Understanding User Needs for Conceptual Design Phases of Architecture Projects, describes design research methods used to understand user needs, identify user requirements and create new conceptual design workflows for an existing architectural software application.

And last but not least, Autodesk employee Chauncey Wilson is a member of the organizing committee for the User Experience and Usability community.

We hope to meet you at SIGCHI this year!

Lynn