Designing the User Experience at Autodesk

Sustainable User Experience in the Clouds (1 of 3)

By Kem-Laurin Kramer

Cloud Computing is the next generation of computing. The trend towards increasing adoption of delivery platforms, such as mobile and ubiquitous technologies, make implementation challenging. The marriage of cloud and mobile technology demands attention from end users if it is to be the new “normal” mode of web service delivery. As more companies embrace cloud computing, end-user experience challenges can be mitigated with good UX practices and general guidelines.

As early as 2003, Forrester Research predicted a trend in both the mobile and cloud based web services delivery. Today, companies are beginning to set cloud occupation goals. We will see a change in service delivery from traditional packaged software to a wider audience packed in the form of web services, allowing for software liberalization to the masses. This will change how end users respond and interact with services delivered in this form. Companies will need to consider design for a universal audience who may not have the esoteric skillset of past professional users. Forrester analyst Glenn O'Donnell writes, "cloud plus mobile is a classic more than the sum of its parts combination." This disruptive paradigm will become a challenge as we ideate a sustainable user experience in the cloud.

From a UX perspective, we need to transcend the general principles of a good user experience: satisfaction, effectiveness, efficiency, learnability and memorability. We also need to infuse what I will call Cloud-Aware User Experience Thinking.  That is thinking about the transformed environment of the cloud and the user expectations in this new space. This includes a keen understanding of the following:

• Software as Service (SaaS): What it is and what it means for the end user?
• Universal Design & Service Liberalization: The impact of web services liberalization and what it means for the collective wider scale of users.
• Value of Service Delivery: Expectations of the value of web services
• Privacy, Security & Trust: Expectations of privacy, security and building cloud trust.
• Flexible User Interfaces: Delivery of cloud services to multiple platforms and devices
• Social, Collaborations: Leveraging and fusing the social and collaborative ideals into web service delivery. 

 

Cloud Computing and the New User Experience

Cloud computing is a disruptive model for enabling convenient, on-demand access to configurable shared computing assets and resources. This includes servers, networks, data storage space, applications, and other services. It is distinct from the World Wide Web. It leverages the web to offer a new way of service packaging and delivery. Cloud delivery means service providers have minimal interaction with the user and as a result can focus on quicker service delivery.  As the level of connection between traditional service providers and end users erodes, optimal UX design becomes even more important. Users need to be self-sufficient as well as learn and grow with little to no service provider support. Users also require a strong sense of safety in a space that seemingly often undermines such necessities of privacy, security and trust.

 

What this means for User Experience and Design

As traditional UX evolves to accommodate new technologies, we must understand the changing landscape, conditions, and user expectation. This is challenging but not necessarily daunting. Ensuring an optimal sustainable user experience will determine both long and short-term adoption and growth of web services as traditional software offerings transforms to SaaS.    Fusing the prevailing ideals of user experience and sustainability one can address the key ideas for building the right Cloud User Experience.

In my next article, I will take a deeper look at the following topics as we examine a more evolved user experience in the clouds. The article will address the following UX challenges.

• SaaS: From traditional software to SaaS.  
• Universal Design & Service Liberalization: Designing to a wider scale of users.
• Value of Service Delivery: Context of service value and what it all means for cloud computing.  

Taken together, this and subsequent articles will help expand UX thinking and help us as professionals to understand the broader scope of what it means to design a cloud user experience.

Anatomy of an Error Message

By Cecilia Farell

“I’ve just picked up a fault in the AE35 unit. It’s going to go 100% failure in 72 hours.”

Some of you might remember this line spoken by the humanlike computer, HAL 9000, in Stanley Kubrick’s movie 2001: A Space Odyssey. Despite the trademark soothing voice (listen), HAL’s message has a chilling effect. Why? Because HAL doesn’t really say anything about what’s actually wrong (what’s an AE35 unit and how is it faulting out?). Even if he did, he offers no way of preventing the failure and whatever might happen because of it.

HAL of course is not unique. He “sounds” exactly like most of the applications and websites we interact with today. In the real world though, as HAL himself would put it, bad error messages are entirely attributable to human error.

The “good” in good error messages

Now that we’ve seen what a bad error message looks like, let’s talk about what you can do to make your error messages good. In a very early post on Alertbox, Jakob Nielsen identified five characteristics:

Explicit

An error message should first indicate that something is wrong. Let users know an error has occurred with an explicit and noticeable message.

Precise

Users also need to know what happened and where and, in some cases, why. But perhaps the most important piece of information they need is what the consequences of the error are, if any, so they can prepare for them. With this information, users feel in control because they know what to do to navigate away from the error.  

Human-readable

Error messages are for humans so they should be understandable by humans. Use plain language and write as a person speaking to another person. Avoid cryptic abbreviations and obscure codes. If you must use error codes, make sure they are supplemental and meaningful to your support staff.

Polite

Write your messages so they don’t punish users or make them feel stupid when they make a mistake (and they will). An error is always an inconvenience regardless of who or what caused it. So always take ownership of the mea culpa and show your customers that you care. This alone goes a long way towards alleviating their frustration.

Constructive

There’s really no point if an error message doesn’t say how to solve the problem and move on. This is where precision comes in again. Think of your messages as a tool to educate users so they can recover and navigate away from an error, and even learn how to avoid it in future.

Errors + error messages = user delight

Nielsen says that the worst error messages are those that don't exist. But it’s really the best error messages that are the ones that don’t exist because good design makes them unnecessary. No design, however, can do away with all errors. So error messages are here to stay.

With this in mind, Des Traynor treats error messages not as a negative but as an opportunity. For him, “all content is marketing” and “everything you write should be crafted with the intention of selling, educating, or increasing customer loyalty.”

If you agree with Traynor that “content is always an opportunity to delight your user,” error messages suddenly appear in a new light: as potential enhancements to the user experience instead of detractions. A perfect example is the whimsical customization of website error messages done to increase brand recognition and loyalty because of the customer’s emotional response.

HootSuite

PLM 360

You’ve heard of defensive driving; now there’s “defensive design”

Errors do happen, making design a lot like driving. The best drivers are those that anticipate driver errors and road problems so they can strategically react and recover from them when they happen. Likewise, the best designers anticipate user and application errors by designing for when things go wrong.[i] In other words, they practice defensive design.

Here are some basic guidelines for practicing defensive design from an article by Ian Lurie in Smashing Magazine:

• Validate to check input errors before they frustrate the customer
• Expand the available options based on the user’s implied intent
• Protect users from errors with informative messages
• Assist the user before errors happen

To learn more about defensive design and writing good error messages, check out the links below. Happy trails!

References

Hyde, John. “Handling User Error With Care: Getting Users Back on Track” in UX Booth, October 13, 2009. www.uxbooth.com/articles/showing-error-messages-to-users/.

Jarrett, Caroline. “Avoid Being Embarrassed by Your Error Messages” in UXmatters, August 9, 2010. uxmatters.com/mt/archives/2010/08/avoid-being-embarrassed-by-your-error-messages.php.

Kubrick, Stanley. 2001: A Space Odyssey. Entry in The Internet Movie Database (IMDb). www.imdb.com/title/tt0062622/ (HAL sound clip courtesy of The Movie Sounds Page. www.moviesounds.com/2001.html).

Lurie, Ian. “Getting Started With Defensive Web Design” in Smashing Magazine, May 27, 2011. uxdesign.smashingmagazine.com/2011/05/27/getting-started-with-defensive-web-design/

Nielsen, Jakob. “Error Message Guidelines” in Alertbox, June 24, 2001. www.useit.com/alertbox/20010624.html.

Traynor, Des. “All Content is Marketing” in The Intercom Blog, July 23, 2012. blog.intercom.io/all-content-is-marketing/.

_____. Microcopy That Strengthens Your Design’s Experience. Virtual seminar offered by User Interface Engineering. www.uie.com/events/virtual_seminars/how_seminars_work/

Waisberg, Daniel. “Optimizing Error Pages: Creating Opportunities Out of Mistakes” in Smashing Magazine, May 18, 2011. www.smashingmagazine.com/2011/05/18/optimizing-error-pages-creating-opportunities-out-of-mistakes/ 

---

[i] The concept of defensive design was introduced by Jason Fried, one of the founders of 37signals, and Matthew Linderman in their book, Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points. 1^st ed. New Riders, 2004. The phrase “design for when things go wrong” comes from the sub-title of one of the book’s chapters. You can buy the book on amazon.com.

 

Method 22 of 100: Affinity Diagramming

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

by Chauncey Wilson

This is the 22nd in a series of 100 short articles about UX design and evaluation methods. Today, I will discuss affinity diagramming, a method for organizing qualitative data into related groups as an individual or group. This method can be used to make sense of data from lab studies, field studies, open-ended questions, brainstorming, diary studies and other methods that produce qualitative data. Affinity diagramming is often done by a group of people in a room with sticky notes, but you can also do this remotely with tools like Google® Spreadsheet (see below), card sorting software and Microsoft® Sticky Sorter.  

View the full article

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?

Maya First Experience Study - the Value and Learning Outcomes of Such Studies

By Veronica Meuris

Imagine you’re on vacation. You’ve just arrived at your destination and are excited to experience everything this new city has to offer.

You leave your hotel room and head off on foot in the direction of the city’s highly recommended tourist attraction! As you walk towards it, you have to detour a couple of times and become a little lost for a brief period. Eventually though, you find your way again. According to the street signs, the attraction is just around the next corner. You excitedly turn the corner only to suddenly find that the road ahead is ‘Closed’. According to the blinking sign, you’re road-blocked. You turn back to retrace your steps but the route no longer looks the same. You turn another corner and hit another roadblock. Then another. Then another. Now, you don’t know which way to go – you’re lost. If only you could find your way back to the safety of your hotel… This experience of going from initial excitement, to increasing levels of frustration caused by obstacles in your path, to the deflating realisation that you’re lost is likely something we’ve all felt at one point in trying new software for the first time.

First experience testing is the most effective, accurate way to identify roadblocks or obstacles in software that make people feel lost. It involves observing target users who are new to the software you’re testing during their first hour of use. In doing this, you see first-hand what obstacles users encounter in trying to successfully use your application as well as what strategies they employ in trying to learn it.

From past first experience studies that we’ve conducted, we know that a user’s first hour of use with an application is a good predictor of continued use with it. Specifically, if users feel successful after their first hour with it, they are more likely to continue using it. If not, they are more likely to walk away from the product, and will probably not try it again, regardless of the changes you make to it after that time. That’s why making sure our products provide the best first experience possible is so important.

I recently completed a first experience study on Autodesk Maya. After the first couple of tests, we began to see patterns emerging - users were encountering the same obstacles and roadblocks. With these early users, we saw that they didn’t get very far into the application. All got stuck in various modes which left them road-blocked. The modes they accidentally entered changed the way some tools worked while turning new tools on and previously shown tools off. Because of this, most users spent their first hour struggling and all expressed frustration at the end of the session over not being able to accomplish more.

As such, we made design changes and tweaked our prototype between tests, trying to address the problems we saw users encountering. Our goal in designing solutions for the problems we observed was to come up with the smallest changes possible to tackle users’ problems while weighing the benefits our solutions would have against the impact, if any, they would cause experienced users.

As our first experience testing progressed, our relatively minor, low-cost changes were validated. The improvements in how users felt using the software and in what they were able to accomplish compared to users tested earlier in our schedule was remarkable. Users got considerably farther into the application during their first hour with it and instead of being frustrated at the end of their session, were very pleased with how much they’d accomplished. Clearly, even small changes can make a huge difference in a user’s first experience with your software.

Autodesk is always working to put the needs of it users first. First experience studies provide invaluable insight into how we as designers, can learn about those needs and best design for them in order to optimize ease of learning, ease of use and overall satisfaction with our products. 

Managing UXD and UA for Multiple Agile Teams

By Karen Smith & Joshua Ledwell

While the transition to Agile software development means big changes for everyone who’s “going Agile,” it has the potential to have the greatest impact on User Experience Designers (UXD) and User Assistance (UA) writers. Although Agile teaches that team members should be fully dedicated to one team, the budget constraints of many teams dictate that some people are shared across more than one team – and those people are often UXD and UA. As more project teams transition to Agile software development and strive to deliver more customer value in shorter, sprint-like chunks, sharing our experiences and best practices with others in UXD and UA is now more important than ever.

At the outset, participation on multiple Agile teams may seem overwhelming, perhaps even unmanageable. Over the last year and a half of working with a variety of Agile teams, we’ve learned that when UXD and UA work together, and have a shared vision with their Agile teams, the process becomes more manageable.

To ease the difficulty of working across multiple Agile teams and work more productively, here are some best practices for UXD and UA:

• Show your Agile team that you are a shared service and that your time is divided between multiple projects and assignments. This helps them understand why you may not be able to attend every standup meeting.
• Volunteer to help with other needs of the team. For example, offer to take notes during a user research or feature usability session, or offer to help with testing.  Agile is about breaking down traditional silos and accepting team responsibility for the success of the product.
• Even though Agile means a full schedule of meetings, UXD and UA should participate in non-Agile team activities, such a lunch outings, impromptu coffee chats, etc.  Getting to know your teammates pays off when you need help documenting a feature or understanding what design choices are possible.

In addition, here are some best practices specifically for UA:

• Prioritize the various Agile meetings. Daily standups, planning, and demos are the “must attend” meetings. UA should skip meetings that aren’t relevant or that don’t add value to the development of learning content.
• Track UA tasks separately from software development tasks. The biggest advantage to this approach is that the closing of a software development user story included in the definition of “Done” is not dependent on the completion of learning content. In addition, Agile team members can separately assign user stories and tasks to UA. If you’re using JIRA to track user stories, you can add links from the UA user story to related software development and QA user stories and tasks, making it easy to find the related information later on.
• Provide feedback to your Agile team on best practices. Getting involved in the team is the key to building trust and earning credibility. Set expectations for UA deliverables, identify where you can contribute to shared team objectives, and be clear about what you will contribute.
• When authoring learning content, don’t be afraid to write fiction. Then iterate, iterate, iterate.

 

To learn more about developing user assistance in an Agile development environment, check out these articles:

• Introduction to Agile Methodologies
• Agile for Technical Writers
• A Writer's Guide to Surviving Agile Software Development

 

Method 21 of 100: Collages

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

by Chauncey Wilson

This is the 21st in a series of 100 short articles about UX design and evaluation methods. Today, I will discuss the use of collages for assessing emotional aspects of products and services and generating ideas and requirements.

Method 21 of 100: Collages
A collage study asks users to find pictures, words, and tangible objects from magazines, clip art, newspapers, the Internet, and physical artifacts that represent their feelings, emotions, and personal experiences with a particular product, service, setting, person, organization, or environment. The user is then asked to organize the clips into a physical or online collage. Tools for creating an online collage can be as simple as Microsoft® PowerPoint® or digital scrapbook software like MemoryMixer, My Memories Suite, and Digital Scrapbook Artist.

After creating the collage, the user, audience (in participatory design), and facilitator engage in a discussion about the meaning of the collage. Here are some examples of the use of collages in UX design:

• Asking people to construct a collage that illustrates their identity and aspirations:
• http://experientia.com/perspectives/creating-togetherbuilding-value-with-participatory-design/
• Making emotional connections:
• http://www.boxesandarrows.com/view/making_emotional_connections_through_participatory_design
• Using collages to share insights:
  http://studiolab.io.tudelft.nl/manila/gems/sleeswijkvisser/participatorycommunication.pdf

 While collages are generally focused on emotional aspects of product design, they can also be used to support early concept design or requirements gathering. For example, you might ask colleagues to create collages of different ways to use ratings in Web and mobile products and then to highlight the top three ideas. Collages can also be used to support future workshops where you might want to create an artifact showing how participants might expect their work to be different in ten years.

Part of the theory behind the collage method is that it draws out emotional and cognitive issues that direct interviews, observations, or surveys do not easily tap. Collages are probably best suited for research into products, services, or systems with which the participant has some direct experience or interest.  

Collage creation supports creativity, can be done by almost anyone, and requires little in the way of supplies or facilitation. Collages can be done by individuals or groups. Some UX practitioners use collages as a focus group activity.

One of the factors in the creation of collages is the degree to which the images are constrained. In some studies people have been given a set of pictures and/or words; in other studies, people had stacks of magazines or large online collections from which to draw their own images. McKay, Cunningham, and Thomson (2006) note that here is a trade-off between the number of images and the time required to create collages - a practical trade-off if you have limited time for creating collages.

Collages can be analyzed for themes. Themes might include things like:

• Privacy
• Security
• Usability
• Aesthetics
• Locations
• Relationships
• Barriers and support mechanisms
• Feelings about the target object or service

You can count the number of themes and also capture the collage makers’ comments and detailed issues, requirements, and problems.

When to Use:
You can use collage studies to:

• Understand emotional issues with concepts. For example, you might ask people to create a collage that expresses what is satisfying and dissatisfying about their work in general.
• Understand organizational culture. You might ask people to create a collage that describes aspects of their work culture and see images like barriers and army tanks or small images of smiling people in a conference room.
• Support participatory design (co-creation) workshops.
• Tie features and product attributes to user/customer values.

References:

Hanington, B., & Martin, B. (2012). Universal Methods of Design: 100 Ways to Research Complex Problems, Develop Innovative Ideas, and Design Effective Solutions. Creative Publishing International.

McKay, D., Cunningham, S. J., & Thomson, K. (2006). Exploring the user experience through collage. In Proceedings of the 7th ACM SIGCHI New Zealand chapter's international conference on Computer-human interaction: design centered HCI (CHINZ '06). ACM, New York, NY, USA, 109-115.

Sanders, Elizabeth B.N., & William, C. T. (2001). “Harnessing People’s Creativity: Ideation and Expression through Visual Communication” Focus Groups: Supporting Effective Product Development. London: Taylor and Francis.

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?

Learnability Heuristics

by Len Whitehead

For nearly all software products, there is some level of learning that must occur to achieve a successful user experience. This learning typically occurs by two primary mechanisms within the product. The first is through the inherent learnability built into the product design. The second is through the content quality and information design. These concepts of usability and learnability are intrinsically related, and must work in concert to ensure a positive user experience.

To provide a standard way to assess product learnability, the Simulation UX / LX Team has developed a set of Learnability Heuristics in the same mold as Nielsen’s Usability Heuristics (http://www.useit.com/papers/heuristic/heuristic_list.html):

1. Good content practices: Content should adhere to good writing and video practices. Bad grammar and spelling, passive voice, use of the past- or future- tense, and hopelessly long sentences seriously degrade the learning experience. 
2. Searchability: Users should be able to find the information they need. 
3. Build-in learnability: The UI design should promote targeted understanding through the association of the discrete steps needed to perform a specific task.  The user should not have to be a product expert to be able to accomplish most goals, but rather be able to leverage a discrete body of knowledge. 
4. Process discoverability: The product design and the learning content should work together to guide the user through complicated processes that involve multiple tasks.  
5. Rapid recollection: The design should promote retention and easy relearning after a break from the product. It should facilitate recognition and rapid re-association with previously learned tasks. 
6. Good information design: Logically group related topics together. Within topics, organize content according to the inverted pyramid model. Start with the main point in the topic, and provide supporting content in order of decreasing importance through the topic. Remember that most readers tend to move on to the next topic if they do not find what they are looking for very quickly. 
7. Action oriented: Content should emphasize both real tasks and what defines successful completion. Instead of focusing on individual user interface elements (the “atomic” level of the product), focus holistically on the product, and communicate actual tasks that the user will perform. Round out the description by describing (or showing) what a successful implementation of the task should look like. 
8. Delivery method: The framework and output format should convey the content effectively and not interfere with the user experience. A clumsy delivery method can greatly impair the effectiveness of even the best content. An obvious example is a 600 page printed book verses a topic-based help system with search capability delivered electronically on multiple platforms. 
9. Motivation: The user should understand the context of the UI element and how the associated learning content helps them reach their goals. The content should effectively convey the exigency (the "why") and the goal (purpose). 
10. Error avoidance and recovery: The content and the design should help the user to avoid known common issues. Because some problems are inevitable, the content should also describe how to resolve known potential pitfalls.
11. User-centric: The content should relate to the user's world and communicate in the user's vocabulary. Product jargon is unavoidable, so at least relate the product vocabulary to the user’s world. If a “gizmo” in the user’s world is called a “widget” in the product, make this connection very clear.

To help achieve the standards described by these heuristics, we developed a series of usability and learning content development guidelines:  

Design for Learnability

1. Use clear and descriptive UI titles
2. Design logical, self-evident workflows
3. Help the user avoid mistakes
4. Provide easily identifiable starting points
5. Create a clear path to Help 
   

Search and Accessibility

1. Use consistent terminology in UI and Help
2. Include synonymous terminology
3. Include links to related content
4. Create a well-designed TOC

Information and Content Design

1. Describe the process
2. Include a range of application types
3. Describe success
4. Lead with primary point

Communication with the User

1. Use "real world" language
2. State objectives
3. Describe error correction

Good Content Practices

1. Apply minimalist written content principles
2. Use video best-practices

It is important to consider learnability as part of the user experience from the earliest design stages. Even the most simplistic “apps”, despite their lack of help, contain built-in learnability. For more complicated products, this inherent learnability is still vital, but must be coupled with dedicated learning content to ensure a delightful user experience. These heuristics provide a means for assessing software product learnability.

 

 

Follow-up from "Agile UX Method Adaptation" half-day course at CHI 2012

by Desirée Sy and John Schrag

We would like to thank the attendees of the half-day course at the CHI 2012 conference, “Agile UX Method Adaptation,” for their energy, attention, and thoughtful questions.

As mentioned during the course, here are a collected set of references mentioned during the course, beginning with the refreshed series of slides:

• Slides from "Agile UX Method Adaptation"
  Desirée Sy and John Schrag, UPA 2011.
• “Adapting Usability Investigations for Agile User-Centered Design”
  Desirée Sy, JUS, May 2007. http://tiny.cc/agileUCD (or Sy_agile-ucd.pdf)
• “Case Study of Customer Input For a Successful Product”
  Lynn Miller. Agile 2005. 
• Agile manifesto
  http://agilemanifesto.org/
• Mike Cohn's site, http://www.mountaingoatsoftware.com/, has a lot of helpful information if you want to learn more about the Scrum flavour of Agile Development.
• “Interaction Designers and Agile Development: A Partnership”
  Lynn Miller. UPA 2006.  
• “Using Formative Usability Testing as a Fast UI Design Tool”
  John Schrag. UPA 2006
• “Using the RITE method to improve products; a definition and a case study”
  Michael C. Medlock, Dennis Wixon, Mark Terrano, Ramon L. Romero, Bill Fulton.
• “Formative usability investigations for  open-ended tasks”
  Desirée Sy. UPA 2006
• “Usability Testing with User Proxies: When is ‘Close’ Close Enough?”
  Desirée Sy. DUX blog.
• Recurring user studies
  “It's Not Rocket Surgery - First Fridays in the U.S. Government”
  Nicole Burton, Steve Krug et al. UPA 2010
• "Distributed Scrum Primer"
  Pete Deemer et al.
• "Taking Aim: The Power of User Experience Goals"
  John Schrag, UX magazine, Volume 7, Issue 1, 2008