Getting Buy-in

As our culture becomes more tech savvy, users need less assistance than they once did.  Back in the day, you had to assume that some of your user base were using computers for the first time.  You had to not only educate them at the task at hand, but you also had to teach them basic things like the differences between a right and left mouse button when using a PC or how to drag and drop.

Today's mind-set tends to rely on that fact that users are now more exploratory.  The users are more apt to try things out rather than stopping and running to a manual or help system to tell them how to proceed.  This is a positive shift for user experience designers and information developers as they can focus on a smaller set of possible informational needs when providing in-app assistance or documentation.

So that sounds logical in this age when information can be found with a few keystrokes.  But are users still going to expect to have access to some document which describes in detail all the components of the interface, which selections are the default, or the character limits of a given text field?  They might be curious about these things, but the interface should do the heavy lifting when it comes to providing guidance and feedback in real time to the users.  For example, if a text field only allows 40 characters, there should be a message presented to the user if they go over that limit.  That is how the user is educated about the limitation.  Burying that information on page 203 of a document is hardly meeting the user's real time needs, and the chances that they would go to the document for that information are pretty slim.  Relying on the interface to the do the heavy lifting means that time and attention *has* to be paid to the user experience.  The days of  designing applications without considering the user experience are over.

What do you do if you have decision makers who still think that users have to have volumes of documentation to describe every detail of a screen and its components?  Gather and provide the decision makers with actual user feedback which details user's expectations.  This kind of data should give you the leverage and buy-in to make the right decisions for your customers.

To Read or Not to Read

Mobile application development is really forcing technical communicators to think outside the box when it comes to user assistance.  Relying on on-line help or linking to PDF documents isn't really the best choice in the limited screen real estate paradigm of mobile applications.  So what do you do when you don't have the space to be verbose?  You get efficient with your words and find other ways to provide information.


When coming up with alternatives, you have to think about the maintenance of the content and where users will be when they need it.  Will they need headphones?  Will they be in the car at a customer site?  Can/Should they be looking at the screen?


Creating a 5 minute video might sound like a great way to explain it all, but if anything changes in the application, that 5 minute video has to be edited or worse, re-recorded.  So, what about short 30 second bursts of information?  


If users travel to customer sites, will they be driving?  Would an audio explanation be the best way to give them the information they need at that moment?


Coming up with new ways to provide users with content they will use is both exciting and challenging.