The tools we use: Challenging dogma in the design process
Many of us in the design and technology community pride ourselves on being tool builders, creating products that others can use to get things done.
But perhaps we don’t stop to consider the fundamental nature of our relationship with tools – we’re aware that they extend our abilities, but can also be blind to the way they shape how we use our abilities.
In a recent talk at UX London, I discussed some lessons learned while growing the design team at Intercom, reflecting on the technology industry’s obsession with tools, and pointed out how our sense of tools as objects or apps blinds us to the reality that the processes we adopt and develop are also, in effect, tools. You can watch a video of the talk above, or read an edited transcript below.
Tools are part of who we are
We all have a very fundamental relationship with the tools we use. We probably all spend quite a bit of time thinking about them, choosing them, debating which is best. We certainly spend a lot of time using them.
“We think of a tool as a piece of physical machinery that augments our human physical ability”
But I don’t think we spend a ton of time examining the motivations behind this approach, or thinking about how they influence the work that we produce with them. This talk seeks to address that, by analyzing the tech industry to understand why everyone is so obsessed with tools and, in light of that, by considering the tools that are available to design leaders. I hope that by the end you have some new ways of thinking about what tools you use yourself, and some of the pitfalls that you might not be aware of.
To start, let’s ask: what is a tool? If you ask most people, they’ll mention something like this – a hammer.
Traditionally we think of a tool as a piece of physical machinery that augments our human physical ability.
Throughout much of history, that’s how we thought about tools – they are akin to an extra muscle.
Here’s an example of a tool augmenting someone’s physical ability. A lot of people see this and they’re like, “Wow that monkey is smart, man!”
That reaction reveals how we think about tools as something so innate to ourselves, something so central to our humanness, that it’s a surprise when we see an animal using a tool. Ultimately, tools are a part of who we are and how we conceive of ourselves.
This was probably best illustrated in what’s been called the single most famous edit in the history of cinema, in 2001: A Space Odyssey. In one 24th of a second, Stanley Kubrick makes the connection between the most primitive and the most advanced tools we can imagine.
We forward millions of years from one tool to another: from the bone to the space station.
What Kubrick is really doing here is establishing their continuity on a timeline. These two tools are bookending the extremes of a very long timeline of the relationship between humans and technology. From the distant past to the distant future.
All of the tools you and I use exist somewhere between these two extremes.
But also the space station is something different. It’s not a tool for physical augmentation. There are other types of tools, and these are the ones that soft-handed individuals like ourselves think about more often.
This is a pencil. Rather than augmenting your physical ability, it’s a simple tool for augmenting your intellect.
Most people can probably do some simple arithmetic in our heads. But if I ask you for 873 x 42 you’re likely to be stumped. Now I give you some simple technology – just wood pulp, graphite, and maybe some paper to go with it – and repeat the exercise. You’ll have the answer in a minute. That simple piece of tech has augmented your abilities massively. It’s expanded your intellectual capabilities.
So what does this have to do with design? Well, how well-designed a tool is really matters to how useful it is.
For example, what if I gave you this pencil and asked you to do the same maths calculation. You’d struggle because the tool is so bad! You’d be slower, for one thing, and maybe it would be so frustrating that you’d just give up.
This is an important point: even for the category of tools that relate to augmenting our intellect, the ergonomics, the interaction design, is deeply important. How well designed tools are matters deeply. Because if they are poorly designed, like this one is, they actually make us less physically or even intellectually capable.
Modern software is obsessed with tools
What’s really interesting about this photo of the brick pencil is that it was actually created to prove that point.
It’s from a 1962 report published by a man named Douglas Engelbart. The report was called Augmenting Human Intellect: A Conceptual Framework. It was part of a project he was running in the Stanford Research Institute called NLS (“oN-Line System”) that culminated a few years after the report on December 8th, 1968, in what’s become known as the “Mother of All Demos.”
It’s called that because it introduced the world to early versions of many of the tools we still know and use today: things like the computer mouse, video conferencing, graphics, hypertext, word processing, revision control, collaborative real-time editing.
This night in 1968 was the birth of the modern software era. But it was also the birth of what has become an obsession within Silicon Valley and the Bay Area that continues to this day: an obsession with tools.
The video operator for the demo was a guy named Stewart Brand, who among other things published a magazine at the time called the Whole Earth Catalog.
It was a how-to guide of sorts, aimed at back-to-the-land hippie types who were beginning to move away from cities like San Francisco and set up communes. It highlighted all kinds of tools and techniques that would be useful in building a new type of self-sufficient lifestyle.
The magazine’s slogan was “Access to tools.”
Remember, this was San Francisco in 1968: a time and place when the hippie counterculture very much intersected with the inventors of early personal computing. So this type of thinking had a great influence on the early computer industry.
A unified theory of technology
Steve Jobs many years later called the Whole Earth Catalog, “Google in paperback form, 35 years before Google came along. It was idealistic, and overflowing with neat tools and notions.”
In fact, you see the influence of the Whole Earth Catalog in how Jobs spoke throughout his life about his belief systems around technology and tools.
This is Jobs in 1985: “A computer frees people from much of the menial work. Besides that, you are giving them a tool that encourages them to be creative. Remember, computers are tools. Tools help us do our work better.”
Then again in 1989: “I think humans are basically tool builders, and the computer is the most remarkable tool we’ve ever built. The big insight a lot of us had in the 1970s had to do with the importance of putting that tool in the hands of individuals.”
A few years later, in 1994, Jobs says: “I’m a tool builder. That’s how I think of myself. I want to build really good tools… Technology is nothing. What’s important is that you have a faith in people, that they’re basically good and smart, and if you give them tools, they’ll do wonderful things with them. It’s not the tools that you have faith in – tools are just tools.”
“A computer has always been a bicycle of the mind. Something that takes us far beyond our inherent abilities”
Perhaps most famously, he captured his thinking in his “bicycle for the mind” quote from 1990, which he used again and again and was perhaps as close as he came to a unified theory of technology: “We humans are tool builders. And that we can fashion tools that amplify these inherent abilities that we have to spectacular magnitudes. And so for me, a computer has always been a bicycle of the mind. Something that takes us far beyond our inherent abilities. And I think we’re just at the early stages of this tool.”
By the way, I show all of this not in some “I’m quoting the great Steve Jobs in a talk about design so it must be true” kind of way. Quite the opposite. I show this to point out that here is one of the most culturally influential people in modern memory, whose shadow loomed large over several generations of our industry, and there’s this theme hiding in plain sight that he kept returning to again and again and again over the course of decades. It drove him, and in turn influenced untold others. So perhaps it’s worth interrogating what that means about our shared attitude to and culture around technology.
Because although this is all very inspiring stuff (in a motivational poster for nerds kind of way), with the benefit of hindsight I can detect an element of disavowal to what was said here, a sense that “tools are tools, they are neutral, who knows what people might use them for?”
To be fair, I believe that this was coming from a place of naive utopian optimism (another central characteristic of Silicon Valley thinking), rather than cynicism. It was a simpler time, perhaps.
We no longer live in that simpler time.
But we still see this language and mindset, and frankly sometimes this excuse, being used all the way up to today.
Building tools leads to the broadest impact
Mark Zuckerberg testified in front of the US Congress in early 2018. In the short written remarks that he submitted beforehand, he used the word “tool” 11 times. His actual testimony was absolutely peppered with mentions of “these tools,” “those tools,” “any tool,” “technical tools,” and – 13 times – “A.I. tools.”
So this obsession with and rhetoric around tools has remained remarkably consistent throughout the entire history of our industry. Why?
Probably, there’s an echo of the countercultural movement ideals. But anyone who’s been to San Francisco recently can confirm that the summer of love definitely ended 50 years ago.
Perhaps it allows for a simple abdication of responsibility, a distancing of yourself from any undesirable outcomes. I’d rather think I’m building a bicycle for the mind than accept that I’m building a treadmill for the soul. So there’s probably some of that.
No, I think the real reason is evident in this quote:
Building a tool is the fastest way to having the broadest impact. You can build a product and influence the people who use it. Or you can build a tool and influence your users and everything they make.
I’m not sure we’re entirely awake to this. We think of ourselves as designers, as shapers of things, but I suspect most of us don’t really notice how our own decisions are in fact being shaped by our tools.
But it’s unavoidable – tools influence and shape the things that are built with them. You can see this very simply in how tools and trends co-evolved as the web came into being.
Early websites were often designed “in the browser” as we’d say today; with design decisions (as such) being made directly in HTML coded with a relatively unopinionated tool like Notepad. (1996)
Then people used early versions of photo editing tools like Photoshop in combination with things like Dreamweaver to create complex table-based layouts or imagemaps. (This website is still live, by the way.)
This evolved over time into the pixel and grunge styles of web design becoming popular, primarily achieved through use of the pencil and brush tools in Photoshop.
The rise of Flash as a design and authoring tool led to people making design decisions like “animated intros” or “massively overworked animated rollovers.” Web 2.0 drop shadows, shiny bubbles, reflections were all achieved using the more powerful gradient and modelling features that were appearing in newer versions of Photoshop. This reached its zenith with the rise (and subsequent fall) of so-called Skeumorphic design.
And finally a move away from raster editing tools like Photoshop to primarily vector-based saw the rise of “flat design” where you’re more directed towards drawing boxes than highly textured elements.
Not all of these trends were solely a result of the tools – designers influence one another greatly – but they were definitely affected by the tools and the type of design that the tool encouraged you to create through what it made prominent and what it made easy to achieve.
Kind of like how you could solve that math problem with a pencil taped to a brick if you really had to, but you won’t. You could create a grunge-style web page design if you had to, but as long as you’re using Sketch you probably won’t. You’ll create something that looks like this instead:
Of course, the danger here is that we end up with a design monoculture, where everything looks the same. But if you’re interested in work that doesn’t just fit in, you should be aware that the tools you use may be suggesting a very prescribed and specific path for you to follow, maybe without you really noticing it.
Above all, you should be aware of the biases inherent in your tools, and be somewhat critical of them. Dig into what they are trying to get you to do, and question it. Don’t let these tools push you around!
To recap our thoughts so far:
- Tools are amazing: they augment your abilities.
- But don’t forget: tools can also be weapons. There’s a saying: “The invention of the ship was also the invention of the shipwreck.”
- And finally, tools can lead you astray if you’re not paying attention. They contain hidden biases.
That last one is particularly important to realize when you’re running a team. Because as we’ve seen, tools are more than just apps. As a design leader, all of the processes and structures that you put in place for your team are very much tools as well.
Process is a tool
Taking this slightly broader definition of tools, what tools are available to design leaders? Here’s a question that I hear a lot when talking to other folks who are running design teams: “What’s your process?”
Design leaders are often tasked with designing “the product that builds the product”: the team. It’s human nature to look at what your peers are doing and think, “Surely I should just be copying that, right?”
“The structures and guidelines you put in place for how you work as a team are a tool for affecting the whole team’s output”
Because when you dig into it, it turns out we have all the same problems in common. And yet we all somehow seem to need to invent independent solutions, because our teams and companies are at different stages and these things come up at different times. So we all end up “reinventing the wheel,” designing our own process for getting design done in these massively complex, dynamic environments. We already know that the tool you choose affects your output. So it can be slightly terrifying to then approach designing the process that your whole team is going to use.
But it’s true that process is a tool. The structures and guidelines you put in place for how you work as a team are a tool for affecting the whole team’s output. Which leaves us with a number of questions.
How will your process actually work to augment your team’s capabilities in the way that a good tool does? How do you make sure you’re not giving them a pencil taped to a brick? You need some kind of safety measures built in to the process.
And of course your team changes over time – you might be scaling like crazy, so how do you make sure you haven’t already outgrown your tools and processes?
Consider kaizen
Here’s how, by way of a story. In the 1980s Toyota, the car company, were in a battle for supremacy with the American car companies. And the prevailing wisdom that the victors would be the ones who could squeeze every last drop of efficiency out of their current manufacturing processes: Taylorism turned up to the max.
But what Toyota realized was that they could do something different. Rather than trying to lock down and optimise their existing manufacturing processes, they should give assembly-line employees the ability to stop the line at any time when they saw something that wasn’t working well. They literally installed big red buttons that employees could hit at any time they wanted to stop the line and point out the problem that they were encountering and fix it. This was counterintuitive to some people, given that the goal was to keep the line moving as fast as possible. But they realized that they needed to enable their front-line people to call out when something could be better, and change how they were working, even if it meant a short stop.
This Kanji script is Kai, which means change, and Zen, meaning good. Kai-zen. Change for good. Or basically, improvement. Continuous improvement – “Kaizen.” This is what Toyota called their approach.
At Intercom, we kicked off a project in the spirit of Kaizen, in recognition of the fact that we would never be done with improving our processes, and that such improvement couldn’t be top-down, it had to be informed by members of the team.
Twice a year we survey the entire company (about 600 employees), where we ask everyone what’s working, what’s not, what things need to evolve, what would they like to see changed, and so on.
And then we act on it, approaching it, like I said, in a very similar structure to how we approach building product. So we treat the evolution of the team and how we work almost as if it was a product to be continuously iterated on.
At a high level we have a cascading set of structures that we use to define what we want to achieve at a company level (mission, vision, strategy, programs). And then individual teams have roadmaps, six-week cycle goals, and weekly goals. So we decided to approach improving our design team just like we approach improving a product.
Just like a product team, we have a roadmap with problem statements, we have cycle goals, we have weekly goals, we have a backlog of items. These are all the rituals that drive how we build product and also how we improve what we’re building and how the team works.
Crucially we report back to the team with actions we’ve taken as a result. This is us doing that in our Design Studio in Dublin.
Over time, you build a sense of trust among the team that even if things are a bit shit, they can and will get fixed. You develop a confidence that we have a kind of self-healing property that we can apply. And really the only way to build that credibility over time is to just deliver over a couple of cycles on it.
To make this tangible, over the past year we have used this approach to improve numerous aspects of our processes.
For instance, we now have designers working across three offices, so it’s critical to have a structured approach around how the team works. To ensure that, we used this Kaizen-inspired process to develop guidelines and documentation around:
- Onboarding new people
- Developing a career plan
- Job ladder with clear expectations
- Refreshed Design Principles
- Our design process
- How we give and receive feedback
- Our philosophy and process on hiring
You can certainly take this too far and overload people, but a core set of short, clear docs is invaluable, especially for new people. Once you start to do this, you will probably be surprised by how much you thought had been obvious was in reality merely implicit. “Writing is nature’s way of letting you know how sloppy your thinking is,” as the saying goes.
We refreshed our Design Principles through this process.
It goes beyond documentation. To encourage as many designers as possible to write we run workshops to brainstorm topics, run a calendar of planned blog posts over the year, and provide editorial support. We do a lot of internal training sessions, both peer training and with invited guests, and we conduct offsites or team events.
These are all things many design teams do, but the aspect I’d like to really highlight is that this never ends. It’s an ongoing process. We’re constantly reassessing and iterating. And this Kaizen-inspired approach of continuously assessing and improving how we work, this practice of meta-design, has served us really well.
After a while running this process we realized something – this is essentially what a lot of other teams are beginning to call Design Ops. In my opinion this approach is almost our superpower as a team or as an organization – the ability to find out what’s not working and address it pretty quickly. Once you can do that, you’ll find that a lot of other things just fall into place naturally.
As I described earlier, tools actually do change how people behave. Relatedly, the structures and processes you put in place for your team are the single greatest lever you have to set them up for success.
Going beyond our limitations
Ultimately, we humans are limited creatures. We can work out all you want, but we’re not going to become orders of magnitude stronger than anyone else. But a person with a hammer can, relatively speaking, perform incredible feats of strength.
We can study all we want, but we won’t become orders of magnitude smarter than anyone else. But a person with a pencil or a person with a smartphone is, for some dimensions of “intelligence”, smarter than the cleverest person without one.
As users of tools, and as makers of tools, we have an incredible opportunity to have a huge impact on the world. Impact can be good or it can be bad, so we must all keep our eyes open and stay aware of what that impact looks like.
Finally, don’t ever hesitate to throw out your old tools and come up with new ones. In the long, long history of the relationship between humans and tools, that has always been the place that new things come from.
