Month: May 2015

Blocking ads

There’s no way to make a web page with a full-screen content-obscuring ad anything other than a shitty experience.

John Gruber’s comment on a linked list item about improving the mobile web. Related.

My list of books to read is immense, and only keeps growing at a rate which outpaces my reading speed. That means there are many canonical books that I’ve never read. In the last week and a half I picked two of them off the list, and loved both.

The first, A Canticle for Leibowitz, is a wonderful science fiction book written in the late-1950s. The focus is a plausible future where humans have annihilated the vast majority of the world’s population through nuclear weapon strikes. Written knowledge, seen as the foundation for that nuclear arms race, becomes both rare and hated.

The second, Fahrenheit 451, is Ray Bradbury’s classic about book burning and the role knowledge and conversation have (or rather, don’t have) in a dystopian future society. Short read, finished in a day, but really fantastic.

Status

Delicious grilled pizzas with Daniel, Leah, and Stijn; great Friday.

Tradeoffs. Episode 36 of Ben Thompson’s Exponent podcast. I’ve been catching up on past episodes lately and this one’s really good. It focuses on the tradeoffs inherent to net neutrality considerations. If you don’t already, I’d also highly recommend subscribing to Ben’s Daily Update.

Half Dome Sunrise

Half Dome

Found this old photo while trying to get the new Photos.app setup tonight. Snapped back in 2008 on a totally basic point and shoot; still like how it came out.

Survey fallacies

Support teams are frequently tasked with figuring out “what the customer wants” with some sort of pre-defined survey. As if a well-constructured set of questions will miraculously fix latent problems in the product.

My two cents: a survey is only worth doing if the product team is willing to devote non-trivial resources to what the survey illustrates as meaningful improvements to make. Without that commitment you’re just wasting everyone’s time.

Blue Chips. An oral history of the 1990s Orlando Magic; basically a narrative constructed through interviews with team members, executives, and people around the NBA. Interestingly designed as well.

Two good reaction pieces to Facebook’s new study published in Science. Zeynep Tufekci wrote an overview of the study as well as links to many other good reflections. Nathan Jurgenson also wrote about what makes the study methodologically questionable and some of its other shortcomings.

Status

Took advantage of summer weather to grill burgers, eat watermelon (with lime), and play board games with friends. Having a grill on the patio is fantastic.

On certainty in support

People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.

I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.

In certain cases WordPress.com users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”

It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.

In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.

If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.