Remedy@Work

Remedy Logo White

 

The Scenario:

Remedy Corporation has a successful set of desktop Help Desk applications called “Action Request System”.  It’s the early days of internet expansion and they want to update this set of applications to run on the web.  Many companies are in the process of building websites, but few are converting their applications to run on the web yet.

The Problem:

Internet technology is very new and consequently, the tools for creating good looking and usable interfaces are rather crude.  Desktop interfaces are improving at a rapid pace, but it was not yet possible to replicate these sophisticated interfaces with the early versions of html.

Remedy tries to port their desktop applications at the same time as it tries to improve the look and feel of the applications.

What resulted was the Remedy@Work suite of applications:

  • Remedy Setup@Work
  • Remedy Expensable@Work
  • Remedy Purchasing@work

What We Explored:

The first thing I did upon taking this contract was to run a usability study to understand how people used the current Action Request System.   I learned that this help desk system had two use cases: the person requesting help filled out the form with details of their problem, and the help desk administrator took the form and had to solve the problem.  The existing system was optimized for the help desk administrator.  When the requestor saw the form, they had to ignore the top region – this was for use by the administrator.

I looked at ways to improve the organization of the form so that they were easier for the requestor to fill out and understand.

 

Original desktop purchasing form and first pass at porting to a web appliation.

Original desktop purchasing form and first pass at porting to a web appliation.

The engineering team took the desktop form and ported it to the web using the existing html technology of the time.  Like all new tools, it was very tempting to take advantage of the cool things that were now made possible.  Note the gradated buttons on the left.

I tried to take this form and organize the information so that it was easier to find the part the requestor needed to fill out.  I right justified labels to make it easier to read and color coded regions that had related information.  Still, this version uses too bold colors and too large and probably gratuitous icons on the left.

Reorganized purchasing form - related data together in four quadrants, right justified labels.

Reorganized purchasing form – related data together in four quadrants, right justified labels.

Note the SAVE button in the upper right corner.  This was originally a “SUBMIT” button, which even then was already becoming a standard term for sending data over the web.  One of the engineers didn’t like the term and wanted it to be called SAVE.  I explained that SAVE, to most users, would mean “save it to my local hard drive” and not “send it over the web to the help admins.”  I suggested that if he didn’t like the word “submit”, we could at least call it “send”.

When I ran a usability study on the mockup shown above, users were very reluctant to click the SAVE button.  The typical dialog went something like this as the user hunted around the screen:

Me:  “What are you looking for?”

User: “The SUBMIT button.  I need to submit this to the help desk.  All I see is a SAVE button.  I guess it won’t hurt to SAVE it.”

They click the SAVE button and continue to hunt.

Me: “Now what are you looking for?”

User: “I SAVED it but I still need to SUBMIT it.”

The Solution:

When the product shipped, the various applications had a consistent look and feel.  Note the final version of the Purchasing@Work app had two buttons, a SAVE FOR LATER, and a SUBMIT button.

Employee Portal and Expensable@Work.

Employee Portal and Expensable@Work.

Note toned down icons on left and two buttons in upper right SAVE FOR LATER and SUBMIT.

Note toned down icons on left and two buttons in upper right SAVE FOR LATER and SUBMIT.  Colors are still too bold.

How this solution fit into the product:

This set of products were first generation web applications, taking advantage of the most current html available.  Much work would be done afterwards to improve the user interface possibilities for web applications.

This was a good solution because:

The Remedy help desk suite was particularly well suited to a web application where requestors and admins could review requests anywhere and anytime and make updates to them without having to download the desktop application on each new computer.

Big Realization:

Just as user interface design technology was growing quickly, the rise of the internet knocked design back a few steps.  It took a few more years (and we’re still working on it) to get web interfaces to be as sophisticated as desktop interfaces.  Performance is still an issue with intricate interface design.

Future:

Remedy Corporation was bought by BMC Software in 2002 and is now the Business Service Management division.

 

 

 

 

 

© Copyright 2011-2013 - Deanna McCusker