Designing the User Experience at Autodesk

Changing Cultures: Towards a Lean User Experience

By Joshua Ledwell

Autodesk development teams that once requested design specifications up front now are collaborating with user experience designers to design, build, and test software in rapid cycles. This incremental approach offers more opportunities to gather user feedback and optimize the product. Success depends on practicing “Lean” UX, in which designers stop attempting comprehensive documentation, and embrace “just-enough” design combined with constant iteration.

The idea of working lean comes from “Lean Manufacturing” at Toyota and more recently The Lean Startup by Eric Ries. Lean companies minimize wasteful business processes that don’t add value for end user. They also get products to customers faster, even with fewer features, so they can learn from their target audience and build the most value into the next version.  

I am a passionate believer in Lean UX, so I was pleased to attend the Lean Day UX conference in New York on March 1. In the morning, seven speakers from different industries described how they navigated the switch to Lean practices.

Key insights from these speakers:

• Ries’ The Lean Startup treats product development as a series of quick, experimental launches. However, transitioning an organization to this lean workflow requires a cultural shift from “experimenting to validate” to “experimenting to learn.” As a UX professional, you may be accustomed to usability testing a complete product. Now, though, you may need new methods to help the product team quickly adapt to user feedback.
• Changing mindsets is critical for Lean UX success, but it’s not easy. Simple rules can help change your organization’s behavior. One speaker’s group outlawed surveys and mandated that all teams meet face-to-face with real users.
• At another speaker’s business, the priority is building lean entrepreneurial teams that take risks and learn from them. To help achieve this goal, managers at this company must present failures and suboptimal outcomes to the entire organization.
• Designing for delight requires building user empathy on your team. One recipe for success is generating many ideas and iterating solutions, moving from broad to narrow focus as you learn more about user needs. “Delighter” features create promoters for your product and brand.
• To paraphrase Bill Scott of PayPal, Agile is a good “engine” for delivering products, but it has no brain. Lean UX leadership can be the brain that ensures the team builds the right product. (see image below.)

After lunch we participated in a rapid prototyping exercise. My team designed an app for public transportation users to refill their passcards anywhere. We focused our design time deciding exactly what user problem to solve and how little we could build to solve it – also known as Minimum Viable Product (MVP). I was impressed by the POP app for iOS for rapid mobile prototyping. With this app you can photograph your paper prototypes, select hotspots for navigation, and link them into a flow.

Here are links to the presenters’ topics. Some of the presentations are online, and links are provided:

Lionel Mohri, Intuit: Getting Dirty With Design Thinking - How Intuit Is Enabling a Culture of Entrepreneurship and Experimentation

Farrah Bostic, The Difference Engine: Research Rebooted - Why Most Market Research Is Broken, And How Lean Can Help Fix It

David Panarelli, LivingSocial: Iterating Forward: Maintaining Alignment and Focus Across Multiple Lean Teams

Tom Illmensee, Snagajob: Build A Recipe For Better UX Process With Fresh Lean Ingredients

Andrew Crow, GE Healthcare: One To Many: Designing For Scale

Emily Holmes, Hobsons: Iterative Innovation – Small Guerilla Projects Can Lead To Big Successes

Bill Scott, PayPal: Lean Engineering: Key Principles For Transforming Engineering Into A Full Lean UX Partner

On the train back to Boston, I reflected on the speakers’ ability to promote user-centered change in their organizations. When UX professionals are willing to abandon potentially wasteful up-front design practices and embrace lean workflows, they are leading by example and increasing their influence on the whole organization. I like that being a change agent and a user-centered designer are mutually reinforcing aims.

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

 

Responsive Web Design

By Joshua Ledwell

Not long ago, designers optimized their websites for a single page width, and worried about supporting only two or three PC web browsers. How should web designers respond to today's world where mobile web devices are proliferating in dozens of different resolutions? In the fourth book from the A Book Apart collection, Ethan Marcotte outlines the Responsive Web Design approach that allows a website to embrace users' needs on any size display, all with the same underlying HTML.

Responsive web design involves implementing three components in a site's CSS files. Flexible grid layouts use percentage widths to maintain a page's proportions over small changes in resolution (like all the slightly different mobile screens out there). Next, fluid images scale to the containing layout. Finally, media queries rearrange page layouts on a macro level for classes of Internet devices such as phones, tablets, and PCs.

Together these techniques can make the web accessible and usable on almost any Internet device available. Examples of websites that have gone responsive include ThinkVitamin and the Boston Globe. However, the approach is not for everyone. Advertising-supported websites, for example, often are contractually prohibited from resizing or moving ad placements.

What sets this short book apart from a CSS manual is the author's empathy for traditional web designers grappling with the mobile web's ascendancy. Marcotte shows why mobile content should be different, and how to delight mobile users without coding an app or a separate mobile site. If you're a web designer or developer this book will have you thinking "mobile first!" on your next project.

 

Resources:

Book website: http://www.abookapart.com/products/responsive-web-design

Summary article: http://www.alistapart.com/articles/responsive-web-design/

Sample responsive website (pictured): http://responsivewebdesign.com/robot/

Transforming Qualitative Data into Actionable Information

by Joshua Ledwell

­­Interviews and open-text survey questions are two common user research methods that often result in large amounts of qualitative data. Some UX practitioners don't know where to start analyzing all the notes and open-text answers their research generates. Others may accurately analyze the data, but the results may take too long to generate or they may result in no business value for their stakeholders. 

To speed up the analysis process, consider coding your survey responses, interview notes and transcripts. A coding scheme establishes a framework for analysis by organizing the information into categories most useful for the researchers. After exhaustively reviewing a set of interview notes about our engineering software, we induced this list of nine workflow-oriented codes. We successfully used the same coding scheme on later survey results and interviews.

Code	Description	Useful to
Followup	A customer question or issue that requires an answer.	Mark specific issues for a customer service response.
Key quote	The customer's words.	Use a quote to emphasize a point to stakeholders.
Other tool	Participant uses another product to get the job done.	Learn how others products fit into a customer’s overall workflow.
Pain point	Something the participant doesn't like about the software.	Examine these issues to find improvement ideas.
Positive	Something the participant likes.	These help balance a report that might otherwise contain all negatives.
Process	How customers use the software.	Validate assumptions about how your users work.
User	Information specific to a firm or participant.	Effectively, this category is a catch-all for data that’s interesting but probably not actionable.
Wishlist	Customer feature requests.	Don’t turn these directly into requirements. Analyze wishlist requests to ensure you understand the root customer need.
Workaround	To get the job done, participant is using the software in unintended fashion.	These point to missing, difficult to discover, or inadequate features.

Coding of qualitative data may take place in the moment, as a facilitator takes notes during an interview. The coding may also take place retrospectively when analyzing survey responses or transcripts. Either way, the strength of this simple coding scheme is speed. The facilitator can use written shorthand symbols or macro keyboard shortcuts to quickly mark each sentence or statement. A method we found successful was to break up passages of text into bullet points or paragraphs, then paste the text into Microsoft Excel. Each item becomes a single row that can be tagged in another column with one of the codes, then sorted and manipulated at will.

Sometimes a single customer statement may apply to two or more codes. In these cases it’s often best to break the statement into its coded pieces. For example, a customer may say “We use the color-coding filter to mark which user owns each part, but it really slows down the software.” In this case you have both a Process note and a Pain point to consider.

This coding framework is simple enough that a whole team can collaborate on the analysis. By distributing pieces of a large survey or several interview transcripts across team members, a large amount of data can be processed in a shorter period of time. However, note-taking shorthand, word choice and handwriting may be difficult for a separate coder to understand, so it is usually best to have the original facilitator code their own notes, or at least ensure they are available to clear up any potential ambiguity.

Fictional example of coded interview notes:

Code	Note
Other tool	Enterprise Customer A uses our widget along with paper documents.
User	They are currently using our older product and weighing the purchase of our new product.
Key quote	"Widgets are more useful than paper, but why are they slower to use?"
Pain point	Their widgets take too long to boot up in the morning.
Followup	How can they set up their widgets to start up faster?
Process	For their planned upgrade, they'll need to roll out the new widgets one office at a time. Some offices will have the old widgets for a long time.
Wishlist	Need to be able to take control of the widgets in an entire office over the network.
Workaround	They implemented user interface based on old paper forms, but on the widget they just skip the fields that they don't need.
Positive	They like the idea of the mobile widget project.

Once your qualitative data is coded, some of it may be actionable immediately, especially “Followups” and “Pain points”. Other feedback, such as “Wishlist” and “Workaround” items, may lead to valuable discussion and creative ideas about how to enhance the software. The remaining items may go into a report for stakeholders, or be used in a holistic affinity diagramming exercise.

A final note: Our team has found the coding scheme above useful, but practitioners should consider what framework will best meet the goals of their customer research. If your goal is to create user personas, for example, your coding should relate to the components of your personas. Now, code away and enjoy transforming all of that text into actionable next steps for your organization!

References

Patton, M. Q. (2002). Qualitative Research and Evaluation Methods (3rd ed.). Thousand Oaks, CA: Sage.

Strauss, A. & Corbin, J. (1990). Basics of Qualitative Research. Thousand Oaks, CA: Sage.

Thomas, D. R. (2006). A general inductive approach for qualitative data analysis. American Journal of Evaluation 27 (2), 237-246