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

  • UserOnboard.com
  • GoodUI.org
  • LittleBigDetails.com
  • AndrewCne.co – 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 (gov.uk)
    • 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.

Designed against

Architectural deterrents to skateboarding and sleeping are interesting because – when noticed – they draw attention to the way that managers of spaces are always designing for specific subjects of the population, consciously or otherwise. When we talk about the ‘public’, we’re never actually talking about ‘everyone’.

When you’re designed against, you know it. Other people might not see it but you will. The message is clear: you are not a member of the public, at least not of the public that is welcome here.

Ocean Howell, former pro skater and currently an assistant professor of architecture history at the University of Oregon talking about anti-skate architecture in a Guardian article on defensive urban architecture.

What struck me was Howell’s point that people who are designed against know it. This was certainly true when I was a skateboarder: public spaces didn’t feel so public. This feeling of being “designed against” could certainly explain why Republicans use more energy when nudged to use less or the recently reported partisan nudge bias.

I’ve long suspected that nudges aren’t as subtle as some of the nudgers (myself included) think they are. Put another way: people who are using nudges and other tools to change behavior tend to overestimate themselves, and more often than not, they underestimate (and often offend) the people on the end of these nudges. No one likes to feel manipulated. More and more, I’m starting to believe that nudges are more effective when they are a stage whisper: we’re happy to go along when we’re included in the “secret.”

Harry Brignull has spent the past few years collecting and cataloging dark patterns used on the web. These are usually designed to get people to do something they didn’t intend to do, such as clicking on an ad, paying for a service or sharing personal information. In many of these cases, people figure (often after it’s too late) what has happened. While the designers may have believed that they were “changing behavior” most people simply wind up feeling tricked.

In Living with Complexity, Don Norman talked about desire lines: the paths that are worn into the grass over time, as person after person takes the quickest route rather the route than urban planners and architects intended them to take. As Norman points out, urban planners and architects tend to view this as an aberration, an error on the part of the people using the spaces they designed. But, then again, error is architecture.

All of this brings to mind the debates around Apple’s introduction of ad blockers in iOS 9. As online advertising has become more aggressive, the Internet starts to feel hostile, people start to feel designed against. John Gilmore once pointed out that the Internet interprets censorship as damage and routes around it. Overly aggressive advertising can certainly be interpreted as damage. The rise of ad blockers and the success of services like Instapaper, Pocket and Evernote’s Clearly could be interpreted as desire lines.

Howell is right, people know when they are designed against, even when that may not be what designers set out to do. At work, we recently redesigned a key part of our application. Both before and after we launched these changes, I spent a lot of time with our customers. For the most part, feedback was positive. During the redesign, we removed a few features that saw little usage. It helped us simplify the interface for customers. In speaking with those customers, they overall feeling was that they had been designed against. We had removed something that was a part of their overall workflow. We’d introduced new tools that we believed met those same needs, and we’re continuing to refine those tools with the feedback of those customers. Nevertheless, those initial conversations will stick with me: the very real of having been defined against, of having something that you want to do thwarted by somebody else’s decision. When that happens, it’s entirely understandable to feel that those decisions are aimed directly at you.

Unpublic spaces

[I]f you visit San Francisco … [y]ou’ll see people living in the streets, many of them mentally ill, yelling and cursing at imaginary foes. You’ll find every public space designed to make it difficult and uncomfortable to sit down or sleep, and that people sit down and sleep anyway. You’ll see human excrement on the sidewalks, and a homeless encampment across from the city hall. You’ll find you can walk for miles and not come across a public toilet or water fountain.

I finally got around to reading Maciej Cegłowski’s What Happens Next Will Amaze You, which has been much talked about recently. The topic of Cegłowski’s was the loss of privacy on the Internet and what can be done about it, but what struck me was the above passage describing design interventions in public spaces in San Francisco.

Dan Lockton has written about the these types of interventions as architectures of control. What strikes me about this type of design is that it often often solves the smaller problem. I was going to say “solving the wrong problem” but I think that’s not exactly right.

The larger problem here is obvious, but it is not an easy one to solve. The designers of these solutions (uncomfortable or nonexistent public seating, anti-homeless spikes, disappearing water fountains) seem to be asking one question: “How can we stop people from sleeping in public spaces?” A slightly different question—reframed by zooming out—might be, “How can we help the people sleeping in public spaces?”

Solving the smaller problem is usually easier. It also may also improve things or appear to improve things. There is, of course, the risk of hitting a local maximum that is inherent in all iterative design. In this case, though, solving the smaller problem appears to create another problem. By making a city progressively more hostile to the homeless, you make it hostile to everyone. In some sense, a “public space” starts to loose its meaning: can a space be said to be public if it aggressively discourages the public from using it?

I understand, though, how these smaller problems become the problem to solve. I understand how these solutions become reality. I’ve been in discussions where the smaller problem is being discussed, and someone else will try to bring up the bigger picture. The answer is often along the lines of “that’s not the problem we’re trying to solve here” or “that’s great, but we don’t have the time right now.” I’ve been on both sides of this. I’ve been the one trying to open up the conversation and the one shutting it down.

I don’t have the answer to this right now. I do have more questions. How do we keep the big picture in mind when we’re working on the smaller problem? Can keeping the big picture in mind change our approach the smaller problems? How do we determine when the right time is to zoom out in order to focus on and discuss the big picture?

And of course, Cegłowski’s question is the hardest:

If at the height of boom times we can look around and not address the human crisis of our city, then when are we ever going to do it? And if we’re not going to contribute to our own neighborhoods, to making the places we live in and move through every day convenient and comfortable, then what are we going to do for the places we don’t ever see?

By focusing only on the smaller problems, we run the risk of inadvertently designing unpublic spaces, whether that be our town squares or the whole of the Internet. Keeping the bigger picture in mind is hard. It’s easy to get lost in the details.


Switchtracking is a pattern in feedback conversations that is so common that it’s instantly recognizable: someone gives you feedback and your reaction to that feedback changes the subject.

A switchtrack is that place where the track is going a long and there is a switch. Depending on the way the switch is turned the train will glide smoothly onto a second track or stay on the first track.

So what’s happening is a conversation starts, the first person stays on their own conversation, the second person smoothly switches to a different topic which is their own reaction to the feedback and often the feedback that they have themselves for the first person. They get further and further apart and they don’t even realise that they’re going in different directions.

There are really two topics on the table… and [each participant] is hearing the conversation through the lens of their own topic. They’re not even realising that there are two topics on the table.

Sheila Heen discusses switchtracking on the first episode of Shankar Vedantam new Hidden Brain podcast. The Hidden Brain podcast is one I’m going to continue to listen to. You should definitely listen to this episode, if only for Heen’s entertaining example of switchtracking.

Heen was right. Switchtracking is instantly recognizable. I’ve been focusing on improving the conversations that I have with other people, both at work and outside of work. While I had a vague notion that either I or someone else was “changing the subject,” having the idea of “switchtracking” is going to make it much easier to identify when I’m doing this.

It will also make it easier to identify when someone else is doing this. As with asking more questions, identifying when someone else is switch tracking is useful not so that I can catch people out, but so I can identify what is important to the person with whom I’m speaking. Heen also addresses this in her discussion with Vedantam:

For the person doing the switchtracking, you’re just thinking, “Well, that’s not the most important thing to talk about. What we need to talk about is your problem.”

The person who started the conversation sometimes actually does realize that the other person is changing the topic, and they view it as making excuses or distracting or trying to take us off on a tangent. To the second person, it’s not a tangent at all. It’s the most important thing going on.

So that’s what the fight then becomes about. We’re both aware we’re having an argument, and the real argument is about what’s the most important topic here between us.

Interestingly, Vedantam asks Heen what happens when both people feel their topic is the most important and neither wants to give way. Heen’s response: “You’re sunk.”

This, for me, was the key insight of the podcast. I’ve been in more conversations that end like this than I’d care to admit. “You’re sunk” is exactly right. Those conversations go nowhere. Or rather, they go round and round like a screw that’s lost it’s thread.

These situations aren’t irrecoverable. The parties can come back later, but in the heat of the moment, an impasse is reached. To overcome this, someone has to give up their agenda and start listening. I’m working on becoming that person.

An endless source of comfort

Our ability to measure and apportion time affords an almost endless source of comfort.

“Synchronise watches at oh six hundred,” says the infantry captain, and each of his huddled lieutenants finds a respite from fear in the act of bringing two tiny pointers into jeweled alignment while tons of heavy artillery go fluttering overhead; the prosaic, civilian looking dial of the watch has restored, however briefly, an illusion of personal control. Good, it counsels, looking tidily up from the hairs and veins of each terribly vulnerable wrist; fine: so far, everything’s happening right on time…

“Oh, let me see now,” says the ancient man, tilting his withered head to wince and blink at the sun in bewildered reminiscence, “my first wife passed away the spring of -” and for a moment he is touched with terror. The spring of what? Past? Future? What is any spring but a mindless rearrangement of cells in the crust of the spinning earth as it floats in endless circuit of its sun? What is the sun itself but one of a billion insensible stars forever going nowhere into nothingness? Infinity! But soon the merciful valves and switches of his brain begin to do their tired work, and “The spring of Nineteen-Ought-Six,” he is able to say. “Or no, wait-” and his blood runs cold again as the galaxies revolve. “Wait! Nineteen-Ought — Four.”… He may have forgotten the shape of his first wife’s smile and the sound of her voice in tears, but by imposing a set of numerals on her death, he has imposed coherence on his own life and on life itself… “Yes sir,” he can say with authority, “nineteen-Ought-Four,” and the stars tonight will please him as tokens of his ultimate heavenly rest. He has brought order out of chaos.

Richard Yates (Revolutionary Road, pp. 215-216) on the reassurance that measuring time brings: having a plan, whether it’s likely to happen or not; having a set notion of the past, whether it’s accurate or not; leaving out much and focusing only what we think we need.

From other-where

On referring to the books for information as to the history of the mimulus as a British wild flower, I found that in some it was not mentioned, and in others mentioned only to be dismissed with the remark that it is an “introduced plant.” But when was it introduced, and what is its range? And whom are we to ask?

And what, we should like to ask of our masters, is a British wild flower? Does not the same rule apply to plants as to animals namely, that when a species, whether “introduced” or imported by chance or by human agency, has thoroughly established itself on our soil, and proved itself able to maintain its existence in a state of nature, it becomes, and is a British species?

And, going farther back in time, it may be said that every species has at some time been brought, or has brought itself from other-where—every animal from the red deer and the white cattle, to the smallest, most elusive microbe not yet discovered; and every plant from the microscopical fungus to the British oak and the yew.

W.H. Hudson, in Hampshire Days, asking what it merans for a plant to be introduced. As he points out, mimulus (he’s probably referring to Mimulus guttatus,  or monkey flower) is widely distributed in the UK. The two wild flower books that I just checked still list it as introduced, though one also mentions that it is naturalized.

There is probably more going on here than just a question of whether a flower was native or introduced. Hudson’s parent were English and Irish, settled in the United States and eventually moved to Argentina. Hudson grew up in Argentina, established a name for himself there (and in England) as a talented naturalist, and settled in England when he was 33. As Jason Wilson points out in WH Hudson: the Colonial’s Revenge, Hudson resented the fact that he was never truly accepted into English society. (Having lived as a foreigner in two countries, I can empathize with that frustration.)

Hudson’s question about what is native and what is introduced is still valid, though. And his underlying motivations make it all the more interesting. The talk about introduced plants and animals, in particular “invasive species” is often closely related with the way immigrants (especially illegal immigrants) are spoken of. This is especially true when it comes to eradicating a species, such as grey squirrels or buddleia.

In many cases, the fears about “invasive species” prove to be unfounded, such as the concerns about kudzu taking over the southern United States.  These can often have benefits, such as extending the time certain pollinators have access to nectar.

Certainly, introduced species can have an impact on an ecosystem. This is cause for concern and should be paid attention to, but the discussion of so-called “invasive species” can often lose sight of what is happening ecologically, and other social anxieties seem to hijack the discussion. Hudson was complaining about the term “introduced” but I think that “invasive species” is even more problematic. It’s a term that is going to play on those social anxieties whether we want it to or not. Nobody wants to be invaded, and raising the spectre of an “invasion” isn’t helpful when trying to understand something as complex as the ecological impacts of different plants and animals.

Opportunities to practice

Design thinking is absolutely experiential, and I think the first mistake that we made when we started rolling this out eight years ago was, if you’re going to change the way people work day to day, that’s going to take a long time. You can’t just ask people to do it and expect them to change. You have to give them ample opportunities to practice so that they can then understand it and make it their own.

When we started eight years ago, the first mistake that we made was telling people to please do this. Everyone nodded their head and said, “Yep. We got it.” Then they went away, and then a year later no one was doing it.

So we tried again. The second year we said more forcefully, “Please do this.” from the CEO down. No one did anything.

We brought in inspirational speakers. We had really convincing Power Point slides about why they should do it. Everyone nodded their heads and nothing happened for two years.

It wasn’t until we had our first workshop–where we said, “Do it and do it now.”–that things really started to change. Because it went from being in their heads to being in their hearts and in their fingertips. They were starting to practice it themselves. We found that it takes people eight to ten times of practicing it before it finally resonates with them: what it means to them and how to start doing it every day.

Suzanne Pellican talking about introducing the practice of design thinking at Intuit. The whole talk makes a great listen, but there are three things that I want to pull out of from her story.

The first is that telling is not usually the best strategy for getting people to listen to you.

The second is that people change what they do on a day to day basis, not because they’ve been told to, but because opportunities are created for them to change.

The third is the importance of letting people practice, which means allowing people to get it wrong.