Links and articles about technology, design, and sociology. Written by Rian van der Merwe. Follow @RianVDM
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.
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:
- 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.
- 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.
- 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.
- 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 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.
- 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.
I’ve been thinking about being recently. Being online, being at home, being at work, being in public, being in private. This year my family and I made some gigantic changes in our lives that I won’t bore you with, except to say that constant change and discomfort gave me a renewed appreciation for human frailty. In fact, I’ll go so far as to say that, for the first time, I feel like I truly understand these words by Thomas Kempis:
A true understanding and humble estimate of oneself is the highest and most valuable of all lessons. To take no account of oneself, but always to think well and highly of others is the highest wisdom and perfection. Should you see another person openly doing evil, or carrying out a wicked purpose, do not on that account consider yourself better than him, for you cannot tell how long you will remain in a state of grace.
We are all frail; consider none more frail than yourself.
All of this helped me figure some things out about being that I haven’t been particularly certain about before. Things like who I want to be and what I want to do with my life. The answers to those questions are probably irrelevant for what I want to write about here, so I won’t dwell on that. What I will do is share a few things I’ve become fairly sure of over the last few months (while I remain open to data-driven mind-changing next year, like any decent designer would).
So here are some things I learned in 2014:
Smaller networks are better
During some of the darker months of the year I retracted from Facebook and found some solace in the 5 or so active friends I have on Path (go ahead, laugh it up…). On Twitter I doubled down on what I’ve always done: being a link monkey, there for your daily dose of UX and product management links. There’s certainly comfort in that ritual and the feedback that comes from it. But it does get pretty empty after a while.
When things started to improve I gave Facebook a try again. I once again expanded my network. And suddenly it just felt really really loud and crowded and filled with people like me who are just looking for positive reinforcement and I didn’t like the way that made me feel.
So I went back to small. I’m still active on Path. On Twitter I share more personal things in addition to links I really like. It pisses some people off, but it feels more real. I also started writing a newsletter and I’m really enjoying the personal nature of that medium.
All of this to say that we’ll do well to remember that the web is people all the way down. And that smaller networks mean more meaningful relationships.
Who we amplify is who we are
Every day we choose whose voices we amplify online, and those choices make us who we are. After Ferguson happened I felt like I didn’t have a right to say anything about it. But what I could do is amplify the voices of those who did have something important to say. So that’s what I did. I retweeted articles and calls for help. I eventually did write something, and I still feel uncomfortable about it, but in the end I felt like I had to.
The things we say are important. They make us. Not to get all preachy, but Matthew sums it up pretty well:
But the things that come out of a person’s mouth come from the heart.
So I’m not always getting this right, but I want to amplify good things and people who say important things. Who we amplify is who we are. So let’s choose wisely.
Learning and sharing is what makes us a community
After much reflection I realized that to become a better designer and be a good web citizen there are only a few basic things you have to do:
- Read about a new thing.
- Practice new thing until it works for you.
- Write about what you learned while practicing the new thing.
- Repeat ad infinitum.
That’s it. That’s what community is: learn from others, practice until you get it, and teach others the new things you learned. We should really do more of that.
Being a small fish in a big pond is ok
I don’t know how to write this without sounding weird so I’ll just go ahead and put it out there and hope it comes out right.
When I lived in South Africa I thought what I wanted was to become an author and conference speaker. It was a bit easier there because there aren’t as many UX people as there are elsewhere in the world. And when I decided to move back to the US several people didn’t understand. “You’ll be a small fish in a big pond,” they said. “I know,” I would answer, “isn’t that awesome?”
The fact is that where I am right now is a much better fit, and I recognize the importance of being content in the situation we’re in. I do a job I love at a company with an awesome culture. Every once in a while I share things. My book didn’t become a bestseller, but the people who read it seem to enjoy it, and that makes me happy. I spend time with my family, and I tweet some jokes and links every once in a while.
I don’t get invited to speak at conferences, and I don’t have a major book deal coming. But I still enjoy writing, and I enjoy being with the people I hang out with — online and in person. After the year I’ve had, that is all I could ever ask for.
It was hard, but I’m thankful for 2014 and the meaningful lessons that came out of it.
Now let’s get it behind us and move on, shall we?