"Designing Interfaces" by Jenifer Tidwell (O'Reilly Media)

This post is written as part of O'Reilly Media's Blogger Review Program.

"Designing Interfaces" by Jenifer Tidwell combines reference and how-to in one thorough, accessible book. I keep an eBook copy on my iOS devices so I can always have it with me.

Given the title, the book could easily stretch to thousands of pages, but Tidwell does a nice job of delivering a few general intro chapters before diving into a rich collection of interface design patterns. The patterns are what make me keep this book close at hand.

Consider something as mundane as a list of items that needs to appear in a user interface. Designing Interfaces has a whole chapter devoted to this common problem, containing a host of solutions along with the rationale for when to use each one. Examples relating to lists include:

  • Thumbnail Grid
  • Carousel
  • Row Striping
  • Pagination
  • Alphabet Scroller

Each pattern is described and defined, and some good use cases are supplied as well. This is referred to as the Use when. (For example, use a Thumbnail Grid when "the list of items have small visual representations that uniquely identify them.")

Even better, each pattern also includes a Why, How and Examples of popular apps that correctly use the pattern. I see these three sections as providing value to a slightly different audience.

The Why is for an interaction designer to mull over the rationale and ensure that the problem they're solving matches this pattern. If not, they should move on and consider alternatives.

The How is more for a visual designer or front-end engineer to understand the nuts and bolts of the implementation. This is quite useful, both details that are easy to overlook and for guidance on what not to do.

The Examples are useful for anyone with a working eye, but I find them particularly effective as illustrations for non-designer stakeholders and clients to get a sense for "how it will really be." I feel strongly that you can't make progress in those types of discussions without using visuals, so it's convenient that they're baked right into the book.

Though part of me hates to admit it, the fact that the examples are mostly taken from popular, successful sites (YouTube, Zappos, etc.) means the concepts behind them are easier to pitch to clients. Everyone's got tight deadlines, and the less time spent arguing and debating, the better.

If you pull from these patterns to sell your design ideas, you'll find that having a clear vocabulary on the concepts and patterns makes you more effective. If you're doing the pitching, take a close look at the Use when and Why sections.

When you're brainstorming rough ideas for a given user interface flow, I recommend you take a moment to unpack the true problem at hand and consult a book like this for alternatives that didn't come to mind. It's tempting to rush through the ideation stage when you have a deadline, but I can say that my work has greatly improved if stop to breathe, think and realize others have likely already worked through this problem.


User Experience 101 for Developers - Dreamforce 2012

At Dreamforce 2012 in San Francisco, I lead a conference session that I called User Experience 101 for Developers. As the name implies, this session was targeted at developers with no prior knowledge of UX (User Experience). I had two primary goals for this session—the attendees would:

  1. Get a basic working knowledge of User Experience (what it is)
  2. Learn a lightweight User Experience Design process they can use to improve the next thing they ship

I feel this is relevant since the lead developer becomes the de-facto UX designer on teams with no dedicated UX practitioner.

With that in mind, here are some concise notes you can use if you'd like to refer back to something I mentioned.

What User Experience Is (and Isn't)

  • First, a visual analogy using cereal
  • It's about understanding what your users need to get done, and then adjusting the interface so they can get it done in the best possible way.
  • Keep the scope and features profitable, feasible and desirable.
  • It's not limited to any particular platform: UX design applies to standard Salesforce, custom apps powered by or any app built on Heroku.
  • It's not about fancy graphics or “jazz hands.”
  • It's not about sitting in a coffee shop waiting for brilliant inspiration.
  • As developers, you're in the best position to know what's possible, and actually make something great that people really use.


  • On a scale of 1-10, how painful was your last requirements gathering session?
  • Wouldn't it be better for the users to tell you stories about what they actually needed to get done? What’s behind that requirements spreadsheet anyway?
  • Activity: Ask the person next to you what they wanted to “make sure of” the last time they checked the weather online. What were they going to then do? Interview them, documentary style, for 2 minutes, then switch roles.
  • This works in shorter bursts, but it can get tiring for users... and they may not answer questions that well anyway.
  • Driving analogy: the user is driving though their day, doing one thing or another. They’re not processing and remembering everything they see or do. They can't really explain it.
  • Instead, “ride shotgun” with them and watch what they do. Also, notice what's on their desk and what the sticky notes on the monitor say.
  • Speaking of sticky notes, one observation per sticky is a good way to capture what you learned. Later, group stickies together that relate in the user’s mind.
  • If you can’t be in the same cubicle, watch them via a web meeting.
  • After all this, you'll have a deep, real-world understanding of the “so that” on your agile story cards. That's what you want.


  • Most requirements come from the MSU method: Making Stuff Up. Requirements are an input to the design process. Your new observations and understanding is another, and your budget is the last (main) one.
  • Take requirements as a starting point, then work up better alternatives. Reference UI Pattern Libraries, which are similar to Design Patterns in the world of coding.
  • Often times, its not that hard to come up with better interaction concepts now that you understand the user’s real goal. How much can the system do for them...can you skip or combine steps? Can you drop certain feature ideas that don't tie back to any goals? (Refer to your observation sticky notes.) What does the platform do out of the box?
  • 6-up templates are great for exploring ideas cheaply with pen and paper. Check out Dan Roam’s Napkin Academy to bone up on sketching basics. Trust me—it's not that hard, and you don't need an art degree.
  • If you want to play with ideas in higher fidelity before coding, check out Keynotopia or Keynote Kung-Fu. Different fidelities are useful at different stages of the product. (Lower fidelity early on, before things gel. Then, go higher fidelity later.)
  • Also consider platform-specific approaches (that users wouldn't suggest) like standard page layouts and VF tags in Salesforce, or UI frameworks like Twitter Bootstrap or ZURB Foundation when using Heroku.
  • After trying some alternatives, combine the best ideas into something cohesive that flows smoothly, again measuring against the user goal. Interactive Sketching Notation can be used with paper or high-fidelity renderings.
  • Speaking of flows, why not just build a prototype of the idea? That way, you can just click through the flows for real. With and Heroku, you can piece together something clickable very quickly. This is helpful if you have a more radical concept. ”Show, don't tell,” as they say in Hollywood. Ideas don't sell themselves, unfortunately.


  • On a scale of 1-10, how painful was your last UAT session?
  • UAT has the wrong connotation and implies users can reject the entire app (if they don't “accept” it), but there’s never enough time in the schedule to account for non-trivial requests.
  • Good news: since you have a much better idea of what the user actually needs, you're a LOT more likely to get change requests and surprises at this stage. It’ll still happen, but it’ll be clearer you were working from inadequate information.
  • Prepare for feedback of some kind. You’ll almost always make SOME sort of change. Nobody’s perfect. Don't worry...80% of these changes are cosmetic (according to Salesforce).
  • If you have a good relationship with the users, you may be able to show them early mockups or sketches and quickly take their temperature on an idea, even before it's fully baked.
  • If not, slowly work up to this by presenting clickable prototypes (thus building goodwill). Emphasize how users would flow through the screens and accomplish the goals you discovered earlier on.
  • If you're working with a user that hasn't been deeply involved to date, this is an opportunity for Usability Testing. Don't be a “talking manual.” Get them oriented, then see if they can complete their tasks. Make it clear you're testing the software, not them.
  • When you get feedback that doesn't seem relevant, ask how it relates to the original goal. There's a fair chance you didn't get the full story, so something important may be missing.
  • If it’s just a bad idea, say “we’ll get back to you.” Then, render it quickly and show that it's bad. Don't just tell them it’s bad.
  • Remember when you asked your partner why they checked the weather? Compare that to the Dark Sky app. How does it stack up? Were they going skiing? Were they packing for a trip?


  • Fill in the “so that” part of your User Stories by riding shotgun with your users. Only when you understand their goal will you have a starting point for your design work.
  • Start with the requirement or the obvious approach, then try at least a few other different concepts. Next, combine the best ideas into something cohesive.
  • Build prototypes and test them with users, then tweak when you find non-trivial issues. You can't beat and Heroku when you want to get something clickable out the door fast.

My thanks to Luke Wroblewski for inspiration on a lightweight, effective format to post notes from a conference session.


Instagram: beating Facebook at the job it's hired to do

By now, everyone who reads the Wall Street Journal knows what Instagram is:

Instagram's Wall St. Journal cover story

The article covers the surface level details, which (to oversimplify) are as follows:

  • Two Stanford whiz kids made an iPhone app that uploads cameraphone snapshots to the Internet.
  • The app generates no revenue, but is growing so fast that big-time VCs invested, valuing it at $500 million.
  • The founders sold the app to Facebook for a billion dollars.

Those are the key facts, though the article sheds precious little light on the subject—especially if you’re creating a product and want to replicate their success. The Journal makes only the briefest mention “removing a rival” as a possible motivation for the purchase.

Let’s stipulate that taking a competitor out of your market might be worth $1 billion and look at how, exactly, Instagram competes with Facebook.

Competing = Doing the same job

If I asked you to picture Facebook in your mind, I’d wager you’d conjure up an image like this:


The primary focus of this page is the News Feed (highlighted in yellow below), which is a stream of “status updates” posted by your friends indicating what they’re doing or what’s on their mind.

Facebook's News Feed

Having a textual description of what you’re friend is doing is great, but a picture is worth 1000 words, right? So, something like this might be more engaging:

Popular photos on Instagram

The above is a sampling of the popular photos right now on Instagram. Now, I’ll add annotations to call out some of the more interesting stories:

Popular photos (annotated)

I’d say it’s clear the concept of textual status updates is rather dry and geeky by comparison. If a friend told me she was rooting around in MTV’s archives, I’d think that was pretty cool. If she showed me some photos and gave me a real sense for what it was like, I’d be much more engaged. Also, notice that an image doesn’t have to be a photographic masterpiece to tell a story that your friends might find compelling (see cats wrestling above).

If I want to communicate to you what I’m doing or thinking about, it will almost always be more effective to show you, not just tell you. So by this logic, Instagram is not only doing the same job for me that Facebook is, but it’s doing it better.

Get better by focusing on the Job-to-be-Done

Looking at product based on the “job” it does for the consumer is a useful analysis tool for this type of post-mortem. Clayton Christensen, the Harvard Business School professor most famous for his work on disruptive innovation and The Innovator’s Dilemma, has written about this technique and will publish a book on it soon. If you’ve never heard of the Jobs-to-be-Done theory, start by watching this short YouTube video where he tells a great story about why people hire milkshakes. To dive deeper, check out the work of the The Re-Wired Group.

If you’re working on a product of your own, having a clear understanding of the job-to-de-done is a litmus test that can tell you whether a given feature is core to the user’s experience. If it’s not, consider skipping it. In the case of Instagram, by focusing on the core flow of capturing the moment, adding emotion (via filters), and sharing with friends, they were able to avoid building:

  • A full-featured web app
  • Sophisticated photography controls (exposure, white balance, histograms, etc.)
  • Grouping/sorting your photos into albums or collections

Based on what other photography apps/services do, it would be easy to say that Instagram “needed” those features to be competitive. Instagram’s founders, however, knew all they truly needed to build was a way to shoot, style and share a photo for their users to get the job done and tell the story of that moment in their lives. They could then make the appropriate tradeoffs and divert resources to polishing the smaller, core feature set into a great user experience.

The pace of business is always increasing, and Instagram used focus as a weapon to not only beat their direct competitors (PicYou, Hipstamatic, picplz and many others) but also threaten the 800 lb. gorilla known as Facebook.

What job do your customers hire your product to do?


Sketchnotes from Agile UX NYC 2012

Since I’ve been working on my sketching and drawing skills, I decided to take a page from the Luke Wroblewski playbook and share my notes from the inaugural Agile UX NYC conference. It was an intense day and I don’t have something…legible…for every session, though most of the slides are on SlideShare.

Pivot Your Culture to Win with Agile: Eric Burd

Investing in Design: Phin Barnes

Replacing Requirements with Hypotheses: Josh Seiden

Getting Out of the Agile Building: Tomer Sharon

Managing Your Malkovich Bias: Andres Glusman

Quick, Visual, Collaborative & Continuous: Lane Halley

This one’s a little thin—be sure to grab the slides if you want to go deeper.

Learning to Play UX Rugby: Anders Ramsay

The Design Studio Method: Todd Zaki Warfel

Code Literacy: Jonathan Berger

AToMIC Design: Jennifer Gergen

Demystifying Design: Jeff Gothelf


Emotional Design, Affective Computing and Social Animals

When I see Dan Saffer and Gabby Hon posting long lists of books they've read in 2011, I sink a bit and sigh longingly. Despite my rampant Instapaper-ing, I simply don't make enough time to read long-form content.

I did make it through one book last year, though, and it really stuck with me: The Social Animal by David Brooks. As a developer who's transitioned into design, I made my way through a self-guided crash course in interaction design, visual design and the like, but moving "up the stack" into understanding emotion was uncharted territory. Luckily, Brooks' book made the topic very approachable, since it's written as an allegory.

The Social Animal has many insights, but this is the one I keep revisting: every piece of sensory input a human being receives will evoke an intellectual and an emotional response. The takeaway is that you can fold this into your personal interactions and benefit, or ignore this at your peril.

Interesting stuff, right? But how do we use this knowledge to make our designs better?

Here Comes The Knowledge

Three separate pieces of work have crossed my path that address this topic:

  • Designing For Emotion by Aaron Walter is the quintessential guide. Simply put, I don't think we'd be talking about this without Aaron's work.
  • Affective Computing by Kristina Höök is a more academic take on the topic that reviews the relevant research. It's deep stuff made more approachable with video interviews.
  • Grouped by Paul Adams focuses on the social angle with discussions of influence and how ideas spread between people. Some of the same concepts are in this slide deck, so you can start there to get a sense for the thinking that shaped Paul's work with Google+ and Facebook.

So, What Now?

Have I synthesized all this into a Unified Theory of Human Computing? Um, not quite yet. But I think the sheer amount of activity around these concepts tells us we'll need to fold them into our design practices—where there's smoke, there's fire.

For now, I have all this stuff on my reading list, which I promise I'll get to very soon.