Beautiful Interfaces

For a long time I agonized over whether I was “really” a designer or “really” a developer. First I wanted to be a developer, then I wanted to be a designer, then I was a designer who wanted to be a developer, and then a developer with an interest in design.

At this point, I’ve come to the conclusion that it is completely possible to do both — just not at the same time.

Differences

Design mind and developer mind are like two different lenses or frames. They hold different concerns, have different sets of tools, and can be very different ways of seeing the world.

Design tends to be holistic, looking at all facets and angles of a thing and trying to make them harmonize. Development tends to be analytical, breaking down a problem into smaller and smaller steps that can be individually tackled and solved.

Many types of design are quite spatial, concerned with relationships between objects within a field of view. Development is often more temporal; it is concerned with changing relationships between objects over time, and with passing information through a series of transformational steps.

Design is always about ‘what’: what is the right thing to build, what does the client want, what is the pleasing solution to the problem at hand. Development is more about ‘how’: how to create a capability, and make it flexible and fast and robust and concise.

Both are important, and both are quite difficult, and both can be so rewarding when you get something right.

(Of course, these are all generalizations, with plenty of counterexamples to be found.)

Doing Both

I think the key to successfully doing both is building up your ability to switch between the two. To look at a problem as a designer, as a developer, and as a designer again. To know how to switch perspectives, and when.

Doing this can be jarring. Things that design mind really really wants might prove frustrating or impossible to actually build. Developer mind might want to do things in a logical way that compromises design mind’s vision. In fact, all of the conflicts that occur between designers and developers come up, inside of your own head! But the trick is just to keep doing it, and to focus on creating something beautiful.

When I’m working on a project where I’m doing both roles, I keep separate to-do lists for development and design. I’ll tend to work through one list at a time, perhaps design in the morning and develop after lunch. I might need to match my surroundings to my task, get away from my computer and my desk, and go someplace where design mind can make itself heard. (There are some great suggestions about how to do this in the book Pragmatic Thinking and Learning.)

It’s definitely not for everyone. You do trade away some depth for breadth, and maintaining the different skillsets can take up a lot of time. Employers may not ‘get’ you; it can be hard to find a role that exercises both minds, in a heavily specialized world. And your job title is guaranteed to always be wrong.

On the other hand, you get to have a foot in two fascinating worlds; you get to translate between two important domains; and you get to have conversations with two completely different sets of awesome folks. And sometimes, if it all works out, you might find that there’s a huge strength in being in-between, and that it lets you really impact your world.

“Designevelopers” of the world, unite!

(Here’s an example from the world of automobile design.)

[Edit: I took the word "manifesto" out of the title because I decided that it sounded dumb.]

When I think about my career and my interests, this phrase keeps coming back to my mind, and I’ve also made it the title of this blog.

But what do I mean by “beautiful interfaces” in the first place?  I think it can be summed up in 3 points.

1. Beautiful interfaces contain nothing unnecessary. A beautiful interface has no extraneous elements, nothing in it that detracts from a complete, coherent experience.  This doesn’t mean that there can’t be design elements, but it does mean that the design elements cannot be merely unthinking decoration.  Every part must contribute to the whole.  In otherwords, beautiful != mindlessly pretty.
2. Beautiful interfaces contain everything that is necessary. On the inverse of the above, a beautiful interface contains everything that the user really needs, gathered in one place and presented in an understandable, accessible manner.  Thought is put into creating flow and connecting disparate elements as necessary; the goal is to create an untroubled, uninterrupted experience for the user.  The goal is for the interface to “disappear” completely, because it works so well that it requires no thought.
3. Beautiful interfaces are backed by beautiful code. It may be possible to have a beautiful, effective interface that is created with terrible code, but I have to imagine that this is a fluke when it occurs.  Crappy code (both client-side and server-side) makes an interface slow, brittle, and inflexible.  It builds you into corners, so that you can’t respond to the client’s real needs, or to changing technical conditions that arise.  And I have seen first hand how crappy legacy code tends to hijack the concerns of the entire design and development team, such that everyone spends most of their time coddling the crappy code instead of refining the experience and improving the design (both of the UI and of the code).

I’m not saying anything new with all of this, I’m well aware.  And these are all aspirational points to me; I definitely don’t have any of this mastered.  I’m just an interested beginner who’s really into this stuff.

Life is too short to deal with ugly, tedious, argumentative interfaces.  Why shouldn’t the everyday things that we use be beautiful?