Value of a Design System: The Impact of Design and Usability on Complex Systems

Traditional software design methods present a problem: it is entirely possible to create a system that is neither useful nor intuitive but meets usability guidelines. Typically, a list of new features, functional updates and component wish lists are collected from key stakeholders and representative users, handed to a talented development team who do their absolute best to coordinate the requirements and create a unified system that will make sense to users.

This is how software with a terrible user experience is created.

In this whitepaper, we will look at a different approach: one that starts from a set of requirements rooted in user needs (rather than wish lists), and which involves usability analysts and design professionals early on to collaborate and create quick, inexpensive models of the final system. Since this process of rapid “paper” prototyping does not require code, it is as easy to modify as erasing a line. It also provides the opportunity to put the prototype in front of users and test both the conceptual ideas generated during requirements gathering, as well as screen-level usability, ensuring that the final, implemented product will be both usable and useful.

Cars, Houses, and Software

Cars have been around since the late 1800s. They began as mechanized carriages, powered by primitive internal combustion engines. By all accounts, early cars were uncomfortable, unreliable and dangerous. But they did what the mature modes of transportation at the time could not. They could go farther, faster. And while the owner/operator also needed to act as their own mechanic and parts fabricator, it was enough.

Houses have been around quite a bit longer than cars. Early on, providing shelter from the elements was the deciding factor in choosing a worthy home. If it kept the rain off and the wind out, it was enough.

Software, particularly enterprise software, is the most recent of the three. Software is interesting in that it is not a physical object like a car or a house and therefore not tied to a particular form or size. However, like cars and houses, primitive software (and I would argue that almost all software today that requires human interaction is primitive software) is considered acceptable if it contains an impressive list of features and functions. Regardless of whether anyone can use it, if the software does more than the previous version (or its competitors’ software), it is enough.

What becomes clear as you trace the evolution of these three is that, initially, complex systems begin their existence as engineering events. It’s enough that they work. As time goes by, complex systems evolve from the engineering to the personal. This is certainly true for cars and houses. Software, however, isn’t quite there. As shown in Figure 1, Don Norman referred to this idea in his 1999 book The Invisible Computer, though he was speaking about hardware rather than software (see, Norman, D., 1999: The Invisible Computer).

Software is a young product, from a product evolution perspective. While that may be sufficient to explain much of why it remains so difficult to use, it is not a reason to accept it. Every piece of software is the result of countless, well-meaning decisions. It was designed to be exactly what it is. That’s the problem. Not every product is designed well.

Isn't Usability Enough?

Companies attempt to address the issue of poor design by handing the problematic screens to usability professionals. Through rigorous testing and adherence to time-honored guidelines, overall usability can certainly be improved. However, when dealing with complex systems, improving usability after the system has been designed is akin to treating the symptoms rather than the disease. With that in mind, the following section provides the answer to the question that begins this section:

Usability Is Not Enough

There are several ways to approach the design of a new system. In the first, a list of new features, functional updates and component wish lists are collected from key stakeholders and representative users. This list is then handed to a talented development team who do their absolute best to coordinate the requirements and create a unified system that will make sense to users. This is how terrible software is created. Why? Because developers are not usability analysts or designers and they are being asked to do the jobs of both.

In the second, a user research lead works with key stakeholders and representative users to determine the needs and requirements of both groups. This results in a more appropriate set of requirements.

This is incredibly powerful. Neither users nor stakeholders are typically able to see beyond their immediate wish list and the difference between incremental improvement, giving users what they want, and innovation—giving users what they need—lies in skilled requirements elicitation. While this new system will be based on an excellent set of requirements, issues such as screen layout, interaction models and data visualization (i.e., design issues) are still being determined by roles whose core competencies are not design.

In the third, user research leads and design professionals collaborate, gathering requirements and creating innovative ways of supporting users as they complete their work in ways they never dreamed. Sound a bit too utopic? It’s true and when you can be part of such a “design process” as either a stakeholder, user or team member, it’s a beautiful thing. Emerging design-to-code systems such as Indigo.Design also help facilitate true UX design-development collaboration.

It’s not uncommon for user research leads to find out that even the end users themselves don’t always know what they need.

Here’s a case in point: on the trading floor of many financial companies, it’s not unusual to see a trader’s workstation with four monitors mounted two over two, on a single pedestal, angled such that they basically wrap around the trader’s head. On the monitors you’ll typically see a complex mix of spreadsheets, line graphs, and scrolling, blinking and colored data points. You might assume that the trader didn’t have much control over how the data was displayed and that they were simply streaming in data from other sources. But when a trader at one financial firm was asked “Who controls the way data is displayed on the screen,” the trader’s reply was surprising: “We do. We have complete control of the data and how it’s displayed.”

You might think he’d say that he’d like to see important information highlighted or even something as simple as “stop these things from blinking all day.” But when this trader was asked what would help make his job easier, he said he wanted a faster processor because the one he had could only run 4 monitors. With a faster processor he could have six.”

When you think about that answer, you realize the limits of the user’s perspective. Would that have improved their performance? For the more experienced traders, it probably would have resulted in some degree of incremental improvement. But it’s not what they needed.

User Research: Understanding What Users Need

What a user needs becomes clear as you observe them work. It becomes clear as you ask them to explain why they took a certain action or why actions were taken in a certain order. Innovation becomes possible once you understand what the user is trying to accomplish. During one task, the trader was trying to decide whether to buy or sell a certain financial product. To do this, he was interested in knowing how certain currencies were trading relative to one another, whether the rates of change between the currencies were trending in the desired direction over time and how this compared to historic rates of change between the currencies: concerns such as rate of change, the rate of change of the rate of change, and historical comparisons of rate of change. There are many ways to represent this information. One way includes 6 monitors worth of spread sheets and line charts. Or a designer could create 3 novel ways of visualizing rate of change data at a glance (because it’s what they’re extraordinarily good at). Users cannot think in these terms. Frankly, neither can most usability analysts.

I have made the case that the creation of more evolved software is possible through the implementation of a design process that relies on collaboration between usability and design professionals. What if it could also decrease the risk associated with software development? And since risk typically incurs cost, what if user experience and design could reduce the cost of software development? Before we look at the two most prominent models of software development, it would be useful to consider another anecdote.

A Tale of Two Harrys—or How a Final Result May Not Satisfy Expectations

To better explain the challenges of software development, let’s consider the experience of young boys who have fallen in love with Harry Potter books and their reaction when seeing it on the big screen. By the time the first of the Harry Potter movies was released, these boys had already read the first three books and were anxious to see the film. But an interesting thing happens after waiting in line, paying $10 per ticket, buying soda, candy and popcorn and watching 90 minutes of Harry Potter’s adventures. They didn’t like it.

When asked why they didn’t like the move, they said it wasn’t the same as the book. Apparently, neither the person who wrote the screenplay, the director nor the actors could match the “movie” the boys had constructed in their heads. Therefore, the film was a disappointment.

This is exactly the problem with traditional software development methods. Coding begins when everyone involved in the project agrees that the prose-based requirements documents, containing the sum total of everyone’s wants, needs and desires, correctly captures said wants, needs and desires. This is the first of the three ways in which software can be created (described earlier). Not only are the stakeholders (and users) dependent on the developers to create a usable system, but they are depending on the developers to create a system that matches the system they’ve already created in their minds! Inevitably, many months later, when the curtain is pulled back and the alpha release is revealed, the team struggles to find the system they envisioned. This is followed by variants of “That’s not what I was expecting.” The only real difference between my movie example and this software development example is that the boys’ dad only spent $40. The software project spent more than that on coffee.

The two main software design processes today are Waterfall and Agile. Each model begins with prose-based descriptions of the requirements that describe what the software should do. Each begins with a “Risk Potential” (my term) of zero. By this I mean that at the beginning of the development phase, everyone is confident and happy. Nothing bad has happened and everyone believes they share a common vision for the end-product. Then development begins and risk begins to increase. Why? Because decisions are being made that cause the final form of the product to veer away from the vision held by each member of the team. Is it the fault of the development team? Absolutely not. They’ve been put in the uncomfortable position of needing to make design decisions as they try and do what they love to do – code. And so, as time passes, risk goes up and up.

As demonstrated in Figures 2 and 3, this happens whether the project is following a Waterfall or Agile methodology. Waterfall is the more problematic of the two because the result isn’t available until the build is complete. Agile attempts to address this issue by chunking the build into short sprints. However, this only allows views into isolated pieces of functionality, requiring the team to imagine how they will work within the larger whole.

Neither process allows the team to view what the final system will look like, how it will behave or how it will interact with other systems and other pieces of functionality until the development process is complete. In both, the initial development cost is high. Changing design decisions that have already been implemented in code is even more expensive. The likelihood of users accepting such a system is small.

The design process, as shown in Figure 4, on the other hand, coordinates the skills of usability analysts and design professionals and addresses this problem.

In addition to creating a better set of requirements (which, admittedly, could be the input to either Waterfall or Agile methods), the usability and design professionals also create quick, inexpensive models of the final system. Through a rapid series of sketches, wireframes and screen mock-ups, the team can provide a view of the complete system that enables everyone to gather around, question and come to agreement. Since this process of rapid prototyping does not require code, it is as easy to modify as erasing a line. It also provides the opportunity to put the prototype in front of users and test both the conceptual ideas generated during requirements gathering as well as screen-level usability. Once the bugs have been worked out and everyone shares a common understanding of the final product, the development team can begin working. And in addition to the requirements, they also have designs that concretely demonstrate the final visual form of those requirements. Development risk is therefore minimized before coding begins and held relatively constant throughout the development process.

Good design is a research-based, iterative process that discovers and defines requirements. It provides an understanding of what users need to accomplish, in addition to what they want. It enables early consensus, modifications and user testing. It is fast. It is inexpensive. It is usable and intuitive, beautiful and inspiring. It reduces risk. It provides for innovation rather than incremental improvement. It fits within existing software development methods. It is scalable and supportable.

Software is an infinitely malleable product. It can be molded into absolutely anything. No need to worry about the availability of raw materials, transportation logistics or factory support. It will be what it was designed to be. All it requires is the desire, and a process, to make it great.

Resources

Norman, D. (1999). The Invisible Computer: Why Good Products Can Fail, the Personal Computer Is So Complex, and Information Appliances Are the Solution. The MIT Press.