Problem: Adobe PDF Writer asks its users for help but makes helping very difficult

Solution:  

What's misdesigned?

PDF Writer is Adobes program to create PDF Documents. When the program encounters a problem it asks its user to help the Adobe PDF development team in troubleshooting. However, it seems that Adobe assumes their users to be particularly patient as they make this process extremely difficult and time-consuming.

Figure 1. Adobe PDF Writer attempting to collect feedback for troubleshooting

It would be as if

It would be as if the waiter asked you for feedback after eating at a restaurant. When you agree to help him, he asks you not only to fill out an extensive questionnaire with unfamiliar and strange information, but also to go all the way to the post office and mail it to his boss, once completed.

How to fix this problem

There are many elegant ways to request help from users. In the example below, the program has done all the information gathering for the user: If you want to help the program developers, simply push a button. At the same time, this interaction design leaves the user in control as he/she is given the option not to help. Also, privacy-concerned users may inspect the information before it is sent.

Figure 2: Windows XP attempting to collect feedback for troubleshooting

Research themes surrounding this misdesign

Get Notified!

Get notified when new misDesigns are added!

Your Email

The research themes surrounding this misdesign is broadly speaking that of Interaction Design (see the encyclopedia entry). More specifically, this misDesign touches on the means by which designers of software communicate (results in bibliography...) with users and what the designer-user relationship is about. Designer-user communication (or the lack of it) is often talked about as the Gulfs of Evaluation and Execution (see encyclopedia entry). The interaction designers at Adobe could have used an Interaction Design Pattern (see the encyclopedia entry) to help them avoid annoying their users. Moreover, Semiotics (results in bibliography...) is the study of communication where the acts of communication are not limited to verbal and written communication but includes signs, gestures, etc., which is why semiotics has a long tradition of being used for design of communication between user and the computer/software. Other, more specific, themes include status (results in bibliography...) and feedback (results in bibliography...), i.e. how the software communicates its status (e.g. an error state) and feedback information. Status and feedback is used to maintain rapport, which is one of the most important aspects of interaction design: It is commonality of perspective, i.e. being in "sync", being on the same wavelength. Other than the above, obvious research themes are privacy (results in bibliography...) and error handling (results in bibliography...)

What do YOU think?

Give us your opinion! Do you have any comments/additions
that you would like other visitors to see?

Petr says: Apr 24th, 2009

#1

Good point.

Programmers should know that there are tools for collecting and sending crash dumps from users. Windows has a DbgHelp library and other systems have too, see Wikipedia.

Ux Critic says: Aug 9th, 2009

#2

"If you want my help with your software bugs, how about helping me work around them?"



What's lacking here is reciprocation. The first example provides something the second does not: At least one recommended action that might remedy the problem. Even better if they had explained possible causes (e.g. link to troubleshooting webpage) and given cause-specific suggestions (if-then).



Instead of offering help, the second example merely assigns me a QA task... a quick and easy one, but with no direct benefit. On submit, my immediate (and possibly urgent) concern goes into some bug-thrashing black hole in a vast, faceless office building in an undisclosed offshore location, and I'm left with another task. Go find someone, anyone who's dealt with this before, and get their advice... or pay an IT consultant $75 an hour to muddle through it with me.



So our helpful, responsible user, who, after being interrupted by a software failure, actually took the time to describe in detail what just happened, won't even get a follow-up email. Ever. Not from tech support, not from customer service, not from the feedback management team. That is a lousy user experience.



It would be as if... a car manufacturer got a message you had broken down on the side of the road, called your cell to ask what happened (so they could improve their cars), and then as soon as you finished telling your story, hung up on you without saying another word.

 

You say: Mar 21st, 2010

#3

Your text will appear here ! 

  will be spam-protected
 

  Basic HTML tags allowed, e.g. links, <b>,<i>, etc. Line breaks will become <br>'s

 
How many?

=

e.g. "6"

+ Add note  (without logging in)