Want users? Google Reader is giving them away.

With Google Reader shutting down at the end of June, there's a unique opportunity for another company to scoop up thousands of new users if their product can "do the same job." This is a rare occasion where users are being forced to switch products—something that is usually very tricky to achieve.

What does it take to switch?

Bob Moesta and Chris Spiek of the ReWired Group helped me understand just how hard it is to get someone to switch from using one product to another. (You have the same opportunity to learn: jump on it.) Many companies make an implicit assumption that if their new product has more/better features than a competing product, customers will transition to them. That's simply not true; features aren't nearly enough. You need:

• Push: The consumer needs to have some problem or dissatisfaction with the solution they're using now.
• Pull: Your product needs to have a compelling feature set, ideally one that speaks to the problem(s) they're having.
• To address Anxiety: Customers won't implicitly trust you and your offering, and will worry about what bugs/issues they'll run into.
• To address Inertia: Customers have built up habits that will be hard to break. Installed base, existing integrations and behavior habits are all working against you.

The idea is to get customers to move from left to right. Imagine two tall buildings side-by-side, and the the owners of the building on the right built a bridge for people on the left to come over. The building on the right might look nice (pull), though people will be skeptical that it has problems of its own (anxiety). Worse, there's nothing wrong with the building on the left (no push) and moving is a big pain (inertia).

In the case of Google Reader, everyone is being forced to exit the building. It's on fire. The bar is a lot lower to get people to cross over.

Will Facebook build a good Reader?

The "sunset" of Google Reader is an amazing gift for companies who want those customers, since Push and Inertia have been supplied. That said, others have noted a dropoff in Reader usage long before the shutdown, traced back to the addition of a number of social features Reader users weren't interested in. The social element didn't speak to a "job" those users were "hiring for," hence there's an oversupply of technology. They were overserving the market.

Eliza Kern from GigaOm makes a good point that Facebook could easily oversupply in the same way, since social is at the core of their company. We'll find out soon enough, though I hope they've thought long and hard about what people wanted from Google Reader.

Engineers, UX and motivation

Designer and Lean UX pioneer Lane Halley posed this question on Twitter:

What do you think? How much UX can and should a "full stack developer" know? laurencegellert.com/2012/08/what-i…@carbonfive

— lane halley (@thinknow) June 7, 2013

The article linked in the tweet states that the true "full stack" developer should have knowledge starting down near the metal, stretching up past the UI, into the user experience and beyond, into the business. (I'm exhausted just thinking about it.)

Knowledge by itself can't be a bad thing, though in my experience motivation is the real source of magic. I have some strong opinions on this, because I've been fortunate enough to see the results when engineers become excited by shipping products others will value, instead of solving puzzles for their own enjoyment.

The engineer mind

Solving puzzles is where it all starts, though. When today's programmers were children, they enjoyed building with Legos, working hard until the pieces fit together. Tomorrow's programmers are ignoring their meals and debugging their Arduinos as I type this. Why? Because it's fun! At least, they think so.

Actually, let me rephrase that: It's fun for them. They extract enjoyment and learning from it, and those positive outcomes go into their hearts and minds. Even if they're just passing the time, the critical distinction is the activity is about them and not another person.

Can you hear me now?

Here's another example: the recently released book Exploding the Phone: The Untold Story of the Teenagers and Outlaws who Hacked Ma Bell tells the story of the teens and twentysomethings who figured out how to "hack" the phone system and make free long-distance phone calls in the 1950s-1970s. The author breaks up the tech talk with compelling narrative, and stops to make the point that these kids had no one to call. The goal was not to save money, or stick it to The Man, or anything beyond conquering the challenge.

In one anecdote, the pranksters called several military facilities (among other places) and were busted by the FBI and military investigators. Since this was the Cold War era, the authorities thought they uncovered a ring of spies. The interrogation was intense, and only ended when an AT&T engineer produced records proving the kids had essentially made no calls of any possible value. The G-Men couldn't wrap their heads around the fact that the kids would spend so much time reverse engineering the system without a "real reason."

But, to them, it was a reason: it was fun. And they learned something.

The big shift

Product teams need to take talented, dedicated people who start with that mindset and get them to build something that someone else will use and like, whether or not it's an exciting technical challenge. By hook or by crook, their focus needs to move outward into the messy world of people from its comfortable den of internal control. And, since comparatively few organizations are truly design-led, it's incumbent upon designers and product managers to build bridges to these awesome folks and activate their amazing potential.

The good news is, it's possible. I've seen it happen. And it's incredible. In our case, a key front-end engineer attended a design conference, and the seating chart worked out such that he sat back-to-back with our (also incredible) visual designer. Before long, the two of them were working on ideas of their own, and we were shipping stuff that was both well-designed and well-built.

That success inspired me put together a UX "crash course" targeted towards developers. If you have a roomful of developers nearby, I'd love to share that message again. I truly believe the single most effective way to improve your organization's products is by getting the engineers to care about design.

TL;DR

If design isn't a big part of your company's culture, don't worry about how much engineers know about design and user experience. Building things for others isn't why they started their career. Get them to care about shipping things others think are great, and backfill the knowledge they need a little at a time. They have to want the knowledge before you hand it to them.

Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.

— Clayton Christensen (@claychristensen) August 3, 2012

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.