Hello everyone And welcome to the switch statement podcast It's a podcast for investigations into miscellaneous tech topics
Jon:This is episode 12 in our series on the Design of Everyday Things by Don Norman.
Matt:Hey, John, how are you doing?
Jon:Hey Matt. I'm doing pretty good. How are you?
Matt:I'm doing all right. I'm interested to get your ideas about are which features should we remove from mat chops? We must have stuff we can remove.
Jon:We, there's so much stuff we could remove, we could remove. multiplayer, we could remove avatars, we could remove,
Matt:Dude, we can't remove avatars.
Jon:I mean, I love the avatars, like I worked on the avatars. Although looking at the analytics for how often people use avatars is depressing. But there's always this, it, it's interesting talking about removing things because Uh, you know, as I've grown in my career, I've become less and less attached to things that I've done. I've, I've almost reached the point where I am like utterly apathetic. Like, oh, you wanna wholesale delete this entire thing that I've just poured my heart and soul into for two months? That's fine. Like, I just have no emotion to it whatsoever. But I used to get attached to things and I actually think that can have value. Because you can sort of continue to mine it and like eventually reach a point where it's, where users love it, talking about something in this chapter. There's that whole incremental progress of technology. I think the same thing exists for products where products start out really shitty. Like I think Drive is kind of an example of this, uh, where when Drive started, it paled in comparison with Dropbox. But I would argue that today Drive is better than Dropbox on almost every axis you could think of. so anyway, that's my question With math chops features, it's like, are they bad features that we should cut or are they things that we should iterate on more?
Matt:This is, this is what he gets into where bad features are iterated into good ones and good features are kept, I think he was talking about how like iterative development works, as opposed to specifically harping on the fact that we never remove features, but. I think they are actually related. It's like, Iterative development ties directly to a rampant feature ism or a what is, what is his term? Creeping, creeping futurism.
Jon:yeah. Creeping features. Um, Yeah. I don't recall him talking about removing features. I just recall him, uh, saying, which I completely agree with this, and I think he was quoting someone else, you should strengthen your strengths rather than w you know, working on your perceived weaknesses. Like obviously if you have actual weaknesses that are hurting your business, you need to work on those. But I think a lot of companies. And, and the example that he uses is you see another similar product implement some feature, and you immediately think that you also need that feature. And that is often a fallacy in building products. Like you should focus on what your product is good at, and what your users love about your product. And basically just ignore what other people are doing. And he calls, he calls out, uh, Jeff Bezos ism. which is, uh, to be customer obsessed, that's the term that he uses. Which by The way, slight tangent, but I feel like all of this business acumen gets attributed to Jeff Bezos when it's actually just like ancient wisdom and it kind of bothers me cuz I like hate Jeff Bezos. But if you're starting a business like that is, that is the absolute watch word that your entire business should be focused on. Customer obsessed. You know, if the customer cares about it, improve it. If they don't care about it, you shouldn't care about it.
Matt:Right. Um, but I actually, I do want to, um, take a step back this is chapter seven. This is the last chapter of this book. And it is designed in the world of business. You know, you're probably gonna kinda got a sense that we're starting to talk about. Like, How do companies decide. To make decisions that effect. Designers and the product and what have you. Uh, in a competitive landscape.
Jon:I thought an alternate title for this chapter could be. Or why the previous six chapters are almost never employed in the real world.
Matt:It really is sad.
Jon:just spent an entire book talking about this ideal way to approach design. But uh, because of reality, none of those things ever get employed.
Matt:Here's why you're actually not going to debt. To do any of that stuff.
Jon:Exactly. Which, it all goes back to resourcing trade offs. You know, you only have so much time and money. You need to make a product with that time and money and you know, you can't waste a huge amount of time doing some idealized brainstorming session that takes two months or whatever. He starts the chapter off with an interesting anecdote where he talks about how there used to be a close coupling between designers and users. And how the golf between those two things has grown. Where now there's like a product manager or like a salesperson that talks to a customer or maybe a customer service representative, and then that gets filtered to a product manager that gets filtered to a researcher and that finally gets filtered to a designer. And then that finally gets filtered to an engineer, and then the engineer builds the product. And we've, we've definitely talked about this before on the podcast. Uh, but I just thought it was interesting that he was calling this out in this chapter, uh, because it's just, it's one of the realities of business today is that that golf between the user using the product and the people actually building the product has only grown as time has gone on. And there are benefits to that in business, but there's also a loss to that. You know, like as an engineer, I have noticed. That I have been out of touch with users on many, many occasions and I think that that's probably hurt the products that I've worked on. Um, so this is something I've always found interesting cuz whenever I feel that direct connection to a user, like if I'm going to user studies and if I'm actually talking with users, I feel like I'm building better stuff.
Matt:Yeah. No. I think that's very true. And I feel like. For a lot of my career, I've been completely detached from the user. And then now at. When. We were working on match-ups, which just to, just to explain, I don't think, you know, it's been a while since we've talked about match-ups match-ups is, uh, a test prep app that, uh, John and I. Uh, and I work on with another, uh, actually the CEO was on a previous episode. Uh, just in case it was like bewildering, like what match-ups was. To get back to my point, When we were working on our own personal projects and now I'm working at a startup. You have much more direct access to users and their pain and how are they using the product? And I, and I agree. Um, there's this point that I wanted to raise. I just recently rewatched that kind of iconic scene from office space if you've never seen it, there are these two. Uh, two guys that they've brought in the bobs to make cuts at this software company. So they're talking to this guy. And they're like, so you bring the requirements from the customer to the engineers. Why can the customer just talk to. The engineer and he's like, well, I'm a people person. Like I understand people, like I know what the user wants. It's funny. Cause I think at first it's just a funny situation, but you kind of realize like, That's how it works. I feel like the writers of office space must have been in the software development lifecycle somewhere because everything about that movie is like, is really on for software development. But it, it really is true and that's like farcical representation, but it's exactly what you're saying where there's all of these, like this business Croft in between the user and the people actually building it. I would just wonder what gets lost in translation. There.
Jon:Oh, I wonder that's so often and you know, you do see the, just to argue the flip side of that briefly, like I. You do see benefits from doing it that way, like it is really beneficial when the engineering team can just focus on the task at hand. Um, a lot of engineering shops use agile development where you have iterations and basically throughout the iteration the engineers can just put their heads down and like really focus on what they're building. And obviously if you were talking to customers all the time, you'd get distracted. You know, you'd probably lose sight of certain priorities. Uh, so I do think that those layers of insulation, those kind of buffers create those, uh, that situation where each person can focus on their role and not lose sight of near term priorities. So I do think there's pros and cons of, you know, having a more direct connection to the customer. But definitely, you know, if you are building a product, You need someone with that direct connection and you need communication lines to be very clear between the customer and the engineer. Um, so anyway, I I, I could go on about this for a million years and I would probably just repeat myself over and over again. Uh, another concept that he talks about a little bit later in the chapter, which I thought was interesting is tech compression. Where, and I think he referred to it as tech compression. I have a, that, or that was just a term I came up with, but he just talked about how cameras merged with phones at one point. And it's weird to think about that because today we, I don't think anyone thinks it's weird that cameras and phones are the same thing. Um, but I do remember that period where that was happening and I was thinking like, why are cameras and phones, I. The same thing, you know, like it was weird to me cuz I was old enough to like, you know, see that it was happening and I just thought it was kind of strange. Um, and I wonder in the future, like what things are going to merge? You know, like, is everything just going to be in a cell phone eventually? Like, you'll have a little assistant in your cell phone. I think, uh, it's all just gonna merge.
Matt:Yeah. It is funny. I feel like. If I were an engineer on that team or a designer on the team, who's like considering the smartphone. I do feel like, uh, a camera it's like, are we putting too much into that? Like, it's like, let's have one thing that does a good job. And then like, obviously in retrospect, that would have been a terrible idea. but does that? Not just smack of like feature creep, ism that it's attempting to do everything.
Jon:Yeah. It's a weird coupling, right? Going back to the coupling term,
Matt:I feel like every five or 10 years. Uh, someone puts out a modular phone concept. Uh, that just for whatever reason. And I don't know if it's just the fundamentals of like a, it's a combination of the engineering is hard and not enough people care. You know, it's like, I guess the reality is that. The vast majority of people. I can just use the same thing and it's good enough for them that like you don't need really customizable functionality.
Jon:Yeah. Well, and that's, that's something that I think has always hurt those modular phones is The vast majority of consumers just want like a ready-made, turnkey solution. Uh, I think people like you and I are very interested in something like a modular phone where, you know, maybe we could put like multiple cameras on it and have like stereoscopic images or some crazy thing. But, you know, most people just, uh, they want, they want things to be simple and just work.
Matt:So he also talks a lot about innovation in this chapter I think even on a small level, you can kind of take. I an incremental approach to improvement or this like radical approach to improvement. And I think there's pros and cons to each approach. Uh, so I'm curious, what you thought about this.
Jon:I did think this section was very, very interesting cuz I've, I've wrestled with this a lot in my career. My personality is such that I want to just quickly identify problems and quickly identify things to work on and just start working on them. I think I, I fall in more of like the radical camp where like, yeah, I just, I want changes to be big and I want, you know, things. I don't wanna spend a huge amount of time thinking about like, tiny little things that we can do here and there. I mean, obviously I do spend a lot of time doing that. I think any engineer who's been doing this for a while, you know, a lot of what they do is that, um, But I, I find it to be, I don't know, I find the radical side of the spectrum to be exciting and kind of intoxicating in a way cuz you're sort of always pushing for like, you know, the next big thing. Um, and I, I, I also think it's interesting, something that I was thinking about while reading this was I think that the incremental approach can actually be approached in a, in more of the radical way where. Like one way to approach the incremental approach is you decide on like a bunch of small things that you're gonna build and, you know, you, you build them and you sort of like, uh, test them a little bit. Uh, you use AB testing in order to like get feedback and you see which ones work and you just pick the things, uh, that did well. But another way of doing it is sort of applying the radical ideology to the incremental approach where you try to like skip a few steps. You know, you try to like do something a little bit more radical and obviously there's this trade off between resource costs. Like you might waste a bunch of time working on something that, you know, just falls over once you're experimenting it. But you might, you might skip some steps, you know, you might actually save yourself some time. Um, and I think, you know, just to use a concrete example, uh, I think a lot of old systems have struggle with like architecture problems. You know, where your architecture either has a lot of tech debt or you know, your, your modules are too tightly coupled, your system isn't modular enough, so it's difficult to work on, and you can either approach that iteratively where you identify little tiny things that you can change about the architecture that slowly get you towards a better architecture. Or you can just say, Hey, let's tear the whole thing down and rebuild it, which is almost always. You know, the wrong thing to do. Like that's, it's very frowned upon and generally viewed as naive. But I think you can use certain elements of that. You know, maybe you can tear down an entire, like vertical of the system and just rebuild that vertical. And you're sort of doing this hybrid between incremental and radical, uh, which I think can, you know, bear fruit sometimes.
Matt:Yeah. No. It's funny because I was almost going to say. The opposite where. I feel like, I feel like an anti-pattern I've seen with engineers is. They look at the current system and they're like, This is terrible in so many different ways. We have to replace it all. And
Jon:Yeah.
Matt:it's like, is that the right? And, and I guess you're getting at this, like there, the redesign is kind of this like classic blunder, I guess.
Jon:a siren song for sure.
Matt:Um, So I feel like I've been. Much more. Interested in going in taking like you identify a. Like you have a vision of, of what, like an idealized system would be. But. You don't allow. Not achieving that vision to block these other incremental improvements. And then I think as long as you understand what a more ideal version of the system would look like. And that those tiny steps that you're making are kind of like in that direction. And I don't know, maybe this is kind of like the safe. Never actually solved the problem approach. Like it's like you have fundamental design issues with the system, and then you're just layering on these quick band-aids uh, and then all the band-aids are negatively interacting with one another. And so. I do worry about that where it's like at a certain point. The problems are more fundamental and you just need to do this radical rearchitecting. Um, but I think it's too easy to fall into the other thing where you, you want to immediately change everything about the system. Um, and I think that's actually a worse problem that leads you to just not ever be able to land anything. You know what I mean?
Jon:Oh, I agree. Yeah, I, I think it's, I think it's something where you need to prove that the, the trade-offs make sense, you know, because I think the way that you're talking about it is almost always the case where, It just does not make sense to like, tear down the entire thing and rebuild it. Like, I don't think, I think that almost always is, is a bad way to do things. Um, but yeah, I mean sometimes there's, there's leaps and bounds in technology. You might have like a large part of your system that maybe some library is out that like basically does that and you could replace some big part of your system with the library. Um, And in those types of situations, maybe it does make sense to consider something like that, but it all goes back to the pros and cons analysis. So it's tough. Um, I don't know. Is, is now a good breaking point, uh, for.
Matt:Yeah. Let's wrap it there. So yeah.
This first section was
Matt:kind of about. The competitive decision-making and how innovation works.
In this next section
Matt:talk about, uh, more obligations of design, like what. Responsibility as a designer. Do you have,
Jon:fun stuff. All right. Bye.