This is a 30-ish minute talk I gave at the Amsterdam UX Meetup on March 7th 2018. Advance the slides using the arrow keys on your keyboard or by swiping on your mobile device.
Agile methodologies have quickly become central to the way we create and refine digital products. These rapid cycles of building, measuring, and learning are great for refining an already innovative product but these techniques are being increasingly called upon to produce innovation itself and they kind of suck at it.
In this high-level, philosophical talk, I draw from 25+ years of experience in digital product strategy and design to take a critical and sometimes controversial look at processes that claim to cultivate innovation but too often fail to deliver.
I also highlight some principles and practices that I've seen promote real innovation and help it survive the perilous journey from the minds of innovators to the hands and hearts of users.
So, who the hell am I?
I’m Scott Neilson. I’m a UX Designer and Strategist.
My career began back in the Bronze Age, about the time computers were becoming practical design tools, enabling us to put down the stone axes we’d been using up until then.
Initially, I was a graphic designer but when it started to look like this new internet thing might take off, I began expanding my skillset. I worked with Microsoft and designed several of their early MSN properties. Eventually, I left to become the first designer at a little online bookstore startup called Amazon, perhaps you’ve heard of it. 😉 After my time there, I got involved in a long series of startups in Seattle and San Francisco. About 6 years ago, a longtime friend and collaborator and I started a little agency in Seattle called UXanimal. Last spring, I moved here to Amsterdam with my partner, Rachelle to start my current UX consultancy, TallScott.
In retrospect, I should have chosen a different name because I’m only TallScott back in the US. Here in the Netherlands, I quickly discovered that I’m just average height Scott.
This talk is divided into two parts – Issues and Advice.
In Issues, I’m going to practice Dutch directness and highlight how certain modern practices for creating digital products can fail to deliver the efficiency and innovation that they promise.
In Advice, I’ll offer a few high-level principles common to every organization and product I’ve been involved with throughout my career that I regard as deeply innovative.
We love our processes, and of course, we need a certain amount of process to conceive and create digital products. Duh. And with each new book or blog post, the array of processes available to us seems to increase.
As we focus more attention on understanding and implementing these complex processes, are we losing sight of our core values and crisp product vision?
A colleague of mine refers to this as how-ism, that is focusing on how something is being created and losing sight of what it is being created, and sometimes even why we are creating it.
It’s tempting to become a howist because seeing stuff get built is really satisfying. Also, these how skills are relatively stable and portable. But often the what and why tend to be pretty squishy.
The howists in this scene of the Ministry of Information from Terry Gilliam’s film, Brazil are frantically focused on the how, with very little understanding what they are creating, let alone why.
In simpler times, it was mostly large organizations that suffered from extreme how-ism. This is what made them vulnerable to scrappy startups that wanted to step in and eat their lunch.
In today’s more complex world, even the scrappy little startups are taking on a huge amount of process overhead. The ballooning number of tools and services we use for communication, scheduling, process management, development, testing, marketing, etc. are distracting us from the vision we’re working to realize.
Agile processes promise to turn our organizations into lean, mean learning machines that iterate their way to innovative products with lightning speed. And all of us who work in agile environments can attest to the fact that that's working perfectly, right? 😉
In my experience, this way of working seldom lives up to all the hype. We’ll dig deeper into why in a minute but this diagram gives us 3 clues:
Notice how many process-intensive activities this “lean” cycle contains.
Note that Ideas are given the same weight as Code and Data.
And finally, words that are at the heart of successful products like Vision, Innovation, Design and Users are nowhere to be found, but note that the word Faster appears 3 times.
Agile is great for helping us know what users are actually doing and that can give us all kinds of valuable insights.
But too often, we let these insights short circuit our product vision (the what) or worse, our values (the why). Of course, we should listen to our users and of course their reality should inform our decisions, but we need to stop short of letting data design our products. That’s not user-centered, it’s messy and dangerous.
It’s cool that we can test multiple things at once and see which works better. Agile organizations are running these tests more frequently and in more places throughout their products. Eric Ries would be so proud!
But split testing leads to at least two problems.
1: Used in a careful way, this incremental technique can slowly refine an already innovative product. But some organizations have this upside down. They presume that innovation will somehow emerge from this activity. This is like rearranging the deck chairs on the Titanic - No matter how rapidly we make incremental changes to a weak product, it will never compete with one built around a brilliant, innovative idea.
2: The second problem is that making frequent changes to a product, even “good” changes, undermines usability and trustworthiness for existing users. We're starting to see terms like update fatigue and a/b dissonance enter our dialogue because they are driving an epidemic of disengagement and abandonment. Some smart organizations are recognizing this and doing a lot more testing and refinement of their design up front and less harmful testing and iteration of their live products.
What’s not to love about design systems?
Atomic design systems promise to free us from reinventing the wheel. They enable us to focus on higher-level user flows while also speeding up development.
Of course, it’s generally good for users when we leverage familiar patterns in consistent ways. However, too often products are rushed to market without the thoughtful details that differentiate the experience or the brand.
A friend of mine called design systems “The stock photography of UX.” People know when something is canned, rushed, or inauthentic and they tend not to be too impressed by it.
In theory, these popular tools and techniques help us realize our product vision faster and more safely. In practice, however, they tend to overemphasize the how and cause us leave our vision, and sometimes even our values in the dust.
It’s also ironic that some people can be so inflexible about their agility.
In practice, Agile tends to be much more process heavy and less “agile” than many people think.
Which of these is your organization putting first?
Agile promises the impossible.
It argues that Good will somehow emerge from Fast (and therefore Cheap) iteration and learning.
Unfortunately, this is a myth. Good, rarely if ever, comes out of fast or cheap.
As Ratcliffe points out, placing too much importance on speed carries a high cost. Decisions are made impulsively rather than thoughtfully.
These ways of working tend to produce premature, experimental products that lack a cohesive vision…
…and consequently aren’t well received by the market.
A well-known quote wrongly attributed to Henry Ford is “If I had asked people what they wanted, they would have said ‘faster horses.’” Agile processes are great at giving us faster horses faster but they’ll never invent a new category of transportation.
It’s also worth mentioning that building digital products, even rapid MVPs, is crushingly expensive.
I heard a VC in silicon valley crack this joke and I think it’s relevant here.
In my experience, pivots too often happen in desperation after the MVP falls flat and the budget is in trouble. Some companies will put a positive spin on their “learnings” and ask for more money. Others will water down their revised vision to something that can be built with the scraps of their failure.
These ways of working sound fantastic on paper, especially to risk-averse investors and impatient engineers. They appeal to our desire for predictability and our strong inclination to jump straight in and do something.
But in practice, I've found that risk-aversion tends to promote timid product vision, and impatience tends to yield weak expressions of that vision.
Now, I’m not advocating for a return to old-school waterfall processes.
Despite the last 30 slides, I think agile methodologies have a lot to contribute… to the careful, in-flight refinement of already innovative products.
They get us into trouble when we mistakenly think all those feedback loops and rapid iterations will produce innovation.
Here’s a metaphor that I’ve found useful when thinking about (and communicating) these ideas:
In chess, Knights and Bishops have the same value, three points. But Knights are worth more early on, before the game has taken shape. Bishops are worth more later in the game once the structure is in place and they have room to run.
Just like Knights and Bishops, design and development are equally valuable and can’t win without working together - but their strengths are biased toward different phases of the game.
Many agile organizations rush straight out with their Bishops (engineers) only moving the Knights (designers) grudgingly and often for damage control once the game/product is in trouble.
This make sense because they usually have a lot of really smart (and expensive) engineers and letting them just sit there while the designers open up space isn’t an option.
When I walk into a room full of engineers, I see trucks pouring concrete on a construction site. I’m always hopeful that everyone is working from a thoughtful, detailed blueprint but that’s much less common than it should be.
It seems that too many organizations never have time to do it right but somehow always have time to do it over. This is a massive waste of time and resources.
Snap recently split tested a change to their information architecture aimed at helping them better monetize content.
The test results were inconclusive (which never happens, right?) but they didn’t seem negative so they rolled out the change.
The next morning, they woke up to a petition signed by about a million angry users, then a key influencer erased almost 1 billion dollars of their valuation with a single tweet.
I used to love Evernote. It began life as a really focused, innovative, must-have product. Synchronized, searchable notes that could magically read images too. Full stop.
After a few years of listening to users and letting feedback dictate the trajectory of their product, Evernote became a bewildering mess of apps, features, services, plug-ins, integrations, co-branded collaborations and more!
Many people including myself have seen Evernote’s usability and performance suffer dramatically. I don’t have data but their abandonment rates must be through the roof despite their users’ high switching costs.
Ok, so if anything I’m saying is true, then what?
Bruce Mau said “Now that we can do anything, what shall we do?” We now have tools that enable us to realize even the most ambitious product vision with incredible efficiency. We have a huge amount of power.
Some wise organizations are beginning to boldly use that power, paradoxically, to slow down and allow deeply innovative product vision to develop.
“Don’t just do something, sit there.” is a funny saying from Vipassana or Mindfulness meditation.
In my experience, innovative ideas seldom emerge in the frenetic doing culture found in most organizations. More often, they emerge when we can relax and sit quietly with the problems we’re trying to solve.
It takes serious guts to introduce this principle into an organization and even more to tell investors, “Hey, relax, the fruit will fall when it’s ripe.” The fact remains, however, that innovation, like inspiration and relaxation, can’t be forced.
That’s not to say that we can’t use this time in a way that nervous stakeholders see as “productive.” There are many low-risk activities that can help lay the groundwork for the implementation of a vision that’s still waiting to be born. A few of those activities even involve engineers, so having one or two of them involved at this stage isn't a bad idea.
Innovation can’t be forced but there are activities that tend to support it. Creatively reframe the problem you’re trying to solve and encourage absurd ideas. Someone thought “What if wagons didn’t need horses?” or “What if phones were also a little general-purpose computers packed with sensors and big touch screens that were always connected to the internet?”
A powerful discipline that I’ve noticed many successful organizations cultivate is a sharp focus on the innovation or value proposition at the core of the product vision.
This is about being courageous and resisting the pressure - from internal stakeholders and customers - to add features that may make sense but that ultimately add complexity and blur a product's crisp, confident vision.
I have a friend in Seattle who sells beautiful hi-fidelity music systems. Often, customers come into his shop inquiring about surround sound systems. He gently discourages them from this, because that would require spreading their budget across a 5 or 7 speaker system. He instead encourages them to focus that same budget on a much higher quality 2-channel system. While it isn’t what the customer thought they wanted, he guides them to a simpler and far superiorlistening experience.
Another example I like is the old TV show, Kung Fu. The main character, Caine, always defeated his enemies with confidence, grace and a minimum of movement. He masterfully did only what was required to get the job done while his frantic opponents exhausted themselves throwing wild kicks and punches.
Inspirational companies tend to look like Caine. They realize that by calmly mastering the right moves, they can beat just about anyone, no matter how fast or big they are or how hard they work.
Originally, digital technology was created by scientists, for scientists. Today, digital products aren’t just for the people creating them, they are woven deeply into the lives of ordinary people. Therefore, we have a responsibility to hold digital products to the same high experiential and aesthetic standards that we have for the physical products we use everyday.
The scientific agile culture is great at making products useful and usable but has a tendency to shortcut or even skip the hard work required to make them desirable. The best, most desirable physical products are a blend of artistry and technical prowess, this should be equally true for the digital products we create.
To put this another way, the left and right brains of our technology culture are out of balance…
…and if that balance were restored, we’d get more products people love to use.
I’m borrowing the Rockets vs. Cars metaphor from Mr. Ries here.
Yes, a car is much faster and cheaper to build and it comes with a steering wheel to help us adjust course easily.
Yes, the old waterfall (Rocket) model for creating digital products was way too slow, expensive, and risky.
But the new agile (Car) model too often fails to get our innovative visions off the ground without painful, or even fatal compromises.
The good news is that the technologies we use to create digital products have matured dramatically so we can now build rockets much more quickly and economically. Visionary organizations have the guts to set their sights higher and light more rockets rather than incrementally steering their cars toward a series of destinations that each suck a little less.
Not a perfect image but I included it here because it involves a rocket, a car, and a steering wheel… And it’s just insanely cool.
Sure, going after the larger rewards that real innovation can bring does require additional risk but let’s be honest, these days, many investors are doing so well that it would make Marie Antoinette blush. We know that many of them can afford to take on that risk and we can afford to ask them to.
Bigger bets come with higher risk, but they’re also a lot more exciting, making it easier to motivate and rally people around the vision.
We all want to be clever, well-rounded innovators, and part of this is knowing how to sell these bigger bets to business and product owners.
This is a big overstatement but the point of innovation having massive value is valid.
So, let’s stop disappointing so many people with minimum viable products and cultivate the courage and patience to create minimum lovable products instead.
The Light phone is laser focused on a problem many of us are familiar with but few have the guts to solve. The problem is the ever-increasing complexity, messy-ness, and time-suck of these little computers that are taking more and more of our precious time and attention.
Light envisioned a radically simple device that stays out of the way of core communication tasks… and that’s it. It’s simple. They boiled away the cameras, the app ecosystem, the sensors, services, gestures, and just about everything else we’ve come to take for granted in a mobile device.
The result is a highly differentiated tool that helps people reclaim time and focus. It’s also a sexy little badge that says you “Think Different.”
Are.na - Playlists for ideas.
Are.na made the deceptively simple innovation of providing a platform for… anything. Unlike the zen focus of the Light Phone, Are.na’s big innovation was to be deliberately UN-focused and enable users to provide all the conceptual structure.
On Pinterest, a search for “Spinoza” predictably returns images related to Spinoza... mostly.
The same search on Are.na returns an interesting mix of community-curated images, published works, audio, and more.
I know I said this talk had two parts but here’s a bonus section that I think relates to the topic.
We tend to regard ourselves and our users as quite separate. We often think of them in the abstract.
But it’s healthy to remind ourselves that at the end of the day we’re just people working to create something of value for other people.
That seems simple and direct.
But the route from our intentions to the users’ experience contains many practical and conceptual hurdles.
Our values and vision need to clear these hurdles in order to get to the user with the greatest possible clarity.
In a perfect world, the route would be lossless.
In reality, however…
Each hurdle introduces friction and possible misinterpretation.
Add to that the friction created by the complex realities of modern business and it seems like a wonder we get products in front of users at all.
Our values and vision can seem like Napoleon’s poor army on its way to and from Moscow in the dead of winter…
…which Charles Joseph Minard illustrated so brilliantly.
Mr. Incredible’s failed escape attempt brings the feeling home pretty well too. As we pile on processes, features, and changes and the route to users proves lossy, the strength of the vision we started out with is greatly diminished.
I find it useful to think of us as smart, energetic shepherd dogs.
We are deeply loyal to our core values and the resulting product vision. We are rightly troubled when our vision (here the sheep) fall prey to the hazards of product development. But there’s no feeling better than safeguarding the flock all the way through the process so it arrives home, to our users, healthy and intact.
My sincere thanks for your time and attention.
I’d love to hear your thoughts about this and/or about the projects that you're working on so please don’t hesitate to reach out, either online or IRL for a coffee or beer.