Menu

Links and articles about technology, design, and sociology. Written by Rian van der Merwe.

The downsides of tracking everything about ourselves

As is often the case with these things, I just noticed two articles that make very similar points about the quantified self movement. In Quantify Thyself LM Sacasas makes the point that we don’t know what we don’t measure:

Not only do we tend to pay more attention to what we can measure, we begin to care more about what can measure. Perhaps that is because measurement affords us a degree of ostensible control over whatever it is that we are able to measure. It makes self-improvement tangible and manageable, but it does so, in part, by a reduction of the self to those dimensions that register on whatever tool or device we happen to be using to take our measure.

In a similar vein, Anne Helen Petersen has a great piece on Buzzfeed called Big Mother Is Watching You: The Track-Everything Revolution Is Here Whether You Want It Or Not. Here’s the kicker:

But there’s something to be said for the allure and beauty of the mysteries not only of our confusing, previously unknowable bodies, but the intricacies of life. For the daily banalities of tuning the thermostat, or of knowing you had a good night’s sleep because you feel good, not because an app indicated as much. For the pleasure of running without knowing how fast or how long or how many calories but simply because your body could and did move, and that even without a digital trace, a GPS footprint, or way to leverage evidence thereof against friends and co-workers — it nonetheless felt something like being alive.

How to Interview

Last year I accidentally became an expert on interviewing. I didn’t want to, but hey, we do what we need to do. I just published some things I learned in the process on A List Apart, in an article called How to Interview. Here’s one piece of advice on how to get companies to email you back…

Send separate, personal emails to each of the likely hiring managers you found. Make it really, really short. Don’t go on about how awesome you are—you’ll get a chance to do that later. Tell them you like their company, you like the role, you’re interested in talking. Link to stuff you’ve done: your LinkedIn profile, your portfolio, articles/books you’ve written, etc. Then ask them if they’d be willing to have a call, or forward your information on to the right person. The point is to not burden people. If they see a long email, the chances are high that they will delete it. But if they see a short email that’s respectful of their time and gives them the information they need to make a quick decision—that’s a different story.

What makes online collaboration successful

Smarther Than You Think

I just finished Clive Thompson’s Smarter Than You Think: How Technology Is Changing Our Minds for the Better and really enjoyed it. So much of what we read about technology these days is doom and gloom that I wanted to spend time on something a little more positive. And turns out, there’s much to be positive about.

There are many stand-out moments in the book. One is the exploration of ambient awareness — how social media often makes our in-person connections stronger because we know so much about each other’s minutia that we can skip the small talk and jump straight to the important stuff when we see each other. But the part I want to elaborate on a little bit here is what historical events tell us about the important criteria to meet for collective thinking to be successful.

Clive points out four important aspects of successful online collaboration:

  1. Collective thinking requires a focused problem to solve. One disastrous story Clive tells is when the LA Times create a wiki page on the Iraq War and encouraged people to edit it. No focused outcome = a rapid decline into the bottom half of the internet. But give people a common problem to solve — like “Which tent hospitals in Cairo need help, and what do they need?”, and people start to shine together.
  2. Collective problem solving requires a mix of contributors. Specifically, it needs to have really big central contributors, and then a lot of people making small contributions to push the solution forward. As Clive puts it, “these hard-core and lightweight contributors form a symbiotic whole,” coming up with the best solution in the fastest possible way.
  3. Collective thinking requires a culture of “good faith collaboration”. Contributors need to struggle constantly to remain polite to each other. And it is a struggle, but a necessary one. As Anil Dash once said, if your website’s full of assholes, it’s your fault.
  4. To be really smart an online group can’t have too much contact with each other. This sounds counterintuitive, but the evidence supporting the point is pretty overwhelming. Clive goes over a few examples that shows that “traditional brainstorming simply doesn’t work as well as thinking alone, then pooling results.” This also explains why Design Studio is such an effective way to solve design problems. So one of the secrets of online collaboration is that it “inherently fits the model of people working together intimately but remotely,” as Clive puts it.

There’s much more to say about the book, but I think I’ll stop here and just encourage you again to read it. You’ll agree with a lot of it, disagree with some of it, and think about all of it for days after finishing it. That’s all we could ever ask of a book.

Taking back the music

I wrote a story about jazz, coffee, and liner notes, and hopefully managed to turn it into something with a logical conclusion. But feel free to judge for yourself by reading Taking back the music:

We like things fast and disposable — I get that. I mean, no one even knew what the word “ephemeral” meant until Snapchat came along. But moving quickly from one thing to the next will just never be as satisfying as really spending time with something or someone, with no escape from the person or the artist’s intentions and successes and failures. We can all do with a little bit more of that.

Building a case for qualitative research

Bill Selman wrote a great post on the importance of research triangulation. If you have trouble making the case for qualitative research in a company smitten with “big data”, show them Why Do We Conduct Qualitative User Research? (emphasis mine):

There is no one research method that satisfies answering all of our questions. If the questions we are asking about user behavior, attitudes, and beliefs are based solely on assumptions formed in our homophilic bubble, we will not generate accurate insights about our users no matter how large the dataset. In other words, we only know what we know and can only ask questions framed about what we know. If we are measuring, we can only measure what we know to ask. Quantitative user research needs qualitative user research methods in order to know what we should be measuring and to provide examples, theories, and explanations. Likewise, qualitative research needs quantitative research to measure and validate our work as well as to uncover larger patterns we cannot see.

Design and angry mobs

Paul Ford knocks it out of the park again in What I learned about hatred from my tiny daughter, an essay about collective anger on the internet:

When you aggregate enough people and get them to talk about design they become, basically, a single giant toddler.

The stories behind our passwords

There are some wonderful and surprising stories in Ian Urbina’s The Secret Life of Passwords:

SEVERAL YEARS AGO I began asking my friends and family to tell me their passwords. I had come to believe that these tiny personalized codes get a bum rap. Yes, I understand why passwords are universally despised: the strains they put on our memory, the endless demand to update them, their sheer number. I hate them, too. But there is more to passwords than their annoyance. In our authorship of them, in the fact that we construct them so that we (and only we) will remember them, they take on secret lives. Many of our passwords are suffused with pathos, mischief, sometimes even poetry. Often they have rich back stories. A motivational mantra, a swipe at the boss, a hidden shrine to a lost love, an inside joke with ourselves, a defining emotional scar — these keepsake passwords, as I came to call them, are like tchotchkes of our inner lives. They derive from anything: Scripture, horoscopes, nicknames, lyrics, book passages. Like a tattoo on a private part of the body, they tend to be intimate, compact and expressive.

I now use 1Password to create unique passwords for each service, but the article did take me back to the one password story I do have. Back in college, when it was time to select a password I could remember easily, I remember leaning back in my chair and giving it some serious thought.

I had just seen Patch Adams and top of mind for me was part of a poem the character recited that really stuck with me (full version here):

Pablo Neruda

I know it’s ridiculously syrupy, but I apparently used to be a romantic. Huh.

Anyway, my default password became two words from the poem, smashed together. Even though I don’t use the password any more I just can’t get myself to tell you which words, though. I guess some of this story needs to remain mine alone.

QA in a post-QA world

There are a few controversial ideas in Benjamin Sandofsky’s You Can’t Go Home Again, in which he basically says that Agile methodologies shouldn’t be used in mobile app development. I did find this perspective on QA interesting in our increasingly post-QA world:

Sit down with a software engineer from anywhere but the web, and ask them about QA. Tell a game developer you don’t need it, they’ll tell you you’re nuts. Maybe these agile people have been burned by bad QA, but a great QA team is far from a bunch of monkeys clicking buttons all day.

Formal QA provides a counterpoint to “move fast and break things.” Their job isn’t to say, “No.” It’s perfectly fine to ship bugs– otherwise software would never ship. You need someone who is aware of all the bugs, and help you make the decision if the risk is worth it.

Also see Michael Lopp’s The QA Mindset for some really good perspective.

Designing for behavior change

Dan Lockton’s As we may understand is unnecessarily long and rambling at times, but it’s still worth it for the very interesting views on the Internet of Things and designing for behavior change:

Many of the issues with the ‘behaviour change’ phenomenon can be characterised as deficiencies in inclusion: the extent to which people who are the ‘targets’ of the behaviour change are included in the design process for those ‘interventions’ (this terminology itself is inappropriate), and the extent to which the diversity and complexity of real people’s lives is reflected and accommodated in the measures proposed and implemented. This suggests that a more participatory process, one in which people co-create whatever it is that is intended to help them change behaviour, is preferable to a top-down approach. Designing with people, rather than for people.

Again, it comes down to understanding people and their needs before embarking on a design. I wonder if we’ll ever fully learn this lesson.

Also see:

Product management vs. tech team responsibilities

David Cancel has some interesting thoughts on how they split up product management and tech team responsibilities in How we transformed HubSpot into a Product Driven Company. I really liked this part about embedded designers:

While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. […] The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.

That post led me to Jeremy Crane’s What does a Product Manager do at HubSpot, which goes into more detail on the PM/Tech team split:

Every product team’s job is, essentially, to solve problems for their customers. Solving problems involves two key components: (1) Understanding the problem, and (2) creating the solution. At HubSpot the product manager owns the “problem” and the technical team owns the “solution.”  The “problem” is defined by whatever is likely to produce the greatest value to the customer and the business at large within the area of influence. The “problem” is both long-term and short-term in scope. It addresses the immediate challenges that the customer is experiencing, while still keeping an eye the longer-term vision of the product as a whole.