Intro to Design Thinking from A Software Developer’s Perspective

April 18, 2019

Everyone is talking about design thinking. Books are being written, job descriptions are requiring it. But what is it and why is it important to software developers? Joshua introduces the concept and a new series of Youtube videos from Getting Apps Done on design thinking for developers.

• 00:02 Joshua

  Welcome to Getting Apps Done, a mostly non technical podcast with the goal of helping you deliver software because if you didn't ship it, it didn't happen.

• 00:15 Joshua

  Hey folks, welcome back. Uh, again, we have another week with no Kellen, unfortunately. So you are stuck with me, uh, for better or for worse.

• 00:25 Joshua

  But what I wanted to talk about today is design thinking and I'm working on a series of videos to go a little bit more in depth about each of the phases of design thinking. But I just wanted to give a general overview of what I think design thinking is and how it plays into my everyday life as a developer.

• 00:44 Joshua

  Now I know a lot of designers and developers have some issues with design thinking. Most of that seems to be centered around the fact that good designers and developers have been using design thinking for a long time. It's not a new concept though. The terminology is new and I think that's actually a really important part of what it is.

• 01:03 Joshua

  Because prior to design thinking being a thing, we didn't necessarily have a way to communicate what we were doing or why we were doing it to other parts of the business. Trying to explain to a manager why you need to take time to empathize and understand your end users could be quite difficult if that's not something that they naturally grasp. Much the same. Prototyping and building mocks and iterating quickly is not a concept that necessarily makes a lot of sense to somebody unless they can see it within the context of a process.

• 01:35 Joshua

  And that's really what design thinking gives us. It gives us a defined process that is shared amongst more than one discipline. So it makes sense to developers, it makes sense to designers, it makes sense to managers, project managers, investors, you name it. And there's a lot of power in that because we're all on the same page and that doesn't happen very often.

• 01:56 Joshua

  So I think the concept of design thinking a while it's not new and I hate it when things become "things", is still really important and it is good for us to keep in mind. And I'm very grateful that it exists and it is bringing this to the forefront of software development and design in general because of that whole concept of putting us all on the same page, putting us in the same context when we're building an application. Now the way design thinking breaks down this process is into five steps, empathizing, defining, ideating, prototyping and testing. Now there's actually some missing pieces in there I think for the software development process, but this actually gets us to a stage where we have a good design and a good idea of what it is we're building. So these are kind of pre steps to building software.

• 02:45 Joshua

  So, I'll start with empathy because empathy I think is probably the single most important in all of these. Some of the others, they're all very, very important. But I think empathy gets us on the right footing and it's something that a lot of developers I've seen miss because developers tend to be engineers. We like to fix problems. The problem with that is we don't necessarily see the same problems as our end users. It might just so happen that we happen to be our end user as well and we do see those problems and some really great applications have come out of that. But in general, if we're building something for somebody else, we aren't in the same context as them. We're not in their shoes. We don't know what their problems really are.... We're talking about problems that the application is solving, not just in general. Empathy allows us to put ourselves into their shoes... at least briefly so that we can start to understand what it is that they struggle with on a day to day basis. What aspects of our software it will improve their day will make it easier for them to do things or allow them to do things that they couldn't do before.

• 03:46 Joshua

  The second step is to define those things. So once we have put ourselves in their shoes and started to identify what problems they have and what their day to day life is like and how we can improve it, we start to then list those things down. Now, there are a lot of different ways to do this. Some people like user journeys, storyboards, role objectives and lists of pain points and user personas and things like that. I really don't care about any of that. No, I that I take that back, I care about them, but I don't care which one you pick as long as it is a good way to clearly define what you discovered during your empathy stage where you were interviewing people or you were shadowing them where you were learning to understand what it is they do.

• 04:28 Joshua

  Because the definition of that is what is going to help us basically grade ourselves later on. That's what we are matching up against. What we're measuring against in the end when we get to the final phase, we need to make sure that what we have built actually matches the definition.

• 04:44 Joshua

  The next stage is idea generation basically. Um, so this is where we kind of just throw things against the wall and see what sticks. The idea is that there's no bad idea. There are just lots of varying ideas. Some are better than others. Okay. No I take that back. Sometimes there just are really bad ideas, but let's ignore that for the time being. What we're trying to look for is anything in the box, out of the box, on top of the box, holding the box, throwing the box that might help solve some of those problems. Some of those pains that we saw when we were looking at what a day to day role looks like for the person we're building an app for.

• 05:18 Joshua

  Just list them all down and start to rate them. Basically find which ideas seem to have the best traction amongst the internal group you're working with or if it's just you see which ones feel the best to you.

• 05:30 Joshua

  The next stage is actually then testing those ideas by building prototypes that's putting together mockups that's building a, it could be low fidelity, it could be medium fidelity, probably not high fidelity prototypes at this stage because we actually, we want this to be really quick. We want it to be simple and if it's post-it notes that works best for you, then make post-it notes, but the idea is to be able to very, very quickly iterate on our design. On our application and figure out which things again are working best for matching what we defined.

• 06:01 Joshua

  And the final aspect of this obviously is then to test that. Once you have a rough prototype, you test it and the realities, the prototype and test aspect of this and even the ideation piece of it is almost a loop. You are going to test your theories with your prototype, see if any of those really do work. If not, you're going to go back to the drawing board. You might go back to adjust the prototypes based on some of the ideas you already had. You may have run out of good ideas, so you need to go back and think about new things, new ways that you can help with the pains that your end users have and then build new prototypes based on that so you can test those.

• 06:35 Joshua

  And that's basically it. You quickly iterate and build upon that, and we've talked about this on the show before, incremental iteration, slowly building upon the knowledge that you've gained during your ideation, prototyping and testing process to get to a stage where what you are prototyping, at least in the limited set of testing you can do at this stage does solve a problem or it does relieve a pain or does allow for somebody to do something they couldn't do before or to do it in a way they couldn't do it before.

• 07:05 Joshua

  And once you get yourself to that stage, you're then actually to a point where you could go build a minimum viable product. You have a good idea, you know that it's going to solve a problem that your end users have and you've done some testing with them and they've confirmed that, yes, I do have that problem and the solution you're proposing looks like it's going to solve that for me. This is great. You've also started that feedback loop early on and these are all things that we should have been doing all along and I know a lot of really good developers and designers who have been doing these things for decades, so this is absolutely nothing new. But having this design thinking thing out there means that people are starting to think about it more.

• 07:46 Joshua

  Now. It's the same as anything else. I love agile but I hate agile is a thing because once it becomes a thing then there are all kinds of processes and people start to build things around it and there's right ways and wrong ways to do it.

• 07:58 Joshua

  I don't buy into any of that. I think there are right ways and wrong ways for each individual, for each team, for each project, potentially. And finding one that is a good fit and a good match for you is a very personal thing. It's personal to you and personal to the team that you're working with.

• 08:15 Joshua

  Which is why I can see some designers and developers who dislike design thinking. I can see their point, but at the same time it gets it on the table. We're talking about it. And that is really, really critical because if we're not talking about it, it's not happening. And we all know that good design doesn't happen by accident. It has to be planned. We have to talk about it, we have to discuss, we have to share. And if we're not doing that, we're not improving, we're not growing.

• 08:39 Joshua

  So the fact that it's out there and we are talking about it, I think that's great.

• 08:42 Joshua

  That's all for today. I'll put some transcripts up at gettingappsdone.com. Please be sure to check out my website at joshuagraham.info and checkout Kellen's website, even though he's not here again this week at piffner.com. We're also posting some YouTube Videos and I'll be following up this episode with a series of videos on empathy, defining ideation, prototyping, and testing the design thinking process on YouTube shortly. So please check out those videos we're working on. In the meantime, if you've got any thoughts on design thinking or any questions, please let me know. I'd love to hear them until next time. Thanks for listening.