I’ve been thinking about product feedback. We do alot of it at Jive, since most of our work happens in the open. It’s one of my favorite things about Jive and I wouldn’t change it for the world. We all want to make the best product possible, and you can only get that if you put everyone’s heads together.

So I’ve been thinking about how we can make sure we give each other good feedback. I went back and reviewed some of the things I’ve learned over the years about what makes product feedback useful. I wanted to share three articles in particular that have been really helpful to me. I’m going to try to use these techniques more, and I invite you to join in.

First, Mike Monteiro wrote a great post called How To Give Better Design Feedback (it’s now mysteriously gone from the internet, but I managed to resurrect a copy from my Pinboard archive and post it on Evernote). This part, in particular, is a great point to remember:

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.

Cemre Güngör’s How to give better product feedback is also a great article to go through, and this is some good advice:

Describe objectively what you expected and what the product delivered (or fail to deliver). Speak about your particular experience “I got confused when I used this…” instead of generalizing “This is confusing…” or speaking of hypothetical user-beings “Users will get confused…”. This should help disarm the team and empathize.

The worst kind of generalizations speak on behalf of the whole wide world: “Nobody will like/use this”. Being dramatic is unlikely to make the product team start thinking about their work in a new context and change their ways.

But my favorite article on this, because it provides such a great framework for feedback, is Jared Spool’s Moving from Critical Review to Critique. The whole thing is fantastic, and it goes over how to structure a good review. Here’s the gist:

What makes a critique different from a critical design review is we are not there to find flaws. We’re there to learn from the design and to explore where it works well and where it could be improved.

In a well-run critique, we explicitly separate out the discussion of “What are we trying to do with this design?” from the discussion of “Does this rendition accomplish it?” By separating out these two pieces, we avoid digging into the designer’s work just because they unaware of a critical requirement or need.

This part is particularly effective:

The audience also now can explore the design. Often this is done, not with critical commentary, but with exploratory questions. “Have you thought about how users will share the photos with their friends?” “Have you considered how the application works when there’s no network connectivity?”

By posing their thoughts as questions, the designer can say whether they’d thought about that issue or not. If they have, it gives them a nice chance to talk about their thinking. If they haven’t, well, they just say, “No, hadn’t thought about that yet.”

If you have any other tips on giving good feedback, please let me know!

Lukas Mathis’ False Dichotomies is a great post about how quickly design feedback can turn into an argument about the wrong things:

In creative endeavors, tribal, black and white thinking can be problematic, because it prevents you from noticing all possible options. Whenever the discussion veers from «how can we solve this problem» to «should we pick option A or option B», you need to take a step back, and ask yourself — and your team — if these are really the only two options.

Is there any kind of middle ground?

Are there entirely different approaches we didn’t consider?

Are there valid concerns the other group is raising, and can we take these concerns into account without completely dismissing our own concerns?

Matthew Panzarino wrote something that historians will reference in thinkpieces on Medium 40 years from now. From The Apple Watch Is Time, Saved:

And that is the target market of the Apple Watch. Not “rich people” (though there’s a model specially for them), not “tech geeks” and not “Apple fanatics.” It’s people who want more time, and that is a very large target.

This, for some reason, is the thing that Apple has had a hard time articulating. This is the primary use case of the Watch. It’s not just that it’s a “notification center”; it’s that it allows you to act without any additional distraction.

The idea that some new technology will give us more time to do “other stuff” is as old as technological innovation itself. By now we should have learned that no, actually, this time isn’t different. But we’ll never learn. We approach every new technology with starry eyes and hopes and dreams of a life less time-consuming. When I read something like this, I always think about this classic scene from Arrested Development:

In just one of several historical examples of the time-saving delusion, John Maynard Keynes published an essay in 1930 called Economic Possibilities for our Grandchildren [PDF], in which he predicted that technological innovation will save people so much time that they won’t know what to do with themselves:

Thus for the first time since his creation man will be faced with his real, his permanent problem—how to use his freedom from pressing economic cares, how to occupy the leisure, which science and compound interest will have won for him, to live wisely and agreeably and well.

That, alas, has not happened. We are busier than ever these days. Instead of giving us more time, our technologies have instead given us more ways to be connected, to stay in touch with work, to never have to leave the office. I don’t see how one can argue that the Apple Watch will reverse this trend.

What the Apple Watch will do instead, I believe, is to accelerate a different trend, described by Douglas Rushkoff in Present Shock:

Our society has reoriented itself to the present moment. Everything is live, real time, and always-on. It’s not a mere speeding up, however much our lifestyles and technologies have accelerated the rate at which we attempt to do things. It’s more of a diminishment of anything that isn’t happening right now—and the onslaught of everything that supposedly is.

I’m not saying the Apple Watch won’t be wildly successful, or that I don’t want one — I definitely want one. I just don’t think we should fool ourselves into thinking it will somehow give us more time because we might look at our phones less. If history teaches us anything, it’s that we’ll find a way for the watch to fill up our “saved” time in other ways — and then some. And in doing so we’ll continue on the path Kevin Kelly lays out in his excellent book What Technology Wants:

Our lives today are strung with a profound and constant tension between the virtues of more technology and the personal necessity of less: Should I get my kid this gadget? Do I have time to master this labor-saving device? And more deeply: What is this technology taking over my life, anyway? What is this global force that elicits both our love and repulsion? How should we approach it? Can we resist it, or is each and every new technology inevitable? Does the relentless avalanche of new things deserve my support or my skepticism—and will my choice even matter?

That said, this post is only about the first version of the Apple Watch. The next watch is a different story. The next watch might be the one that finally saves us time. Just wait. You’ll see.

Robinson Meyer reflects on Medium and What Blogging Has Become:

And I too, a lowly twentysomething, pine for days of less centralization. As I wrote a few days ago, in a New Medium-style short post, “I still find the idea of a diverse blogosphere — arrayed across tens of thousands of URLs, with sites organized by author and shaped by distinctive interests — really, distinctively, unavoidably cool.”

But is there a place in the web ecosystem for this kind of writing anymore? And is the cost of using Medium, which will centralize writing and create a kind of publisher/publishee power inequality, worth the ease? What will happen when widespread abuse comes to Medium, the way it’s come to Twitter? And social media companies have proven tremendously malleable, product-wise, to the desires of other companies — will Medium be the same? What does a piece of advertising look like on Medium anyway, when the line between journalism and PR on it is already so thin?

I’ve been around long enough for Blogger to rise (and fall), for MySpace to be the best (and then the worst) place to write your thoughts, and for Posterous and Windows Live Spaces to disappear (along with all my posts there). So I will stubbornly hold on to writing on this here, my very own URL.

I wrote a guest post on mobile usability testing for my friends at Unboxed Consulting. It’s something I’ve mentioned briefly here on Elezea before, but in this post I go quite deep on the ins and outs of setting up a mobile usability lab. From A technical guide to mobile usability testing:

Setting aside the details of recruiting, script writing, and interviewing, from a technical perspective doing usability testing on desktop web applications is pretty simple, thanks to software like Morae and Silverback. There is, however, no straight-forward, single solution for doing usability testing on mobile devices. I recently went through the process of setting up our own mobile usability testing process at Jive, so I thought I’d share some of what we learned about the components of a good setup.

Steve Barnett makes some great points on long-term planning in Plans, Details, Dates, and The Future¹. I especially like the point about how user research fits into planning:

Before development starts on a new bit of work, you should be building prototypes and doing user testing with them. This always results in some changes to the plan, and often results in rather large charges. You can’t plan what these changes will be: you don’t know until you’ve done your user testing.

Erika Hall speaks so much truth in her post On Surveys:

If you are treating a survey like a quantitative input, you can only ask questions that the respondents can be relied on to count. You must be honest about the type of data you are able to collect, or don’t bother.

My first role at eBay, years ago, was as a quantitative user researcher¹. We ran surveys to measure satisfaction with different areas of the product over time. If that period taught me anything, it’s that surveys are extremely useful when combined with analytics as well as qualitative user research (triangulation), and pretty useless when looked at in isolation. There just isn’t enough context by itself.

The Paradox of Empathy is such a great post by Scott Jenson that I pretty much want to quote the whole thing. But I’ll stick with just this one gem, and encourage you to read it in full. It is a fantastic exploration of empathy in design, and includes a framework for making empathy part of our everyday work in a very practical way:

Designers will be the first to admit that not every empathic observation leads to a miraculous insight. However, it’s called “Design Thinking” for a reason: it’s how we process and explore, taking a complex problem and breaking it down before we build it back up. Product managers seem to expect a designer to walk up to a product, say something brilliant, and drop the mic. Experienced designers deeply understand a simple fact: design isn’t a deliverable, it’s a process. A process paved with dozens of small empathic observations that lead you, slowly, iteratively to a better product.

The problem for us designers is that our fellow teammates don’t always think this way and unfortunately, we as a community don’t reflect on this difference. It’s ironic that designers are passionate about how a product interacts with people but not how they themselves interact with their team.