The Tools We Use: Challenging Dogma In The Design Process
The Tools We Use: Challenging Dogma In The Design Process
Many of us in the design community pride ourselves on being tool builders, creating products that others can use to get things done. This is, at some level, the fundamental promise of all technology. Yet if we don't pay close enough attention, our own tools can sometimes get the better of us. Whether it's a team using a prescribed design process, or a company building software to be used by the entire planet, it turns out that these tools can be used in unintended ways. They can break, or grow out of control. And so our job as designers is not just to build things, but sometimes to recognise when we need to take them apart again. In this talk Emmet will discuss some lessons learned while growing the design team at Intercom, how that relates to the broader technology industry, and why building a process for everyone to follow is less important than building a culture that can upend it.
Emmet Connolly, VP of Product Design,Intercom
The tools we use: Challenging dogma in the design process
Speaker: Emmet Connolly
Hi folks, it sounds pretty impressive when you describe it like that. I hope I can live up to the promise. So, I'm Emmet Connolly, I am a director of product design at Intercom. Super quick intro if you don't know us, we build a platform and series 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 of all before I get into that I really wanted to tee up the team that I want to address you here today. So I think like with a mixed crowd like this, different roles, you often have people coming to talks or whatever it might be with different expectations.
I think that on some fundamental level, whether you're like a designer or an engineer or a researcher or a PM or whatever else it might be. I think a lot of us here probably just consider ourselves at some kind of basic level to be makers, just people who build stuff that's how I think about my role anyway and 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. This isn't going to be like a deep design nerdy like Sketch versus Figma talk. In fact, it's about broadening the definition a little bit about tools and getting everyone to reflect a bit on the tools that they use, especially the more I've like grown into my role as a design leader.
The tools that I use are pretty different from the tools that I would've used when I was more focused just on my work and also I've just become interested, fascinated really with how we as an industry think and talk about and engage with tools. So that's the preamble, to begin with, I'm going to start pretty simply. If you ask most people, what a tool is, they would probably pick something like this. They would probably think of a hammer or a wrench or a saw or whatever it is and 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. So it's an augmentation of your physical abilities and that's true.
Of course, tools do that but really there is a bit in a long line of progression I think from these pretty standard basic tools that augment your physical capabilities all the way up to the most modern tools that we use today and that we might think about in this software or design kind of context and I think this is actually pretty well and famously illustrated in what is perhaps the most single famous cut in cinematic history. This, of course, is 2001 a space odyssey by Stanley Crick and in this, there's a cut that happens in a second from the bone to the space station and it's making this point in the film and the film generally makes this point. I think that the tools that we use are like 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 us and the tools that we use.
In many ways, these two tools are like book-ending this very long timeline of tools that we make and build and use and in some sense, I think that almost all of the work that we do engages with the tools along this timeline, in some sense, right? So that's a super, a 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 also if you ask me is a tool but whereas before the tools we are looking at were ones that augment your physical abilities. This one actually augments your intellectual capabilities. So to illustrate that point I could probably ask most of you like a simple maths 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 but then if I give you this really simple piece of technology just like wood pulp and graphite and a piece of paper may be to go with it, you'd probably be able to work out the answer pretty quickly.
And so this tool, this very basic piece of technology really has augmented your intellectual capabilities massively, it's expanded your intellectual horizon almost.
So 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 self-evident but there are other ways of designing tools like this, for an example if I gave you this version of a pencil and I asked you to repeat that same exercise you'd probably have a hard time. I bet you wouldn't complete it, right? You'd likely give up in frustration or you just really struggle with the mechanics of it, which is 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 matters.
And actually, if the interaction design is a big shit, it means that it's actually going to reduce the ceiling of the intellectual capability that the tool can expand you to if that makes sense. Now 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 Engel Bart. The report is called augmenting human conceptual framework and it was part of a wider project that Engel Bart was working on, in the sixties. In the Stanford Research Institute, he was working on a project called NLS for an online system and that project culminated a few years after the report on December 8th, 1968 which has become known since as the mother of all demos.
This is a video from the demo that evening in 1968 and 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, 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. 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 really in Silicon Valley and in the bay area and our wider industry here as well to this day.
And that obsession that has remained, I think is an obsession with tools or the idea of building tools and that being a valuable and a noteworthy thing. So 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 that time called the Whole Earth catalog. These are some spreads from the catalog. So it was a magazine and it was a how to guide, it was aimed at back to the land hippies types, who were moving from cities like San Francisco back to commune 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 self-sufficient lifestyle. There is some mad stuff in there. You should check out the cover of the whole earth catalog featured the tagline, which was access to tools.
So remember this is San Francisco, 1968 and if you know anything about that period you'll know that it was a time when this kind of hippie counterculture style of thinking was very much intersecting and overlapping with the birth of the modern personal computers, same time, same place, these same two things were coming out, out of the same areas and a lot of the ideas and philosophies. Even people kind of co-mingled and c- influenced across between these two groups. Steve Jobs who would've been on the scene at the time later called the whole earth catalog, like Google in paperback form 35 years before Google came along, it was idealistic and overflowing with neat tools and notions. You can actually see the influence of the Whole Earth catalog and how Jobs thought and spoke throughout his entire career about his belief system, his attitude toward technology.
I feel like at this stage there should be a content warning for showing like 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, like in 1985, in his little known Striped jumper era, he was talking about you're giving people tools that encourage them to be creative computers are tools. In 1989, the mullet eras he's talking about people are tool builders and the computer is the most remarkable tool. Several years later, again in 1994 grizzly 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 kind of bicycle for the mind, parable I guess you would call it which is as close as he ever came to like a unified theory of Steve Jobs's opinion on the technology you've probably heard it.
I won't go into the whole thing here but he's talking about humans being tool builders. We can fashion tools that amplify these inherent abilities. So it's that augmentation theme, right? And for him, the metaphor for this is a computer has always been a bicycle for the mind. Now I bring up all of these examples not to be like isn't it's Steve jobs and he is amazing so therefore it's validating like my point in this talk actually kind of the opposite of that fact. I bring this up and point out this pattern, just to say that one of the most in retrospect culturally influential people in modern memory, like someone whose shadow loomed massively large over our industry and a lot of the work that has come out of it since had this team 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 and so it obviously drove him, it probably influenced tons of other people and so maybe it's worth interrogating that a bit and trying to figure out what that actually means about our chain, our shared attitudes and culture around technology because although like it's all very inspiring nerd motivational poster stuff these quotes. In some way, there is an element to what with the benefit of hindsight of separating yourself and saying look we just build the tools. We don't care what people do with them. Tools are tools and people do with them what they will. And I think what we've seen in the last few years in the 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 or whatever it might be. What those repercussions, those second-order effects might be. I think it's important to highlight that because we still see this kind of attitude prevailing today. So Zuckerberg in front of Congress, whatever it was a couple of months ago and in his prewritten testimony he talked about, used the word tool or tools 11 times in just the little preamble and then absolutely scattered throughout his actual spoken testimony where he was being like grilled by the senators. He just kept coming back to it again and again, if you just like check out the transcript, these tools, those tools, 13 times he mentioned AI tools. So this really like just gets me wondering what's the deal here?
Why does this obsession seem to persist over a long period of time with tools? I think some of it is genuinely goes back to those countercultural ideals that may be started with the Whole Earth catalog. Some of it might be the fact that allows you to distance yourself from the messy reality of what the tool gets used for and so it's kind of a hands off approach but fundamentally I think people focus on tools a lot and think and talk about them and valorise them is because tools are like levers for impact and do the work and making a change in the world is a thing that's very much like celebrated in our industry. But I think what I'd really like to hone in on is the fact that as I've maybe been hinting at already, these tools if you're taking it upon yourself to build tools they're not necessarily these neutral things, they do have a pretty big influence on the work that's being produced with them.
They even have an influence in some cases. In many cases on the physical world, I thought this was completely fascinating. So 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, right? Like the architect is sitting there thinking like 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 suggesting their own use to us as designers or makers whatever it is, are influencing whether we know it or not the output and this definitely isn't just the case with architects, it's the case with like what I imagine most of us here, our software people as well.
And I think I can demonstrate this by showing you how the tools that we have used assuming most of us are like digital software design type people. How the tools that we have used have actually driven a whole bunch of trends and 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 these 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 mockup or a prototype and then handing that of implementation. A lot of these design decisions happened on the fly as they were being built which was around 1996. A few years later people started using these photo editing tools.
Things like Photoshop in combination with other tools like say Dream Weaver so what you could do is draw the static picture in Photoshop and then use Dream Weaver 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 tools which were Photoshop for a long time started to suggest new styles. So this might have been like the late nineties the brush tool and layering tools allowing you to do lots of pixel-style things. So that became a really popular trend for a while. Photoshop got more powerful brushes where you could do lots of textures and layering and 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 like having a crazy animation at the start of your website was important not the case at all, right? Like the tool suggested to people that they should do, like these big intros and crazy like rollover transitions and so on. And then finally like into the web 2.0 type era where things like gradient and modeling features in newer versions of Photoshop started to become available. You can see those coming out here and then finally like reaching its Zenith and maybe subsequent demise in so-called design and finally flattening out, to the prevailing aesthetic of today. As we moved from these riskier photo editing type tools to Photoshop to this newer generation of design tools we use today, like Sketch, which is way more vector-oriented. So you open Photoshop and it suggests to you subtly right through little signals and the tools it makes available, hey you should build layers and blend them together and get that grunge look and the Sketch doesn't do that at all.
Sketch says you should like to draw boxes and layer those boxes and create drop shadows between them but the tool really influences what you do that and those trends and there's a bit of a dance here. Like the tools are also responding to some emergent trends but I think that for anyone who is at least interested in the idea of like pushing their craft forward a bit or trying new things and at least some of us should be I think we should like come to these tools somewhat skeptical come to sketch and realize like I could do like a grunge style design here but I'm never going to, it would almost be like solving the math problem with the brick. It is so unergonomic to do it with that particular tool that I'm not even really going to end up doing that.
And so what we end up with is a load of websites or products or apps that look like this instead. None of them is offensive. All look pretty nice, all individually you'd have no problem with them but taken as a whole I think highlights the danger here, there's the possibility that our tools railroad us a little bit too much and we end up with like a design monoculture almost. I mean, think about what these tools are suggesting to you somewhat quietly and don't let them push you around. 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. And 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 which is like, what's your process?
What's your production process? What's your design process? The idea being like that, some other group has got it figured out and you just need to latch on or maybe adopt some of what their process is and everything's going to be totally grand and I actually do try and like connect with other design leaders in the industry and ask them this question and the really good thing that I take from that is that like a lot of other people are dealing with the exact same problems that we're dealing with. In short, it's kind of a bit of a show for them as well which is incredibly reassuring, so like 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 like a lot of these things are problems that come back to how your process is set up and the interesting thing is that we all seem to somehow need to like 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 like struggling in isolation going, what are the tools that I need to build for my team that helps us to 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 like a specific process really influences like a whole bunch of people's work and can have a massive like impact. Sometimes that impact is not necessarily what you would have in mind.
So the same thing applies where the tool you choose can influence your output, even at this kind of process level. So the 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 and for the last section here I wanted to talk a bit about the process of my own kind of philosophy around how to tackle this at Intercom after realising through any kind of false starts where we just need to get our process locked in and then we'll be in a good place and things can just run and it took me a long time to realise that we're just one step away from being finished was absolutely the wrong mentality to adopt when it comes to putting a process in place.
My approach was way more influenced by actually the way Toyota approached their car manufacturing assembly line in the process. So like a long story short, the Japanese and the Americans were in a kind of a trade war of sorts about who could win the car economy essentially globally. And the prevailing wisdom that was like the most optimized process for building a car was the one that was going to win. So take the existing assembly line process and turn up the raylorism dial to the max and just get as every last drop of efficiency out as you could. And Toyota kind of changed this model in a very subversive and unexpected way. They said hey if anyone is on the line instead of us telling you what to do and that's the process and just do it as fast as you can and shut up and stay quiet about it.
There's literally a big red button on the line and if you see something wrong or that can be optimised you hit the button and we'll stop the line. Now the frame of mind was ‘keep the line moving as fast as possible’. So this 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. They called this approach, Kaizen, if anyone here likes to read: Kai means change and Zen means good. So essentially continue change for the better, change for the good or like continuous improvement. That's the philosophy here. So taking this approach as inspiration and realizing that we were never going to be done that with 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, and it's kind of this project where we will be driven by members of the team, figure out how to improve our process on an ongoing bases, no more like, idea that with one more tweak and we will finally be done and we can get onto something else.
So we set this up and we ran it exactly like we run projects at Intercom because it's an ongoing thing, this is like maybe somewhat boring but I think people don't like to go into the spreadsheet reality of like work all too often. Us running it as a project at Intercom means that we have a roadmap with problem statements. We have got cycle goals. We work in six week cycles. We break those down into weekly goals and so running it like a project we have a backlog of things that we're not going to do now but we might get into in the future. Running it like a project allowed us to think of it as a thing that won't be finished, like our products that we build, we don't think of them as something that'll be finished. We're actually into this mindset of iterative design all the time.
It's like a rolling thing. And I think we need to think about our process and the tools that we use as something very similar. So we did this, we were running for a while and then someone kind of went hey this whole like Kaizen thing isn't that essential design and we were like oh yeah, it is actually. So we invented design ops without knowing it but have since changed the name to be this 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, I guess like sometime last year teams like Airbnb and Pinterest are really leading the charge here and they're at the forefront of establishing it as an actual function and a role within design teams.
And these are essentially like staffed full-time members of the design team and their job is to continually improve how the team works, improve efficiency, improve how we operate and all the problems that I add up the board air earlier. A lot of those are opportunities for someone who works in design op to solve. So stuff like our team processes, our rituals, the software that we use, how we are recruiting, how we do onboarding training org, design, resourcing, like all this kind of stuff that honestly like takes a ton of time from people who are also trying to like ship product and do other things. It really allows them to focus on it. And then they also have horizontally across the team kind of remit to make some of these changes. So essentially what it's about is like maintaining in the broader sense of the word, the two that we use, both of the software tools but also the processes, the rituals, all that other stuff.
I'm kind of personally delighted to see this becoming like a part of design teams. I think it's one of the grungiest things that we struggle with and like 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 of the world gets to see, it's the under the iceberg stuff and I think it's just an opportunity for us to get a bit more mature and organized and operationally-minded about how we do design work and therefore are more efficient. And the ultimate thing here is to bring it back to enable everyone to build their own products, build their own tools whatever it is that they're building and be more effective in that regard. 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’. 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. I guess some final thoughts back to the broader team of tools like we as humans, as hairless apes were like somewhat limited creatures, you can like exercise all you want, but there's some natural limit to how naturally strong you're going to be but use a tool and you can augment your physical capabilities exponentially. You can sit down and think or you can study or can talk all you want but fundamentally or for some measure of intelligence, you're never going to be as intelligent as any regular person equipped with like a smartphone.
For some measure of intelligence, at least 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 about 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? 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 and 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 for any of the quotes or whatever you can drop me an email and I'll send them to you. Thanks very much.
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. Does anybody have a question for Emmet? Right here in the front.
I'm Graham, I'm a designer at IBM. I guess one question I had was with the idea of that sort of design team have you found any sort of pushback may be from the rest of the design team members where if you're sort of centralising this idea of like okay here are the people who are responsible for improving our process, how the rest of the design team responded to that? So I think with the Toyota example each individual worker was sort of empowered to flag an issue they saw but if you have like another team, who's kind of saying well this is actually the way you should be working. Like how you found that response?
That is a really important thing that I probably should have addressed in my talk. So the short answer is that it's highly important that this person is a conduit for what the team actually wants and they're responsive to it, so that's why the Kaizen example is about like it comes from the team, how we do that at Intercom? How do we model that? We don't have a big red button. We have twice a year, we run a companywide survey, so 600 and something people now in the company get this survey. And it's basically prompting everyone to like hey, how are we doing? What is working and what is not, what would you change? What do you want the leaders to know about? Like, it's quite broad and we collect all of that feedback and we break it down by like department, we break it down by everything.
We break it down by gender. We break it down by location, all this kind of stuff. So then as a design leader, I can see what are the pain points for my group? What is the stuff that they're saying, what worked for us when we were like 15 people is starting to break for us a bit, now that we're pushing 20 things like that. So that gives us the ability to react with that and basically all of this stuff is done in collaboration with the teams. So the design person is more of a facilitator than like a dictator. Yeah.
Great. Thanks. Emmet you're going to be around at the break. So if you have more questions for Emmit he'll be around at the break. Thanks a lot.