Hello everyone And welcome to the switch statement podcast It's a podcast for investigations into miscellaneous tech topics
Jon:This is episode 11 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, pretty good. How are you doing?
Matt:I'm doing okay. I'm excited discuss how theory and practice meet.
Jon:Yes. Yeah, Don Norman has this great quote. In theory, there is no difference between theory and practice. In practice there is.
Matt:I mean, that's all you need.
Jon:That's all you need
Matt:you need for e theory and practice.
Jon:Episode over. but yeah, he's, he mentions how human-centered design. Which is something we discussed in the last chapter. It's basically this framework for solving real world problems and creating real world things that people can use. Describes this ideal theory of like how to solve problems, how to build products, but in the real world, there's these things called businesses that have bottom lines and they have to reach quarterly targets. And it often throws many, many wrenches into this process of human-centered design.
Matt:Yes. There was a part where he talked about this, which like, I just felt very, like, seen by, uh, by this part. He talks about, he says, all right, imagine the design team being told that it's about to work on a new product. Wonderful. That cries. The team will immediately send out our designers. He's like, how long will that take? And he's like, we can do it quickly, a week or two to make the arrangement, two weeks in the field, a week to distill the findings. Four or five weeks. And then the product manager's like, There's no time. There's no time. And then the designer comes back. It's like, it's essential if we want to really understand the customer and then the product manager's like, next time, you know, we're behind schedule, we're over budget right now, but like next time we are gonna do it. Right.
Jon:Yep.
Matt:I feel like that is literally every time I do anything in software engineering where it's like, I, I start on a project and then like immediately it just gets like, it's, it like the theory and practice meet. It's like I have this idealized idea, idea of how I'm supposed to approach an engineering problem, and then very quickly that all just gets thrown out the window.
Jon:Yeah, I have this bullet point in my notes. Ask Matt, have you ever followed H C D properly?
Matt:No.
Jon:Yeah, neither have I. And it is really sad, like I've e I've even been on teams where our stated mission was to like truly understand the needs of, uh, you know, our audience. Like I was on a, a virtual reality team where we were trying to create. You know, virtual reality was this fairly new thing at the time. So we were trying to create a solid product that, that, um, some demographic could use and we had no idea what the product was going to be when we started. Like, we literally formed a team and had no product. Um, so we attempted to go
Matt:was the, what was the prompt though, of the team? Like build. Build?
Jon:productivity. It, it was meant to be, you know, this was at Google, so, You know, Google's whole mission is organizing the world's information. Making people more productive is, is sort of a facet of Google's mission. So our stated mission on the VR team was make people more productive with virtual reality. And we tried out a bunch of prototypes and it was super duper exciting. We did, we sort of did this process in microcosm, but I feel like there was a point where, I'm assuming someone got yelled at, some high lead was like, Hey, you're taking too long. And we just sort of like stopped that process completely. And we switched gears and started working on an actual product, which, you know, I didn't think was the right, the right play, but I'm sure that's debatable. But anyway, the point is we did not, we sort of followed this process, but then we stopped and it felt like reality kicked in.
Matt:I am curious, w w did you attempt to do a. of what you had learned up until that point, because it almost feels like a, a divergence convergence opportunity where you're like, okay, we've diverged for a while. Like what is the process of converging towards like, or did it just seem like arbitrary and you kind of just picked one of the.
Jon:No. Uh, so I actually felt like we were doing this, but it just, it just felt like there was a point where it stopped abruptly and, because what we were doing is we were building a bunch of prototypes. We built a prototype where you could like read a design review, but you were like in a peaceful beachside resort, you know, so you had your head, your virtual reality headgear on, and there was basically this like floating document. Um, and then what we would do is we would invite a bunch of people to use that product. Uh, basically this, the observation part of things, and we would distill their feedback. You know, we would listen to them. A lot of people for that particular thing, a lot of people complained that, you know, virtual reality, it's just hard to read things and virtual reality. Um, so yeah, we were going through the exercise and I felt like we were doing it right. Uh, and we built, you know, four or five pretty cool prototypes, but then there was just a point where it was kind of like, okay, let's stop doing this. I personally felt like we should have kept doing it for another month or two. Um, so I, I, the issue wasn't that we were doing it wrong, it's that we just abruptly stopped and like made a premature decision. That's sort of, that was my perception of events.
Matt:Interesting. So you kind of felt like the process should have continued until you found something really compelling, when in reality it was like it stopped and we picked the most compelling idea that we had at the time, which was still not particularly
Jon:Exactly. Exactly. Yeah. I felt like we were slowly getting towards this, you know, maximal possible idea, but we stopped at like a local maxima and just kind of ran with it. And, uh, you know, there, I mean, obviously there's a point where you have to stop and actually build a real product, but I, my opinion at the time was that we should have kept going for a little while. Um, but yeah, I think Don Norman puts it pretty well. He has Don Norman's law. The day of product development process starts, it is behind schedule and above budget, which is very true. Like this is how every single thing I've ever worked on has felt.
Matt:He his antidote to that problem. It was interesting to me, and it alludes to the fact that like, I, I guess a single person could do human-centered design, but like it's really more of a f of an idea at like an organization level where you have. You have dedicated resources who are constantly researching the, the way the users are using the product.
Jon:Yes.
Matt:they're just gonna have insights in, into how users are using it, when the product team needs it. Um,
Jon:Yeah. No, and I, I actually have become a huge proponent of this philosophy. I witnessed this at Facebook, like I worked at Instagram for about a year, and there was a person who was sitting with our team, and she was a user researcher. And she would do user research about things that we were not even working on. Pretty much exactly what Don Norman is talking about, where she would come up with like a theory, you know, maybe, uh, users are happier when they're talking to their parents. That would be like her theory and she would look at the data a little bit. She would enlist the help of a data scientist. She would also go out into the field and talk to like, you know, high schoolers cuz high schoolers are like the main demographic of Instagram. Um and it was amazing. She would come back to the team and she would present to us like, Hey, here's what I observed with this interesting topic. And you know, sometimes that would distill into like part of the product that we would work on, but sometimes it was just this like really interesting, you know, sort of. I don't know, like nugget of knowledge that she had gathered and it was somewhat disconnected from like the overall product cycle. And I, I found that personally to be really, really valuable cuz she sort of had this really global understanding of like how our part of the product worked.
Matt:It never ceases to amaze me how. Incomplete a picture, an engineer who works on a product every day can have about the user's u usage of that product.
Jon:Yeah.
Matt:Uh, it's like, you know, I, I work on what is, you know, I work on our client app, like spending very little time understanding the user's flows and things like that. So, um, I don't know. I think that that work is really invaluable.
Jon:I, I came out of Facebook thinking that the user researcher was the most valuable member of the team. Like they're the person, like they're literally the person on the front line who actually knows how the user functions.
Matt:Yeah, which as discussed, that's the only way to know what actual problems you have to solve.
Jon:Yeah.
Matt:Um,
Jon:Yeah And it, it's interesting cuz engineers kind of, by necessity, I want to say, have to be behind like several layers of indirection.
Matt:Yeah.
Jon:you can't, you know, the, the user researcher can't like directly convey to an engineer what they need to build. I mean, I suppose if you had this like omnipotent user researcher, maybe they could, but I feel like it generally has to go through, you know, a different human being who has learned the art of like distilling user feedback into product, you know, chunks and then knows how to un, you know, convey those product chunks to an engineer, which is yet another entire thing that you can spend decades learning. Um, so it truly is, you know, multidisciplinary teams truly are the secret to like building an actual good product.
Matt:You're, you're alluding to kind of this, this spectrum, uh, of human to machine where it's like, okay, we just have, we just have a series of humans who progressively they switch from understanding humans really well, and maybe not necessarily understanding machines particularly well. And then they, we get progressively closer to like, okay, understanding how machines work. And then like, you don't, like the human understanding has been kind of distilled into a machine specification. So the engineer at that point doesn't even, doesn't really need to care.
Jon:Yep. Yeah, and it's, it's funny cuz historically in order to build products you've had to be able to like leapfrog those, chasms, those huge gaps in understanding between different members of teams. And you need these very amazing people who can do that. But but today we're seeing things like, you know, G P T, which can basically take
Matt:do it all in one shot.
Jon:Exactly. Yeah. Which is super exciting, but also super, you know, just scary, I guess, to see how it's gonna influence the industry.
Matt:Yeah, no, I'm, I've, I've resigned myself to having, like, there's a kind of a TTL on my employability, uh, which is maybe 10 years. Uh, and that's game over.
Jon:Yeah. I'm lucky because I'm already old. So I, I only have another, you know, five, 10 years of life left. So I'll, I'll be okay
Matt:Um, okay. He did have one thing that I wanted to get your thoughts on. He has a section in this chapter called Complexity is Good.
Jon:yes,
Matt:It's confusion that is bad, and I wanted to get your thoughts about that.
Jon:this was my favorite section in the entire chapter because this is something. I wrestle with at my job nonstop. And he mentions like I, I use this term intrinsic complexity. Uh, I don't know if this is like, I don't think this is a term I invented, but in any product, there's going to be complex problems and there's going to be complexity that is required to solve those problems. And I refer to this as intrinsic complexity. But then there's all sorts of complexity that exists because people didn't solve the problem accurately. Or, you know, let's say you're trying to combine a series of solutions and the, the links in the chain that combine those solutions are complex themselves. Mm-hmm. So, so you're talking about complexity that's not inherent to solving the problem, but it's been added to the system. Um, and to me, It, it's basically tech debt. I mean, it's another term used to describe like, parts of a system that exist that don't necessarily need to exist or could be updated or could be made more conventional, more idiomatic, or use newer technology that's just better and solves things in a more simple way. Um, but yeah, I, I wrestle with this constantly this, and he uses the term complicated. Which I thought was interesting. I don't think I've used that term, but he says complexity is good because tasks are complex, but complicated is bad. He, he uses complicated to refer to unnecessary complexity.
Matt:I think a lot of this is like, is a definition of terms. So I think you could wind up kind of going around in circles. Um, there's a talk that I really liked where they talk about the difference between simple and complex and easy and hard, and he actually goes into the roots of these words like complex. Like, uh, complex comes from this, uh, idea of having two bits of fabric, interwoven together, and he translates that into something is complex when it has many interwoven parts that maybe they don't like need to be. Interrelated, you know what I mean? Um,
Jon:tight coupling.
Matt:tight coupling, right? So anyone who is, you know, uh, has, has taken like software design classes, like you're probably familiar with this concept or like, have worked in the industry for a little while, like you have two pieces of code or one piece of code that's kind of like doing two different things, um, like. That's bad. Right? And, and so I think that conception of complexity, I would say is always bad. I don't know, I think I reject his premise that complexity is good. it's a necessary evil. Like yeah, it's All complexity shouldn't be astr entirely. Like sometimes you need it. Like getting back to your point about intrinsic complexity, like that's kind of the irreducible complexity of the system.
Jon:Yes. Yeah.
Matt:Um, and, and again, like now I'm using comp complex in two different, in two different terms here. Like I would kind of more use his term of complexity to mean just having a lot of knobs basically. Uh,
Jon:Yeah. I also did not like his, uh, terminology, like maybe I'm getting pedantic or whatever, but. You know, complexity and complicated are like the same word. Right, but aren't they just different tenses or different? Uh, I don't know if it's tense, but, uh, I just didn't like how he's basically using the same word to describe two completely different things. Um, I like, you know, your term irreducible complexity or inherent complexity. I like those terms. Um, and then I've, I've used the term bad complexity to refer to like, you know, unnecessary complexity. And I like sort of qualifying the word complexity because complexity can be either good or bad. That's my conception of things.
Matt:Right, and it, it's funny because maybe complexity is. Neutral, like, because I'm thinking of something like a flavor, you know what I mean? Like you're drinking wine and it's like, oh, this, this wine has a really complex flavor. And it's like, oh yeah. Like there's kind of, there's multiple aspects to this, which are where they're like showing up in different ways or there's like a complex design.
Jon:Yeah
Matt:well, again, like I, I'm saying it like a visual design, not like a complex user interface design, but um,
Jon:no, I think you're hitting the nail on the head though. I see complexity as a neutral thing. Like it can be either good or bad. It just depends on. Whether it's it's needed or unneeded.
Matt:Um, but there is this point that I did wanna raise, which maybe this is, maybe I'm, uh, shoehorning this into this conversation, but, um, I think of it like when you are trying to solve a problem in an existing system. I think you could optimize for the simplicity of the change or optimize for the simplicity of the system.
Jon:Mm-hmm.
Matt:And it's like, yeah, you could make a, you can make a small easy change that actually makes the system more complex, uh, because like, oh, you just kind of like bolt this thing onto the side and it's easy, but then it, there's kind of more conceptual overhead to using the system.
Jon:Yes. Yeah. And actually this is something that I've seen come up a lot where systems often look kind of like onions, where it's, you know, a bunch of concentric. circles, I guess, where you, you have like a kernel of a system that a lot of things use, and then you have this outer layer that uses the kernel and then you have an outer layer that uses that, you know slightly more inner layer. I, I would use the example of like clients, like a mobile app or a web app, both a mobile app and the web app might use the server. This is like a super highly simplified thing, so if you're implementing some feature and you want it on both the mobile app and the. Web app, you might say, Hey, let's implement it once inside the server and have the server just return This like thing that both the mobile app and the web app can use. But that is often the exact wrong thing to do because what you're doing is you're, you're taking the complexity of a problem in the now, a problem that you're facing today that you understand today. And you're adding that complexity into the API of your server. So two years from now when someone is reading that api, they're like, what the hell is this? Like, it's this completely impossible to understand, you know, obtuse API because it's been written to serve the client needs. Um, this is something I've seen come up over and over again. So it's always good to try to design an ideal api. That might mean that more complexity gets added onto the clients. But in the long term, that's what you wanna be doing. And you can actually, there are other solutions to this problem. There's this concept known as an intermediate service, which can contain some of that like client specific complexity. But in any case, yeah, this is just an example of like trading off, you know, some complexity now for like this far down the road, you know, horrible complexity.
Matt:Yeah, and I think, I think it is a hard problem. I don't want to be dismissive of, like, I, I think there's a reason why a series of engineers have made that decision, especially like, I think there's the cult of like dryness, which like people can adhere to, to a fault. Anytime you have the same logic in multiple places, people are like, absolutely not. This logic, like we're repeating the logic in multiple places, like this is unacceptable. And they literally won't even consider another alternative just because it's apparently this, uh, this hard rule that has an infinitely negative weight in terms of evaluating a potential design. And it's like, okay, maybe we need to back off the dry a little bit like. Um, which, uh, I don't know, did I, did I say what dry stands for? It stands for Don't Repeat yourself. Uh,
Jon:right Yeah This is where religion and engineering meet and it becomes really weird because there is a lot of religious thinking in engineering. And it's funny because you call it computer science, but I feel like a lot of times it's uh, it's a very unscientific thing, kind of what you're talking about. There's, there's a few engineering maxims which feel completely unassailable. You know, you just can't argue against them. And, and d r Y is one of them, and it is obnoxious in my opinion. Um, but what are you gonna do?
Matt:What are you gonna do?
Jon:one section that we have not talked about, which is standardization. Yeah. Um, and I thought this was a, a really interesting section. Basically it's this concept that, you know, different cultures might come up with different ways of doing things. You know, like America uses the imperial system of measurement, for instance, whereas European has the metric system or most other countries in
Matt:The entire rest of the world.
Jon:Yeah. I feel like
Matt:countries.
Jon:every once in a while on the internet, you see those maps where they like, Color code, you know, who uses the Imperial system? And it's literally like some country in Africa and the United States Yeah. Um, but yeah, I feel like we see this a lot in our industry. I know when I started out working in our industry, I, I had to implement everything like five times for i e six. Firefox Opera, and now today, since things are more standardized, you know, there's more of the same consistent JavaScript tooling as used across all browsers today. It's just much easier to solve problems.
Matt:You mean because, uh, Google has a strangle hold on the, uh, Razer market
Jon:much
Matt:they can just bend, bend everyone's, everyone to their will. Well, eventually in the case of safari
Jon:Yeah, but I do, I feel like if you're a, a JavaScript developer or a web developer, you should be slightly happy about
Matt:Oh yeah. It, I feel conflicted. Like I definitely, you see these people espouse these, uh, beliefs like, oh, it's bad. We have a, we have like a, a browser monoculture. And I have a little bit, I have a hard time like, like I see their point, but by the same token, like I have a hard time really feeling that badly about it, given that like how much good that Chrome's approach has had on the ecosystem.
Jon:Yeah. Yeah, I mean it's, it's fascinating cuz there's, there's clearly power in standardization, but there's also, you know, there's unique attributes to non-standard system. Like he talks about digital time, for instance like choosing a different breakdown of how to, uh, represent time. But there's actually a lot of advantages to our, our current system. You know, like I think the number 60 is a logic, a fairly logical number, cuz it can be easily divided by three and 10 or whatever. Um, so, so it's interesting. I think there's just competing concerns. Like it's, it is good to have a standard that literally everyone in the whole world is using, but sometimes if you, you over standardize, you kind of lose some advantages. I've even seen. YouTube videos that talk about the advantages of the Imperial system. And it's while I am more of a metric system proponent, it is interesting that you would, if we all converted to metric, we would be losing something.
Matt:Yeah. I, I'm a big proponent of, of standardization. Like I, I feel like there needs to be a really high bar in order for. Um, for it to be worth having, like multiple different ways of expressing something. Um, I don't think I don't think the, uh, I don't think the, uh, imperial system is meeting that bar. Uh, in my, in my view, all of the imperial measures are expressed in terms of metric anyway at this point. Like they're all legally defined in terms of their metric counterparts. Uh, so it's like it's all metric under the hood anyway. Um, but um,
Jon:I agree. You know, another thing, oh, sorry. Go ahead.
Matt:Well, yeah, you talked about, um, being overly constrained, um, or like having, um, having standardization be like overly restrictive and he has this whole section all about TVs and how like this international organization was spending so much time working on the standardization that by the time they had ironed it out like. The professional world had already moved past it anyway, so it was all moot. Uh, so I do think, I think there's an interesting question around how, how these, like applauding international organizations deal with this extremely fast moving technology. Um,
Jon:Yeah. Um, well, yeah, so I, I think that's, The chapter, uh, in a extremely small nutshell. I mean, there was a lot of little interesting tidbits that we didn't cover. I think one last thing that I would want to leave the listener with is we should standardize the way we represent dates. It should be year, month, day.
Matt:Yes. Yeah, I'm, uh, like I do think, I, I, I agree. I don't, there's nothing else to be said. It's the way, it's the way to do it. Um, alright but let's, let's leave it there. So next time. Uh, is our last chapter for, uh, for the design of everyday things. It's called design in the World of Business. So it should be interesting to get into, uh, I don't know. We will get more into the whole, uh, practice. I'm sure he'll talk about the realities of of working in a business.
Jon:Yeah, should be very interesting. I'll see you there, Matt.