Best practices for non-functional aspects of the end-user experience

From PegaWiki
Best practices for the non-functional aspects of the end-user experience / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Best practices for non-functional aspects of the end-user experience

Description Best practices for non-functional aspects of the end-user experience
Version as of 8.5
Application Platform
Capability/Industry Area Application development



Non-functional aspects of the end-user experience, such as vanity URLs, error screens and messages, title tags, dead ends, application logos, are the fine detail that would normally fall outside of a team’s thoughtful consideration in an enterprise software project, but if handled incorrectly or incompletely by the out-of-the-box application, will have a material impact on the usability of that application. It is recommended that, during a software project, each of the following should be evaluated for contextual fit.

Vanity URLs[edit]

Vanity URLs could be either branded links or custom short links which redirect to a destination link that is usually longer to type, render, or hard for users to remember. In most cases, your team will want to pursue this route when they:

  1. Lack control over the destination application’s URL configuration.
  2. Would like to direct users to a specific page or section within an application or website where the URL is verbose and not easily-readable.
    • Want to make URLs brief.
    • Need to make URLs fit for the context.
    • Want to make URLs memorable.

Error screens and messages[edit]

Error screens and messages are an opportunity for the application to inform users that either a system or user error has occurred. It is also an opportunity for the application to help the user recover from the error and avoid costly support calls.

To quote directly from Neilsen’s 10 Usability Heuristics (1994); Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

The guidelines for creating effective error messages have been the same for 20 years. Good error message should include:

  • Explicit indication that something has gone wrong. The very worst error messages are those that don't exist. When users make mistakes and get no feedback, they're completely lost. Email, for example, offers several situations where explicit indication would be useful. Such as: When you send a message that gets eaten by the system and never reaches the recipient. Another good example? When you state in an email that you'll include an attachment, but forget to do so. Finally a job for that annoying paperclip: "You seem to want to attach a file to this message, but you have not done so. Would you like to attach one now?"
  • Human-readable language, instead of obscure codes or abbreviations such as "an error of type 2 has occurred."
  • Polite phrasing that doesn't blame users or imply that they are either stupid or doing something wrong, as in "illegal command."
  • Precise descriptions of exact problems, rather than vague generalities such as "syntax error."
  • Constructive advice on how to fix the problem. For example, instead of saying "out of stock," your error message should either tell users when the product will be available or provide a way for users to ask to be notified when the product is restocked.

Title Tags[edit]

Title tags are primarily used for search engine optimization. However, often within applications, title tags are used to orient the user in the context as the tags are rendered at the top of the browser. Title tags are also used to help orient users with visual impairments who may rely on screen readers to navigate the digital world. Follow this guidance:

  • Title tags should change with context.
  • Title tags should be succinct but descriptive in helping users understand the screen’s content.
  • Modifiers within the string should be prepended to the tag text as the ends of longer title tags are hidden after a certain number of characters.

Dead ends[edit]

A user executes a "forgotten password" workflow that concludes on a screen containing little more than the application logo and a success message. What just happened? What is next? What is the user supposed to do? Dead-end user experience is a driver of support calls that are easily avoidable.

In workflow applications such as Pega, we commonly find dead ends at the end of workflows. Here are a few ways to avoid them:

  • Provide clear instructions for the next actions that you expect the user to take.
  • Provide the user a way back to the primary path of the application through a hyperlink.

Having a clear understanding of a unique end user’s journey will help teams determine the right design for optimal experience.  

Logos[edit]

Application identifier

Applications can be identified by an end-user through a textual name or a unique application logo. The application identifier should take visual precedence over the client or Pega logo. It is most important that end-users are aware of what application they are visiting.

Client and Pega logo

Client logos in enterprise applications should be located in the upper-left corner of the screen alongside an identifier for the application. The logos should be clickable, returning the end-user back to the default screen of the application.