Designing the User Experience at Autodesk

Powerpoint for Prototyping: Part 2 of 2

by Tom Vollaro

In the first part of this blog post I wrote about the advantages and disadvantages of using Microsoft PowerPoint as a prototyping tool. I also provided some low, medium and high fidelity examples. In the second part, I am going to delve into specifics of various techniques for creating these prototypes. Keep in mind, much of this could be done with other presentation tools (Apple Keynote, Open Office, and even Google Docs) but having worked on a Windows-only desktop application for five years, PowerPoint was the most readily available.

Hot Spots

 

Guided Hot Spots

 

Animation

 

Animation with Motion Paths

 

Animation with Video

 

Sharing Your Prototype

With your new prototype freshly minted, you are now ready to share it. For traditional user testing, this is straightforward. As long as you are testing with a dedicated machine (either in a lab or with a laptop in the field) you can just put it in front o the participant and click F5. If you need to share your prototype with remote colleagues or place it online for un-moderated testing, you are in luck. PowerPoint provides a wide range of export and publish formats. Here is a short list of the most useful:

• PPSX: Useful for distributing a fully featured slideshow to someone without PowerPoint. A download of a free viewer is required
•  Save to Web: You can save to Microsoft's SkyDrive, which allows you to edit and view a presentation on the web
• Other web options include exporting to PDF and/or uploading to SlideShare or Google Docs, but these convert the slides to bitmaps, so animations, videos, and hotspots will be lost.

I am curious to hear about other tools and techniques for creating quick and dirty clickable prototypes.

Inspiration from the past at CHI 2011

by Ananth Uggirala

Inspiration from the past at CHI 2011

Last month, I attended the annual Computer Human Interaction (CHI) conference with a few of my colleagues in beautiful Vancouver. This conference was held at the Vancouver Convention Center, with picturesque views of the bay and mountains.

View from Vancouver Convention Center

In the last decade, CHI has become a place to showcase the latest innovations in interaction, like PaperPhone or MagicDesk. Researchers share new findings about how to design survey questionnaires, or how to conduct field studies in several countries simultaneously.  In addition to the ‘cool’ stuff, there are also a few talks that truly inspire and make you feel important as a UX professional. One such talk I was lucky enough to attend this year was, “What’s It Like to Design a User Interface for Six Billion People?”  by Larry Tesler, who was awarded the Lifetime Practitioner Award at the conference.

Larry is known for his invention of many familiar interaction techniques in all graphical user interfaces. These include cut-copy-and-paste editing along with their keyboard shortcuts, inserting, and overwriting text without entering a mode, among other things.

  Larry Tesler talking at CHI Conference

Invention of Cut-Copy-Paste

Larry talked at length about his career in the 60’s & 70’s at Stanford and PARC; how he hated modes and constantly thought of changing that prevalent interaction in computers. He and his partners developed various new interactions, which eventually resulted in the design of cut-copy-paste interaction. It was fascinating to hear how something considered so obvious today (cut-copy-paste) had taken several years to be conceived and accepted in the software industry.

Some of the objections Larry received to his cut & paste paradigms were:

1. Unfamiliar metaphor
2. User mistakes
3. Extensibility to other applications

As I took notes on this, I realized how we encounter similar objections to any new design which replaces an accepted interaction paradigm.  I also learned that great design needs perseverance, years of iterations & testing, and a vision for the future.

As he concluded the talk, Larry had the following advice to CHI practitioners. These are powerful takeaways!  I have them hanging on my desk as reminders, and have deciphered each of his points into actionable lessons for UX professionals:

Larry’s Takeaways:

• Unless you want a career in operations, build easy-to-use, bug free software.

Lesson: We all know that shipping products with bugs and hard-to-use designs will create a bad user experience for end-users. But, it also creates an unpleasant experience for company employees. Instead of working on innovative new projects, employees will be spending time debugging and fixing usability issues in the released product.

• Don’t be compatible with a bad UX.

Lesson:  As a UX professional, it is important to focus on end-to-end user experience for your products. This will involve crossing the boundaries of individual projects, understanding the ecosystem, and having the courage to not allow a bad UX in the ecosystem.

• Never confuse busy with productive.

Lesson:  In this fast paced, at-the-moment, connected life, it is easy to get busy. Set goals to achieve by the end of the morning or afternoon or week.  Tune out your email, social networks and phone. 

• You don’t have all answers. Team up.

Lesson:  Different skill sets are required to build great products. It is important to share your ideas and thoughts with team members, collaborate to achieve great results.

• If everyone else thinks something is impossible, it’s a great topic for research.

Lesson: Most often, UX professionals fall into the trap of doing research on the obvious. Research is meant to understand the unknown and uncover latent needs on projects.

• To fight an uphill battle, choose a short hill.

Lesson: Don’t give up if the problem is too challenging. There is always a small chunk of a big project you can achieve.  Start with the small chunk and reassess after completion.

 

---

References:

1 Lahey, B., Girouard, A., Burleson, W., and Vertegaal, R. PaperPhone : Understanding the Use of Bend Gestures in Mobile Devices with Flexible Electronic Paper Displays ?” in Proceedings of the Conference in Human Factors in Computing Systems (CHI 2011)

2 Xiaojun Bi, Tovi Grossman, Justin Matejka & George Fitzmaurice. Magic Desk: Bringing Multi-Touch Surfaces into Desktop Work. in Proceedings of the Conference in Human Factors in Computing Systems (CHI 2011)

3 Sauro, J. & Lewis J.R. When Designing Usability Questionnaires, Does It Hurt to Be Positive?" in Proceedings of the Conference in Human Factors in Computing Systems (CHI 2011)

4 “From Basecamp to Summit: Scaling Field Research Across 9 Locations”, Jens Riegelsberger, Audrey Yang, Konstantin Samoylov, Elizabeth Nunge, Molly Stevens, Patrick Larvie, in Proceedings of the Conference in Human Factors in Computing Systems (CHI 2011)

The Forgotten User

by John Schrag

 

I’ve really enjoyed hearing all the new ideas being tossed around here at the Usability Professional's Association Conference in Atlanta, Georgia. My colleague Desirée Sy and I had presented a tutorial on the topic of making your UX practice Agile, so I was on the lookout for more Agile/UX materials. With this in mind, I went to see a poster presentation by Jon Innes of UX Innovations and fellow Autodesker James McElroy , called “The UXI Matrix”.

Jon and James presented a method of charting and making visible the state of an Agile project in terms of its usability, to help a team monitor and control its UX work. The chart had many features, but I was particularly interested to see how they charted the stories in the backlog against all the different user personas. A series of checkboxes showed which features were related to which personas. The chart also showed a tally of how many actual human beings representing each persona type had been talked to by the team. This mapping had some interesting effects; it suggested when personas might need to be merged (when they share all the same stories), and warned when potential error loomed (when a given persona was under represented in actual human contact). And it showed when the needs of some personas were being ignored by the project --- none of their stories were getting done.

This ‘forgotten user’ idea struck home later that day when I was using the hotel bathroom on the conference floor, and found a smartphone that some poor fellow had left behind. There was no one else in the bathroom, so I poked around on the phone to see if there was some way to determine who owned it, and to get a message back to him. I had no luck; the phone was very securely locked up, protecting the owner's private data – but also preventing the phone from being returned.

I realized that I was a forgotten persona --- the "honest guy who finds a lost phone". I represented a rare but critical persona, with a single workflow. The phone designers had focused instead on thwarting another valid persona: the phone/identity thief. I imagined a feature on the phone that would allow me leave a voice mail for the owner (that would be emailed to him, or that he could pick up from his phone service provider) so I could let him know that I was leaving his phone with the hotel concierge. 

Some smartphones (such as the iPhone) have a feature to help the owner track it down, and even to display a message to whoever might have found it. But these features are designed for the phone owner, not the honest finder.

So ask yourself: in your designs, do you consider the people who interact rarely but critically with your designs? It's something to think about.

No, I did not ‘pause’ my workout!

by Veronica-Meuris

I’m here at the Hyatt Regency hotel in Atlanta, Georgia this week for the Usability Professionals’ Association (UPA) conference. I woke up Tuesday morning bright and early, geared up for a great day of tutorials and discussions. Before that though, being a creature of habit, I headed to the fitness centre for my morning workout.

At home, my workouts alternate between running and elliptical training so here in Atlanta, I thought I’d switch it up a bit – I tried the recumbent bike. They have a reclined position whereby your legs are out in front of you, and have nice large padded seats and back support.

The bike itself was very comfortable but the touch display design was an entirely different matter. At intervals while biking, I pushed the ‘increase intensity’ arrow to make it harder to pedal. Every time, and I mean – every time I did this, I unintentionally paused my workout. After the 6^th time, I left the intensity button alone and just pedaled faster to get my heart rate up…

The ‘increase intensity’ arrow is nestled between the ‘decrease intensity’ arrow and the ‘Pause’ button. The problem seems to be the size of the ‘Pause’ hit zone. It’s enormous and extends considerably into the ‘increase intensity’ zone.

 

What’s maddening about this design and or its implementation however is that yes, it’s hard to be exact when you’re tired and wanting to decrease intensity or to pause your workout. So – increase the hit zones that address this use case then. Alternatively, swap the order of the intensity arrows so that the ‘Pause’ and ‘decrease intensity’ buttons share their enormous hit zones that when pressed (intentionally or accidentally), give riders a chance to slow down and catch their breath.

Riders though who are still raring to go and want to keep increasing the intensity are probably better able to access a hit zone the size of their finger. After all, they’re presumably feeling good and have the ability to be more precise in what they’re pressing – if they weren’t in full control, they wouldn’t be increasing the intensity!

Now, I know it is bad form to spy on people working out beside you but I couldn’t help myself – after my 6^th false start, I was frustrated. I watched the man beside me encounter the same problem – he too had to tell the bike that, ‘yes, he wanted to resume his workout’ after unintentionally pausing it 9 times over the course of 30 minutes. He appeared equally frustrated and left shortly thereafter.

Tomorrow, it’s the treadmill for me, no doubt about it.

A Technology Galapagos at CHI 2011

by Erin Bradner

I was at a conference last month and found myself in a room teaming with people engrossed in technology. Two people were using smart phones, others were tapping on PDAs, and one was using a word processor. None of this is blogworthy until I tell you that the transfixing technologies in the room were all digital antiques curated in a makeshift gadget gallery. On display was the world's first portable word processor from 1978 with only six keys on its keyboard. Another curious artifact was an early touchscreen PDA featuring buttons designed to be played like a trumpet. But what drew me in was the world’s first touchscreen smart phone, a dinosaur that predated the Apple iPhone by 14 years. That phone, designed by IBM, is the origin of several user interface patents in the iPhone today. 

Image from the Buxton Collection Sampler. Image Source CHI 2011

This anachronistic smattering of digital curios was part of a private collection shipped to the Human-Computer Interaction Conference (CHI 2011) in Vancouver, B.C. The owner and curator of the collection was the inexhaustible gadget hound, Bill Buxton. Throughout the conference Buxton gave non-stop, guided tours of his collection for anyone who walked by. Think Darwin in the Galapagos. Meandering through the collection he would point out the design quirks, elegance and ingenuity of each device. I noticed that he rarely got two gadgets into a thought without referring to a larger innovation taxonomy that seemed self-evident to him. While walking and talking, he would grab two dissimilar devices from opposite ends of the room, hold them next to each other and explain that they were in the same family; one was simply the miniaturization of the other. Next he would scoop up a specimen and explain how it was the cross-fertilization of species from the PDA genus, the tablet genus and a trumpet.

Over time, as Buxton spoke, I noticed that his rapid-fire audit of the distinguishing traits of each gadget included complimentary terms like wonderful, inventive, and inspired. Yet never, while I was there, did I hear the words big idea, giant or genius. Then, standing somewhere between a Reverse Polish Notation calculator and a foot-operated mouse, he blurted out a Darwinian truth. I can’t quote, so this is the gist:

That’s how we do it. As designers, we slice up a given design space along the various dimensions of size, speed, permutation, etc… we amplify and attenuate, expand and contract until we find something interesting and suspiciously doable.

 Something clicked for me then. Perhaps the collection of digital doodads catalogued before me wasn’t as it appeared to be. It was not a systematic progression of gadgetry punctuated by paradigm-shifting sparks of the Genius Inventor. It was a mashup of form factor, features and user interface. It was the work of legions of tireless designers actively seeking under-populated niches in a design space and growing ideas there – then cross-fertilizing and mutating and growing more and more ideas.

Economic or ergonomic, it also struck me that some form of natural selection had to be in play.

Freshly liberated from the cult of the Genius Inventor, I went downstairs to lunch. As luck would have it I found myself sitting across the table from Jim Lewis, the Human Factors Engineer from IBM who designed the user interface for a phone I held in my hand only minutes before in the gadget Galapagos upstairs. I felt compelled to confront Jim immediately with a pressing question: “If you’re not a genius, if you’re not a giant, if the UI for the world’s first smart phone didn’t spring fully formed as a big idea, then how did you design it?” I let him finish his lunch and then I asked. I’ll recount that conversation in my next DUX post.

 

 

Powerpoint for Prototyping: Part 1 of 2

by Tom Vollaro

PowerPoint is like being trapped in the style of early Egyptian flatland cartoons rather than using the more effective tools of Renaissance visual representation.

— Edward R. Tufte (Beautiful Evidence)

Boy does PowerPoint get a bad rap. I guess it is somewhat warranted. But the blame falls squarely on the authors. Like any tool, PowerPoint itself is neutral – it can be used for good or evil. This post will hopefully lean towards the former. In our interaction design work on Autodesk’s building information modeling (BIM) tools, we have found PowerPoint to be a powerful, low-cost prototyping tool.

Advantages

• Immediately available on almost every designers desktop.
• Easy to learn. If you know other MS Office apps, and even if not, PowerPoint has a fairly low learning curve.
• By its very nature, it is perfectly suited for storyboarding.
• For viewers without PowerPoint, prototypes can be exported to a variety of read-only formats.
• Works well for Agile teams - it conveys just the right amount of information.

Disadvantages

• Lacks sophisticated branching logic, without the use of VB scripting or add-ins.
• Difficult to simulate complex interactions such as 3D models - but perfect for web pages, UI "chrome", help and dialogs.

Examples

All of our PowerPoint prototypes can be grouped into low, medium and high fidelity. Many times they evolve from low to high as our designs develop. Sometimes, they may go from low to medium and then, depending on resources, we will have a “real” prototype coded up by a developer.

Low fidelity

Like I mentioned before, PowerPoint is a great platform for storyboarding. By its very nature, individual visually oriented panels organized into a sequence, PowerPoint is perfect for storyboarding. The simplest low-fi prototype can be imported sketches that are organized into a sequence. Simply re-order the slides to start to refine and tell the story of your design. This is very useful for sharing a set of storyboards with remote colleagues who could not attend an in-person design review.

Project Vasari concept storyboard - part 1

A simple prototype consisting of scanned images in sequence.

Medium fidelity

Once we start moving past sketches and into “real” design, we start to add screenshots, annotations, and even user interface elements. The following example is a refined version of the sketch storyboard shown above. In this version, we have started to mix media between screenshots, scanned sketches, and images from another prototyping tool (in this case, Balsamiq.)

Project Vasari concept storyboard

A more refined version of the early prototype above. This one is mixed media.

This type of medium fidelity prototype has also served us well on the Agile/Scrum project I have been working on. Instead of long, drawn-out documentation, we just put together quick annotated prototypes like the one below to communicate a specific set of behaviors to the developers. We use the text tool to overlay UI elements. It is OK if it looks rough, I have enough trust with my developers to get it right. And if not, we are agile, so we can always make slight adjustments. Annotations help explain an intended behavior or interaction.

 

Project Vasari - 3D Images Storyboard

A short annotated prototype used to communicate a design for an agile project.

In part 2, I will show some higher fidelity examples and talk in more detail about how they were made and how they can be shared.

Method 14 of 100: “Yes, and …”

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

by Chauncey Wilson

This is the 14th in a series of 100 short articles about UX design and evaluation methods. Today’s method is “Yes, and …”. This is a technique borrowed from improvisational (improv) theater that can be used to generate ideas and requirements. The technique requires little training and can be used with small or larger groups.

Method 14 of 100: “Yes, and …”

In the world of improv theater, performers start with an idea or scene and then build on that by adding a bit of information. The process of adding new information is referred to as “Yes, and …” and this method allows performers to continually redefine the scene and make leaps into new dramatic (or comedic) territory.

The approach can be used in the UX domain as a way to explore possible user scenarios, generate requirements, brainstorm, or envision future concepts. To start the process, you provide an initial verbal scenario and then ask colleagues to say “Yes, and …” and then fill in some new information or add new requirements.

Here is a short hypothetical “Yes, and …” session undertaken by a group of design colleagues or foodies who are defining the concept of an electronic menu for a new restaurant:

• I am planning a new restaurant and want to use electronic menus that offer the diner all the information that a waiter or waitress could normally provide.
• (a colleagues says) “Yes, and the electronic menu must be water proof because kids might spill things on it…
• (another colleagues says) “Yes, and we need to provide pictures of our meals…
• Yes, and we need to a way to allow people to do substitutions…
• Yes, and we need to include a way for people to tell us about allergies...
• Yes, and the calorie count must be included – that’s the law now…
• Yes, and we need to know if this is a romantic dinner or that someone is going to propose…
• Yes, and when someone is going to propose, we can bring out our special cake and make sure this is something they remember. 
• ... and on and on and on with “Yes, and …”

When to Use:

This method can be used early in the product design and development process as a way to elicit requirements, explore concepts, or even help develop personas. This approach sometimes reveals gaps or missing requirements that might elude more structured approaches. It is also a fun and simple approach that can enliven a tired team.

 Procedure:

1. If you read the improv literature, you will find different approaches for the “Yes, and …” method, but the basic process is to assemble a group and provide a starting statement or scenario like the electronic menu example.
2. Describe the "Yes, and ..." method and provide a brief example.
3. Consider if there are props that you could use to trigger ideas, for example, in the electronic menu example, you might bring an iPad to the “Yes, and …” session.
4. Ask someone to write the ideas where they are visible to the group or tape the session so you capture all the details.
5. Have the leader of the group start the “Yes, and …” session with the introductory statement.
6. Encourage someone to say “Yes, and …” and add something new. If you need to, you can say “Yes, and …” to prompt the next reply.
7. Continue until the group slows down.
8. Thank everyone for their contributions and willingness to engage in the “Yes, and …” activity.

Strengths and Weaknesses:

+  The basic “Yes, and …” method as applied to UX does not require a lot of training (though if you are planning on doing improve for a living and will depend on humor, you will need a lot of practice to be perceived as spontaneous). As a side note, some training on improv and theater techniques could be quite useful for a UX group. There are many papers on the application of theatrical methods to product design.

-  I’ve seen this method get a bit out of control and you might need to intervene at some point and direct the group away from the ridiculous without seeming like a dictator. In improv theater, you would not generally engage in this type of blocking of the scene development, but in the product development world, sometimes you need to change a focus that has gone outside the bounds of usefulness or appropriateness.

References:

Danzico, L. (2010). From Davis to David: lessons from improvisation. interactions 17, 2 (March 2010), 20-23.

Gerber, E. (2009). Using improvisation to enhance the effectiveness of brainstorming. Proceedings of the 27th international conference on Human factors in computing systems (CHI '09), 97-104. 

Wikipedia. Improvisational theatre. Retrieved from http://en.wikipedia.org/wiki/Improvisational_theatre on June 1, 2011

 

---

What’s Next in the Series?

The next UX method posting will discuss misuse scenarios. These are scenarios that focus on threats, both intentional and unintentional, to a system.

 

 

Questionnaires & Answers at CHI 2011 in Vancouver

by Karen Mason

I attended CHI in Vancouver a few weeks back. Authors can submit papers on original research to CHI. If your paper is accepted, you have 20-minutes to present it at the conference within a session where other papers and notes are presented.

One of my favorites was, "When Designing Questionnaires, Does it Hurt to be Positive?" [pdf], a paper presented by Jeff Sauro (and co-authored by Jim Lewis). It received the CHI Honorable Mention award.

It asks the question: Are both positive and negative items necessary in questionnaires?  Great question. I’ve often thought that you needed to mix it up to get an unbiased, more balanced result. My intuition was that results will be biased towards the positive side if we don’t give subjects the option to respond with a lower rating.

“By providing a mix of both positive and negative items…, we are not predisposing our users to give us a positive response. We reduce the possibilities of biases: Acquiescent and Extreme response.”

• Acquiescent bias: Users have a tendency to just agree to whatever statements we have.
• Extreme response bias: User haphazardly circles the most favorable response for all.

  

Sauro & Lewis did a study where users were randomly given either version of these questionnaires:

• Standard System Usability Scale (SUS), which uses alternating positive and negative questions
• All Positive System Usability Scale, which uses all positive questions

It turns out you get virtually the same results, but when using the alternating positive and negative questions, your results are more prone to error. The 3 M’s:

• Misinterpretation: users interpret the question incorrectly
• Mistakes: user understand the question, but accidentally agree to the negative items when they meant to disagree
• Miscodes: researchers forget to alternate the items back

It is interesting to note that 18% of subjects who completed the Normal SUS responded favorably to both positive and negative questions.

Recommendations:

• It’s OK to keep using Standard SUS for existing questionnaires, just be sure to check for errors.
• For new questionnaires, the recommendation is to use all positive questions. The negatives (3 M’s) outweigh the positives in alternating positive and negative items in usability questionnaires.

Audience question:

• Q. Did anyone try grouping positive and negative questions separately, vs. alternating positive and negative?
• A. Jeff answered that a user might still forget to switch mindset when the questions switched to negative. And more importantly, it doesn’t matter, so just use all positive.

Jeff has also posted a video of their presentation on YouTube.