I get these weird obsessions sometimes—a thing that starts small in my head until it becomes all-consuming for weeks on end. Maybe you can relate? Anyway, my current obsession is centered around jazz, and how much we can learn from it about technology, how we listen to music, and yes, even design.

If you follow me on Twitter you’ll know that I just finished reading How to Listen to Jazz, a book I thoroughly enjoyed. I shared screen shots of some of my favorite sections from the book here, but suffice to say it is about so much more than jazz, and I highly recommend it not just for music lovers, but for anyone who works in a creative role.

Right on cue, as so often happens on the internet, I came across Ken Norton’s excellent post Please Make Yourself Uncomfortable, about some of the leadership lessons we can learn from great jazz records (especially the all-time best one, Kind of Blue):

Miles, Ella, and Duke were adept at guiding their bands into the optimal anxiety zone, making them restless and opening up a space where they could create masterpieces. Such talent is also needed in product management. So much of what we’ve learned, our instincts, are to do the complete opposite. We’re told to minimize risk, communicate a clear plan, and document every step. As product managers, our most important job is to help our teams find the place of optimal discomfort—the goldilocks zone of ambiguity and uncertainty.

The same day I read Gretta Harley’s The Slow Listening Revolution, about why she still has a vinyl collection:

Why vinyl? Commitment. In this mid-second decade of the 21st century, music is being taken for granted on a collective scale. An entire generation of music listeners will never pay for music, nor do they believe that they should. The long form music medium has taken a back seat to song culture, yet the average person only listens to a song for approximately 24 seconds before deciding if it’s worth their time to continue to listen. I ponder the substantive value of something that our capitalistic, corporate-model culture places on “free.” When we can listen to a whole song, or usually only 24 seconds of a song without paying for it, do we really value the music? I wonder if we listeners are as committed to music as we were pre-internet? I really like the internet, so these words are in no way a complaint or indictment, but merely observation.

All of this—jazz, new music, old habits—came together as I picked up Dire Straits’s 1985 CD Brothers In Arms, which in some versions had this cover:

It used to be that proclaiming “A FULL DIGITAL RECORDING” was a selling point. Now, the first thing I look for when I buy an album is the phrase Mastered from the original master tapes, a sure sign of its 100% no-digital, analog-only experience.

Or, wait, maybe we’re just being anti-technology in our criticisms of digital music? There has always been a reluctance to adopt new things—a longing for the past and how things used to be. Clive Thompson gives us another example of this historical skepticism in That cursed newfangled technology, “electric lights”:

Robert Louis Stevenson penned “A Plea for Gas Lamps” in 1878, hoping to dissuade London’s authorities from installing obnoxious electric streetlamps like those in Paris. “A new sort of urban star now shines at night,” he wrote, “horrible, unearthly, obnoxious to the human eye; a lamp for a nightmare!”

So I don’t think we’ll solve this particular “which one is better” musical argument any time soon. But if history teaches us anything, it’s that it’s not a new argument, so we should just roll with it. And rock with it1.

---

1. Sorry, that’s a really bad joke. I’ll see myself out. ↩

Kevin Slavin’s Design as Participation is one of those articles that stays with you for days. There are multiple ways to read it, but I view it as a thoughtful critique of my primary field of focus: user-centered design (UCD). There have been other discussions on this topic, most notably Cennydd Bowles’s excellent Looking Beyond User-Centered Design, and Mike Long’s Stop Designing for Users. Kevin’s is a worthy addition to the debate.

Kevin’s main thesis is that UCD is selfish (since it puts a user at the center of everything), and we should instead see users as active participants in a design:

Broadly, UCD optimizes around engagement with the needs, desires and shortcomings of the user and explores design from the analysis and insight into what the User might need or want to do. Simply, it moves the center from the designer’s imagination of the system to the designer’s imagination of the user of the system.

But we are no longer just using computers. We are using computers to use the world. The obscured and complex code and engineering now engages with people, resources, civics, communities and ecosystems. Should designers continue to privilege users above all others in the system? What would it mean to design for participants instead? For all the participants?

Also:

Some contemporary work suggests that we are not only designing for participation, but that design is a fundamentally participatory act, engaging systems that extend further than the constraints of individual (or even human) activity and imagination. This is design as an activity that doesn’t place the designer or the user in the center.

If this all seems overly academic, fear not, practitioners! Kevin shows several examples of “Design as Participation” in his essay, and also ends with this call to action:

A new generation of designers has emerged, concerned with designing strategies to subvert this “natural default-setting” in which each person understands themselves at the center of the world.

These designers do this by engaging with the complex adaptive systems that surround us, by revealing instead of obscuring, by building friction instead of hiding it, and by making clear that every one of us (designers included) are nothing more than participants in systems that have no center to begin with. These are designers of systems that participate – with us and with one another – systems that invite participation instead of demanding interaction.

We can build software to eat the world, or software to feed it. And if we are going to feed it, it will require a different approach to design, one which optimizes for a different type of growth, and one that draws upon – and rewards – the humility of the designers who participate within it.

It’s always hard to see one’s views challenged, but Kevin does it in the best possible way here. He understands UCD and why it came about, he presents a compelling argument about its issues, and then he shows us how we can do better.

I don’t think this means the end of UCD (or even that we should stop using its basic methods like personas and usability testing). But I do agree that we need to shift our thinking so that we’re less concerned about the success of an individual user (or groups of users), and more concerned about how different systems interact with each other. Alan Cooper touches on this topic in his wonderful essay The Edges:

What each organization has to do today is to regard the edges of its products with as much diligence and attention as they give the center. The quality of both their outside system connections (known as application program interfaces, or APIs) and their user interfaces demand levels of expertise and investment that have historically fallen short.

As nebulous as Kevin’s idea of “building software to feed the world” sounds, I like the sound of it. I like the hope and the desire to do good in the world that it communicates. We need to make that idea concrete in our daily design worlds, and I don’t think we quite know how to do that yet. But every practical mission starts with a grand vision, and I quite like this one.

There are two things everybody in business (say they) hate: meetings and email. So the past few years have seen a great many startups that try to re-invent, revolutionize, and strategerize the crap out of meetings and email. However, recently we seem to have come to a disappointing realization: meetings and email are the worst ways to get things done, except for all the other ways.

In Meet Is Murder Virginia Heffernan goes deep on the topic of meetings: why we hate them, what people have tried differently, and how we just can’t seem to quit them. Her resigned conclusion hints at what really might be the source of our meeting hatred:

What’s so bad about meetings, after all? At bottom, they are nothing but time with your fellows. Which suggests that hating meetings might be akin to hating traffic, families or parties—just another way to express our deep ambivalence about that hard fact of existence: other people.

Meanwhile, in Slack, I’m Breaking Up with You Samuel Hulick shares his dismay with Silicon Valley’s latest darling company. These kinds of articles are inevitable at this point—we’re almost certainly approaching 6 PM SVT (Silicon Valley Time) for Slack. Anyway, Samuel wrote a break-up letter to Slack, but at times it reads more like a subtle “Please come back!” letter to email. For example:

While it’s true that email was (and, despite your valiant efforts, still very much is) a barely-manageable firehose of to-do list items controlled by strangers, one of the few things that it did have going for it was that at least everything was in one place.

And this:

When work gets done over email, there’s a general expectation of a response buffer of at least an hour or two. In you, though, people can convene and decide on anything at any time.

Also this:

When I started feeling like our relationship was getting to be just a little too much, I decided to take a few days off. That was never a problem when I was with email—I’d just fire up a vacation autoresponder and be on my merry way.

I’ve always liked email (which, sorry, I know, is like a Portlander saying “Oh you just found out about Kale? I’ve been eating Kale all my life!”), and felt that the bigger problem is not the system but the way we deal with it. I tried Google Inbox and that Mailbox thing that Dropbox bought and shut down, but I could just never get into a groove with a system that tries to sort my email for me. Instead I just do something that works really well for me: I read every email, and file each message in the appropriate place when I’m done dealing with it. That’s it.

I’m also not as against meetings as I used to be. My rules there are equally simple: always walk out of a meeting with an artifact. This could be a whiteboard sketch or a note about a thing you need to go research—it doesn’t really matter. Just walk out of there with something. Meetings should focus on facilitating the things that meetings are good at: collective thinking. Meetings that energize me are the ones where most people are standing, working together on a common goal. From customer journey workshops to design studio sessions to analyzing usability testing results, there are plenty of useful ways to spend our times in meetings. That’s my only criterium for a good meeting: make progress.

These guidelines are probably way too simple for the majority of businesses and people. But I do think that when we try to “reinvent” meetings and email we’re trying to solve a people problem with technology, and that’s just never going to work. Technology can help, for sure, but at its core we need to figure out why we hate email and meetings, and then fix that first. And I think the main problem with meetings and email is that we don’t spend enough time taking personal responsibility to make them more effective. Until we stop trying to offload our personal responsibility on the shoulders of technology, nothing will change.