Say we’re adding a new screen to an app.

Someone has to design that. The product owner doesn’t know what kind of interaction to use for a task, so someone has to brainstorm, ask questions of end users, and write stories to capture the upcoming work.

We need to put a warning dialog on the screen under some condition; someone has to write the dialog copy.

At Labs, we don’t have specialists floating around to perform these tasks: either someone is billing on a project, or they’re not. And if there isn’t a designer or a product manager billing on the project, then the aforementioned design and product decisions fall to the consultants who are on the project: developers.

In such a situation, it makes sense for developers to learn something about the other disciplines involved in building a piece of software. I’ve decided to delve into them a bit, starting with UI design. I chose Joel Spolsky’s UI Design for Programmers as my introduction to the subject.

Why did I choose this book? It seems like a weird choice because it is short—better for getting the gist of something than learning it in detail. I’d argue that this is in fact an asset for a person’s first book on a subject. See, no one book will ever teach someone everything they need to know to master something. That comes with continued study and practice. So the very first thing that someone does to begin on that journey of study and practice should have, more than comprehensiveness, a wide margin of success. It should be hard to screw up doing that first thing—and it’s harder to screw up (in this case, stop reading) a short book than a longer book, because you have less time in which to give up.  

This book also seems like a weird choice to learn UI design in 2015 because it was published in 2001. When we design for the web and for mobile devices, it might seem odd to choose a UI design book that was published before the release of the first widely adopted consumer smartphone (long before the advent of iPhone or Android devices).

But here’s the thing: as a developer, I have always pictured a UI designer to be someone who makes things pretty: a person who chooses cool colors and rounds the corners on all the little boxes in the app. I know that UI designers do not like this generalization. Apparently UI design and “making things pretty” are different. However, I didn’t know how they were different. This book came out before cool colors and rounded boxes were a thing: every example in the book comes from either a Microsoft product released in the late ’90s or a program that intentionally tried to look like a Microsoft product released in the late ’90s. Everything is grey and all the boxes are very square. The contemporary app “look and feel” is completely missing from the book, making it downright impossible to conflate that “look and feel” with the principles that make a program usable. I understand the difference much better now that I have read about one aspect of an app’s design in the complete absence of the other aspect.

The book itself

From among the material presented in this book, two principles persist:

1. Design for people who can’t read, can’t remember, and can’t use the mouse.  

I don’t read long dialog boxes. I admit it. I also know from a previous career as a copywriter that people read short sentences much more often than they read the long ones. To design apps to this principle makes total sense. The next one also makes sense: I don’t remember my password for apps I log into once a year, and I like it to be easy to retrieve that information. The final one doesn’t apply to smartphones, except that it applies perfectly to smartphones: I cannot click on linked tiny text. I can barely type on the alphabetical keyboard. And here comes the kicker: most of the time, I hold the phone in my hand and navigate the app with my thumb on the hand that I am using to hold my phone. This makes me about as dexterous as it is possible to not be, and I love that iOS 8 lets me double-tap the home button to move everything at the top of the screen into thumb’s reach (pick your jaw up off the floor and try it). I don’t love that, when I toss the phone a little in my hand to hit the buttons in the upper left hand corner of the maps app, the phone thinks it has been rotated and rotates the screen so the button is no longer where I tossed the phone to tap it. Right now at work, I work on a scanning app for Android. I have never thought about how our design might be affected by the way the users hold the scanner, but I’ll definitely start,

2. A well-designed app asks the user to make as few choices as possible, leaving them only the choices they need to get their task done.

I have an app on my phone (Uber) that calls a car for you. It opens onto one screen. All I have to do to call the car is press a single button on the screen. I also have an app on my phone that displays the workout at my local Crossfit gym. It takes a minimum of five taps, including the navigation of a scrollbox, to get to today’s workout, which is what I want to see 100% of the time when I open the app before I have completed the day’s workout.

I can do a lot of stuff in my workout app. Actually, I can do too much stuff in my workout app. The thing I want to do is behind a lot of taps.

Spolsky recommends eliminating as many choices as possible for the user without preventing what they want to do. This makes a whole lot of sense. The danger, which he also discusses in the chapter on heuristics, comes if we make guesses about what the user wants that are wrong.When we make these guesses, we do best to make guesses that we are sure, the vast majority of the time, are right. We also do best when we make our guesses easy to undo on those few occasions when they are wrong.

The two previously discussed apps provide valid examples here, too. The car app, by default, orders a car to the place where I am located when I open the app. If I want to order a car to a place other than where I am located (say I have ordered it for a friend), then that is an easy setting to change the start location for the car on the same screen where I can press the button to order the car. On the workout app, I open it to see the workout before I do it, but after I do the workout, I want to see where I rank in the results. If I want to switch from the workout view to the results view for a given workout, I have the option of pressing a button at the top that only works sometimes. Other than that I have to reopen the menu, click a new button whose title is not “Results,” and wait while the page loads. Here a kudos is due: it does remember that I want to see women’s results and does not show me the men’s results. So that’s one checkmark in the positive column for this app’s design.

There’s another principle from the book pops into my brain as I use IntelliJ at work:

Usability tests test learnability, not usability. The two are not the same.

The IntelliJ IDE allows me to do the majority of my work without touching the mouse at all. I can use keyboard shortcuts to perform most navigation and refactoring tasks with relative ease. That said, I had to sit down with a keyboard in front of me and practice key bindings for hours before I could do these things. There are lots of options on the IntelliJ menus to do these things, but the icons are not always obvious, and I don’t know where in the toolbars most commands are located. IntelliJ, therefore, is not especially learnable, but it is extremely usable.

And honestly, I don’t consider it a weakness of the IDE that it’s not especially learnable. I don’t even know how you would make that many commands learnable without popping up 50 dialog boxes anytime someone opens the editor (IntelliJ actually has this, but it allows you to turn them off by clicking a checkbox. I clicked the checkbox a long time ago).

Activity Based Planning

The above principles are helpful for critiquing and improving an existing UI, but not for creating one from nothing. Spolsky offers ABP as a method for figuring out from scratch what a user’s workflow should look like.Take a music streaming app, for example. Instead of saying “Well, the user should be able to play music” and developing features from that, ABP involves coming up with actual activities a user might perform with the app:

• create a playlist with some of their favorite artists
• come across a song they like on a channel and save it on their own phones, or send it to a friend
• prepare for an upcoming music cruise or festival by listening to songs from the appearing artists

Pandora allows for the first of those with relative ease. The second one is sort of possible, but harder—which is okay, because it’s probably less commonly done than the first one. Sending a song to a friend I don’t think you can do. If you can, I don’t know how. That said, I can imagine, and can imagine a market for, an app that makes it easy to get songs onto your phone from a stream. I can also imagine people buying songs for friends on there and sending them to their friends’ phones by, say, clicking a button on the screen while the song is playing and scrolling through a list of contacts to whom they can message the song. I can imagine folks choosing a channel for an upcoming event (say, Lollapalooza) and getting that channel in their list like any artist or song channel. I can even imagine unpaid users hearing ads on that channel from sunscreen, vodka, and battery-operated-squirty-fan-thing companies. Those clear images and follow-on ideas come from having a specific activity in mind, rather than a task like “stream music.”

A note on metaphors:

Spolsky also talks at length about making a UI work the same as the user’s idea of how the UI should work. One way he recommends showing a user how a UI should work involves using metaphors, like the files and folders metaphor common to today’s PC. He applauds the trashcan metaphor on the original Apple computers (until it got fancified to make the trashcan look messy when it had something in it, anyway). This idea makes a lot of sense to me.

That said, the book leaves room for arbitrage on the subject of metaphors. In Chapter 4 it states that “a metaphor, even an inexact one, works a lot better than none at all.” Then, in Chapter 5, it states that “a metaphor badly chosen is worse than no metaphor at all.” So metaphors shouldn’t just get used anywhere and everywhere. Instead they fall on a spectrum that includes between “inexact” and “badly chosen,” and the value of “no metaphor at all” falls somewhere between those. Perhaps an accurate judgment of whether or not a metaphor makes something more or less clear sets apart a discerning designer. I’ll look for more specific ideas on this in further reading.