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.)

(In case anyone outside the US reads this: the DMV is the Department of Motor Vehicles, the place where you have to go to get your drivers license renewed or replaced, get an ID card, and other such licensing requirements for vehicles.)

The DMV sucks. Every one that I know hates it, hates going there, hates standing in line for hours and sitting on the floor and being grumped at by unlikeable government serfs. I have a bad habit of losing my wallet (the current record is twice in one year), and every time I have to go to the DMV to get my license replaced, I get a feeling of dread. It is a thoroughly unpleasant experience, and one that people hold up regularly as an example of government incompetence.

So what could be done to change that? Just for fun, I’d like to invite you to join me in brainstorming how you would change the DMV to make it more effective and less miserable. (Leave a comment with your ideas!)

I think I would start by listing the common reasons that people go to the DMV, and then I would run some time studies on each category of task, to gain a thorough understanding of the time required to complete each type of task. For example, taking your initial drivers test is going to take a lot more time than getting your address changed.

I would use the findings of these studies to create an online reservation system with a pleasant, simple interface, where people could indicate what they needed to do and sign up for a specific time slot to come in. The system would allocate appointments to workers, based on the length of time needed for each task (with some extra built in). And — this is the key part — I would build into the system a feedback mechanism where the DMV employees could indicate when they finished each appointment.

This way, if things started to back up and run late the system could a) reallocate appointments to other workers who might have extra time, and b) send people text/email notifications, like airlines do when a flight is delayed. There could even be an iPhone app where you could check your place in the queue, find out whether your appointment was likely to be delayed, and reschedule if necessary.

My motivation with this redesign is to tackle what I see as the biggest point of pain, which is the interminable waiting (often measured in hours) and the powerlessness of not knowing what time you’re going to be seen. My system would provide better feedback to the user, allowing them to make better use of their time; and it would benefit the employees too, because they wouldn’t be dealing with huge backups and angry, disgruntled customers all of the time. (And of course the scheduling algorithm would take into account lunch hours, breaks, and vacation days.)

In order to accommodate the constituency that doesn’t have internet access, there could be scheduling kiosks in the DMV lobby, where people could come in and make their appointment. That way at least they could leave and do other things while waiting.

Of course, the real-life DMV is a government monopoly and therefore has no incentive to change. But it’s fun to think about how much better things could be, if they decided to leap into the 21st century.

[Update: Hey, it looks like California and Florida actually have online scheduling systems. Good for them! Although they still don't provide the granular level of feedback that I think would be ideal.]

Meta: I’m going to be posting these redesign exercises occasionally in this blog. Sometimes it’s fun to brainstorm without real-life constraints, and to look at a broken system and think about how it could be improved.

I would like to invite you to participate along with me, in the comments. What do you hate most about the DMV? How would you change the experience, if you could?

[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?