Designers that code: a response to Jared Spool

In his blog post entitled “Why The Valley Wants Designers That Can Code,” Jared Spool points out that designers who know how to code can be enormously valuable, specifically to Silicon Valley startups. These “super designers” bring two people’s worth of skillsets to the table, plus role flexibility. And that means happiness for everyone!

As usual, Jared is basically correct (though I can’t answer for Silicon Valley, since my clients are mostly East Coast). But the reality is complex. I think that in his brevity, he glossed over some issues that can make this dual role very difficult and painful.

The part wherein I agree with Jared

Yes, of course having both design and coding skillsets is valuable! I’ve made a career out of that concept, and I wouldn’t want to work without either of them at this point. Design and engineering have different histories and methods, but their highest values are the same: build something useful, delightful, and high-quality. There are many reasons why coding skills are valuable:

  • A designer who knows how to code can prototype her designs quickly and skillfully, with a broad choice of tools.
  • A designer who codes can keep the ultimate end in mind during the design process. How easy will this be to implement? What tools are available to implement this interaction technique? Does this aspect of the design require too big an engineering investment to even consider at this point? Code-level technical knowledge can help you understand images and video better, which I’ve found useful.
  • If you can build your own designs, you can see that design through to implementation while maintaining your design vision. There’s nothing “lost in translation” when you try to communicate your design to the coders. (Good communication artifacts and skills help, of course, but it’s still time-consuming and fraught with potential mistakes.)
  • If you still need to hand off your work for implementation, communication with engineers is easier if you know the materials they’re working with. Informal conversation and hanging out can be more fun, too.
  • The “self-improvement” reason to learn to code: everything you learn changes your brain. As you learn more about writing software, you start to look at software products differently and with more depth. You learn to think in terms of abstractions, functions, parameters, components, frameworks, object classes, templates, latency, etc. Your thinking may get more precise and nuanced. And as you practice debugging, your overall problem-solving techniques will improve.

And finally, yes: hiring managers do like candidates with multiple skillsets. Who wouldn’t? But there’s a big problem with that.

The first “but:” coding considered more valuable

This seems so wrong, but it’s been true for me — organizations often value coding skills more than design skills. And when that happens, and you have two skillsets, which one do you think will get used more? Yeah.

The hiring manager may like having a dual-skillset person, because of the flexibility it gives the team. They may even pay you more. Yet in my actual experience with a dual skillset, I ended up spending lots more time doing coding than design, often due to the non-creative efforts — debugging and refactoring — that eat up lots of engineer time.

I also found that heavyweight interactive software tends to require large and heavyweight engineering efforts, especially when compared to the time it takes to design their interfaces. Now, I’m not talking about tiny websites and agile startups here, I’m talking about major software with hundreds of thousands of lines of code. (Or millions, in some cases.) All custom. To keep something like that running well, engineers need to spend serious time designing and building the software itself. And when you have lots of pre-existing users, you can’t break backwards compatibility when you go in and add stuff, so that adds yet more complexity.

To a large company with products like this, engineer time tends to be more valuable than designer time. That’s how the product gets built. Yes, user interface design must be done well, with a correspondingly careful effort — but in the end, design took up maybe 20% of my time on projects like that, while the remaining 80% was all coding (often debugging, often with other people’s code). Not my idea of a fun time.

Here’s another problem with the larger companies. What does your job title say? More to the point, what will you get evaluated on at review time: your design efforts, or your coding efforts? I’ve never seen both weighted equally. If you want to go this way, work it all out with your manager before you jump in. What do you want to spend your time on — design or coding — and how can you best bring value to your employer? How will your manager help you balance the conflicting demands on your time?

Even in a much smaller organization, your “coding” skillset may ultimately be valued more than your “design” skillset. In my experience, it’s not because people don’t value good design per se; it’s because that website just has to get built, and if you’re the only one who can build that fancy new page layout someone requested, that’s what they’ll ask you to do. And they may not come to you with minor design problems, since you’re busy coding. Habits form. Next thing you know, you’re not doing design much anymore.

So, it’s possible to be seen as both a designer and a coder. But it requires very, very careful management of your personal brand. Set expectations clearly, and defend your personal boundaries — if you’re doing more coding than you like, you’ll have to decide when and how to push back or ask for more design responsibility.

The second “but:” software engineering takes time to learn

Now I’m going to be a snob. There’s coding (HTML/CSS/JS, using JQuery to create modules on a page, prototyping, etc.), and then there’s coding. Software engineering, that is. It’s an art, and a craft, and somewhat of a science, and it’s something you can spend the rest of your career learning and never reaching the fluency, speed, and wisdom that the real masters possess.

…Actually, that’s a false dichotomy. There’s a nice continuum between them; you can dig ever deeper into the languages and tools that a designer ought to know, and the more you learn, the better you’ll get at what you do. Find your happy place on that continuum.

The thing is, it takes a long time to build up these skills and mental tools. They take practice. And many concepts are genuinely difficult to learn, evading all but the smartest engineers. Here’s what an experienced senior-level software engineer knows and has done:

  • They’ve used many languages and frameworks, to the point where everything “new” looks vaguely familiar.
  • They’ve worked with many tools — development environments, editors, debuggers, interpreters, compilers, build-and-test systems, code generators, databases (and again, after a while the new things seem like remixes of old things).
  • They understand the subtleties around threading, pointers, memory management, order of growth, exception handling, recursion, the problems with instrumentation, and other things that can trip up a naive engineer and cause software to Just Not Work Right. These concepts endure across decades and languages. (They’re quite useful to know, so if you want to make yourself more valuable, they’re great places to start!)
  • Likewise, they’ve learned well the enduring concepts behind software creation — software architecture, defensive design, API design, object-oriented class design, self-documenting code, iterative or agile or test-driven development, optimization, refactoring, debugging, testing, and general software upkeep.

So there’s lots of good stuff to learn before you can create production-quality software systems. But here’s what I worry about: it takes years to learn it well, and this is what a lot of good software engineers do for 50+ hours per week, building knowledge and picking up new skills. Practice, practice, practice.

Hey, designer. Can you afford to invest those years?

(“But you did,” you might say to me. Not exactly. I learned that stuff straight out of college, and then I slowly moved into UX design, so I didn’t need to make the choice to stop practicing design while I learned engineering. Not sure I would do that if I’d started right out in design.)

Coding? Oh, sure. That’s absolutely worthwhile for a designer to pick up. I highly recommend learning as much as you can about HTML/CSS, Javascript, Actionscript, Flex, PHP, Ruby if you need it, Python… all good! Build things, experiment, prototype the hell out of your designs, produce professional-quality CSS, debug lots, read and think deeply about program design. Just don’t — and I say this gently, not accusingly — don’t fool yourself into thinking you can produce a substantial, high-quality, stable, enduring software system without either being a serious professional engineer or collaborating with one.

If you’re a designer who want to learn “real” software engineering, and you understand the opportunity costs to your design career, then go for it! You’re in for an adventure. Go forth, learn, increase your professional value tenfold, and make the world a better place.

If you don’t, and you would rather just code prototypes and create excellent HTML/CSS pages, then no one will hold it against you. Certainly I won’t, and I bet Jared won’t either. :-)

News Streams and email trouble, Part 3

(Part 1 and Part 2 preceded this, but you don’t need to read them first.)

When my son turns sixteen or so, there are a few things that I’m going to teach him directly: how to drive, how to manage personal finances, and how to handle email and social media effectively.

I want to teach him skills such as:

  • How to choose what messages needs prompt responses, and what should be deferred until later
  • How to use available tools to organize his incoming News Stream content
  • Why and how to archive material (and when not to)
  • How to maintain an appropriate digital persona, and what might happen to it
  • Self-restraint when dealing with online entertainment and fluff content
  • To attribute positive intent in online conversations, and cultivate good relationships
  • How to recognize scams and spam

What? He’ll learn all this himself with no help? From the evidence of the grownups around me, no, I don’t think people learn it all that well by themselves. In fact, I think it might be quite hard to learn.

Besides all the issues I mentioned in Part 1, consider what basic email usage looks like to a typical non-technical person. I mean, the really basic stuff. You have to learn so many little details: per-message functions, text editors, attachments, subscribing and unsubscribing, To and CC and BCC, email addresses, contact lists, etiquette rules, error recovery, spam, sorting, searching, filtering, and the whole model of what email is and how it works. Facebook introduces another set of models for message handling, privacy, and social interactions. Twitter, forums, blogs — yet more. And for more fun, they’re interconnected!

Just learning how to use two or three of these personal News Streams is a real hurdle for many non-technical people. And we expect them to figure out, on their own, the subtleties of using them effectively? That’s crazy. I’ve seen plenty of very smart, technically adept people tie themselves in knots as they try to cut back on email time and effort. I sure don’t expect a 16-year-old with still-developing executive functions to just “get it.”

So let’s teach it! Effective News Stream management is a life skill that benefits many people as much as driving does. Email and social media help people do their jobs. They help support their personal lives. Misused, they can cause terrible misery, by way of bullying, interpersonal misunderstandings, and privacy violations. And though getting through our daily pile of email and social media is often a chore, it can also be a source of profound enjoyment and personal connection.

We designers should be thinking in those terms. Not necessarily “design for the lowest common denominator,” because that implies a kind of value judgement on the users of our products. Try this instead: “design to help people feel competent, and to become even more competent.”

Maybe that means recognizing that some things are fundamentally hard, and that we should organize the larger social and learning systems around them accordingly. So be it.

News Streams and email trouble, Part 2

(Read Part 1 first, if you’d like.)

The last point of Part 1 was that good executive function, or lack thereof, lay at the root of many troubles people have with News Streams. We designers don’t have any control over that, and we don’t have the right to expect users to change. But we can control the design of the News Stream tools that we work on — email clients, Facebook, Twitter, RSS, and so on.

So how do we design these tools to help people avoid or mitigate the problems listed in Part 1?

Keeping up with the stream: the impedance-matching problem

One problem was: “The frequency of a source’s messages may not match its personal importance to me.” Like many people, I’ve solved that by redirecting high-frequency, low-value mailing lists out of my main inbox and straight into separate folders or archives — separate streams, essentially. Then I only look at those streams a few times per week, and I pick and choose what to read, ignoring or deleting the rest. My inbox is now “quieter” and has a better signal-to-noise ratio.

Email clients usually offer filters for doing that. But they’re not always easy to use; they’re fiddly, and they tend to break if you give them slightly wrong information about what messages to redirect. I wish filters were easier. Or automatic. I don’t quite know why my Mac Mail client can’t recognize that a lot of my messages come from an easily identified mailing list, and ask me if I want that one filtered.

As for channels other than email, Facebook used to allow users to separate their incoming stream by lists of friends. I have at least ten friend lists. It used to be that if I wanted to see the status updates of only my work friends, for instance, then switch to those of only my family, I could do that. Facebook got rid of this mechanism a while ago, though, and I resent that loss of control. On the other hand, RSS readers generally provide good tools for separating the incoming stream (deluge?) into user-defined categories.

Just off the top of my head, here are some design possibilities for redirecting incoming messages into secondary streams:

  • Categorize them on what basis? By source (e.g. a single mailing list or a single friend’s status updates), by message rate, by topic, by social group, by importance. What else? How do these combine?
  • Are these other streams hierarchical — like nested folders — or flat? Are they Gmail-style tags, where any message can get any number of tags, or are they more like containers, where a message only goes into one secondary stream at a time? I love Gmail tags, personally, but they still don’t work well for people with a “folder” mindset.
  • Automatic vs manual. How much filtering work can the News Stream tool do for the user? If it’s mostly automatic, how accurate can it really be, given technical constraints? That’s easy for identifiable sources like “From” addresses and social media identities. It’s not so easy for softer categories like topic or degree of importance to the recipient.
  • It sure would be nice to share my most common categories across my News Stream tools. Work, family, gardening, parenting, local issues — do I really have to redefine these everywhere?
  • Reminders to read an ignored stream. There are some low-traffic mail folders that I just forget to read for a while, and then I have to spend a lot of time catching up. Sometimes I miss time-sensitive things altogether. I kind of hate that.
  • Using Multiple Workspaces to read multiple streams side-by-side, when the situation calls for it. I love Tweetdeck because it does that so well. I can split up my Twitter stream by topic (or hash tag, or whatever), and watch its four columns display four incoming streams separately. Magically, this makes interpersonal Twitter conversations more coherent and easy to follow.

Acting on items: flagging, to-do lists, and reading later

Here’s another problem from the previous post: “The items in my single inbox stream have diverse meanings and consequences.” Some need immediate responses, some later responses, some none; many items should be archived, but others can be deleted. I have to make triage-like decisions about them all the time, as they come in.

Flagging or starring items is one way to cope. I use flags as a “deal with this ASAP” marker, though other people may use them for different reasons. And on Mac Mail, that’s all I’ve got! Having assigned flags a certain meaning, I have no other markers for other meanings — I’d love to mark some messages as “read this sometime soon,” for instance. Then I could easily scan my inbox and find those messages when I have time to read them this evening. In short, I want more flag types! (User-invented Gmail tags work well for this purpose: “todo”, “read-soon”, etc.)

To keep my inbox quiet, I sometimes move a content-rich message or item into an archive for later perusal. Maybe I never get around to it, but at least I can search for it later. (Good search facilities are, of course, critical; I’m sure you designers don’t ignore them.) Meanwhile, Facebook and Twitter’s “content-rich items” tend to be URLs. I still don’t have a great read-it-later mechanism for URLs, though I keep meaning to look at Instapaper for that.

Some email systems offer formal support for transferring email messages into a to-do list (or creating such a list from email messages themselves). These never quite caught on for me, but they work for many people. I would love to be able to easily set up a timed reminder to myself to deal with a stack of flagged messages, though. I can find other tools to do that, but why can’t my email client do it?

Getting rid of unwanted message sources

Another problem: “Some of us have trouble getting rid of sources from our news streams.” This ought to be easier than it is. Mailing lists should be drop-dead easy to unsubscribe from (and some are, to be fair). And vendors, don’t be evil; let people opt out of your marketing email easily!

Facebook offers a way to hide people from our news stream without actually unfriending them. I see this as socially valuable because we generally avoid offending people. I don’t actually want to unfriend that person I met at a conference last year and barely know, even if I don’t want to see all her status updates, six times a day. And I sure don’t want to unfriend Uncle Bob and cause a family drama! (Not really. I don’t have an Uncle Bob.)


  • Are there ways to present Alternative Views of a large email inbox, or a busy Twitter stream, or a voluminous RSS feed? Could we use innovative information graphics to manage these streams better? Various products have tried through the years, but I don’t think anything has really caught on. Why not?
  • Sorting and searching mechanisms — generally, ways to find specific messages — are of spotty quality across News Stream tools. My Mac Mail client is okay at it, not great. Gmail is better, though it should show more search results per page. Frankly, Facebook sucks at it; I wish it didn’t, because I sometimes like to go back through a stream (either my combined friends feed, or a specific person’s feed) and find an item that I know I’ve seen sometime recently.
  • Capacious and well-organized archives really help with a lot of tasks, including searching. It also takes a burden off of me: when I read Gmail, I almost never delete anything, and so that’s one more decision I don’t have to make at triage time. (Of course, I recently achieved the honor of actually running out of Gmail space, so take that for what it’s worth.)
  • Threaded conversations engage readers better. Again, we are social beings, and conversations among people we know and like can be deeply rewarding for us to read or participate in. (If we don’t like them, these conversations can be highly entertaining.) So support rich conversations! Twitter, I’m looking at you.
  • Speed matters. If I can blast through a block of 50+ new email messages or RSS items quickly, with no perceptible system wait in between, that keeps me “in the flow.” I’ll save time and have more fun.

One last point: Different News Stream mechanisms match up well with different kinds of sources. I check in with my various News Streams at different rates. My Twitter feed? Frequent — if I wait too long between updates, I’ll miss things! My home email? Not so frequent — I know email can usually wait a few hours, and they don’t come in as often as tweets anyway. Gmail — in between, because I use it for high-volume mailing lists that I want to cherry-pick, archive, and occasionally search.

Given that, I don’t mind going to different touchpoints (apps, devices, sites) to gather all this content. In fact, when many of them were all temporarily funneled into Google Buzz, I didn’t find it appealing. For me, Buzz ended up being mostly a Twitter feed, with a few other types of updates scattered and lost among the numerous tweets. I went back to my usual multiple-touchpoint way of working.

Well, I think I’ve written more than enough for now. I have one more thing to say, but that should be in a Part 3.

News Streams and email trouble, Part 1

In the last post, I went on at length about Picture Managers. At the end, I mentioned that Instagram is functionally a News Stream, not a Picture Manager, even though its medium is photography. Its purpose is not to curate, but to share what’s new via a time-based stream of content.

That’s a News Stream in a nutshell. And like Picture Manager, you probably know exactly what it is, even though you may not have put a name on it. A News Stream application or site delivers a stream of current content to its users, with the latest at the “top.” It’s a big and ever-growing list, in reverse chronological order, of items from (usually) multiple people or sources. It serves the drive-by user, the casual reader with a wide subject interest, the Twitter user who wants to retweet an interesting story, and anyone who reads email.

(You can read the News Stream pattern if you’d like. It’s one of the new patterns in Designing Interfaces, Second Edition.)

These are some of the News Streams I use regularly:

  • My “home” email
  • Gmail, for certain high-volume mailing lists
  • Facebook
  • Twitter, via multiple clients on desktop and mobile
  • Assorted blogs, general news sites, special-interest news sites, etc.

For now, I want to focus on the personal types of News Streams: email clients, Facebook, Twitter, RSS readers, and other streams in which users assume direct control of what and when they read. We choose what to put into these streams, and we use them like lenses — to collect, combine, and focus the vast amount of digital content of interest to us into one small place. In fact, I have a hunch that most people see the Internet through these lenses most of the time. We collectively spend a heck of a lot more time on Facebook than at most other popular websites, for instance, and we reach a lot of external sites by following links that people send us in our News Streams.

In short, these streams are really important to our experiences of the digital world. But I don’t think we’re collectively very good at using them.

This is a hunch, too, and I wish I could support it with real research and not just anecdotal observations. Still, it seems to me that email alone bedevils a lot of people. And not just infrequent users, either — the most intelligent and competent software engineers I’ve worked with have trouble coping with a high volume of email. They have trouble sorting it, tagging it, archiving it, purging it, keeping track of important messages, responding to them, converting them to action items, keeping their inboxes down, and simply spending an appropriate amount of time on email — not too much, not too little. For many of us, email is a beast that threatens to eat up all our productive time. And for me, at least, Facebook’s no better.

(Another anecdote: I informally polled some of my friends about their older children’s use of email and social media. I asked them how old their kids were before they could manage and administer these personal News Streams effectively. The answers I got were frequently jokes: “Never.” “42.” “At least 38, but I’ll let you know when I get there.”)

Why is it so hard?

We don’t want to miss anything. Many of us are terminally curious. So we overload ourselves with sources: mailing lists, social media connections to friends and family, news outlets, causes, blogs, podcasts, vendor programs. All that stuff comes through our lenses and gets combined into one concentrated, fast-moving stream. I know I have trouble coping with it already, and yet when I find another source of useful information — or, say, another group of old friends that I didn’t know was on Facebook — I happily subscribe, knowing I’m adding to my daily burden. Whatever. I want that knowledge or connection, and I honestly don’t think much about the cognitive price.

We aren’t good at ignoring attention-getters. Hey, look at the title of that email that just came in: “Killer Compost!” I have to go read that now; excuse me. . . . Okay, was that email more important than writing this blog post? No, but it was entertaining and I learned something. It could have been put off until tonight, though. As always, the fun things distract us from the important things.

The items in my single “inbox” stream have diverse meanings and consequences. I mean, take a look at all the different types of email messages that I get, and the different actions and decisions that might arise from each type:

  • Personal messages. I tend to not delete these, and often they need thoughtful responses, in which case I feel obligated to respond promptly.
  • Action items. These get converted to items in my to-do list, and some require prompt attention. Sometimes I need to keep these messages around for archival, sometimes not; often I don’t know which it will be until later.
  • Responses to my own messages or posts. These might result in action on my part, or I might need to respond to them in turn.
  • Time-critical news of personal or professional import, such as local real-world events (the preschool is letting out early today) or news about a client or vendor that I use (like connectivity problems with an ISP).
  • Deeply involved conversations among people I care about. I may get involved in these conversations, or not, but I want to read them in any case.
  • Articles, well-written posts on a topic, question/answer threads, and other information that I keep around for future reference. They don’t need to be read now, but I may read them later.
  • Entertaining news, humor, and other lightweight items. Again, these can be postponed, though I occasionally need a mental break and read these as they come in.
  • Receipts and other noncritical ecommerce-related notices. Important to look at briefly, then archive.
  • Ads and sale announcements. Mostly I barely even look at these, but very occasionally, I act on one of them.
  • Spam.

Email isn’t the only channel for these, either — Facebook now serves both my personal and professional needs, and so does my Gmail account. Usage evolves unpredictably. Anyway, each item needs to be triaged, which means classifying it according to this list (more or less) and deciding what to do next with it: read now, read later, respond now, respond later, act, tag, move, archive, forward, star, delete, postpone a decision, whatever. That’s a big cognitive burden, when you sum it up over all the day’s messages. But it’s made harder by the next problem…

The frequency of a source’s messages may not match its personal importance to me. I might get fifty messages a day from mailing list A, five a day from list B, and one a week from list C. What if list A’s messages are far less interesting than the others? That doesn’t matter — the list fills up my inbox relentlessly, claims my attention and time, and swamps the more relevant messages from the other lists. That’s a problem. Likewise for other media, especially Facebook and Twitter — some Twitter users that I follow produce two orders of magnitude more tweets than others. And on Facebook, I once “liked” Mashable because I really do enjoy some of its articles. But it flooded my Facebook stream with eight to ten posts per day (more at one point, I think). So I dropped it. Sad for me, but sadder for Mashable if they lost a lot of followers that way.

We are social beings. When someone we know and trust takes the time to send us a message, we pay attention. If a friend sends me a link to an article about hilariously overpriced kitchen appliances, for instance, I’ll tend to follow that link, so that I can read what my friend is reading and maybe respond to him. (See the “Personal Recommendations” pattern in Designing Interfaces.) Social modeling plays a part, too. If we’re involved in an online community that follows a strong pattern of social interaction — like immediate short responses to Facebook posts — then we’ll tend to follow suit, even if it takes our time and attention away from other items in that news stream. Finally, reposting or retweeting something to our followers is a fun way to get attention, and we tend to do it immediately upon reading something worthwhile.

Some of us have trouble getting rid of sources from our news streams. Unsubscribe, unfollow, unfriend — all very unhappy words! And they sound so final, don’t they? Even when we get past the negativity and decide that a source really isn’t worth our time anymore, we need to make a special effort to go and unsubscribe. It may be hard to figure out how, or it may not work, or it may require a password that we don’t remember, or we realize that we don’t want to offend someone, or we may decide it’s easier to just ignore that source right now rather than drop it entirely.

It’s easier to read a News Stream than do actual creative work. If I’m having trouble getting into a flow state on the work I should be doing, then I can always catch up on email and Twitter and pretend I’m being productive, right?

Really, it’s remarkable that anybody gets anything done when email and social media are involved.

To close this first part of a two-part post, let me point out one of the root causes of these problems with digital News Streams: executive function. It’s a set of high-level cognitive skills that develops in our late childhood and early adulthood. We have varying degrees of talent and maturity in this area, which means that we vary in our ability to plan, meet deadlines, keep track of things, multitask, ignore tempting stimuli, stay on task, form good habits, break bad ones, and generally manage our attention and time effectively. If I practiced certain EF-related skills, then I imagine I could get better at managing my own News Streams!

But as a designer and maker, I have to meet people where they’re at. Not everyone is good at executive functioning, and it’s not my place to require users to be good at it, nor ask them to get better at it. So that leaves us the other root cause of this laundry list of problems: tool support.

My next post will talk about the design implications of News Stream management. With some idea of what the problems are, how can we design tools for people to handle their email and social media effectively?

Notes on Picture Manager

One of the first new patterns in Designing Interfaces, Second Edition is Picture Manager. You’ll find it in the second chapter, which is about the information architecture of apps and sites. The chapter describes application archetypes or organizing principles such as News Stream, Wizard, Canvas Plus Palette, and Dashboard.

I found the Picture Manager concept interesting because it is so well-defined — everyone can identify one or more Picture Managers that they’re personally familiar with, and those of us who use them tend to have strong expectations for certain features and behaviors. (Personally, I find it hard to imagine any serious tool for managing visual objects that doesn’t more or less follow this pattern. Maybe a more inventive designer can.)

Here’s some of the functionality we tend to expect from Picture Managers:

  • We want an overview of our collections of pictures (or videos or other artwork, as the case may be). Usually this manifests as a grid of thumbnail images, which lets you see a lot of them at once. If we don’t actually own any items, as with TED or a museum site, then we expect to see a gallery of interesting items that we can browse.
  • We want to drill down to individual pictures or videos. Those single-item views are where we expect to find metadata — date, author, etc. — along with editing tools, social sharing, comments, and links to previous and next items in the lineup.
  • We want to browse and search. What’s popular right now? What’s got this keyword or tag? Can I see all the pictures with Aunt Judy in them? Where on earth did I put those pictures from Italy? What’s in this directory over here?
  • We want to manage the items that we own — add new ones, categorize or tag them, reorder them, edit their metadata, make them private or public, or otherwise enrich them in various ways that make them more interesting to ourselves and others.

Lots of familiar apps and sites work this way: Flickr, YouTube, iPhoto, SmugMug, Adobe Bridge, and so on. Some are public, some private, some both; but they all fit the pattern. Their different characters arise from how these features are manifested. TED’s home page, for instance, uses a variable-sized thumbnail display to show the videos matching the current filter — an interactive visualization within a Picture Manager! Nice. Clicking on one brings you to a single-video view, as one would expect. Doing otherwise might startle or puzzle a viewer.

(If you haven’t read the pattern yet, you can read it here. At least look at the pictures. Go on!)

Anyway, when writing the pattern, I found it instructive to compare the interfaces of iPhoto and Adobe Bridge, which is a photo organizer bundled with Photoshop and other costly Adobe products. Both organize your photos, but their designs are radically different in certain ways. iPhoto must be usable by all Mac users, regardless of their technical prowess, and the interface is ruthlessly simple for most of its features. I used it for a while, to manage my (large!) personal photo collection. But it lacks certain functionality that I want, and it’s had problems with scalability. I now choose not to use it.

Adobe Bridge, on the other hand, is a serious tool that must scale up to the needs of professionals. It’s complicated. It requires a lot of screen space, with its countless tabs and panels and tables, and it imposes a high cognitive load at first; it took me a bit of thought and twiddling to figure out how to use it best! But after I climbed the learning curve, it was better suited to my needs than iPhoto, especially since I spend a lot of time in Photoshop. I just needed its scalability and features. (I still wonder if a designer somewhere has figured out how to make an industrial-strength Picture Manager with a more graceful interface.)

Two audiences, two designs, but one pattern at the core of each product. So far, so good.

And then I signed up for Instagram.

Oh, it manages photos, all right — you create them, modify them, store them, share them, browse through other people’s collections. But it’s not really a Picture Manager. It’s a News Stream.

Say what? you may ask. Well, if you’re a user of Instagram, think about its purpose. It’s not trying to be Photoshop. It’s not trying to be Flickr, either. Its whole point is to share pictures instantly, and to build up a one-dimensional timestream of photos that communicate what’s new, not what’s past or what’s best. So far as I can tell, you can’t even see a Thumbnail Grid of your own past photos, let alone your friend’s — other than tags, you certainly can’t do much curation of your image collection. It’s a Twitter for photos.

…Which is fine, of course, and its users seem to be quite happy with it! I use it as a counterexample to Picture Manager not because it’s “wrong,” but because it casts a sharp light on the boundary between Picture Managers and other types of applications. Picture Managers seem to be appropriate for collections that are large, varied, complex, and that need to offer access to the “deep catalog” and not just the latest items. Picture Managers are browsing and curation tools for various media and audiences. Their designs are optimized accordingly.

In the next post, I’ll talk some more about the News Stream pattern.

On UX, amateur design, emergence, and a changing world

On Sundays, I often make time to read or listen to thought-provoking essays and talks. Yesterday I got not one, not two, but three of them that collectively knocked me to my knees.

First, Cennydd Bowles’ closing plenary at the IA Summit made the point that user experience (UX) has finally reached the mainstream. We designers don’t own it anymore — everyone who builds products and websites is responsible for the user experience. Most of those people now understand the value of good customer-centered design, and how to create it, when ten years ago they may not have. Furthermore, things are changing in the world: in 2011, people expect their digital artifacts to be ubiquitous, connected, empowering, and to serve their needs. He says, “A great deal of the world will have to be re-engineered around the needs of communities and citizens. We can be central to this movement; in fact, I’d say it’s our moral obligation.” Amen.

Second, Studio 360 reposted an interview with Christopher Alexander. (An architect and philosopher, he’s the one who started the whole patterns movement with his book, A Pattern Language.) While I wish the short podcast had more of Alexander’s own words, it reiterated for me one of his core ideas — that non-architects can pick up and use these pieces of design to create humane, local, unique designs that suit their way of living. They don’t always need architects. And their built environments should put their needs and hearts first; not business interests, not governments, not trendy design ideas.

Third — and I’m sorry, but you can’t find this one online! — I attended a spellbinding talk by Phyllis Tickle, the founding editor of the religion department at Publishers Weekly. Okay, it had nothing directly to do with design. (shrug) But a few of the themes she touched upon resonated with these other two talks in remarkable ways. She sees a worldwide emergence of religious believers who are increasingly diverse, connected, community-based, unwilling to quietly accept hierarchical or top-down control, and perfectly happy to construct their own experiences that meet their spiritual needs. Oh, it all sounds very familiar…

Humane. Customized. Unique. Bottom-up. Suited to the local environment. Connected to other people. Self-designed and constructed; we don’t need the experts for everything. Is this where digital design is headed?

Honestly, I don’t see how it could be otherwise.

When I wrote Designing Interfaces, I intended it to be used by non-designers more than professional designers. The pros already know all that stuff, but in 2005, most software engineers and product managers didn’t. Happily, many of them now do! At Google, for instance, the engineers I worked with were quite aware of UX principles and techniques. Some of them produced excellent designs without the direct help of UX specialists. And that’s good. There’s still a role for skilled professionals, and there always will be, but seriously, we can’t do all the design work that needs doing — there’s too much of it!

Now I’m seeing laypeople create good design, too. I suppose that’s the next frontier. But let me pull in the themes above: specifically, what does it mean for people to design or modify their own digital habitats?

  • It means excellent digital support for the things that nurture our hearts: family photos, videos, friends’ blog posts, personal emails, and other items that mean a lot to us personally. We should be able to put them into secure places where we can find them, enjoy them, respond to them. And create them, of course.
  • In a related vein, we want to be able to find stuff easily, whether in the cloud or our private devices. We need organizational models that make sense, that scale well, and that remain stable over time. We need repositories that are easy to search, and tools that are robust with respect to where documents come from and what format they’re in.
  • We want to choose who we connect with online, and to easily keep track of those conversations that are going on now. Who’s in our digital social circles? When and how often do we hear from them? How often do we feel compelled to respond, and does that end up being a pleasure or an unhealthy compulsion? How can our social tools — email, Facebook, Twitter, etc. — help us manage that so that we’re gentle to ourselves and others?
  • We want to know what’s going on in the world, with more truth and less bias. How and when do we find out about stuff? We choose between “tell me when it happens” (push) and “let me seek it out” (pull), and maybe we want more control over the source and medium of our news. (I hate news videos, personally; give me an article or transcript anytime.) And we don’t like being deceived. How do we assess the authenticity and truthfulness of our news sources, so we can make intelligent choices? How do our social circles influence all this?
  • Entertainment. Yeah, that’s a big part of our online lives. Again, how, when, and where do we choose to “waste” our brains on stuff that makes us happy (or riles us up)? There are some things I’d rather see on a large screen than a mobile screen, for instance, but if the mobile app supplier doesn’t have a rich web presence that I can find, then I’m out of luck. Or vice versa.
  • Low “friction” for necessary chores. I pay my bills online, and it’s better than the paper alternative, but it’s not exactly fun; the quicker and simpler it is, the better. Likewise for online shopping. I’ll pick stores and services that offer the easiest experiences, and I’ll do whatever is needed to make it even easier (within reason).
  • Control over our digital identity. What image do we project to the world? Do we use different online personas for different contexts, e.g. family versus work, and how do we manage those? Most importantly, we need strong, detailed control over our privacy. Our tools absolutely have to provide that; it’s inhumane not to do so.
  • Beyond designing our own digital habitats, we sometimes design them for others. Our children, for instance — we want their online environments to protect them, encourage them, and teach them. Our digital tools should support the important work of families and teachers.

It’s interesting that nowhere in this list does “layout” appear. Nor “color” or “typography” or “form design” or any other low-level design concept. They’re still important parts of our craft, of course, and laypeople ought to know about them. But in the end, their only real value is in how well they serve bigger needs: content, connection, self-determination, convenience, beauty.

Onward to the actual patterns! I promise to keep them in their proper place.

A pattern hunter’s work is never done

Welcome to Deep Background.

When I set out to rewrite Designing Interfaces, I expected it to be easy. I would go through the patterns one by one, assuring myself of their enduring value (or lack thereof). I would go forth onto the web and find new examples of those patterns in the wild. I would update the look of the whole book, both with a new layout and those new examples. It wouldn’t take long!


It took over a year. What I discovered, of course, is that the web held plenty of new patterns begging to be written down. Some of those made it into the new edition. Others didn’t, simply because I couldn’t fit them into the ever-growing manuscript in a way that made sense. (I wrote an entire chapter about behavioral patterns in online communities, for instance. It was cut. Didn’t quite fit the book’s purpose.) Oh, and there was also a chapter on help patterns that never got written at all!

Meanwhile, the more time I spend working on real-life websites, the more new patterns and new examples I see. And I have more to say about how the existing patterns interrelate — how a designer should choose among alternative solutions, for instance.

Finally, the book makes it really clear that it’s not about implementation at all. That’s as it should be for a book like that: it’s about the enduring design ideas, not the particulars of CSS or Javascript that one should use to implement them. Those particulars may change every time a major browser or spec is released. Now, the book doesn’t change fast at all — once every five years, apparently. But a blog’s rate of change is far faster. So I may talk here about implementation techniques that I use for some well-known patterns.

Here’s my plan for the foreseeable future of Deep Background:

  • Behind-the-scenes explanations of the second-edition patterns
  • New patterns, and ideas for possible new ones
  • Pattern instantiations seen “in the wild”
  • Deeper explanations of how to choose among patterns and techniques
  • Implementation options
  • General nattering on about user experience design issues

What else would you like to see?