Skip to main content

Software Usability Case Study: Novices and Power Users

Posted by pbrittan on August 4, 2003 at 5:31 PM PDT

Yes, you can support both

In his post, Widgets
follow form follows function
, Chris Adamson ably describes the dilemma many software designers face when trying to design applications that support both novices and power users. In my post, Brittan’s Rules of Software
, I introduce the idea that software usability strategies can be seen through the application of three concepts: perspicuity, alignment to personal workflow, and style.

The dilemma that Chris describes stems from the fact that novices need more perspicuity (so they can figure out what to do) and power users care only about workflow efficiency (they already know all the functions by they just want to work fast). And this is a problem because perspicuity and workflow can interfere with each other in application design (wizards are an example of this).

But there does not have to be a conflict between perspicuity
and workflow. I can’t resist offering up a case study from my own experience on an approach we took to support both novices and power users. My first
company, Astrogamma, developed and sold single product called href="">FENICS which performed pricing calculations
and risk management analysis for foreign exchange options traders in large
banks and brokerage houses. FENICS was able to capture 80%+ market share of institutional FX options traders around the world. We sold the company in 1995 but
it continues its market domination today, in large part because of the quality
of its user experience.

Traders are a very tough group to design software for. They are incredibly demanding. Speed of execution is critical for their business. They certainly have no
patience to read a manual and learn how to use obtuse software. FX traders are very international (our customers were spread across dozens of countries) and many spoke very shaky English at best, so long explanations were lost on them. But traders also engage in a pretty narrow set of activities all day long, day after day, so they are prime candidates to become power users quickly. Our software was core to their ability to do their jobs, and most traders used only FENICS during their day.

In order to support a quick learning curve for impatient users, we used a fairly typical perspicuous GUI layout. All the fields were visible on the screen at once. All the functions were clearly labeled and visible at all time on a toolbar. The goal of our layout was to make sense of a trader’s world and present them with a full dashboard of fields and functions that would seem intuitive to them the first time they used our software.

So handling novices was pretty straightforward (we also had very complete but wildly underutilized documentation). But how did we handle power-users (the bulk
of our user population) in that same interface? For that, we used a variety of strategies including the ones below, some of which admittedly took us a little astray from what is standard Windows GUI behavior today:

  • Keyboard navigation: Mouse navigation in FENICS was totally optional and was in fact rarely used. All the data fields were arranged in two vertical columns, and the user could navigate from any field to any field with the arrow keys (more like spreadsheet cell navigation than a typical form) and we provided hot-key
    combinations to instantly move focus to any specific field. We also supported Tab which moved focus to the next empty field.

  • Smart parsing: All data fields on the main screen were edit boxes. No
    radios or checkboxes on the main screen. And each of those edit boxes featured a
    smart parser that knew a lot about the type of data that was being entered into
    it. The parser would engage as soon as the user left the field or hit “Enter” in a field. We would try to interpret whatever the user typed in. Our parsers understand specialized lingo of FX options traders. We could parse dates in multiple formats, for a simple example. If there were ambiguity, the parser would pop up a list of choices for the trader to select among. If the user entered blank into a field, a list of all possible choices would pop up (obviously we didn’t do this for numeric fields!). The Esc key instantly dismissed the pop-up. As soon as input was parsed, it was immediately re-displayed into a standard format to let the user know that what they entered was understood.

  • Use context: Not only did parsers know about the type of data being entered, but they also knew about the context. For instance, let’s say that at that time the exchange rate between Deutsche Marks and US Dollars was 1.5 Marks/Dollar and the exchange rate between Japanese Yen and US Dollars was 150 Yen / Dollar. If a trader entered “14” into an exchange rate field, then the parser would look at which pair of currencies had been specified for this options contract. If it was $-DM, then that 14 would be interpreted as “1.4000 DM/$” and if the currency pair was $-Yen, then that 14 would be interpreted as “140 Yen/$”.

  • Multi-field parsing: In some areas we let the user enter values for several fields into a single field. They we would parse of the individual pieces and populate the correct fields with those pieces. This was extremely fast for the power user and a novice could always fill in the individual fields. So for instance, a power trader could enter “150 $ DM Dec Call” into the upper left field (which had focus when you first entered this main screen). This string of seeming gibberish is how an FX options trader naturally describes a contract anyway, so it was very natural, and it was translated as a “Call option to exchange US Dollars for Deutsche Marks in December at a strike price of 1.5000 DM/$”. We would parse all the pieces of that out and populate the individual fields: option type (call/put), each of the two currencies, the maturity, and the strike price.

  • Auto-calculation: An option contract has many interlocking pieces of data, and specifying some number of pieces of data would necessarily imply what the remaining pieces would be. FENICS just did this automatically. For instance, there is a set relationship between the current exchange rate between two currencies, the interest rate of one currency, the interest rate of the other currency, and the ‘forward’ exchange rate of the currencies. As soon as any three of those four pieces of data are specified, the forth is calculable. So, in FENICS when any three of those fields was entered, the fourth was immediately automatically calculated and filled in.

  • Default values: We tried to fill every field possible with an intelligent default, like today’s date or the most common market for a particular instrument. Some defaults were customizable by the user on a set-up page. Any default field could be overwritten on the main screen. If the overwriting value were erased, the default would reappear.

  • Color coding: Using different font colors in the edit boxes, FENICS would show the user which fields had been filled in manually, which had been calculated, and which had default values in them.

  • Get rid of things that interrupt flow: Everything vital to pricing an FX option took place on that main screen, and it was very ‘flat’. We featured no wizards, and used pop-up windows as sparingly as possible.

The main screen of this application was incredibly reactive. The user could move around the screen very rapidly, could enter values as they wanted to enter them, and the system was constantly interpreting what he user was doing to try to remove any unnecessary steps. These concepts proved so useful in FENICS that we carried them forward into subsequent products. They are even supported in our current product, Droplets.

To wrap up, this case study was intended to illustrate that there are ways that the seemingly conflicting usability needs of different types of users can be addressed at the same time, and to provide a description of what we did so that others can build on those ideas.

Related Topics >>