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

Tools

  • 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.

Findings

  • 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.

Iteration

  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.

Methods

  • 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.

Cartographic omissions

The land itself, of course, has no desires as to how it should be represented. It is indifferent to its pictures and to its picturers. But maps organise information about a landscape in a profoundly influential way. They carry out a triage of its aspects, selecting and ranking those aspects in an order of importance, and so they create forceful biases in the ways a landscape is perceived and treated.

It can take time and effort to forget the prejudice induced by a powerful map. And few maps exercise a more distortive pressure upon the imagination than the road atlas. The first road atlas of Britain was produced in 1675 by John Ogilby. It was a six-volume work, which claimed to be the only ‘Ichnographical and Historical Description of all the Principal Road-ways in England and Wales’. Ogilby’s maps showed a scrupulous attention to landscape detail: they depicted not only roads, but also the hills, rivers and forests that the roads ran round, along, through and over.

In the centuries since Ogilby’s innovation, the road atlas has grown in ubiquity and influence. Over a million are sold in Britain and Ireland each year; twenty million are thought to be in circulation at any one time. The priorities of the modern road atlas are clear. Drawn by computers from satellite photos, it is a map that speaks of transit and displacement. It encourages us to imagine the land itself only as a context for motorised travel. It warps its readers away from the natural world.

Robert Macfarlane (The Wild Places, pp. 8-9) discusses how maps can impact the way we perceive a place. This goes well beyond the map not being the territory. A map, like any good model, is wrong, but useful. For driving one place to another, a road map is a useful model. But maps are also a sort of language, and the language we use can influence the way we think.

Road maps are designed to be task-focused. They allow you to plan a route from Point A to Point B. Turn-by-turn navigation does this job even better. Road maps and turn-by-turn navigation are successful because leave out a great deal of information, but what is left out changes our perception. Instead of being aware of the surrounding landscape, we’re aware only of our own route through it, focused only on the blue line that draws us forward toward our destination. Everything else drops away.

The road map is only one way of representing a landscape. For the traveller who merely wants to move through the landscape, it is probably the right tool. For the traveller for whom the journey is the landscape (perhaps this is an explorer, not a traveller), there are other maps that show what road maps have left out: the topography, the history, the ecology, the geology. Of course, there is also everything that no map shows, and that’s where things start to get exciting.

Universal design

Marc Harrison’s simple and elegant Cuisinart design was based on studying the requirements of people with disabilities. The large and easy to use handle and button were inspired by the needs of people with motor skill impairments while the large clear text labels came from thinking about people with low vision. Though I am certainly not an expert on the history of industrial design, I have been told that Harrison’s work, as a designer and teacher, was an early and major influence on the design of so many innovative and ergonomic kitchen gadgets – products that are repeatedly referenced as examples of great design.

It has been almost thirty years since Harrison demonstrated that thinking about people with disabilities can result in innovative, influential and highly commercially successful products, yet too many people, especially in technology, still work under the false assumption that making products accessible is a burden (while struggling to discover sources of innovation).

Dean Karavite has written a short piece on Marc Harrison , who designed the Cuisinart food processor. Harrison, a professor at the Rhode Island School of Design, was a proponent of Universal Design.

Creating opportunities

Rather then just telling people to go the gym, public health professionals and advocates must work with architects, urban designers, and planners to reverse the design trends that have contributed to declining physical activity. Creating opportunities for exercise in daily life routines can increase physical activity and assist in controlling epidemics related to obesity, as well as contribute to environmental sustainability.

from New York City’s Active Design Guidelines.

What stuck me about the above paragraph form the Active Design Guidelines was the phrase “creating opportunities.” What I like about this is that it recognizes that the people we are designing for have agency and choice.

There has been a lot talk about behavior change for the last several years. I’ve written before that I’m not entirely convinced by it. Not least because it’s not always successful. Such as when nudging Republicans backfires and they actually start using more—rather than less—energy when shown how their energy use compares to their neighbors.

The idea of “behavior change” all too often leads us to think of people in the abstract, which leads us down the route of believing all people can be easily manipulated. This flawed assumption leads to not understanding the people you’re for whom you’re designing (e.g. not doing enough research) and to designs backfiring.

Creating opportunities, on the other hand, means we need to understand what opportunities are needed. It encourages us to look for something that has been missed, rather than using the same cheap tricks to try to get people to do what we want them to. It means creating more value than you capture, rather than extracting as much value as you can.

After taking Dan Ariely’s beginner’s guide to irrational behavior, I’m convinced that behavioral economics is a truly useful tool. I’m also convinced that much of behavioral economics has been badly used by the design community.

When I linked to a spirited criticism of nudging on Goolge+ (a post which seems to have gone missing), one of the replies was began with the assumption that “technology is morally neutral.” Even if I agreed with that (which I’m not entirely sure I do), language isn’t neutral. And the connotations of “behavior change”—power, arrogance, manipulation and control—make me very uncomfortable.

Focusing on “creating opportunities for change,” rather than “changing behavior,” puts the onus on us as designers. It means we should understand the people we are designing for and use that understanding to help them make their lives better. In other words, thinking about “creating opportunities” works as a kind of a handrail that guides us toward to the type of work that we should have been doing all along.

Update (September 18, 2015) I’ve realized a year after writing (while still thinking about the idea of open nudges) this that focusing on creating opportunities rather than specifically on behavior change fits in nicely with what Clay Shirky says about behavior being motivation filtered through opportunity. Understand people’s motivations and you can design an opportunity which will help them change their behavior. This is why nudging Republicans to reduce their home energy use backfires: the motivation simply isn’t there.

Technology and design solutions

Q. You talk quite a bit about design solutions vs. technology solutions — what can be done by designing the places we live differently, rather than putting an emphasis on “What’s the new electric car?”

A. The whole point of urbanism is that it reduces the demand on the technology. If we just posit that everybody’s going to keep driving 24-25,000 miles per household per year, the burden on electric cars and streets and parking and congestion — just the hundreds of square miles of solar farms or wind farms that we’re going to have to build — is going to be extraordinary. It’s much more cost-effective to reduce that fundamental behavior number, the amount of auto dependence we have, before we start thinking about what kind of automobiles we’re going to drive.

The same is true of energy in buildings. It’s exciting to see all the green technology that’s being applied to buildings, and it’s very, very important, but step one has got to be to build more compact buildings that inherently demand less energy to heat, cool, and light.

Peter Calthorpe discussing the difference between design solutions and technology solutions. I like this a lot. After reading through some of the back and forth design vs technology interchanges between Don Norman and Bruce Nussbaum. I’m not really sure technology vs design is a useful debate. Using technology and design to improve our lives and the world we live in, on the other hand, is very useful indeed. Chicken-and-egg questions and turf wars can easily distract my attention from what I should be focusing on: working on something I care about.

Related posts

Innovation vs invention

It is often said that invention is not innovation and I believe it. Invention has to have socio-economic value to become innovation. It has to be socialized or else it sits in the lab. Xerox Parc was famous for the huge number of digital inventions that never became innovations until people outside Xerox connected them to what people wanted in a PC. Dean Kamon’s Segway is a great invention still waiting for socialization to become an innovation that adds value to people’s lives. The entire Japanese robot technology industry is an example of invention that is not innovation because outside the labs, there is no use for them (unlike the lowly iRobot Roomba which does something useful–it cleans our floors).

Bruce Nussbaum’s reply to Don Norman from a few years ago. This is part of what I was trying to get at with my second point. “Conceptual breakthroughs” aren’t an innovation until they have an impact on society, until they “change our lives.” Invention vs innovation is a helpful distinction.

Related posts

Technology precedes needs

New conceptual breakthroughs are invariably driven by the development of new technologies. The new technologies, in turn, inspire technologists to invent things, not sometimes because they themselves dream of having their capabilities, but many times simply because they can build them. In other words, grand conceptual inventions happen because technology has finally made them possible. Do people need them? That question is answered over the next several decades as the technology moves from technical demonstration, to product, to failure, or perhaps to slow acceptance in the commercial world where slowly, after considerable time, the products and applications are jointly evolve, and slowly the need develops.

Several years ago, Don Norman made a convincing argument that technology precedes our need for it. Rereading this article now, a few things strike me.

The first is that he is talking specifically about design research and its outcomes. Much of the discussion of the article came from a much broader audience which reacted as if he was speaking of design as a whole. There are some designers that I’d argue fall into the category of “technologist” in the sense that Norman uses it: “The new technologies, in turn, inspire technologists to invent things, not sometimes because they themselves dream of having their capabilities, but many times simply because they can build them.” That sounds like a lot of “designers” I know. Perhaps we’d call them “makers” these days (and perhaps that’s a better word).

The second thing that struck me is how long it took me to get my head around the way he used the word “innovation”. Early in the article, makes a distinction between two types of innovation: “conceptual breakthroughs” and “incremental improvements.” He then goes on to speak of “revolutionary innovations” and “grand, breakthrough innovations” which I assumed was the same as a “conceptual breakthrough.” On rereading the article I’m not sure this is the case.

The grand, breakthrough innovation is what professors love to teach their students, love to write about, and to discuss. But not only is it rare, even the occasional brilliant concepts are difficult to pull off. Yes, it is exciting to contemplate some brand new concept that will change people’s lives, but the truth is that most fail. The failure rate has been estimated to be between 90 and 95%, and I have heard credible, data-based estimates as high as a 97% failure rate.

Here, it seems to me that it is the “conceptual breakthroughs” fail. What interests me is his mention of “changing people’s lives.” He mentions it again later in the article:

Major innovation comes from technologists who have little understanding of all this research stuff: they invent because they are inventors. They create for the same reason that people climb mountains: to demonstrate that they can do so. Most of these inventions fail, but the ones that succeed change our lives.

Once again, these seem to be the “conceptual breakthrough” innovations (“inventions”). Some fail and others succeed and “change our lives.” What I find interesting here, is that I don’t consider either the “incremental improvements” or the “conceptual breakthroughs” to be innovations. Innovations have an impact on people and the society the live in. I don’t think we’re actually talking about innovation until Norman starts talking about the major / grand / revolutionary innovations.

It might seem that I’m splitting hairs here, and maybe I am. But it took me several readings of the articles to unpick the difference between Norman’s three kinds of innovation (“incremental improvements”, “conceptual breakthroughs/inventions” and “change our lives innovation”). I’m currently reading Scott Berkun’s The Myths of Innovation, and I like his straight-forward best definition of innovation: “Innovation is significant positive change.” Even better, I like the fact that he encourages people not to use the word at all. So in that spirit, here’s my understanding of what Norman is saying:

A technology is created. Someone (a technologist/inventor) has a conceptual breakthrough and invents a use for that technology. It is into a product and released into the market. The product may fail. If it doesn’t, it just may end up changing our lives. We won’t know we needed the technology until well after it’s been invented. Once we recognize that we need the technology, design researchers come along and research those needs and help to incrementally improve the product. (Or to use Norman’s tidy summary: “technology first, invention second, needs last.”)

The final thing that struck me on rereading the article was the discussion of “incremental improvements.”

Revolutionary innovation is what design companies prefer, what design contests reinforce, and what most consultants love to preach. But if you examine the business impact of innovation, you will soon discover that the most frequent gains come from the small, incremental innovations, changes that lower costs, add some simple features, and smooth out the rough edges of a product. Most innovations are small, relatively simple, and fit comfortably into the established rhythm and competencies of the existing product delivery cycle.

It sounds to me as if Donald Norman is describing a local maximum problem. The proposed solution to a local maximum problem is getting out the building and talking to our customers, i.e. design research. Norman does not think this is going to have as much as an impact as we’d like to think:

But the real question is how much all this helps products? Very little. In fact, let me try to be even more provocative: although the deep and rich study of people’s lives is useful for incremental innovation, history shows that this is not how the brilliant, earth-shattering, revolutionary innovations come about.

I’m not writing this blog to convince myself (or anyone reading it) of anything, but to explore the assumptions that underpin the way I live and work. And so, I’d like to leave this as a dangling question for the moment. Can design research go beyond the incremental improvements that attain to the uninspiring heights of a local maximum? Can it lead to significant positive change? I’m not sure of the answer. I’m not even sure it’s the right question. I suspect the right question might have more to do with creating more value than you capture.

Related posts

Desire lines

Walk around parks or college campuses and there, amid the neat sidewalks and pathways, you will find messy trails of people, worn-down dirt paths through the lawns, grasses, and even flowerbeds. The trails are social signifiers, a clear indication that people’s desires do not match the vision of the planners. People try to simplify the paths they take when walking, taking short routes rather than long ones, even if it means walking across gardens or scampering up hills.

Landscape architects and urban planners are not pleased with the resulting destruction of their grounds. Some planners resent them, treating them as a destruction by thoughtless, lazy people of carefully laid-out plans. These human-made trails are called “desire lines,” for they reflect desired paths even though the formal layout of streets and sidewalks do not accommodate them. Wise urban planners should listen to the message underlying these desire lines. When a desire line destroys the pristine plan, it is a sign that the design did not meet human needs.

Don Norman, Living with Complexity, p. 126

Handrails

…Frank Gehry’s buildings, which from the outside look like they might not have windows, but in fact, he’s very careful to put in what he calls “handrails” so that wherever you are in the building you get a sight of view of the outside so you can orient yourself, and you can navigate more easily.

On ABC National Radio’s All in the Mind podcast, Ester Sternberg discusses the science of stress, place and wellbeing. The whole interview is fascinating, but her description of Gehry’s idea of handrails jumped out at me.

I haven’t come across Gehry’s concept of handrails before, but it appeals to me. It turns out that it’s a broader concept than Sternberg implies in her interview. The best definition I’ve found is in Karl E. Weick’s essay Designing for Thrownness:

Handrails are familiar details in an otherwise strange setting that give people a feeling of safety and heighten their willingness to wade into someone else’s preinterpreted world and try to become more attuned to what is already underway in it.

In the articles and interview I’ve found online, Gehry refers to handrails as the reason for the the symmetry of Walt Disney Concert Hall and his use of brick in The Strata Center.

Handrails. What a fantastic metaphor for providing people with a familiar guide in unfamiliar territory.

Just one person

Yesterday, Jason Kottke featured this tidbit from Kurt Vonnegut’s eight rules for writing short stories:

Write to please just one person. If you open a window and make love to the world, so to speak, your story will get pneumonia.

Last night, I read this in 101 Things I Learned in Architecture School:

Design a flight of stairs for the day a nervous bride descends them. Shape a window to frame a view of a specific tree on a perfect day in autumn. Make a balcony for the worst dictator in the world to dress down his subjects. Create a seating area for a group of surly teenagers to complain about their parents and teachers.

Designing in idea-specific ways will not limit the ways in which people use and understand your buildings; it will give them license to bring their own interpretations and idiosyncrasies to them.

Design for just one person: it sounds easy, but it rarely happens.