RealityPrime

The tension between engineering and design is felt in software development in one place more than any other: user experience and user interface design. The fact that the discipline is called ‘design’ shows the bias clearly. UIs are voodoo art, they say. Users are entirely unlike computer hardware — fuzzy, irrational, and wet — and no compiler will validate your design for you.

That much is true. But like much of software engineering, experimentation, validation, and testing is the name of the game. And even the best design firms in the world do not resort to one genius-level artist, alone in a tower, handing tablets from on high. They mock-up designs and test them out internally and with impartial human testers, which I’ll argue is far more science than art.

Which is exactly why engineers can be great interface designers too — if they learn the language. Freehand drawing skills and a photographic eye may be largely constitutional. Design skills, on the other hand, can be learned both directly and through experience, except we often don’t.

In other words, just as C++ can express certain logical and mathematical solutions to problems, so must engineers learn the language(s) of design. We must gain an understanding of how (and when) to critique designs. We need to be able to tell when our own designs aren’t working. And we a repertoire of tools and ideas for improving things, including collaborating to find better solutions than we can find on our own.

When user experience design lives in the realm of art, it’s just one opinion vs. another. Everyone clings to their ideas, as if they’re utterly precious and not simply fodder for constructive criticism, termination or improvement. As art, people tend to design things alone, lacking the skills to collaborate, staying isolated, secretive, and dead-end. They present their masterpieces when they think they’re perfect, which sadly is never the case. And people tend to judge things in a knee-jerk fashion or as if they were the sole audience. It’s as if they still believe there’s some perfect design that will just be evident once they see it or come up with it themselves.

One of the most common things we hear from people who don’t understand how to discuss and evaluate design are comments like "it’s confusing" or "it sucks." That usually just means they don’t immediately get it, which is a fair observation, and useful as a data point. But if they had critical design skills, they could find specific things to point out that are both working and not, good and bad, or at the very least, convey this as their personal experience as opposed to some universal truth.

This is the trap engineers fall into when trying out user interface or game design on their own, and why the negative reputation is somewhat, though not intrinsically, deserved.  It looks easy. You’ve seen some great examples, and some terrible ones. But understanding why those examples work or don’t is just the first step to doing it right yourself. It takes deep discipline and experience, and a commitment to better understanding your customers and how they work, as opposed to the hardware they use.

When it comes down to it, it’s really not rocket science. It about problem solving and communication, which is ultimately what engineering is all about.

The point of this post is not to document that language of design, since that’s a much bigger topic than for one blog post, and I’m always learning more of it myself. The point is for us to collectively take a minute and think about why we run into the same issues again and again, and to start doing something about it.

Tags: Articles //