Newton’s queries

Franklin had read Newton’s Opticks, for example, which contains a set of experimentally proven propositions and ends with a group of “queries,” unsolved questions for further studies.

This was a passing reference in Lewis Hyde’s Common as Air (p. 34), but it caught my attention.

In writing posts on this blog—especially longer posts—I’ve found myself compelled to come to some sort of a conclusion at the end of the post. While this may be what is expected of most non-fiction writing, this isn’t what I want to do on this blog. I want to capture and explore ideas that are new to me without necessarily coming to a conclusion. 

Sometimes in the course of writing about a new idea, I will draw a conclusion, but many times the conclusions at the end of these posts have been forced. Forced conclusions are not particularly compelling conclusions.

Newton’s queries are interesting because they provide a potential way to end a blog post while satisfying my deeply felt need for a resolution of some sort.  A set of questions—things I’m still uncertain about or need to research further—is also more in keeping with the purpose of this blog. It also invites commentary and conversation. Something I’ve not been very good at encouraging on this blog.


  • Is working toward a conclusion is a better way of exploring new ideas? For the moment, my hypothesis is that ending with unaswered questions, rather than a conclusion is a better way of doing this. By for the moment it’s only that: a hypothesis.
  • What I’m proposing here is different from what Newton did. He did come to a conclusion. What I’m doing on this blog isn’t science. These posts aren’t experimental outcomes, but in a way they are the experiment. Iss there a balance between coming to a conclusion and highlighting questions that I’d still like to find an answer for?


Common or common land was not owned by commoners. The soil and anything which it contained, or grew on it, was part of the ‘waste’ or uncultivated land (in the sense of a grown crop). This was usually, but not always, on the outskirts of a settlement. It was a part of the land within a manor and as such was owned by the lord of that manor. The right to the use of the ‘fruits’ of that soil depended on the customs within that manor. These rights acquired names used throughout England. Common of Pasture, the right to graze animals on the land; Common in Soil, the right to clay, sand, gravel and stone; Common of Turbary, the right to cut turf and peat; Common of Piscary, the right to fish and Common of Estovers, the right to take wood from the land, but only to a set circumference. Common of Estovers was further divided into; Housebote, wood to repair a house; Firebote, for fuel; Plowbote, to repair farm implements and Hedgebote to repair boundary hedges and fences.

I first encountered the notion of “estovers” (the right to gather wood on common land) when I was doing researching Odiham Common before we visited it for a weekend walk. This was my first indication that Commons didn’t work the way I thought they did. Since moving to the UK, I’ve lived close to one Commmon or another—Tunbridge Wells Common, Clapham Common, Tooting Common, Streatham Common. I had come to think of a Common as a place anyone could visit and projected that back into history. Assuming that it had always been this way: that anyone could visit, graze their animals, take what they needed from a common. The Commons, I imagined, where an idyllic past where people had what they needed.

To be honest, I was probably influenced to view the commons in this way by Garrett Hardin, whose Tragedy of the Commons has been influential in the way we conceive of the commons. 

The tragedy of the commons develops in this way. Picture a pasture open to all. It is to be expected that each herdsman will try to keep as many cattle as possible on the commons…

As a rational being, each herdsman seeks to maximize his gain…

[T]he rational herdsman concludes that the only sensible course for him to pursue is to add another animal to his herd. And another; and another…. But this is the conclusion reached by each and every rational herdsman sharing a commons. Therein is the tragedy. Each man is locked into a system that compels him to increase his herd without limit–in a world that is limited. Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons. Freedom in a commons brings ruin to all.

It turns out that this kind of Commons has never really existed. Hardin’s Commons is best approached as a thought experiment, rather than an historical reality. To be fair to Hardin, he does propose mechanisms for managing the rights to a Common, and later wrote a clarification that said he his original paper addressed the “unmanaged” commons. Still, Hardin’s hypothetical Commons set out in the Tragedy of the Commons still looms large in our collective understanding of what a Commons is.
Tim Harford discussed Hardin’s hypothetical commons in a recent podcast, and contrasted it with the traditional English Commons.

Garrit Hardin explained that there was no way to sustainably manage the common property. The only solution was to natoinalize it—let the state run it—or to privatize it—divide it up into little parcels and hand them out to individuals. But the English Commons lasted for hundreds of years, perfectly sustainably. They were managed by a community; they were owned by a community. These were people who were neighbors. They lived next door to each other, and they could police those rules.

Harford is somewhat idealizing the past, or at least collapsing it. While Commons were likely managed by a community early on, they eventually came to resemble the situation described in the first quote of this post: the lord of the manor owned the land and decided which commons rights to grant. Lewis Hyde in Common as Air (p. 29) offers a nice potted summary of these two historical approaches of managing the Commons:

In the Saxon age before the Norman conquest, it is assumed that all village lands were held and worked in common, except for a few enclosed gardens and orchards. No one person or family was the ultimate owner; what belonged to people were use rights, the commons being the place those rights were expressed. During the many centuries after the Norman conquest, the lands of any village were more likely associated with a local manor, the assumption being that the soil belonged ultimately to the lord of the manor and that rights of common were granted on condition of fealty to him and attendant acts of tribute (military service especially).

Nevertheless, this doesn’t invalidate Harford’s key point in the podcast: the Commons have been successfully managed throughout history, whether by a community or by a feudal lord. In making this point, Harford highlights the work of Elinor Ostrom on “common pool resources.” Ostrom’s PhD focused on the use of fresh water in the aquifer under Los Angeles, which was being depleted of fresh water and slowly filling with salt water. On the surface, usage of the aquifer seemed as if it was irrefutable proof of the Tragedy of the Commons. What actually happened was very different.

What actually happened was that people got together… and hammered out rules—messy ad-hoc rules. And the rules worked. They not only worked; they lasted.

It turned out other common pool resources across the United States and across the world were also being managed sustainably by these ad-hoc rules. They were different every time. They didn’t always work, but sometimes they did.

And Lynn Ostrom discovered something very important: the Tragedy of the Commons isn’t a tragedy. It’s not inevitable… It’s the Problem of the Commons, and problems have solutions.

The rules of the English Commons were certainly ad-hoc. While they eventually came to have specific names like Estovers, the rights that were granted and who they were granted changed over time. The English Commons lasted for hundreds of years, and only ended with the ‘Inclosure Acts of the 17th century onwards.

I’m currently reading Common as Air, in which Lewis Hyde examines the problems of the commons from the perspective of history. He looks at the ideas and opinions of the founders of the United States of America

When I’m finished I’ll be interested to compare Hyde’s philosophical and historical conclusions with those of Elinor Ostrom’s more empirical approach. 

The hedonic treadmill

About thirty years ago, Philip Brickman, a social psychologist at Northwestern University, organised a team of researchers to investigate the happiness levels of lottery winners. The team found that while lottery winners were initially elated upon landing their great fortune, those feelings of elations tended to dissipate rapidly. As the winners recalibrated their happiness levels, many of the activities they had previously enjoyed (such as reading or sitting down to a good meal) became less pleasurable over time, such that within a few months, the wealthy winners reported being no happier than they had been before hitting the jackpot. Brickman called this adaptational phenomenon the “hedonic treadmill”: the term was dead on in describing the human predisposition to feel entitled to today what we used to feel thankful for yesterday.

Youngme Moon provides a neat summary the hedonic treadmill (Different p. 59).

What strikes me about the hedonic treadmill is that it feels at first counter-intuitive. Once you understand it, however, you start to see it everywhere. The happiness that you feel on getting a new job, new house or accomplishing a goal doesn’t last, you find yourself no more or less happy than you were before.

There are three things that interest me here. The first is the idea of “entitlement”, the second has something to do with occasional rediscovery and the last concerns intrinsic motivation.

“Entitlement” is a word that is often used disparagingly in the UK to describe the behavior of people in lower socioeconomic brackets. This probably has largely to do with the government’s use of the word. It’s always perplexed me, though. I’ve seen more entitlement among people in the middle class (or above) than I have among so-called “benefits scroungers.”

The idea of hedonic adaptation (as well as loss aversion) helps to explain this. As we acquire more and more economic goods, we temporarily get a boost in happiness. Loss aversion ensures that we don’t want to lose what we already have, but hedonic adaptation gives the illusion that we’ll only be happier if we acquire more. This comes across as entitlement. We deserve what we have. After all, we’ve worked hard for it (unlike those people we choose to look down on).

Brickman, Dan Coates and Ronnie Janoff-Bulman discuss a similar phenomenon in the paper that originally described hedonic adaptation.

American soldiers in World War II with a high school education or better had greater chances of being promoted but were less happy with their promotion chances… The better educated soldiers saw themselves as doing poorly compared to their peers in civilian life or their peers who were already officers. Less well educated soldiers, on the other hand, saw themselves as reasonably well off compared to similar others in civilian life or their peers in the service.

That feeling of “doing poorly” perfectly describes what I’m referring to here as entitlement. Both in myself and others, I’ve found this sort of entitlement to an ugly, somewhat inexplicable trait. Getting my head around hedonic adaptation means that I better understand why it happens. That doesn’t make it any less ugly, but it starts to get at how it could be changed.

As I read more about hedonic adaptation, I started to see some patterns where I felt I was able to escape hedonic adaptation. Dan Gilbert made a quip in Stumbling on Happiness (p. 130) that helped to bring this into focus for me.

When we have an experience­ — hearing a particular sonata, making love with a particular person, watching the sun set from a particular window of a particular room — on successive occasions, we quickly begin to adapt to it, and the experience yields less pleasure each time. Psychologists call this habituation, economists call it declining marginal utility, and the rest of us call it marriage.

It occurred to me that there a certain experiences that never seem to get old: the drums coming in on The National’s “Fake Empire”, rereading certain Borges stories, going on a walk on the weekend with my family. And I think the key here is rediscovery. I don’t return to Fake Empire or The Garden of Forking Paths that often: once a year at most, if that.

Our weekend walks are designed to be different. We try to avoid doing the same thing, doing the same walk. Each walk is a new adventure: we walk new paths, find new rocks, identify new plants. There’s a risk with this approach. We’ve been on some terrible walks, but we’ve discovered some great ones, too. As with books and music, we occasionally return to the great walks, usually when we want to share them with some friends, but we don’t return to them again and again.

This seems to point to one way of avoiding the treadmill of hedonic adaptation: that original pleasure doesn’t dissipate if you return to an experience occasionally. However, I’m not entirely sure if this is enough to deal with the problem of entitlement. A job isn’t something you can return to occasionally. A house must be lived in. A goal, once accomplished, is likely to lose its lustre.

I think the key probably lies in focusing on intrinsic motivation, choosing to focus on the challenges of a job or career, rather than the promotion; seeing a house as a base of operations, rather than as an investment; choosing goals that make real difference rather than those that improve your net worth. It’s an ideal, and not an easy one at that. I’m nowhere near living in that way, but I’m starting to believe that just trying is well worth it.

The grain of prevailing wisdom

[I]n the mid-nineteenth century there was simply no context for such a radical overhaul of geological theory; no other pieces of knowledge with which the theory itself could fit. A mainstay of nineteenth-century geology was a belief in the existence of enormous land-bridges which had at one point joined the world’s continents, but had since then crumbled into the oceans. These land-bridges explained the existence of the same species on different landmasses, and seemed far more plausible than mobile continents.

In 1912, therefore, [Alfred] Wegener was arguing against the grain of prevailing wisdom: if his theory were correct, it would nullify many of the founding assumptions of nineteenth-century geology. Worse still, Wegener was an intruder, a trespasser on the turf of the geologists. For his main field of research was meteorology – he was a pioneer in weather-balloon study and a specialist in Greenland, where he led several successful, and one fatal, Arctic research expeditions. How could a weatherman presume to dismantle at a single stroke the complex and magnificent edifice of nineteenth-century geology?

Robert MacFarlane describes the reasons why Alfred Wegener‘s theory of continental drift wasn’t widely accepted by geologists until the 1950s.

This reminds me of Thomas Kuhn‘s notion of a “paradigm shift.” Specifically, it brings to mind his contention that two scientific paradigms are incommensurable, that the propositions of one paradigm are impossible to understand from the viewpoint of another paradigm.

This clash of world views interests me: when it is impossible to get across your point because a certain world view is so entrenched. Wegener’s approach is laudable: he simply kept explaining his theory, publishing and republishing The Origins of Continents and Oceans three times between 1915 and 1929. But is this laudable only because when know he was eventually proven to be (mostly) right? If he’d been wrong would his persistence seem laudable or simply a bit crazy?

Everyone who disagrees with someone else is likely to cast themselves as the hero, squaring up bravely to ignorance or just plain idiocy. Certainly having evidence to back up your claim helps,

Certainly, this is the ideal of the scientific method (or of a Lean startup): have a hypothesis, test a hypothesis, it either works or it doesn’t. The results of the experiment give us the answer.

Too often, though, this isn’t quite how it works out. A Kuhn points out, that evidence can be interpreted through a certain paradigm. The experiment design is questioned. The validity of the results is questioned. The interpretation of the results is questioned. Someone whose paradigm doesn’t allow for the results will always find something to question.

Getting to a point where we can listen and talk across these paradigmatic chasms seems vital, but perhaps it’s overly idealistic. In Kuhn’s analysis, this never happens. One paradigm eventually replaces another paradigm, but in the mean time two communities work as if in isolation from one another.

I’m idealistic, though. Even knowing that two competing paradigms are incommensurable probably won’t stop me from trying to do the impossible: trying to understand both. Or trying to understand one paradigm although I’m firmly placed in another.

Clearly, it’s time for me to go back and reread Kuhn.

Fugitive phenomena

Some of the terms I collected mingle oddness and familiarity in the manner that Freud calls uncanny: peculiar in their particularity, but recognisable in that they name something conceivable, if not instantly locatable. Ammil is a Devon term for the thin film of ice that lacquers all leaves, twigs and grass blades when a freeze follows a partial thaw, and that in sunlight can cause a whole landscape to glitter. It is thought to derive from the Old English ammel, meaning “enamel”, and is an exquisitely exact word for a fugitive phenomenon I have several times seen, but never before named.

Robert MacFarlane describing one of the disappearing words he’s collected which describe landscapes and the natural world.

I’m fascinated by language, and I’m drawn to these uncanny words that describe something specific by familiar. They have the alienated majesty of my own thoughts or observations captured in a single word, and they often have the power to change the way I perceive the world.

The Japanese word wabi sabi is one example of this. When I first heard the word, it immediately resonated with me. The idea of something becoming more beautiful with use was something I’d been thinking about already.

Learning about wabi sabi helped to crystalize some of those ideas, but also changed the way I perceived the world. It’s a concept I’ve returned to again and again when thinking about how things should be designed. Knowing the word fundamentally changed the way I experienced the world.

MacFarlane comments on this in his article.

Smeuse is an English dialect noun for “the gap in the base of a hedge made by the regular passage of a small animal”; now I know the word smeuse, I notice these signs of creaturely commute more often.

Not only is smeuse an amazing word, but it’s had the same effect on me. During my walks around our village I’ve noticed smeuses much more often than I did before now that I have a word for them.

It’s this point — naming something means noticing it — that lies behind MarFarlane’s project to collect seldom-used words that describe the landscape and natural phenomenon.

A recently published version of the Oxford Junior Dictionary removed natural words, such as “acorn”, in favor of digital words, such as “blog.” MacFarlane places his project in this context:

The substitutions made in the Oxford Junior Dictionary – the outdoor and the natural being displaced by the indoor and the virtual – are a small but significant symptom of the simulated screen life many of us live. The terrain beyond the city fringe is chiefly understood in terms of large generic units (“field”, “hill”, “valley”, “wood”). It has become a blandscape. We are blasé, in the sense that Georg Simmel used that word in 1903, meaning “indifferent to the distinction between things”.

There is a relationship between our experience and the words we use to describe it. It works in both directions. As our interactions with nature decline, so too will our our use of words that describe specific natural phenomenon. Those “fugitive phenomena” are less likely to be noticed, so why would we need words to describe them?

I worry that we’re spending less and less time in nature. I worry that we’ll lose more than just words. I worry that we losing the lessons that are learned when you spend time climbing a tree, buiding a den or losing yourself in the woods: self-reliance, cooperation, close observation of your surroundings. I worry even more because these skills aren’t prioritized by our current education systems.

I’m not convinced that collecting these words will necessarily change this on its own, but I believe that MacFarlane’s project is worthwhile as a part of a larger project to reverse this trend. Collecting these words takes a stand for taking the time notice these things that are rarely noticed. If they spark the curiosity of just a few people or change the way they view the natural world, then it’s well worth it.

The practice of awareness

The practice of awareness takes us below the reasonableness that we’d like to think we live with and then we start to see something quite fascinating, which is the drama of our inner dialogue, of the stories that go through our minds and the feelings that go through our heart, and we start to see in this territory it isn’t so neat and orderly and, dare I say it, safe or reasonable. So in the practice of awareness which as gone on for centuries after centuries and millennium after millennium, human beings have asked themselves, Hmmmm, how do I engage this process in a way I don’t become too frightened by what it might unfold or too complacent by avoiding it. This is the delicate work of awareness.

Rebecca Solnit’s observations on what we learn when we give ourselves time to be aware (A Field Guide to Getting Lost, pp 198-199) struck a chord the moment I read it.

A few months ago, I started making time in the mornings to “sit quiet.” It’s funny, though. Though it may outwardly appear quiet outwardly, inwardly it’s anything but.

I’d hoped for something else when I started doing this. I’d hoped for the opposite. It’s cheesy, I had hoped for “inner peace.” I don’t think that’s how I put it to myself, but that’s what I wanted. A place to go to find a sort of silence. A refuge from the constant barrage of everyday life. That’s not what I’ve gotten, though. At least not so far.

The result of sitting quiet two seemingly contradictory things: awareness and focus.

“The drama of our inner dialogue” is absolutely what I experience. The moment I sit down and stop doing, my mind sets off in any number of directions. I think about work, family, the book I’m reading, an snippet from an article I read months ago, a television show I’m watching. These threads of thought come thick and fast. As they do, I let them come, take note and try return my thoughts to my breath, my body or my physical surroundings.

This doesn’t happen immediately, though. Often, my own thoughts carry me away in some direction I had no intention of going. It takes a while before I realize this has happened. I’m so busy following the thread of my own thought that I don’t even realize that I’ve done it.

Sitting, being aware of what I’m thinking, bringing my thoughts back: all of this has helped me learn to focus. Even when I’m not doing this, I’m now much more able to know when I’ve stopped paying attention to a person, a conversation or a meeting. It still takes a while, but I’m much better at bringing myself into the room. I’m getting better at paying attention to other people, rather than what I’m thinking, what I want to say next.

The other benefit is one I didn’t really expect: I know my own mind better. By giving myself time to sit quiet and pay attention to the swirl of thoughts and ideas in my head, I actually know what I’m thinking. I know what I’m worried about. I know what I’m excited about.

When I started, I thought sitting quiet might provide an escape from my thoughts. It hasn’t. As Solnit points out, at first this was frightening. It still is sometimes, when I come across a fear or a worry I wasn’t aware of. Knowing about them changes them somehow. No longer lurking the shadows, they’re less frightening. Just knowing about them makes it easier to breath.

The same goes for ideas I’m excited about. I think there’s a fear in exciting ideas that they’ll never get done, that they’ll disappear into some corner of my mind. Slowing down and spending time with those thoughts makes that less scary. By knowing which of my own ideas are exciting, I’m better able to choose what to do next.

Solnit calls this the “practice” of awareness. This is important, I think. Practice is actually doing something, moving beyond theory, learning through making mistakes, learning through getting it wrong. There are times when I sit down and my mind is a riot of thought. I spend a lot of time chasing one stray thought or another. At the end, it seems I’ve not done a very good job of bringing my thoughts back. But I’ve practiced. Practice also means the way of doing something, something you do over and over again. It’s not so much that “there’s always next time,” it’s more that “there’s always this time.”

Harsh empathy

I’ve come up with similar findings in a series of studies done in collaboration with the Yale graduate student Nick Stagnaro. We start by giving people a simple test that measures their degree of empathy. Then we tell them some awful stories, about journalists kidnapped in the Middle East, about child abuse in the United States. And then we ask them how best to respond to those responsible for the suffering. In the Middle East case, we give a continuum of political options, from doing nothing to public criticism, all the way to a military ground invasion. For the domestic version, we ask about increased penalties for the abuser, from increasing their bail to making them eligible for the death penalty. Just as with the genetic study, we found that the more empathic people are, the more they want a harsher punishment.

Paul Bloom described the dark side of empathy recently in The Atlantic.

I knew immediately on reading Bloom’s article that there was something in it, something that I wanted to get it. It’s been a week since I read it, and I think I’m nearly there.

I knew, of course, that this applied to me. In the article, Bloom mentions “scans for specific genes that make people more sensitive to vasopressin and oxytocin, hormones that are implicated in compassion, helping, and empathy.” I’ve not taken one of these tests, but as someone who has been known to cry at television commercials, I’m fairly sure that I’d test fairly highly for these genes.

The dark side Bloom discusses certainly applies to me. I immediately dislike someone hurts someone else—physically or emotionally. I may think I can hide the fact that I dislike them, but experience has proven otherwise. I’ve twice had people I once knew come up to me years later and say “I got the impression that you didn’t like me much.” They were right. In both cases, the person had once done something to a close friend. Not anything terrible, just the standard unkindness of someone who is being thoughtless.

Empathy can be a dark lens through which I view people. I don’t think I fully realised this until reading Bloom’s article. When friends and family are involved, this has affected my personal life. But I can see now that it’s affected my professional, as well.

I can recall a conversation with a colleague at a new job. Another new recruit and I had a question about some button copy. We were both fairly convinced that the copy wouldn’t be clear to our customers. It was a gut feeling on both our parts, but the copy just felt wrong. We started to discuss it with someone who had been at the company for much longer than us. His response was something along the lines of “that copy works.” It was said with absolute certainty. My immediate response was “Really?” You know the kind of “really?” I’m talking about. The kind intended to make the other person feel like an idiot, dripping with disdain.

Just as Bloom describes in the article, this disdain was coming from the right place: empathy for our customers. The reaction was over the top, though. I may have been taken aback by their certainty, but it proved well founded. It turned out, I was the idiot and I had jeopardized a relationship with a person I’d need to work with closely on a daily basis.

My first job out of high school was working for Greenpeace. I spent about a year there, but eventually left. One of the reasons I left was because of the way we talked about the people who ran companies. At a city council meeting, one of our members found herself talking to the head of a company responsible for an incinerator we were trying to shut down. It wasn’t until halfway through the conversation that she realised who he was. She told us about this during one of our meetings. She said said he was actually rather nice. Perhaps we should see if we should speak to him. She was immediately shouted down.

Greenpeace didn’t manage to shut down the incinerator, at least not while I was there. The thing I learned from being at Greenpeace is that you can’t talk to a monster, and we choose who to turn into a monster. Perhaps, though, our empathy for other people makes this choice for us.

A lot of people who do what I do for a living spend a lot of time with the customers of they companies they are working with. We spend even more time thinking about those customers. Our job is coming up with solutions with those customers in mind. This is absolutely what we should be doing.

However, that dark side or empathy comes up again and again. Our empathy for customers results in unnecessarily harsh judgements. We judge the people who did the work that preceded us, the people that run the companies we work for, the people that we work with on a day to day basis.

I was once speaking with a friend about a usability review of a website he’d worked on over a number of years. It was clear that he felt the whole thing was a waste of time. It turns out the problem was that the review contained comments along the lines of “Clearly, no consideration has been given to…”, “It appears that no one has thought about…”, “Not sure what the aim was here.” These comments were certainly coming from the right place: empathy for the customer, but the end result of these comments was that nothing in the usability was going to be acted on.

This friend had worked passionately over a number of years to make his company succeed and had been involved in most of the areas of the website which were being commented on. His response to the comments was something along the lines of “F*** them. They clearly don’t understand the challenges and thinking that went into those pages. They didn’t even ask about it. We’re not changing anything.”

I didn’t write that usability review, but I could have. There are several heuristic reviews I’ve written that may well have contained that kind of language. Now I find myself wondering whose work I was dismissing and if I managed to offend someone to the point that they simply ignored those recommendations. 

Empathy for people—for our customers—is a good thing. It can backfire on us, though. Our misplaced judgements can inadvertently make our jobs difficult if not impossible. If I had asked questions instead of coming out with a thoughtless “Really?”, I would have had a better starting point making improvements. If Greenpeace had managed to speak to the head of the company as a human being rather than a monster, perhaps some compromise could have been made. If the author of the usability review had been able to apply the Peel mantra and honor the work done by others, some of the opportunities for improvement would almost certainly have been acted on.

The more I do what I do, the more I feel that the hardest part of my job is taking the time to listen. I really like what John Maeda has said about storylistening. Each of the examples of harsh empathy I’ve given above involves someone “getting stuck in their own story.” That button copy is worse for our customers. Anyone who runs a company that pollutes is inherently evil. Whoever designed this website didn’t have their customers in mind at all. None of these things are true. And believing they’re true clouds our judgement and means that we’re quite simply misinformed. It takes time to listen past our judgements, but in the end doing our jobs well means doing the hard work of listening before we make a decision.

Real people

[E]very year, I tell my students that marketing is the only function with the organization that is expressly designed to sit at the intersection where business meets people. Real people. And the problem with real people is that they don’t see the world the same way a businessperson does. they don’t speak the language of bullet points; they don’t organize the world into flowcharts and frameworks. People, real people, view the world more organically. They are idiosyncratic. They are unpredictable. They are beautifully disorganized.

Youngme Moon in Different (p. xvii) discussing the how people differ from our ideas of them.

As a product manager, I strongly disagree that marketing is the only function in a company where the business meets people (I’m pretty sure most of our customer service department would, too).

Nevertheless, I love Moon’s description of real people. It reminded me of something Peter Morville wrote about the ambiguity inherent in communication.

Our ways of thinking about the people for whom we’re designing–segments, personas, etc.—are in many ways inaccurate. They can also be useful is used thoughtfully.

Nothing replaces spending time with people face-to-face. I recently did some testing of some changes we were making to a key part of our product at work. Whether I went out to see our customers or brought them into the office, I invited other people from around the company to take part in the testing. This was much more effective than any report I could have written or video I could have shown. People came back from the excursions knowing what we needed to change and why. I didn’t have to say a thing.

Design + Banter 18

See ya later, suckers

Rik Lomas (@riklomas)
Founder, Steer & SuperHi

  • Moving to NYC. How do you move there and be self-employed?
  • Google says it’s a nightmare.
  • Rik got a lawyer, went to see here.
  • She asked, “What is your job?”
  • He rambled, she asked, “What is a developer?”
  • They went over and over it and came up with a single sentence: “I teach people to make websites.”

User wants complicated thing –> simplify –> User can do that thing
(Applies to both the lawyer and to building websitess)

5 problems that SuperHi solves

Learning to code is scary

  1. Have sensible defaults
    • Get simple stylesheet when you open SuperHi
  2. Remebering difficult concepts
    • Colour: small color next to hexcode that brings up colour picker
    • Make margins and paddings easier: again a hover state that shows the margin and padding
  3. Technical copywriting
    • Making Git easier to use for normal users
    • Two buttons: Save to history, go back in time
    • Try to keep copy as simple as possible
  4. Getting a site online
    • “All you need is an FTP program, and hosting platform, and a domain…”
    • Make it easy to get a site online: create an account, create a project, publish.
    • Most tools are aimed at advance users. For beginners, be opinionated.
  5. If a tool isn’t there, make it
    • Example: making background videos easy

Our job is to help people do the things they want to do, and not get in their way.

Use your words: talking about your work

Camilla Grey (@camillagrey)

  • Was head of content at Wolff Olins. Brand strategist before that.
  • Does both brand & content.
  • Likes to help designers write.

Make friends and win work and get promotes and influence people

There is a need for articulating the thinking behind a design.

Things she keeps hearing:
* “We keep losing work to F***** ****”
* “We need to editorialise our process.”
* “We want to be a part of a community of digital leaders.”

  • Make friends: – Assumption that a blog post needs to go viral. The most important thing is connecting with your peers.
  • Get promoted: – Every agency: the designers that get promoted fastest are the best at communicating why their idea is the best.
  • Win work – The ability to talk about your work in the frame of a brief you’ve been given.
  • Influence people – Talk and find other ways to communicate your visuals means you can help shape the future of thinking in your field.

Five things to help you get going

  1. Practice – you don’t have to publish the first thing you write
  2. Read – identify who writes well, and unpack why their writing works for you
  3. Plan – get someone to “emotionally spot” you. tell your boss you want to do more writing. get them to read it and give you feedback
  4. Respond – if you can’t think about something to write, write about something happening in the world around you
  5. Move the last bit to the top – The place where you land at the end of it all is where you should probably start.

The Anti-Complacancy Design agency

Neil Cummings (@NeilCummingsEsq)
Creative Director, Wolff Olins

Big D

  • Design is getting a seat at the table.
  • No longer a part of R&D, product, etc.
  • Bigger customers, bigger challenges, bigger questions design needs to answer
  • Big companies are bringing design in house
  • Young talent want to work for big brands as much as big agencies
  • The type of agencies that are being brough in house are agencies taht have a specialist function (mobile, service design, ux, innovation agencies)
  • A big agency shouldn’t be seen as a specific function. Wolff Olins is disassociateing themselves from “brand.”
  • Wolff Olins needs to be seen as an “and” business
  • Briefs come from big and fundamental business challenges, WO needs to be able to attack those and draw on a broad range of skills.
  • Spirit – Wolff Olin’s spirit is “push it” – designers should be open to push every aspect of what WO does
  • Push ambition – use this to drive your work forward
  • Push people – this is about getting the user into the conversation during the development process
    • testing is often about validating pre-formed ideas
    • how do you involve users to make design more radical, more thoughtful?
    • example: sent a box with a button around the world, and asked people: “This is what a box that is going to do one thing for you. What is it?”
  • Listen – this opens up how you can make your brand come to live. It comes to life with the tiny interactions people have with your business.
  • Lessons from Tim Allen
    • about participants not audience
    • experience design is about people, and those people aren’t you
    • experience design is about making (brining in and integrating a development team)
  • Push craft – this isn’t just about typographic craft, finding new ways to find visual effects that you want, how to make your ideas more relevant, make your vision replicable by others,
  • Push culture – when you create ideas for business, it’s hard for them to replicate it. They are kind of anti-design. You have to teach them how to design. Give them the tools and create spaces where it’s comfortable to be creative.
  • Push process – you have to be serious about how you design the process of your project. Better ways to design things aren’t in the brief.

JAM 2015

Note: These notes were taken live, so there will be gaps, grammatical errors and other mistakes.

10 Lesson I Learnt the Hard Way

Pip Jamieson (@Pip_Jamieson)
Founder, The Dots (@The_Dots_UK)

“I’ve seriously fucked up along the way.”

1. Hire happy positive people

  • Team is the most important thing in building a product.
  • People who look good on paper might not be right for your business.
  • “I want people to come to me with solutions not problems.”

2. Don’t be afrtaid to work with people offshore

  • Competing with Google, Facebook and other big companies for talent.
  • Development team based in Sri Lanka. They’re amazing. Zero attrition.
  • Product & design are in-house, but dev is offshore.
  • Tools: Slack, Jira, invision

3. Keeping a team

  • “I’ve lost staff because I’ve burnt them out”
  • The chart is great: performance, arousal, Panic Zone
  • You can push a team too hard
  • Team can’t work on the weekend
  • They have to leave at 7:00
  • Constantly getting the trained up

4. Building a product driven culture – meet users

  • When they actually showed the interface to creatives, they hated the look and feel
  • Surveys: typeforms
  • What I find with surveys is that people recommend changes to twhat they see. Chatting with users results in finding out what people’s challenges actually are.
  • People go to word mouth when hiring. Talent is important, but cultural fit is more important.
  • We would never have known that if we hadn’t just listened.

5. Building a product driven culture – hn

  • Team is so passionate that the idea flow is so overwhelming
  • We can’t build everything
  • Internal pitch days every two months
  • If people have come up with a great idea they put them in a folder. Every two months they choose their best two ideas. Pitch for two minutes. Team discusses it for two minutes.

6. Prioritising ideas

  • Priority matrix

7. Down and dirty testing

  • Lots of ideas, but some are shit
  • We get people in every week to see how they are using features.
  • Tools: hotjar for heatmaps, tableau for data collection (pulls in data from analytics, back end, accounting software)

8. Design rules!

  • People expect beautiful things now. They expect usability.
  • invision: prototype and show to users

9. Product development – 5 whys of mistakes

  • Try to get to the core of what the problem is
  • Site went down for two days. Root cause: not robust enough testing or robust enough go-live process.

10. Celebrating the wins

  • Glory wall (not a great name)
  • Feedback from users, great places we’ve found, good talking point for when investors come in

Designing a Better Onboarding Process

James Gill (@JameJGill)
CEO, GoSquared

1. What onbaording entails

  • The management of the early stages of a relationship between a business and a customer. (Collins dictionary)
  • Onboarding is hard.
  • (missed his definition)

2. Ways to improve

  • Think about the staes of our app: Awesome screen, but also Empty and Error states.
  • Onboarding is a flow.
  • Sign-up —> Homepage —> Empty —> Full-on awesome
  • Examples: Developers vs. Marketers
  • Onboarding needs to not piss off either of these users
  • Reduce the # of steps
  • Get to Wow ASAP – focus on the important stuff
    • Every step in the obarding process is a hurdle
  • Set sensible defaults – It’s easy to push decisions off to the user, but it’s lazy product management.
  • Gamify – Think about how to get people to do things, though not necessarily in their first session
    • You don’t need to offer a reward, just having checklist is enough
  • Emails are part of onboarding
    • Make the relevant
    • Don’t send too many
    • Deliver happiness – don’t just spam people
  • Notification (Slack stops sending emails and automatically sends push notifications.
  • Set up a weekly task to sign up as a new user
  • Measure onboarding
    • Good metrics are actionable
  • Define successful onboarding (Install traffic code and sees traffic spike)
  • Chort analysis

3. 3 examples

  • Sunrise – two steps (both because of Google) and you’re there
  • Apple Watch – push the onbarding into an app, most beautiful QR code
  • Slack – only ask for an email address to sign up, then get you to fill in your profile by using Slack


  • Marvel – prototyping
  • Sheperd
  • Olark – live chat
  • Drip – very nice onboarding emails

Good sites

  • – see “The next feature fallacy”

Where Do Good Product Roadmaps Come From

Will Swannell (@wswannell)
Founder & CEO, Hire Space

  • A product roadmap shows how a product is likely to develop.
  • It aligns stakeholders and allows effective planning.

How to present your roadmpap

Five things that a good roadmap has:
* Transparent and accessible
* Can have regular attention brought to it
* People can leave easy feedback and engage with it
* It should be limited in size
* Can be quite easily editable, torn down – set the expectation that this is where we are likely to go

What should go on a roadmap?

  1. Is it big?
    • Is it something that everyone really, really needs to know about?
  2. Is it going to shift a KPI in the next 4 months?
  3. Is it scalable?

How items get (and move) on a roadmap

  • Stakeholders – Team, users/customers
  • Time – Get stakeholder and devloper to give it a number in the fibonacci sequence to estimate this
  • Data, e.g. dropoffs in different funnels across different cohorts
  • Dependencies
  • Decision maker – voting, but groupthink can make bad product decisions, each product should have a single owner

And end-to-end example

  • Venue Groups, e.g. Oval Space has a sister venue: Pickle Factory
  • You can wind up with two users who are managing related spaces.
  • #1 customer service ticket – “What’s my account?”

Product’s Perception And The Needs of Its Customers

Karolis Kosas (@karoliskosas)
Creative Director, YPlan (@YPlan)

  • Too many things to do in London, but people don’t plan.
  • Couldn’t cater to everyone with three events, which is what the original app had.

  • Adding more events meant it wasn’t reliable, so the decision was made to add structure (move from a corner store approach to a Sainsbury’s approach). What was needed was something in-between these two.

  • Intent – predict the intent of people going out.

  • Context
  • Resulted in Categories: Date night, going out with friends, Sunday Brunch, Stay Dry, Free culture

  • People like the quirky and niche things they find on Yplan because they can show off to friends.

  • But the data showed that mainstream was the bulk of the tickets sold.
  • Added a website to pull people in to the big stuff.

  • A lot of customers say that don’t plan a week in advance.

  • Not true for bigger events, they book to get the best deal and are flexible with the dates.

  • For events like theatre, it’s not about the cheapest price, it’s about the value for money (e.g front row vs. sat behind a pillar).

  • Reliable supply – the more supply you have the better the conversion is going to be.

Design at SwiftKey

Scott Weiss
VP Design, SwiftKey

Three components to design at SwfitKey

  • UX Design
  • Visual Design
  • UX Research
    (Skipping copywriting, motion design that they do as well)

Functional roles

  • 1 VP Design
  • 2 Senior UX Designers
  • 1 UX Designer
  • 2 Associate UX Designers
  • 2 Visual Designers
  • 2 UX Researchers

Daily Scrum

  • What did you do yesterday?
  • What are you going to do today?
  • Do you need any help?
    People used to go into gory detail about what they did, but these questions can avoid that.

Co-seating with Engineers & PMs

  • Design sits together, but there are hot desks amonghts the engineers and the product managers

Design Kanban

  • Swim Lanes
    • Typing Experience
    • Visual Design
    • Strings
    • Research
  • Status
    • To Do
    • In progress
    • Resolved
    • Closed

Design Wiki

Weekly Sprint Demos

  • This is when the engineering team shows what they’re working on
  • If people aren’t pulling their weight, it shows. So does doing extra.
  • Demo wall gives everyone the opportunity to know what’s going on

Visual Style Guide

  • Borrowed Google’s style Guide
  • Built their own style Guide
  • Documents patterns, but not every bit of design

Brand book

  • Brand isn’t logo
  • Tone of Voice
  • Typography
  • Colours
  • Graphic devices
  • Collateral

Building Culture

Tim Davey
Co-Founder & Head of Product, OneFineStay

Defining your culture

  • Very nebulous thing?
  • More than ping pong tables in your office
  • “the way a collective of people make individual decisions”

  • Types of culture

    • Product-driven (Apple) – Make what customers want you to build
    • Customer-driven (Amazon) – Make what your customers want
    • Engineering-driven (Google) – Sell what you can build
    • Sales-driven (Microsoft) – Build what you can sell

Communicate the vision

  • They made 6 motivational posters for their cultural values. These didn’t really work.
  • Instead, they distilled it into values:
  • Heroism. Go out and be with the customer if they’re having a problem. You end up taking people who hate your product and you turn them around.
  • Craft (data-driven development) – Focus on taking people who are interested in your business and making them more interested in the business. This makes sense for later stage businesses.

Embed it with process

  • use process, to enforce cultural habits that overcome decision fatigue
  • Confirmation bias (issue for customer-driven cultures) – A tendency to seek evidence that agrees with our position. Looking for data to support your hypothesis. You should also be testing an anti-hypothesis when A/B testing.
  • Authority bias (issue for product-driven cultures) – Tendency to over-value the opinion of those who are seen as an authority on the subject. OneFineStay does Crazy Eights: get people who are working on the problem to do eight different versions, no matter how crazy they are.
  • Bandwagon bias (issue for sales-driven cultures) – Tendency to do things because many people do the same. If you have to do something because CEO makes you do it, test it.
  • Overconfidence bias (issue for engineering-driven cultures) – Tendency to belive ourselves less likely than others to experience negative life events. “I can do it better than anyone else.” Use prototyping to test ideas.

Building culture

  • Who’s driving?
  • What is your focus, right now?
  • What processes do you need?
  • DO IT!

Putting People At The Heart Of Government

Anna Wojnarowska (@voina)
User Researcher, Government Digital Service

Within GDS

  • Digital (
    • Digital by defaults
  • Technology (Anna sits here)
  • Data
  • Operations

What’s the need?

  • Gov’t IT spending is 1-2% of GDP.
  • 4 million desktop computers in UK gov’t.
  • Some teams mark slow hot-desking computers with black dots.
  • GDS wanted to show that procuring computers for people could be done differently.
  • Technology at least as good as people have at home.

Our approach

  • GDS says that user needs are more important than government needs.
  • Civil servants are users, too.
  • Anna was told to find out what it meant to be a civil servant
  • She has a digital anthropology background, so she wanted to go do ethnography for a year, but couldn’t.
    • Agile – need to go test things with people and report back.
    • User research as a team sport – every member of the team needs to understand users in the same way. She couldn’t go along. Other people came with her when she was doing interviews with users.
  • GDS approach
    • Build empathy – understand who the people are that you are delivering to. Cabinet office seen as young people who would welcome change. GDS actually seen as a threat. Used personas to understand people. Personas were completely detached from roles.
    • Break artificial divisions – People saw technology needs in terms of roles. Instead, GDS focused on what people need based on their context. 7 different profiles (probably too many).
    • Make the information useful. – e.g. Found out what percentage of the population each of the 7 profiles were. Useful for those who needed to supply devices to these people.


  • Mobility or flexiblity?
  • Look holistically – Think more broadly than just introducing change into one organisation.
  • Tailor innovation – Don’t just introduce a new device because it’s new, but because it is better for you. Also ensure that people know how to use the device.
  • Develop skills – Instead of investing in new technology, think about what new technology will do to users. What are the skills gaps, and how can they be addressed? Development is something that civil servants struggle with. They often leave the government because of this.
  • “It’s more than a device” – Change does not have to be limited to technology. Change in process can address the core of the issue.

My journey to Data-driven product

Graham Paterson (@GPat_UK)
Product Manager, Intuit

Data is more than just traffic and conversion

  • How TransferWise does product: It’s not the leadership team that decides what to do. Every product manager decides what they want to work on.
  • No one is ever wrong, they just have access to different information.

What is data-driven product design

Three key aspects:
* Delight (e.g. NPS, return rates, social media sentiment)
* Impact (What improvement have you had to your customer’s lives?)
* What to do next

Focusing relentlessly on your users

  • When I was building products, I was doing it for myself.
  • Divorce yourself from the process and focus on the metrics. Are they improving for your users?

Two types of data

  1. Company-based data
  2. Focus on customers (focus on customers)
    • Important to store this in one place, so you can build up a picture of your users.

Segment as much as is relevant

Example: NPS score started going down. Panic. Looking at the data revealed that score stayed the same in UK, but was lower in areas where the company was growing.


  1. Solve for one person
  2. Solve for their segment
  3. Solve for more segments

Data for roadmap ideas

  • User feedback
  • NPS surveys
  • Your sales team – they have greater customer empathy than anyone else in the company
  • Customer contacts

Customers will tell you…

  • People will offer suggestions about how to improve your product.

Good data means testing quickly

  • You can quickly test improvements

Research For The Rest

Rachel Ilan Simpson (@rilan)
UX Designer, Google Chrome Team

Creating the surface between a person and the piece of code that does something for them.

Sense of resistance to doing user research in startups and large companies.

“User research” sounds daunting.
* How does it tell you something that a survey won’t?

Talking to users is scary.
* Gets scarier the further along you are in the development process.

User testing allows you to course-correct sooner rather than later.

Let’s know what to make and how to make it.

Each step of the way
1. Identifying user needs
2. Meet those needs
3. Iterate the idea
4. Are people using your product?

User research is more than a report – It shouldn’t just inform your product, it should change it.

User research should be the backbone of the product. Best way to do that is to bring in the whole team.

To do this, you need to tell stories.

User research is about empathy. It’s in light of this empathy that a team will understand why they need to make changes.


  • Intercept interview – short interviews done in a public space with a wide range of people.
  • In-home interviews – longer interviews done in the home.
  • Card sorts – set of cards with themes to be sorted into categoreis.
  • Usability tests – putting a user in front of your website and seeing what they do.

Trip to India

  • Communicated insights in terms of stories of real users.
  • Connecting user needs to the product.
  • Created prototypes based on insights & tested with remote user testing.

A less daunting method – pulse testing

  • Run a usability test with a small group of users every two weeks.
  • Rocket Surgery Made easy has a similar process. Four hours every month, including a lunchtime debrief.

What users are thinking when they use your product (according to Seth Godin)

  1. What is it? (Very important.)
  2. Do I trust it? (Judgement made in the first few seconds of using your product. Ask them: what does this remind you of?)
  3. What is it offering me? (Clear proposal of what that is.)
  4. How do I get it? (Call to action.)

Research isn’t something you do.

It’s something you practice.

Evangalize your insights

Use pictures, stories and videos as much as possible.

Make real change

Every user testing session is an opportunity to change something about your product.
Start with low-hanging fruit and go from there.