About                      Design as Engineering Monetized Value Problems Solved History

Work                      Clients, Projects, Testimonials Charts  Research

Offerings                      Services: Role & Deliverables White Papers Three-Day Class

Contact                      Contact Us E-mail Brad

The design of a financial system interface is factor that enables but also limits the productivity of everyone who uses it. In didi’s quarter century of experience in financial technology, we’ve noticed that the majority of financial systems are designed without adequately addressing the most important aspects of business workflow: the subtle steps in the thinking process an expert develops throughout his or her career. As a result virtually every revenue-producing role on Wall Street is hobbled by the systems meant to support it.

Common practices in interface design are far from best practices

Interface Design is all but ignored in financial systems. It’s commonly expected that a functional specification will capture all necessary workflow issues, and that design is at best a cosmetic polishing that might be useful for client-facing applications but adds no value to internal systems. There is nothing farther from the truth. It’s our experience that virtually every work process on Wall St. can be made significantly more effective.

Properly practiced, design is not just fashion or branding but an optimization process whose objective is to connect the information in the computer with business tasks in a deep and effortless way. Seen as an optimization process, it’s clear that we can focus on the working parts of the information transfer between computer and financial expert. But the skills needed to understand those working parts are not taught in business schools or computer science curricula.¹ In a typical development cycle, a business analyst is asked to interview traders (for instance) to develop a list of use cases, a dictionary of the data needed to support them, then write this information up for a development team to code. This is an important step in defining what the system must do—but it does not capture how the traders work at a fine enough level of granularity to facilitate the real business processes: what really goes on in their minds.

Design as optimization

To optimize a system’s interface we need to dig deeply inside the thought processes that are the essence of each business task. We need to support every sub-second cognitive step with data (or input opportunities) in exactly the right form to fit how it is being thought about at that moment. It also needs to fit all the other ideas that are part of that task. Traders themselves do not have access to how those processes work any more than a grown adult can describe in words how to tie a shoe or ride a bike. The processes have become “automatized,” so they don’t come out in interviews.

Engineering is applied science, and presumes an almost cookbook-like methodology to apply to problems, at least as a starting point. At didi we directly apply science and have developed such a methodology. The results are as remarkable as one might expect where no engineering has been applied before. Applying engineering practices from the wrong domain (e.g. Computer Science) can sometimes be worse than no engineering at all: human minds do not operate like computers.

The sciences we apply range from Visual Perception and Cognitive Science through Psycholinguistics.² The cookbook-like methodology creates a working process that reveals to all participants exactly what progress is being made, and how obvious its absence was in retrospect.

Introduction to a rigorous design methodology

An introduction to this methodology takes a 14-week college class (or a three-day intensive seminar at a financial firm), but some of its key underpinnings and findings can be hinted at here.

First, a thorough understanding of every element in a business role is compiled, including:

1. Management/firm goals, working expert’s goals (e.g., a trader’s goals), the tasks that build toward the goals, and sub-second-scale cognitive steps necessary to complete the tasks
2. The entities involved in a task (e.g. order, symbol, market, algorithm)
3. The relationships among those entities, and the transitions they go through
4. The business meaning, value, risk, and urgency of every task and transition

This exhaustive dictionary of things/processes/issues is then partitioned—not following database idiosyncrasies or within-firm silos of practice—but following business practices and needs. Thus a single screen might need data feeds from four or five different databases or even different business groups to accomplish a specific task. Don’t send the expert to five screens: bring the data to one.

There are techniques to turn this partitioned dictionary into candidate designs, e.g.:

1. Tasks become screens: each one- to five-second task initially gets its own window in which we can create a tool perfectly honed for that task. (Imagine using a Swiss Army Knife to build a home—financial systems typically throw a database into a do-everything table and let the user configure what they want for various tasks.)
2. Entities become objects in those screens. And importantly, the objects are designed to have the exact and minimum amount of information in them tailored to the task at hand.
3. Relationships become annotations or interface behaviors. States are indicated by coloring, shaping, expanding, or re-positioning of objects. (Color-coding alone is not nearly enough.)
4. The business meaning drives the layout of the windows, while the value risk and urgency drive the visual layering within each window. Information is where it’s expected; more visible the more important it is.
5. Windows and tasks are then re-integrated into the whole workflow of the expert, following both business and local goals. Sometimes this allows task-centric windows to be combined. Even where screens stay separate and optimized for a given task they can be tiled into a worksheet or pop-up only when necessary. And they are always tied together with visual techniques that let the eye easily find the same and related objects in nearby screens.³
6. Later steps in the methodology do step-by-step testing of the system well before coding starts by using “paper prototypes”—with huge cost and time savings.

How many financial screens exhibit the simple mapping that comes out of step 4: that the most important business issue is the most visually obvious thing on the screen? How many screens are explicitly tailored to ease the mind’s task-switching costs as an expert goes from one to another, as addressed in step 5? Standard UI guidelines address none of these issues.

Literally hundreds of techniques exist to tie on-screen visuals to mental processes. Perhaps the strongest value comes from the fact that screens designed to reflect the decades-honed best processes of the experts actually guide every new user to think like your most productive people. The benefits are concrete and create significant value in many dimensions; including productivity gains, lower training costs, risk reduction, and lower support/maintenance costs. Most important it results in improved morale and creativity in your best people because the system finally lets them think not as data entry experts but as the business experts they signed up to become.