 Hello, everyone. OK, I'm trying to get comfortable first before I start. I'm excited to be here today because I was almost not going to make it. And I mean, visa issues, basically. I'm tempted to talk about that story, the opaque processes of visa application, lessons for civic tech. I've thought about it. It would have been very interesting. Well, I'm going to stick to my presentation. I am not so GDL for, as he introduced me. I have experience using design research and user center design for transparency and accountability programs and projects. And I work at the engine room. At the engine room, we help our partners make the most of data and technology. So today, I'm just going to be talking about how we did that in serial alone. So it's a two-part presentation, basically. In the first part, I'm going to talk to you about how we scope the role of tech in our project. And then the second part is how walking with technology impacts you as an implementer. It's more of a personal reflection. Don't worry, it's not going to get rigorous. OK, a bit of context. Because I'm short on time, I'm not going to dive into deep. But in serial alone, there is high availability of water resources, but there is critically low access to portable water, at critical level. And there is a report on this link that gives you a lot more insight into that story. But this was the problem that we're trying to address. And the rest of this presentation is kind of how we went about it in trying to use technology to bridge this gap between high availability and low access. OK, so you can think of it as some sort of theory of change. You first encountered a problem, and then you need to get to a point where you find out how technology can help you address that problem. So it's a two-part situation, or it's a two-part story. So first you're doing some sort of situational analysis. And then from there on, you go on to making your imputes. But you need to first understand the situation. And what we did, even though we had a sense of what a problem was, was starting to first understand how the affected populations described the problem itself. So we knew that there was a gap between there was low access to water, potable water, but how do the people who are affected by it directly talk about it? And these are some of the examples that we found. The first test says that water availability is sparse, but also unpredictable. So it wasn't just that there was low access to water, sorry, not availability. It wasn't just that there was low access to potable water, but also it was unpredictable, right? Even if you, even if water, it would have been a better experience by the people who were affected if they knew that every Monday at 10 a.m. I could get water, right? And I can get like a liter of water. And I need to figure out what I do with that. But the situation is that you do not know when water is going to come, and you already know that water is like scarce, right? So the other thing too was that water was a very political, water is political basically in Sierra alone, right? Because the politicians kind of pushed that forward as a potential fix that it would bring if they are elected, and then the people who, the population also think of it as a point of demand. It's something that it can act of the government, or people who are like, who have like high political interest, so they tend to act for it. There was also just like difficulty connecting quality to what you pay, right? You think by default because I get to pay for water, it should be clean water, but it wasn't a given. And then there was like the disconnect between the service delivery guys and the affected population. So these are like key examples of how the people in the context were describing the problem, different from how we understood it. And this was kind of critical for us to get to before we started talking about how to include technology. The next thing that we did was to figure out, given those problems, how is the affected population trying to address it, right? So they already had their own ways of like dealing with these issues. They were in like sitting and folding their arms. So specific to the one around availability and low access, sorry, low access as well as unpredictability. They had things like having the phone number of like the tap manager, or like people like setting alarm clocks to be able to wake up at 2 a.m. and check like if the water, you know, was running and stuffs like that. I'm not going to go through the rest. But these were like two first critical steps that we took before we got to the third question, which is what incremental improvement can be made to tackle the problem, right? We weren't going to try and address the problem starting too far from how the people in the context were already trying to address it. That was kind of one decision that we made. The second decision was also thinking about our resource, right? And sometimes when you think about resource, it's not only things like financial, but it's also like the technological capabilities of maybe your team and the affected population, right? So those were like resource considerations that we made in trying to get to what tech could do. And it was only then that we started asking the specific technology question, so what tech solution should we implement in this scenario? Yeah, I mean, this is kind of embedded in our design research process. And it took me just like trying to think about what we went through to like pull this out. So I'm happy to like get reactions to the start process. All right, so I think there's a specific thing that we made sure when we said it, what we got to say in OK, what can tech do? We're also thinking that we should make sure it doesn't distort the meaning of the problem to the affected population, so that at the point where you start introducing technology, you will first not introduce any new kind of problem. You need to make sure of that. And also we also wanted to think about what was going to be the cost of introducing technology at this point in time. So sometimes we dream of this tech outcome, but yeah, maybe this is something we just get, right? Tables and chairs are also technology at some point in human history. All right, so the second part of this presentation is about the impact of technology, and specifically on implementers. So I imagine that this room is filled with very smart implementers of civic tech or technology in general. So OK, in getting into the impact of tech, there's some sort of backstory to it. Before we partnered with Code for Sierra Leone, who is a partner we were working with on this project, they had already taken on this problem. They had made efforts to address this problem, and they had gone about it with one specific approach. They did a hackathon, right? And this impact story is my personal reflection on the trade-offs in the first approach that I was seeking to address in this problem and the second approach, like a hackathon and a design research process. And it's good for you to note that this isn't a comparison, yeah, it isn't a comparison, but it's more of like the trade-offs, because they are two very different things, right? It's like apples and oranges. I think because we do not compare apples and oranges, doesn't mean we cannot talk about both of them at the same time, right? OK. So if the process above kind of depicts how you get to tech development, you would see that design research is a very limited part of that process, right? You would do, and it's something that's going to consume your time a lot. It's like painstaking time invested in trying to get to design research, and it only gets you through one part of the process to involve in technology and your project. But the hackathon is more of a compressed process of the first three stages of this entire process. It kind of brings it all together and very quickly. And there's a potential also that with the hackathon, you might have included some amount of research before you went into other stages like the design and development steps in the hackathon. But there are chances that it may not have been design research. Maybe other kinds of research is how you got to that. But yeah, this kind of overlap may be good for you to have a sense of. The other thing I want to talk about in the reflections were the trade-offs, right? So the experience was one in such that it felt like if you were going for deeper evidence, then you would be confronted with less time, right? In a hackathon situation, you might not have the time to generate as much deep evidence as you need. But also, if you turned to design research, there might be so little time for you to do it in a very rigorous way that helps inform your project. So these were some of the trade-offs. The second trade-off there is one of these approaches kind of helped us achieve greater functionality. So there were a lot more things we could do with technology through the hackathon process. But with the design research, it seemed like we were moving to the other end of the spectrum, where it was more usability. This is kind of a cool one for me. It did feel like one of these approaches kind of helps you get stakeholders buying because of the kind of outcomes or the things you kind of create out of it. So the hackathon process can very quickly get you a lot of stakeholders to get bought into your process. It is something that is easy to pitch and people can quickly get carried along on it. But if you move to the other end of this my imaginary spectrum, where there is design research, you probably will be achieving more of a stakeholder's co-creation. And that's a very tough thing to do. I mean, co-creation is like some sort of developing alongside with everyone, being able to pull them along. It's not that easy a process. Yeah. OK. So the hackathon was also good for stimulating the ecosystem because you could bring together multiple types of actors who are thinking about the same problem. In all cases, they were not all technologists. So they were just people who are interested in policy, people who are researchers, academics, or who have experienced this problem and have ideas on how it can be resolved. So the hackathon puts you in a situation where you are stimulating the ecosystem very quickly because you bring all these actors together, they get an opportunity to interact. But with the design research process, you're more just focusing on studying the ecosystem. And there might not be a lot of stimulation like done to that ecosystem. The last piece of reflection from having done these two approaches is what I kind of refer to as the implementer's journey. Let me take a break. So if this graph kind of represents how complexity changes over time, the liner on it will be you moving from a very undiagnosed problem towards making an impact. So undiagnosing the sense that you don't understand a problem. And then as your understanding of a problem increases and your ability to address it, you start moving down towards impact. And then this is the time access for you. And if you think of the beginning of the line as where you kind of insert your research, and in my case, design research, it's like, and it doesn't start at the tip of the axis because there might have been some initial understanding of the situation, but you're not so clear. And you begin to execute your design research process. And you gradually descend in complexity. And you get to a point where you can finally say, you know what? I can start building something. And you initiate your prototyping game. And that begins to happen. And finally, at some point, you feel like I have a good prototype. And you say, OK, let's start implementing the project. So we didn't just kick off right away, say we're implementing the specific project or the idea. But it kind of went through that part. And then finally, post the prototyping and implementation, you get to where you are now doing the tech design. Where it gets interesting with the wavy line, I didn't have a better way of describing that, is because sometimes you're clearly in the zone of impact. But you're not making impact yet. So sometimes you feel like you got it right. And you get user feedback, results. You do your M and E. I don't know how to do that very well. And then it drops again. You feel like, oh, I need to iterate. And you continue down that spiral till you get to some point in time where you are able to make impact. But it doesn't just happen immediately. All right. So here is my take on this. It is that when we think about technology in the way that we are naturally drawn to because of the prowess and the power of the solutions that we have, are able to create, we take the risk of undermining our critical thinking capabilities or our problem-solving skills. So we need to be careful about that. So where then should you begin to think about technology in your project? I can tell you when not to. But I might not be able to tell you when to, right? You should be able to use your personal discretion as to when to. But when not to, I strongly think it's when the problem is too complex or when the solution is too complex. Those are two times where you should not be thinking of involving technology. All right. Thank you very much. That's the end of my presentation.