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.  

Not Waving But Drowning

Stevie Smith’s poem “Not Waving But Drowning” is a brilliant example of how perception completely changes a situation.  You see someone far out in the water waving; you wave back.  In reality, that someone is really trying to get your attention because they are drowning.  That is a colossal misunderstanding.

What could have helped eliminate the confusion in this situation?  Being close enough to hear the person would have helped you interpret the gesturing.  Addressing more than one of your senses is a good approach when trying to communicate. 

This same axiom can be applied to user interface design.  Sometimes the placement and presentation of a feature isn’t enough to convey how it is to be used.  Sometimes including some well-place text can help explain how to do something. 

What do you do if that is not enough?  What if the feature is really complex and users need more help?  You can assume that they will read the documentation, but that requires knowing where to find the doc and wading through documents to find what they need.  Unless finding that information is critical to the job at hand, people aren’t going to do that.

What other options do you have?  How about some field-level help?  An icon near the feature which serves as a link to more detail could address the use of that more complex feature.  That link could also take a user to a recorded simulation which demonstrates how to use the feature.

You always have options.  You just have to invest some time to make things clear for your users and keep them from misinterpreting your signals. 

www.siteblink.com

The Power of User Feedback

Even if you’ve been living under a rock, you’ve probably heard someone complaining about the recent changes to the Facebook interface.  Imagine what the outcry would be like if people actually paid to use Facebook?!?!

When you are developing or modifying the user interface of your application or site, you want to make sure that the majority of your users/customers will embrace the new design and effortlessly adapt to a new way of doing something.   

So, how do you please all the people all the time?  You don’t.  However, you can please some of the people.  To do that, you need to give up some control and show your users or potential users what you’ve done and where you are headed.  Sounds kind of scary, but it’s even scarier to waste time and resources going in one direction only to find that the people who ultimately pay the bills don’t even want to go there.

Most software companies have some sort of user acceptance testing phase in their plan.  This does add time to the development cycle, but spending the time is crucial if you want to win and retain customers.

www.siteblink.com

Everyone Lives a Minimum of Three Lives

Chuck Palahniuk opens his book Fugitives and Refugees: A Walk in Portland, Oregon, with this sentence:

"EVERYONE IN PORTLAND is living a minimum of three lives, says Katherine Dunn, the author of Geek Love."

I think, regardless of location, most people are many things to many contexts.  You may be a truck driver who is a writer who also likes to paint.  You may be a mother who is a gamer who also likes Renaissance fairs. 

This many lives concept inspired my Twitter profile – Artist, Writer, Adventurer.  This week, however, I feel like I’m more Technical Writer, Blog Reader, Software User.  Within the span of two days, the topic of error messages has crossed my radar while working with a team to improve error messages, while reading Seth Godin’s blog, and while getting an error message as a user.  In all three instances, it was apparent that no part of me liked the feedback that software was giving me. 

So what do I/we want from our error messages?  I want an explanation with a clue to the resolution.  Telling me that there is an error is fine, but what am I supposed to do with that information?  The error I was getting this week as a user was missing that clue to resolution.  The message read, “An error has occurred. Blahbity blah is checking for errors.”  Then the program restarted.  It was quite apparent that an error had occurred because the program froze and stopped working.  The error message served no purpose other than telling me what I already knew.  Annoying!

The focus of the developers writing the code isn’t to help the user resolve the issue.  They are concerned with ensuring that the application stops whatever process isn’t working and to alert the user that things have halted.  To Seth’s point in his blog, an error message should not be cryptic.  We’ve all seen errors which only contain numbers.  Those numbers must map to something somewhere, but are meaningful only in the development group.  So to get away from the cryptic, many developers have opted for the vague.  This is as helpful as “Error 641 has occurred.”

How do companies appease the three people living in my head?  Get someone outside of Development to review all the error messages in an application and don’t bother telling people things they already know unless you are going to help them resolve their problem.

www.siteblink.com

Making a Good First Impression

A website or application is like a restaurant kitchen that is visible to its diners.  If the kitchen and its staff aren’t clean and kept that way, it won’t matter how good the food is; people won’t eat there.

Nothing turns a site user off more than paragraphs of text, misspelled words, and poor grammar.  These are all signs that the people running the place don’t really care about you and your experience.  They are just trying to fulfill orders and collect money from customers.

While the consequences of not having time to clean equipment in a kitchen are obviously more dire than misspelled words and poor grammar on a website, the result is similar; your customers won’t trust you to do complex things if you can’t do the basic ones.

Here is a quick list to ensure that your site text is ready for guests:

• Spell check…spell check….spell check.  Did I mention spell check?
  This seems like a no brainer, but it is so simple that it’s often overlooked.
• Get rid of unnecessary words, like Please and Simply.
  Pretend that you are paying per word or tweeting. 
• Try to avoid words or phrases which reference location, like “in the fields below”, “on the form below”.  Explanatory text should be visually grouped with the stuff it references.
• Avoid acronyms, abbreviations, and contractions.
• Think about where sentences or lines of text break and what that does to readability.  If a few words are forced to a second line of text, think about rewriting to keep everything on one line.

Doing these things won’t instantly make your site the best in the land, but your users will stick around long enough to let your site be judged on its own merit.


www.siteblink.com

Decisions...Decisions

Applying the principals of user-centered design to your application or website is just another of those things you know you SHOULD do, but you don’t always make the time or spend any resources to do it.  You know what I’m talking about, oil changes every 3,000 miles, going to the gym, eating at home instead of going out to eat.  

These are the kinds of things that people with unlimited resources and loads of free time don’t really have to think about.  They don’t have to prioritize their day and scrutinize their budgets to include those things in their lives.

You SHOULD be able to think about how and why users will thoroughly embrace your app or site and come back time and time again, but that isn’t the most important thing on your list.  You have deadlines to manage and functionality to implement and test.  If things don’t work and they aren’t delivered on time, it won’t matter if it’s easy to use or easy on the eyes, right?  Well, yeah, if you want to be technical about it.  But what if it were possible to deliver the features on time AND have users stick around without requiring training and interaction with your support team?  Sound too good to be true?

It’s not really that far-fetched.  Just like most solutions, you just have to know where to look.  The need for the service that Site Blink provides is becoming more and more apparent to companies who want to set themselves apart from the pack.  As the user community has become more savvy, the bar has been raised, and companies have to deliver functionality on time and do it better than everyone else.

So the question becomes, can you afford to ignore the needs of your users when designing your app or site?

www.siteblink.com