Design for the Quotidian. Build for the 100-Year Flood.
By Jonathan Blessing
January 13, 2016
After years of building software, I’ve crossed over to the design side and spent the last months thinking about UI/UX. In doing so I’ve come to realize that as disciplines, engineering and designing are far afield. Software development challenges you to think of the worst and least likely, whereas design asks you to consider the everyday essence of the thing.
Floods are uncommon, otherwise someone would have knowingly built your home in a river. Floods are what software developers call edge cases, uncommon happenings, and they are the subject of worry for software developers. They are what we build for. What happens when a user accidentally dumps Moby Dick into the field labeled “First Name”? Or, what happens when the hackers come calling; what weakness will they find?
As users of software, people mostly behave as expected, but not always. Like a city planner preparing for a 100-year flood, software developers carefully consider unlikely events—especially when building for large organizations, the Internet, or for a long lifespan. In the fullness of time, all events inhere. The unusual will happen, which is to say that software not engineered for edge cases is eventually hacked, produces inaccuracies, or simply fails. Just as the 100-year flood will in time arrive downtown, so too do the hackers, the accidents, and the failures. And knowing this, uncommon eventualities often come to define a project. (As an example, consider the extreme, One World Trade Center.)
While software may appear to be about banking, chatting, or auctions, it is really about surviving the crazy things users might do. Designers, on the other hand, don’t care about your crazy. They care for expressing the purpose of the thing. Which is to say, they are designing for everyday use, the common cases, for what the thing is supposed to do. As such, design ensures that things look like what they are about. And, that means mostly ignoring how the thing may be misused.
I’m thinking of a butter knife, and how it is so often a poor substitute for a flathead screwdriver. A nicely designed butter knife announces its function, even at the expense of limiting its utility. The designer of the butter knife doesn’t care that the tip is without the torsional rigidity to help you unwind that screw. He cares that it looks like a thing for cutting and spreading butter.
UI/UX design is the same. A well designed application promotes its purpose, instructs, and looks the part. If common use cases require visiting menus labeled “Advanced”, that’s evidence that the designer missed the point of the software. The discipline of design requires us to rank order the software’s primary functions and subsidiary functions. Then we shape the look of the software to preferentially serve the most important functions, the common cases of use. If engineers build from the edges in, designers design from the center out, first thinking of the essential functions. While the developer fortifies the edges, the designer greases the rails so that the application smoothly satisfies the common cases. While engineers ensure the house won’t be washed away by a flood, designers give its layout order and harmony.
Comments