A federal judge has ruled that Citibank isn’t entitled to the return of $500 million it sent to various creditors last August. Kludgey software and a poorly designed user interface contributed to the massive screwup.
Citibank was acting as an agent for Revlon, which owed hundreds of millions of dollars to various creditors. On August 11, Citibank was supposed to send out interest payments totaling $7.8 million to these creditors.
However, Revlon was in the process of refinancing its debt—paying off a few creditors while rolling the rest of its debt into a new loan. And this, combined with the confusing interface of financial software called Flexcube, led the bank to accidentally pay back the principal on the entire loan—most of which wasn’t due until 2023.
My initial reaction on reading this was: wow, $500m is a lot of money — I wonder how bad the UI is? The article provides a screenshot, which it credits to Judge Jesse Furman:
The men who are cursed with the gift of the literal mind are the unfortunate ones who are always busy with their nets and neglect the fishing.
– Rabindranath Tagore, Sadhana
Modeling is the most critical underused design skill. The ability to examine a domain abstractly — to consider its components, how they relate to each other, and how they allow people to achieve their goals — is essential to designing complex systems that balance the needs of users with the organization’s strategic goals and, more broadly, social well-being.
As someone who cares about the longevity of systems, I love Stewart Brand’s Pace Layer model. In case you’re unfamiliar with the idea, the Pace Layer model explains how complex systems change over time. Such systems don’t change uniformly; instead, they’re composed of elements that vary in scale and rates of change.
The model has roots in architecture, and that’s how I usually introduce it. Mr. Brand’s book How Building’s Learn presents the following version, which is based on the work of architect Frank Duffy:
Designers — at least the good ones — have a rare superpower: they can leap several levels of abstraction in a single bound. Among other things, this allows them to look at the form of a thing (a building, a kettle, a website) and get a sense of its constituent parts, the relationships between those parts, how those relationships help serve particular functions, and what those parts, relationships, and functions say about the goals of the entity that commissioned the thing — all without getting hung up on its “look and feel.” In other words, good designers can look beyond the tangible forms of things to the conceptual models they manifest. Some designers can even map out these models in ways that make sense to the rest of us.
Working with models is a key skill — perhaps the key skill — in 21st Century design. Today’s most important design challenges deal with complex, evolving systems. The parts of these systems we see and interact with (such as user interfaces) are only surface manifestations of deeper structures. It’s essential to understand the connection between these structures, the forces that call them forth, and the user interfaces that manifest them. You can’t skillfully intervene by acting solely on the surface.
However, many designers (and most stakeholders) want to work with screens, not models. Screens are things they can test and critique. Models? Not so much. It takes practice to see the tangible forms latent in an abstract diagram. Most of us lack the patience to acquire the practice. We’re drawn to screens because we can draw screens; they’re familiar, things we deal with every day. Models, on the other hand, are abstractions. They can be ambiguous and subjective and unfamiliar. This makes them hard to communicate. How do we begin to draw such a thing?
And yet, draw them we must. Only by understanding models can we effectively deal with fitness-to-purpose and second- and third-order effects, and thereby ensure design directions are strategically and ethically sound. Of course, this doesn’t mean we won’t work on screens at all. As I said, we can’t test models without manifesting them as tangible artifacts. But these artifacts must be rooted in a clear understanding of the underlying models, not the other way around. The ability to jump back-and-forth between models and their expression as UI requires training and practice. It’s an essential skill for today’s designers, and one I’m increasingly focused on learning and teaching.
As you can see, these aren’t cosmetic tweaks, but significant changes to Gmail’s structure. Where previously the app aspired to be a great email client, now its stated goal is to be “your new home for work.” This goal reflects three fundamental premises:
Much of what many of us do for “work” consists of coordinating with and informing each other
Most of these communications happen over digital channels (especially now that many of us are working “remotely”)
Email is no longer the only (or even primary) channel for these communications
In a 2008 paper in ACM’s Interactions, Hugh Dubberly, Shelley Evenson, and Rick Robinson presented the Analysis-Synthesis Bridge Model. This bridge model describes how designers move from the understanding of a problem domain to a proposed solution. It’s laid out along two dimensions:
On the left half, you have the current state you’re addressing, while the right half represents the future (changed) state. (The authors refer to “the solution, preferred future, concept, proposed response, form.”) The bottom row corresponds to tangible conditions in the world that we can observe and interact with, while the top row refers to abstract models of those things. The design process goes from the lower left quadrant — a solid understanding of conditions in the “real” world through abstraction towards a tangible construct that represents a possible future:
While it seems to imply a clear linear progression (something I’ve seldom experienced in real projects), this model corresponds closely to how I design — especially when dealing with complex domains. I can’t sketch tangible structures (e.g., wireframes, sitemaps, etc.) without having 1) a solid understanding of the domain and 2) models that describe it. This requires spending time dealing with abstract models — and abstraction makes people uncomfortable. Clients want to get as quickly as possible to the lower right quadrant, where they can see and interact with things that look like the thing they’ve hired me to produce. (E.g., prototypes.)
But it’s important to acknowledge that when dealing with complex systems, you’re doing clients a disservice by jumping straight to screens. You really must figure out the structures that underlie the domain first, and that requires devising models — both of the current and future states. The bridge model is a useful tool to help explain how the process works and why abstraction is important to a successful outcome.
Even if you’re not a professional educator, sometimes you must teach others. Perhaps someone has joined your team and needs inducting into your project, or a child asks you about the meaning of some obscure term, or you’re called on to tell an audience about your company. Whatever the case, many of us often find ourselves having to introduce others to ideas that are new to them.
Over time, I’ve found a pattern for teaching that works well for me. It consists of four steps: