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.

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.

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.

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.

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):

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.

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.

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:

• Can Technology Really Change Your Habits? (Fast Company)
• There’s a backlash against nudging – but it was never meant to solve every problem (The Guardian)

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.