Open source software: the opposite of user experience design

I stumbled across this interview with the developers of Quicksilver, a nifty little search/launcher utility for Mac OS X. One of the things that makes Quicksilver so cool is the way it can interact with many other apps via a robust plugin system.

When asked about possible future plugins, Rob said the following (edited for clarity):

Some people seem confused about why we aren’t working on a plugin for Sparrow, or Google Chrome. I don’t use those apps, so I have no need for those plugins. End of decision tree.

This made me pause, think a minute, and jot down these two (skewed) definitions:

• Open source software: Building, though probably not designing, something mostly for yourself.
• User experience design: Designing, though probably not building, something specifically for another person.

In an odd sort of way, open source software is the opposite of user experience design.

The Sketchnote Handbook by Mike Rohde (Peachpit)

Anyone with basic sales skills knows confused people don't take action. If your job depends on others acting upon your ideas, you will get through to them much more often if you learn to draw those ideas. I end up explaining something to someone every day, so to improve my communication skills I recently read The Sketchnote Handbook by Mike Rohde.

What is sketchnoting?

Before I go further, I'll quickly explain what sketchnoting is: Remember when you took notes in class by writing down pages and pages of boring words? If you combine those words with small pictures of the same ideas, you'd have sketchnotes instead of regular notes. The end product is far more memorable and impactful, if done correctly. (Here’s an example of some sketchnotes I made at a conference.)

The visual communication skills you build by learning sketchnoting are applicable whenever you need to explain something and there's a whiteboard or a napkin nearby. Speaking of napkins, combine this book with Dan Roam's Blah Blah Blah: What To Do When Words Don't Work and you'll be a more effective communicator in no time.

Why buy this instead of another book?

If you're like me and are primarily looking to improve your communication skills, you might be inclined to buy a "drawing 101" type book. I've been down this road and it's hard to recommend as a first step.

Those books tend to focus on concepts like drawing accurate 3D perspective, human figure drawing, shading/shadows, etc. Those are great skills to have, but it's way overachieving if you're just trying to get ideas across. I would say it's icing on the cake, but it's more like sprinkles on top of the icing on the cake.

OK so…what, exactly, is in the book?

To oversimplify, the book covers the following topics:

• Sketchnoting 101 (What is it? Why do it?)
• Sketchnoting Process and Structure (How does it work? What does it look like?)
• Basic Sketching Skills (Help! I can't draw.)

I didn't completely understand the whole book would be fully illustrated, somewhat like a children's book. So it's sort of a living example of the principles, and there are also many sketchnote examples specifically included. It's very engaging and makes it easy to get through.

Although it's a fast read, take the time to stop and practice drawing the simple shapes mentioned in the text. You're wasting your time if you don't. If you can't draw your way out of a paper bag, the drawing tips toward the end of the book will get you going and build your confidence.

One more tip: watch the videos. You will pick up great details like how Mike holds the paper flat and works in a slow, deliberate manner. This yields a clean, simple style that works as well on a whiteboard or iPad as it does on paper.

"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 Force.com 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.

Research

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

Ideation

• 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 Force.com 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.

Evaluation

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

Takeaways

• 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 Force.com 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.

@richziade @iA @dkberman @wblau FB overspent on Instagram to remove a competitor. Focus on the real issue, not false comparisons to old biz.

— Jeffrey Zeldman (@zeldman) April 9, 2012

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:

Facebook

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?