The Tools We Use: Challenging Dogma In The Design Process

Emmet Connolly at UXDX Europe. Video: https://youtu.be/DYhoIYUlKl4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

We are all makers, and makers use tools

[00:00:04] It sounds pretty impressive when you describe it like that. I hope I can live up to the promise. So yeah, I'm Emmet. I am director of product design at Intercom. Super quick intro if you don't know us: we build a platform and a series of products for businesses to message and communicate with their customers. We have a pretty big office here in Dublin, one in San Francisco and one in London that we opened last year. I'll touch on some Intercom stuff, but first, before I get into that, I really wanted to tee up the theme that I want to address here today.

[00:00:41] I think with a mixed crowd like this, with different roles, you often have people coming to talks with different expectations. But I think that on some fundamental level, whether you're a designer or an engineer or a researcher or a PM or whatever it might be, a lot of us here probably consider ourselves, at some basic level, to be makers: just people who build stuff. That's how I think about my role, anyway. What I really wanted to hone in on today is one aspect that is pretty common, universally, to all maker types, and that is our use of tools. All of us have this really fundamental relationship with the tools that we use.

[00:01:28] This isn't going to be a deep, nerdy design talk, like Sketch versus Figma. In fact it's about broadening the definition of tools a little bit, and getting everyone to reflect a bit on the tools that they use. Especially, the more I've grown into my role as a design leader, the tools that I use are pretty different to the tools that I would have used when I was more focused just on my own work. I've also become fascinated, really, with how we as an industry think and talk about and engage with tools. So that's the preamble.

From the bone to the space station

[00:02:08] To begin with, I'm going to start pretty simple. If you ask most people to picture tools, they would probably pick something like this. They'd probably think of a hammer or a wrench or a saw or whatever it is. Traditionally, and generally in the real world outside of our little bubble, I think people think about tools as any kind of machinery that augments your physical capability. It's an augmentation of your physical abilities. That's true, of course tools do that, but really there's been a long line of progression from these pretty standard, basic tools that augmented physical capabilities all the way up to the most modern tools that we use today, the ones we might think about in a software or design context.

[00:03:01] I think this is actually pretty well and famously illustrated in what is perhaps the single most famous cut in cinematic history. This, of course, is 2001: A Space Odyssey by Stanley Kubrick, and in it there's a cut that happens in a second, from the bone to the space station. Boom. The film generally makes this point, I think: the tools that we use are a defining characteristic, all the way through from the very earliest glimmers of humanity to the farthest we can think of in the future. There's some fundamental relationship between humans and the tools that we use. In many ways these two tools are bookending this very long timeline of tools that we can build and use, and in some sense almost all of the work that we do engages with the tools along this timeline.

Tools that augment the intellect

[00:03:59] That's a super broad definition of what you might think a tool to be, so let's narrow it down a bit. This is a pencil, obviously. This, if you ask me, is also a tool. But whereas the tools we were looking at before are ones that augment your physical abilities, this one actually augments your intellectual capabilities. To illustrate that point, I could probably ask most of you a simple math problem and you'd be able to do it in your head. But if I ask you a more complicated one, like what's the square root of 200 times 57, you wouldn't be able to do it in your head. Then if I give you this really simple piece of technology, just wood pulp and graphite, and a piece of paper maybe to go with it, you'd probably be able to work out the answer pretty quickly. So this very basic piece of technology has augmented your intellectual capabilities massively. It's expanded your intellectual horizon, almost.

[00:05:04] What does this have to do with design, which is the area that I operate in? Well, I think it's really interesting to think about the design of this tool. This is an extremely simple tool, and you might think of the design as being somewhat self-evident, but there are other ways of designing tools like this. For example, if I gave you this version of a pencil and asked you to repeat that same exercise, you'd probably have a hard time. I bet you wouldn't complete it. You'd give up in frustration, or you'd just really struggle with the mechanics of it.

[00:05:39] That's important when you really think about it, because it means that for this important category of tools on which we rely to augment our intellect, the physical ergonomics, the interaction design of the thing, still really matter. If the interaction design is a bit off, it's actually going to reduce the ceiling of the intellectual capability that the tool can expand you to, if that makes sense.

Engelbart and the mother of all demos

[00:06:09] What's really interesting about this photo, I think, is that it was actually created to illustrate this point. This photo is from a 1962 report that was published by a guy called Doug Engelbart. This is the report. It's called "Augmenting Human Intellect: A Conceptual Framework," and it was part of a wider project that Engelbart was working on in the 60s at the Stanford Research Institute. He was working on a project called NLS, for oN-Line System, and that project culminated a few years after the report, on December 8th [?], 1968, in what has become known since as the mother of all demos.

[00:06:56] This is a video from the demo that evening in 1968. It's so notable, and it's known as the mother of all demos, because it introduced to the world for the very first time the very first versions of loads of tools and technologies that we know of today. It was the first appearance of the mouse, of collaborative text editing, of version control, of hypertext, of real-time video conferencing. All these kinds of things were presented for the first time here. It's the greatest tech demo that you've probably never seen, if you've never seen it.

[00:07:30] What's also interesting is that this is considered the birth or the beginning of the modern software era. It was the start of tools that became accessible to normal people. But I think it was also the beginning, in many ways, of an obsession that has persisted and been prevalent in Silicon Valley and in the Bay Area, and in our wider industry here as well, to this day. That obsession, I think, is an obsession with tools, or the idea of building tools as being a valuable and a noteworthy thing.

Access to tools

[00:08:11] The guy behind the camera, the video operator for this demo, was a guy called Stewart Brand, who among other things published a magazine at the time called the Whole Earth Catalog. These are some spreads from the catalog. It was a magazine and a how-to guide, aimed at back-to-the-land hippie types who were moving from cities like San Francisco back to communes to build their own versions of society or whatever. It highlighted all kinds of tools and techniques that they could use for building this new kind of self-sufficient lifestyle. There's some mad stuff in there; you should check it out. The cover of the Whole Earth Catalog features the tagline "access to tools."

[00:08:58] Remember, this is San Francisco in 1968. If you know anything about that period, you'll know it was a time when this hippie counterculture style of thinking was very much intersecting and overlapping with the birth of the modern personal computer. Same time, same place: the two things were coming out of the same areas, and a lot of the ideas and philosophies, and even people, commingled and influenced each other across these two groups. Steve Jobs, who would have been on the scene at the time, 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 great notions."

[00:09:43] In fact, you can actually see the influence of the Whole Earth Catalog on how Jobs thought and spoke throughout his entire career about his belief system and his attitude toward technology. I feel like at this stage there should be a content warning for showing Steve Jobs quotes at design conferences, but I'm not going to read through the quotes, because that's not really the point. I'm just going to say that in 1985, in his little-known stripy jumper era, he was talking about giving people tools that encourage them to be creative: computers are tools. In 1989, the mullet years, he's talking about how people are tool builders and the computer is the most remarkable tool.

[00:10:29] Several years later again, in 1994, with a grizzled hipster kind of vibe going on here: "I'm a tool builder, I want to build really good tools." People are basically good and smart; just give them access to tools and nice things will happen. And then perhaps most famously throughout his career, this one is from 1990: his famous bicycle for the mind aphorism [?], I guess you would call it, which is as close, I think, as he ever came to a unified theory of Steve Jobs's opinion on technology. You've probably heard it, so I won't go into the whole thing here, but he's talking about how humans are tool builders, and we can fashion tools that amplify these inherent abilities. So it's that augmentation theme, and for him the metaphor for this is that a computer has always been a bicycle for the mind.

Tools are not neutral

[00:11:24] Now, I bring up all of these examples not to say, isn't Steve Jobs amazing, and therefore it's validating my point in this talk. Actually it's kind of the opposite. I bring this up and point out this pattern just to say that one of the most culturally influential people in modern memory, in retrospect, someone whose shadow loomed massively large over our industry and a lot of the work that has come out of it since, had this theme that he kept returning to again and again. It wasn't just a flight of fancy for him. It was something that over years and decades he kept returning to, so it obviously drove him, and it probably influenced a ton of other people.

[00:12:16] So maybe it's worth interrogating that a bit and trying to figure out what that actually means about our shared attitudes and culture around technology. Although it's all very inspiring nerd motivational poster stuff, these quotes, with the benefit of hindsight there is an element of disavowal to them, of separating yourself and saying, "Look, dude, we just build the tools, man. We don't care what people do with them. Tools are tools, and people do with them what they will." I think what we've seen in the last few years in the technology industry especially is that that's not really a good enough answer anymore. I think it's incumbent upon people who make tools to now think about how those tools might be used or abused or misused, and what the repercussions, the second-order effects, might be.

[00:13:14] I think it's important to highlight that, because we still see this kind of attitude prevail today. Zuck was up in front of Congress a couple of months ago, and in his pre-written testimony he used the word tool or tools 11 times, just in a little preamble. Then it was absolutely scattered throughout his actual spoken testimony, where he was being grilled by the senators. He just kept coming back to it again and again. If you check out the transcript, it's there, and 13 times he mentioned AI tools.

[00:13:49] This really gets me wondering: what's the deal here? Why this obsession with tools that seems to persist over a long period of time? I think some of it genuinely goes back to those countercultural ideals that maybe started with the Whole Earth Catalog. Some of it might be the fact that it allows you to distance yourself from the messy reality of what the tool gets used for, so it's a hands-off approach. But fundamentally, I think the reason people focus on tools a lot, and think and talk about them and valorize them, is because tools are levers for impact, and impact on the world, making a change in the world, is the thing that's very much celebrated in our industry.

[00:14:45] What I'd really like to hone in on is the fact, as I've maybe been hinting at already, that if you're taking it upon yourself to build tools, they're not necessarily these neutral things. They have a pretty big influence on the work that's being produced with them. In many cases they even have an influence on the physical world. I thought this was completely fascinating: apparently the CTO of Autodesk said, "I can walk through a building and I can tell you which version of AutoCAD was used to design it." That's crazy. The architect is sitting there thinking, I am the maker, I am the creator, this idea and vision is coming from me. But I think it's very true that in a lot of cases the tools that we use, through suggestions they make to us as designers or makers, are influencing the output, whether we know it or not.

A short history of web design

[00:15:42] This definitely isn't just the case with architects. It's the case with what I imagine most of us here are, software people, as well. I think I can demonstrate this by showing you how the tools that we have used, assuming most of us are digital software design type people, have actually driven a whole bunch of trends. So come with me on a short lesson through the history of web design. A lot of early web design looked like this. A lot of early software design for the internet more broadly looked like this. Websites were designed, as we would probably say today, in the browser, which is to say that we didn't have this process of designing some static representation, like a mock-up or a prototype, and then handing that over for implementation. A lot of these design decisions happened on the fly as things were being built. That was around 1996.

[00:16:41] A few years later, people started using photo editing tools, things like Photoshop, in combination with other tools like Dreamweaver. What you could do is draw the static picture in Photoshop and then use Dreamweaver to slice it up into lots of crazy table combinations or image maps, and create something that looked like this. So the tools were suggesting new possible directions. The commonly used tool, which was Photoshop for a long time, started to suggest new styles. This might have been the late 90s. The brush tool and layering tools allowed you to do lots of pixel-style things, so that became a really popular trend for a while.

[00:17:24] Photoshop got more powerful brushes, where you could do lots of textures and layering, so this grunge style was very popular on the web for a long time. Then Flash came along, and of course, totally not influenced by Flash, everyone decided that having a crazy animation at the start of your website was important. Not the case at all, right? The tools suggested to people that they should do these big intros and crazy rollover transitions and so on. Then into the Web 2.0 type era, where things like gradient and bevelling [?] features in newer versions of Photoshop started to become available, and you can see those coming out here. Then finally, reaching its zenith, I guess, and maybe subsequent demise, in so-called skeuomorphic design.

[00:18:13] And finally flattening out to the prevailing aesthetic of today, as we moved from these more raster, photo-editing type tools like Photoshop to the newer generation of design tools we use today, like Sketch, which are way more vector oriented. You open Photoshop and it suggests to you, subtly, through little signals and the tools it makes available: hey, you should build layers and blend them together and get that grungy look. Sketch doesn't do that at all. Sketch says you should draw boxes and layer those boxes and create drop shadows between them. The tool really influences what you do and those trends. There's a bit of a dance here: the tools are also responding to some emergent trends.

Don't let your tools push you around

[00:19:02] But I think that for anyone who is at least interested in the idea of pushing their craft forward a bit or trying new things, and at least some of us should be, we should come to these tools somewhat skeptical. Come to Sketch and realize: I could do a grunge-style design here, but I'm never going to. It would almost be like solving the maths problem with the brick. It's so unergonomic to do it with that particular tool that I'm not even really going to end up doing it. So what we end up with is a load of websites or products or apps that look like this instead. None of them are offensive, right? They look pretty nice. Individually you'd have no problem with them, but taken as a whole, I think it highlights the danger here: there's the possibility that our tools railroad us a little bit too much, and we end up with almost a design monoculture. So think about what these tools are suggesting to you, somewhat quietly, and don't let them push you around.

Process is a tool

[00:20:14] The last thing, to make it maybe a bit more practical, is to talk about another way that I really think about tools, and that is the tools that we use to run our team. I think the way that this most often manifests, at least when I'm talking to people, is in this question that people ask all the time: what's your process? What's your product process, what's your design process? The idea being that some other group has got it figured out, and you just need to latch on or adopt some of their process and everything's going to be totally grand.

[00:20:50] I actually do try to connect with other design leaders in the industry and ask them this question. The really good thing that I take from that is that a lot of other people are dealing with the exact same problems that we're dealing with. It's a bit of a shitshow for them as well, which is incredibly reassuring. I hear these same things from all sorts of people. It varies depending on what stage you're at as a company and what you value and so on, but a lot of these things are problems that come back to how your process is set up.

[00:21:27] The interesting thing is that there's no one-size-fits-all solution to these problems. We all seem to have the same problems, but we seem to need to invent our own independent solutions. Everyone is struggling in isolation, going: what are the tools that I need to build for my team that help us solve some of these process problems? What I have discovered is that if choosing a design tool really influences the output of your work, choosing a specific process really, really influences a whole bunch of people's work, and can have a massive impact. Sometimes that impact is not necessarily what you would have had in mind. So the same thing applies: the tool you choose can influence your output, even at this process level.

[00:22:18] Process is a tool. It's the main tool that you have if you're someone like me in a design leadership role, or I would suggest a product leadership role as well. So for the last section here I wanted to talk a bit about process, and my own philosophy around how to tackle this at Intercom. It came after many false starts where it was like, we just need to get our process locked in and then we'll be in a good place and things can just run. It took me a long time to realize that the "we're just one step away from being finished" mentality was absolutely the wrong one to adopt when it comes to putting a process in place.

Kaizen at Intercom

[00:22:58] In fact, my approach is way more influenced by the way Toyota approached their car manufacturing assembly line process. Long story short, the Japanese and the Americans were in a trade war of sorts about who could win the car economy, essentially, globally. The prevailing wisdom was that the most optimized process for building a car was the one that was going to win. So take the existing assembly line process, turn the Taylorism dial up to the max and get every last drop of efficiency out that you could. Toyota changed this model in a very subversive and unexpected way.

[00:23:47] Instead of "we tell you what to do, that's the process, just do it as fast as you can, shut up and stay quiet about it," they said: hey, there's literally a big red button on the line, and if anyone sees something wrong or something that can be optimized, you hit the button and we'll stop the line. Again, the frame of mind was to keep the line moving as fast as possible, so stopping the line is very counterintuitive initially. But they realized that sometimes you need to let people stop the line, change something about how the whole process works and then start again, and in the long run that's going to win you greater efficiencies.

[00:24:25] They call this approach Kaizen. I don't know if anyone here reads kanji: kai meaning change and zen meaning good. So essentially change for the better, change for the good, or continuous improvement. That's the philosophy here. Taking this approach as inspiration, and realizing that we were never going to be done, that it was this process of continuous improvement in terms of our work as a team and how we approach our process, we started something internally that we called Project Kaizen. It's a project, driven by members of the team, where we figure out how to improve our process on an ongoing basis. No more of this idea that one more tweak and we'll finally be done and we can get on to something else.

[00:25:12] We set this up, and we run it exactly like we run projects at Intercom, because it's an ongoing thing. This is maybe somewhat boring, but I think people don't go into the spreadsheet reality of work all too often. Running it as a project at Intercom means we have a roadmap with problem statements. We have cycle goals; we work in six-week cycles, and we break those down into weekly goals. Running it like a project, we have a backlog of things that we're not going to do now but might get into in future. Running it like a project allowed us to think of it as a thing that won't be finished. We don't think of the products that we build as something that will be finished. We're into this mindset of iterative design all the time. It's a rolling thing, and I think we need to think about our process and the tools that we use as something very similar.

Design ops

[00:26:07] We were running this for a while, and then someone went, "Hey, this whole Kaizen thing, isn't that essentially design ops?" And we were like, oh yeah, it is, actually. So we invented design ops without knowing it, but have since changed the name to design ops, because it's a more generally understood phrase for what it is. If you haven't heard of it, it was a phrase that I only really encountered sometime last year. Teams like Airbnb and Pinterest are really leading the charge here. They're at the forefront of establishing it as a function and a role within design teams.

[00:26:45] These are essentially full-time staffed members of the design team, and their job is to continually improve how the team works, improve efficiency and improve how we operate. A lot of the problems that I had up on the board earlier are opportunities for someone who works in design ops to solve: stuff like our team processes, our rituals, the software that we use, how we do recruiting, how we do onboarding, training, org design, resourcing. All this kind of stuff honestly takes a ton of time from people who are also trying to ship product and do other things. It really allows the design ops people to focus on it, and they also have a horizontal remit across the team to make some of these changes.

[00:27:38] Essentially, what it's about is maintaining, in the broader sense of the word, the tools that we use: both the software tools, but also the processes, the rituals, all that other stuff. I'm personally delighted to see this becoming a part of design teams. I think it's one of the grungiest things that we struggle with. It isn't the thing that we write Medium articles about or show to the world. It's not part of the tip of the iceberg that the outside world gets to see. It's the under-the-iceberg stuff. I think it's an opportunity for us to get a bit more mature and organized and operationally minded about how we do design work, and therefore more efficient. The ultimate thing here, to bring it back, is to enable everyone to build their own products, build their own tools, whatever it is they're building, and be more effective in that regard.

Throw out old tools

[00:28:31] So I would urge you to think about subverting and replacing a lot of the tools that you rely on today. Don't get stuck in some dogmatic mode of thinking: well, this is the way that we've done it. For any team that's growing and changing, by definition the way you work needs to grow and change as well, otherwise you're going to become obsolete very quickly.

[00:28:54] Some final thoughts, back to the broader theme of tools. We as humans, as big hairless apes, are somewhat limited creatures. You can exercise all you want, but there's some natural limit to how strong you're going to be. Use a tool and you can augment your physical capabilities exponentially. You can sit down and think, or study, or talk all you want, but fundamentally, for some measure of intelligence, you're never going to be as intelligent as any regular person equipped with a smartphone, for some measure of intelligence at least.

[00:29:38] So I think we, as makers of tools and as users of tools, have this incredible opportunity to expand our capabilities. But we also have a responsibility to think: if I'm making a tool, how's it going to get used? If I'm a user of a tool, how is that influencing the work that I do? And don't be afraid to throw out old tools and come up with new ones. It's an incredible way of getting you to think about a problem from a new angle. Really, in the long history of humans and their relationship with technology, casting aside old tools and adopting new ones has fundamentally always been where progress has come from, so that can't be a bad sign. That's it. Here are my socials and stuff. If you want the slides, or any of the quotes or whatever, you can drop me an email and I'll send them to you. Thanks very much.

Q&A

[00:30:39] Host: Great, thanks, Emmet. We're going to be setting up the chairs for the panel next, but I think we have time for a couple of questions. Anybody have a question for Emmet? Yeah, right here in the front. They'll bring the mic over.

[00:31:04] Audience: I guess one question I had was with the idea of that design ops team. Have you found any pushback from the rest of the design team members? If you're centralizing this idea of, okay, here are the people who are responsible for improving our process, how has the rest of the design team responded to that? With the Toyota example, each individual worker was empowered to flag an issue they saw, but if you have another team who's saying, well, this is actually the way you should be working, have you found that response?

[00:31:45] Emmet: Yeah, that's a really important thing that I probably should have addressed in my talk. The short answer is that it's highly important that this person is a conduit for what the team actually wants, and that they're responsive to it. That's why the Kaizen example is about it coming from the team. How we model that at Intercom: we don't have a big red button, but twice a year we run a company-wide survey. Six hundred and something people in the company now get this survey, and it's basically prompting everyone: hey, how are we doing? What's working, what's not, what would you change, what do you want the leaders to know about? It's quite broad.

[00:32:23] We collate all of that feedback and break it down by department, by everything. We break it down by gender, by location, all this kind of stuff. So then, as a design leader, I can see what the pain points are for my group, what they're saying: what worked for us when we were 15 people is starting to break a bit now that we're pushing 20, things like that. That gives us the ability to react to it, and basically all of this stuff is done in collaboration with the teams. The design ops person is more of a facilitator than a dictator.

[00:33:01] Host: Great, thanks, Emmet. You're going to be around at the break? Yes. So if you have more questions for Emmet, he'll be around at the break. Thanks a lot.