00:13 SYDNEY JOHNSON, HOST:
Welcome back to Responsible Disruption and our Design 101 series, where we unravel the intricacies of the design process. I'm Sydney Johnson, your host, and today we're venturing into the develop phase with the talented UX designer from J5, Julie.
Trained at the University of Alberta as an industrial designer, Julie often found herself inspired by the search for the root problems behind the need for design. Naturally, this put her on a path toward service design and UX design. Julie is known among her colleagues as a true complexity buster, motivating the team to think beyond the given parameters.
Focusing on process and giving space for the emergence of whichever intervention is most appropriate for the context, Julie, with a keen interest in both the sciences and the arts, found design to be a natural fit. She uses it to create meaningful change in her work with the government of Alberta. Julie, it's a pleasure to have you on today.
01:06 JULIE KUHN, GUEST:
Thanks for having me. I'm excited to be here.
01:09 SYDNEY: Awesome. So listeners, as we get ready to delve into what the develop phase is and strategies with Julie, we want to acknowledge that we have a couple of extra fluffy guests on the podcast today. You might hear some barks in the background from the dogs that are in my space and Julie's. So just an extra hello from our furry friends.
01:32 JULIE: Yes, they have strong opinions about design.
01:35 SYDNEY: Yes, as they should, absolutely. So Julie, just starting off really. Basically, I'd love to hear about your approach to design in general. What does the design process mean to you and what does being a designer mean to you?
01:51 JULIE: Yeah, I think for me, my approach to the design process, in general, is taking a very investigative, critical approach to current processes. Often, when we're tasked with taking on a design project, one of the first things we need to do is ask questions and not come in with assumptions. That’s where it becomes very investigative for me—starting by asking lots of questions. That’s where the double diamond aligns as a framework because it's very generative. You're trying to expand your understanding of something.
Once you've started to ask questions, have conversations, and get answers, you begin to figure out which answers have patterns, which answers are coming up a lot, and which answers have significant pain points or present new opportunities that maybe we didn’t see when we started. That’s when you move into the convergent phase, where you start to define things. Then there's another divergent phase where you're developing, which brings us to what we're talking about today.
You're starting to ask questions again. It’s this constant undulation of asking questions, getting answers, recalibrating, and repeating. It never really ends. My approach to the design process is that there’s never a true end. There might be an end to a project, but the work itself never ends because the world is always changing, people are always changing, and there’s always more to do and improve. Coming into a project with the mindset that we’re here to ask questions and figure out the best answers forward is my general approach to design.
04:13 SYDNEY: Yeah, that's really elegant. I definitely relate to that. I think that the double diamond is sometimes a misnomer because I think it should be like the triple diamond or the quadruple diamond or, you know, the diamonds.
04:23 JULIE: Yeah, coming diamonds and diamonds.
04:24 SYDNEY: That never stopped. Yeah, exactly. Diamonds are forever. So talking about that development phase though, maybe just again back to basics, what happens in the development phase of the double die?
04:38 JULIE: Yeah, I personally see the development phase as a spot where you're asking questions again. You're diverging in your understanding. Maybe you've gotten your project to a point where you think you have an idea of the problem you're trying to solve, and you’ve developed some sort of North Star guiding where you want to go. But now there's an opportunity to figure out: What are all the different options for how we could approach that opportunity or address these pain points? Because there's no one-size-fits-all solution. There are many ways to address pain points and explore opportunities. Ultimately, I think the develop phase is about asking more questions with more context, now that we've developed a North Star or a problem we aim to address. Actually, I don't like saying we're going to "solve" the problem because I don’t think we ever really solve anything. We introduce things that help, but the word "solution" feels like a bit of a misnomer in design, as it implies finality.
Whatever intervention we’re planning to introduce, there are lots of combinations and permutations it can take. The develop phase is all about exploring those combinations, testing them, and putting them in front of people. You can present different options—say, option A and option B—and ask people which one was easier, which felt better, or which seemed to address their needs more effectively. It's a lot of testing and trying things out within the scope you had previously defined. Then, you go back to that scope and ask: Do we need to recalibrate? Do we need to adjust what we had defined, based on new discoveries? Like we talked about earlier, design isn't a linear process. We’re always going back to definition and discovery. I think the develop phase is a form of discovery—it's just a different structure or mindset compared to the initial discovery phase.
07:20 SYDNEY: Yeah, and I like what you said about it not being about coming up with the solution. It's about thinking of the different combinations and permutations that could help tackle a problem because the problems we work on are so complex. There’s never going to be one perfect solution, and you're not trying to find the answer—you're trying to find an intervention that might help.
07:56 JULIE: Mm-hmm. Exactly. Yeah. Great summary.
08:03 SYDNEY: If I if I can. What excites you about that part of the process like what do you like about it?
08:11 JULIE: Yeah, I think for me, something I was trying to think about is what is different about the develop phase than maybe some of the other phases, and the different things that maybe excite me about the discovery phase, the define phase, etc. And I think what's unique about the develop phase for me is that it's a phase where things really start to click. Like you're starting to test what you have defined, and there are moments where you learn there's this new connection that you didn't know about, and that can really build momentum around developing your ideas and refining them. In the discovery phase, you're more just kind of asking these bigger questions and trying to narrow in. In the define phase, I think clicking happens, but the develop phase is where you test: Did we click it right? Did we make the right call in how we defined this? And so I find the develop phase is where you're starting to get more of that validation, like, yes, we are headed in the right direction. And I think that's kind of the thing that excites me the most.
09:25 SYDNEY: Yeah. And I like what you alluded to there too, which is coming out of the define phase, it's very normal to not have gotten it exactly right and to start to take something forward that you think is the right problem, and then actually have to go back and check again, and maybe rework some of that or go back to some discovery or what have you. Do you have any stories from a project or lessons learned about the development phase that you can share?
09:57 JULIE: With the context of the projects I'm working on right now, which is in the government of Alberta, working in the Ministry of Justice on some digital product transformation endeavors, I think the biggest thing I've learned about the development phase in working on those projects is that it's always happening, and it doesn't look like one thing—it's always changing. There are so many different ways to approach it, and this is where the lines between the double diamond become very blurry and less clear.
For example, I'm currently working on a project where we're hoping to improve the experience of defense counsel requesting appearances to schedule with the Court of Justice, and then on the flip side of that, we're also trying to help clerks who process these scheduling requests to make their lives easier in processing the requests. So there are two very different users who have different motivations, different needs, and we're trying to balance those as we develop and deliver a product.
In that, as we are developing this product, there are definitely different stages of fidelity that we need to work through. There's different fidelity in all forms. Sometimes it's the fidelity of the question you're asking. Sometimes it's the fidelity of whether we’re putting a sketch drawing in front of someone or a full-fledged high-fidelity clickable prototype. It's about understanding what the situation is calling for right now.
Because have we, like, developed the idea to a point where that makes sense? And yeah, with the project I'm working on right now, we're constantly in a development phase, I would say—or at least that's what my job feels like. We're constantly figuring out new ways to test. There are always so many ideas for different ways we can improve the scheduling process, and so we're constantly trying to put different things in front of the users to understand if that actually addresses what they need. As we put that in front of them, we start to understand that, oh, actually, we didn't quite understand that right. There's more nuance to this situation. As an example, the whole problem we're trying to solve in this project is making scheduling easier. You would think one of the first questions we would ask someone is, "What do you want to schedule?" That seems like a pretty basic answer because you could schedule many different things in the Court of Justice. You could schedule a trial, you can schedule a sentencing, you can schedule a bail hearing—the list goes on.
As we thought that that was maybe the first question we needed to ask defense counsel as they're filling out the scheduling form, the more we learned about it, the more we understood that actually the first question we need to ask someone is not, "What are you trying to schedule right now?" We can ask them different questions that lead them to that answer and help us figure out what they are actually eligible to schedule based on the answers they give us to other questions. For example, "What is your client going to plead?" If they're pleading guilty versus not guilty, they're going to have different scheduling options if their file is at a different place in its lifecycle. If it's very early on and you haven't had a bail hearing yet, then maybe that's your first option before you start getting to scheduling a trial.
And so there was a lot of context and nuance that needed to be understood and developed, for lack of a better term, in order to know that, hey, actually, we really shouldn't ask them, "What are you trying to schedule?" Because then that's going to lead to us having to manage a bunch of errors. If they say they're going to schedule a trial but then later say they're going to plead not guilty, well, you can't do that. Or—sorry, I misspoke—if you say you're going to schedule a trial and then you're going to plead guilty later, it's like, well, those things don't go together. You can't plead guilty and then go to trial. Figuring out things like that, in hindsight, makes so much more sense, but when you're navigating this new landscape of the criminal justice system, there are a lot of things that don't make sense when you're first diving in. That took some time to develop to get to the point where we realized, well, this is the first question we thought we needed to ask, but actually there are three or four questions we need to ask first, and then that gives us the answer for what defense counsel is eligible to schedule.
That’s also a better experience for defense counsel because, in the end, they’re being supported through the process of what they're able to schedule, rather than being asked a question when they don’t really know, maybe because they haven’t been asked other questions prior to support what their options could be for what they need to schedule. If that’s not too high-level.
15:32 SYDNEY: Yeah. Well, I think it's a complex example, but it's a good one to show that, you know, you can get far along in the design process where you really understand a problem, and it doesn't mean that you yet understand how your solution, or your proposed solution—again, for lack of a better word, intervention—is going to fit. Like what you said before: you still need to do discovery, even though you're in the develop phase, to figure out if those ideas that are coming up are going to be valuable or not. I also liked what you said because I was going to bring it up if you didn't about the kind of blurred lines between this develop phase and maybe the deliver phase that comes next, because there’s prototyping that happens as part of that. So just again for our listeners, a lot of the activities in this phase and the next phase are ideation, which is just a fancy way of talking about coming up with ideas, and prototyping, which is a fancy way of saying making an idea tangible in a way that people can respond to it. There is prototyping that is expansive, where you're trying to learn about things. It becomes part of, again, discovering and continuing to develop, and then there’s prototyping that narrows you down to that deliver point. So I think it's a really interesting thing; basically, what I'm trying to say is we put these models on these processes, and they don't always fit, but they can be helpful to understand something so complex. Even just the example you gave is clearly a very complex problem—a complex thing with many different iterations—but we can kind of see some similarities.
17:20 JULIE: E Everything is always a tool. There's never—there are no hard and fast rules with anything in design, I find. You can have generalizations, I guess, of how these tools should maybe be used or frameworks, but there's always an exception to every rule and every tool, right? Pat that on a T-shirt.
17:44 SYDNEY: Yeah, yeah, yeah. That's a good one. So at the beginning, you know, coming out of the defined phase and going into the develop phase, you're at that point where you’re starting to figure out what are going to be the ideas that we, as a team, are going to come up with, or what our users are going to come up with. How do you approach ideation? What does that look like in your practice?
18:11 JULIE: Yeah, I find for ideation, trying to have, I guess, a balance between divergent and convergent ideation sessions with the team, where we're really trying to be generative in figuring out all the different ways we can approach this defined problem that we're coming out of this defined phase with. A lot of that can look like different workshops you hold, even internally with your team or externally with people who are going to be using the product, and kind of marrying the different insights you get based on the people you're working with closely in your team who maybe have this whole overarching systems perspective. That's something you're trying to build when you're working, at least in the context of the product I work on: we're trying to understand the system, whereas sometimes users don't always have the context of the whole system. So by gathering different ways and different people, you can ideate. It’s just going to kind of round out what your options are, which is a great strategy to use in ideation. It’s really about diversifying your approach and how you engage. I think it's all about what type of ideation you're ready for, I guess, if you're coming just out of the defined phase.
19:42 SYDNEY: Tell me more about that.
19:48 JULIE: You might think that that seems like a really great time to get very generative. Let’s explore all of the options versus if you have explored a few options and now you're having to make refinements. Maybe it's like, okay, we think these are our top three options based on talking to some more users and engaging different stakeholders that have influence in your project. So maybe they have decision-making power or they have the ability to change things about their process to help users' experience. Or also, again, within your own team and combining all of those different brain forces—your users, your team that you're working with, and then your stakeholders who might have leverage or influence on your project in some way—that will give you a very diverse output of ideation options. Again, I guess I feel like a bit of a parrot, but that'll undulate. You'll kind of go through rounds of that again and again from being very generative in how you need to think of a solution or intervention, and then starting to converge. It’s almost like that convergence can also be iterative, or you can take an ideation approach to how you're going to converge, because that takes creativity to figure out how we’re going to narrow all of these decisions down into something that we actually think is usable and can actually be delivered and is realistic. Because often, when you're being generative, you really want to take away any of the bounds of being realistic, because the craziest ideas always have a nugget of truth in them. So now you're just trying to figure out what that nugget of truth is in all of these ideas we've had, and is there something that we can actually do about that to deliver that idea?
21:38 SYDNEY: Yeah, whenever I'm in an ideation session or leading people through ideation, I always say it's way easier to pull an idea back than it is to make it bigger later on. So think of the biggest, craziest possible idea, and then it can always be reduced. But you'd much rather be in that situation than the reverse.
22:14 JULIE: Yeah, and it is challenging. I find it's a muscle that you kind of have to exercise—your ideation muscle—getting comfortable with thinking generatively. A lot of people haven't been encouraged to do that in their own jobs and roles, and so I find it's something you also need to come back to a lot. You can't expect to run an ideation workshop and hope to get everything you want out of it. It's often something you need to come back to. Maybe your first ideation session is a way to break the ice and plant a seed with some people about thinking about things differently and encouraging them to challenge what their current processes are or how they could see their work being different or a service being different or whatever the case, whatever we're working on and trying to refine. But that doesn't come easily to everyone. So building in space, if you can, in time to build a relationship with ideation is almost important—building a relationship with the design process because we can't just expect to come in and have everyone be at a place where they're comfortable thinking about their work in that way or being comfortable with challenging their work.
23:41 SYDNEY: Or even just—you can have the intention to know, like, “OK, I know I'm not supposed to shut down an idea yet. I know that this is the time when I'm supposed to be thinking a little wilder and not worrying about the realities of putting an idea into place.” You can know that intellectually, and it could still be really hard to do if you're not used to doing that. Or again, like—that's not your job; your job is to think of all the things that could go wrong.
24:08 JULIE: Exactly.
24:09 SYDNEY: You have to practice.
24:10 JULIE: Yes. Yeah, exactly. Yeah. You need lots of practice time, and you get better with time for sure. I've seen it happen, like, even in our own projects that we're working on right now. But the people we've engaged with, like, over time, those relationships have just been built to be so much stronger, and now people do come to the table very generatively and are very able to, like, not start to think of what's wrong about an idea before they've even said it. Like, yeah, which is really great to see; that progress can be made. You just gotta put in the practice.
24:46 SYDNEY: Yeah, 100%. Yeah, and know where you're trying to head, for sure. So you work on a lot of digital projects, of course, in your role as a UX designer and, of course, with the government of Alberta. What is the importance of collaborating with, you know, your team, you as the UX designer, the service designer on your project, and the development teams during this phase of the work?
25:14 JULIE: Yeah, that is super important. Collaboration is always important as much.
25:20 SYDNEY: Collaboration is key.
25:21 JULIE: Yeah, collaboration is key. Anytime anyone who's involved in delivering something should also be involved in being affected by whatever is delivered, they should be a part of the process in some way, shape, or form and should be consulted. So that includes the development team. I work on a six-person team where we have a product owner, a service designer, a UX designer, two full-stack developers, and a digital architect. So it's about half of our team is what we've referred to as the technical side of the team, which would be the developers and the digital architect, and then the design side of the team, which would be the service designer and the UX designer, and then kind of the business side of the team, which would be the product owner. That's an overgeneralization, of course, but those are kind of the general fields at play where we're trying to figure out how do we all best collaborate and play in the same sandbox together. And I find, at least in my own experience working particularly with a development team referring to more of the technical side, that building relationships with your developers and your digital architect is super important. Making sure you have trust and communicating the importance of the design process is key, so they can see the value in what they're developing and building. Including them in user discussions is essential, as it allows them to hear directly from users about their own experiences rather than having it filtered through someone else. This is always an important part in order for them to see the significance of what they're developing. So I find that building those relationships and collaborating effectively in our teams at the Government of Alberta requires a lot of time and effort.
Making sure you're connecting often is also key, so not letting too much time go between, I don't know, them working on something and you seeing where it's at in the process. Kind of like we were just talking about with the ideation phase, different people are comfortable showing different fidelities of their own work, and sometimes some developers are really comfortable showing you something that's very much in development and very much a work in progress. Other people don't want to show it until they feel like it's done. So trying to break down or challenge those walls of, like, when is a good time to meet and check in on where you're at in your certain development phase, so that we can make sure we're keeping aligned as the work moves on and that they're not accidentally kind of verging off path. Then you don't find that out until after a couple of weeks of them developing something, and then you're like, oh, actually, we need to correct that. So that's still true too. Different people have different comforts in showing different levels of where their work is at. Creating more of a safe space to understand that things are a work in progress, I have to remind myself of that as well. Making sure I show work when I don't think it's ready to be shown and being comfortable with that. Just setting up people's expectations that, like, hey, this is a work in progress. But I just really love to get a sense check on, am I headed down the right path? Are there any glaring red flags you're seeing with what's going on here? Or is there anything you really like about the direction that this is going right now? And getting checks on that. That goes for the development team too, making sure that that's kind of following a similar process and relationship, and we're holding each other accountable to that.
29:19 SYDNEY: And it makes me think also of, you know, with your users when you're in that early, like maybe you're just starting to test the concept with some folks. Those kinds of early stages of the develop phase, do you ever find issues showing unfinished work to users? As in, like, having them see something that isn't completely polished?
29:43 JULIE: Yeah, there's sometimes where, like you show someone something and they become like, whoa, like I don't like that.
29:54 SYDNEY: Why is that red?
29:57 JULIE: And sometimes it's really good to. I think this is a challenge I just always have as a designer, like you're alluding to: when is that right time to share something, and how do you know it's the right time? And that's always changing. There's, again, not a general rule to this or an absolute answer, but I like to think like I like to balance between like we don't want to be haphazard, and we don't want to—like we want to be intentional. I guess it's kind of where it lands, and like we want to be intentional about the things we show; we want to respect people's time. So making sure that we're not just showing anything all the time—like you can swing too much to the chaotic side where something definitely just isn't ready to be shown, and because it hasn't really been considered or hasn't had thought put into it yet. But then we also don't want to swing all the way to the other side, where we're working on an idea and getting stuck on details, but like aren't as critical. And maybe we actually need to sense check the direction of this before we're sense checking the details of it or in that way. So trying to find the balance of like I want—I always want to be intentional about what I'm sharing and why. And usually, a way to do that is to develop a goal around what is the goal of what we want to learn from talking to people, so that we can also have something to test against, like did we achieve that goal? It's also okay for that goal to change because maybe you'll find that, like, as you had this conversation, it veered off into a different discovery of something you didn't even know was relevant to the project, but I think that's a good way to kind of ground how you engage with users and when to know it's right or maybe not right. But when to know, like you're ready, I guess.
32:04 SYDNEY: Right.
32:07 JULIE: But I also, I guess, to contradict myself a bit, it's also good to push yourself out of your comfort zone a little bit. It will never feel ready, but it can feel intentional. So figuring out, like,
32:25 SYDNEY: That's a perfect quote. It's never going to be ready, but it can feel intentional. Yeah, exactly. How do you decide what ideas to move forward with, or what things you're going to show, or what you're going to start to build out to put in front of a user? Or even when you have that collection of crazy wild ideas, how do you narrow it down to which one you're going to go for or which three you're going to try?
32:55 JULIE: That is a great question, and context is definitely very important in how we nail it down. But I think, as a general or best practice, there are many ways you can slice and dice how you want to assess an idea or feature. I find a value versus effort matrix is a good way to decide if this is something we think we can do based on the timelines we have.
Value can be defined as how many people would positively benefit from something like this frequently. Would this feature be interacted with or used? What pain point or opportunity does this address, and how big is that? Is there desirability for something like this? The feature score, or value score, can help you start to decide that. For example, if everyone that comes into the service is going to touch this feature, that already gives it a high value score. If this addresses a pain point that we've heard from every single person we've talked to, that's a really high value score. So it's almost like you can start to quantify it while still being sensitive to the qualitative aspects because you can never really put hard numbers to a lot of these things. Nuance is important. On the flip side, you're testing your value against the effort that something like this might take. How many remaining unknowns are there about this feature? Do you need to put more time into understanding the dependencies around delivering something like this? How much design time will be needed to build the design around this feature? How much development time will be needed to actually code that feature? As you map that onto a matrix, you can see where things fall, identifying those with very high value.
But it's also very high effort. Is that worth it compared to another thing that's almost just as valuable but can be done in three months rather than six? You're really trying to assess making things visual, which always helps. That's why having a matrix to post your features and ideas can make it visually easy to see what's the highest-ranking thing versus the lowest. If we think something might be of less value and requires high effort, do we want to invest any time into pursuing it if we don't think it will provide much value? So I think that's a good way to assess when you have a lot of different ideas coming in, especially if some might contradict. You can start to put it against that framework of value versus effort to figure out what exactly is achievable in the given time and what will have the biggest impact.
36:23 SYDNEY: Yeah, if it's, if it's low impact and it's going to take us forever, it's probably not the right thing to move forward with.
36:28 JULIE: Exactly. Yeah, it's very easy to see that when you've mapped it out, but it’s also very easy to get stuck in circles of conversation if you haven’t put that on a matrix that everyone can look at and align on. Again, it’s just another tool you can use to facilitate these conversations. All of the stickies on that matrix are movable; as you discuss, the value can go up and down, or the effort can change because, for example, someone might have an idea for a really easy way to implement something that we weren't seeing the first time we looked at it. Everything is always a working document in a lot of our work.
37:23 SYDNEY: Well, I was just going to say I feel like something I would imagine listeners might be taking from this episode, which is very true, is that there's a lot of complexity. There's a lot of nuance. There's a lot of ambiguity that happens in the design process, and this is a lot of time where the rubber meets the road around that ambiguity. I wonder, Julie, if you would leave the listeners with kind of a thought or maybe a piece of advice around this phase, what might it be?
37:52 JULIE: I would encourage people who are in the development phase to really lean into the mystery of it. Because you've just come out of a defined phase—at least likely—you have. I encourage people to approach the development phase as another discovery. In some ways, there's a lot that can still be uncovered as you're developing an idea. So I think just leaning into knowing that this is going to be another investigation is important. Try not to think that you have it figured out because you've defined something already. Instead, come into it with the mindset that you're going to learn new things and make new connections as you develop an idea, and be open to recalibrating your original definition of where you started.
38:54 SYDNEY: Yeah, that's wise words to end on. That's the end of our time here today. I really want to thank you, Julie, for sharing your valuable insights with us.
39:04 JULIE: No, thanks so much. This has been great.
39:07 SYDNEY: Listeners, thank you for tuning into this episode and make sure you catch our next episode of the Design 101 series, which will take us to the final section of the Double Diamond, the deliver phase. Until then, keep exploring and innovating.
[Outro music]
That's all for today's episode of Responsible Disruption. Thank you for tuning in and we hope you found the conversation valuable. If you did, don't forget to follow, rate, and share wherever you get your podcasts. To stay up to date on future episodes and show notes, visit our website at thesocialimpactlab.com. Or follow us on social media and until next time, keep on designing a better world.
