So in this segment we'll continue our discussion of identifying user needs will pick up with where we were in the last segment and give you some more discussions. But the first point I wanted to appreciate and we'll have a quick video clip of Doctor Sarkar here, is this distinction between the voice of the engineer and the voice of the customer. And what matters is the customer's needs, the user's needs. So we have to keep that in mind throughout and understanding our users needs, it's a fundamental problem. So let's listen to Dr Sarkar. >> It's important to understand that for the software, it's the voice of the customer that's important and not the voice of the engineers [LAUGH]. Which is what often happens if you don't completely understand sort of your user needs, right? And actually unfortunately there is no real substitute to interacting with your customers directly. I mean, if you can and if you have the opportunity as a software developer to do that, please go ahead and do that. And try to understand directly from your customer what their needs are, what they're paying points are, the more varied you can sort of get your customer base. Take for example, suppose you're targeting like a medical practice, perhaps going to the academic medical practice as well as the community medical practice. Try to get a good sampling like a sort of a distribution of your users, understand what they main points are. And they're going to be different, they're going to be different in different settings. >> So the process here often starts with meeting new users and the process will start inevitably with an initial meeting. So maybe those icons there, whether you see that on the table or whether this zoom call or some kind of teleconference or a combination. Perhaps those are the icons on the top left. So all these projects start with initial meeting and it's critical in the beginning to establish a good working relationship. The usual rule supply of making a good impression beyond time, dress up properly for the environment. If you're not sure, ask what the dress code is. Be on time is actually kind of critical hospitals are mazes, so plan with their early, otherwise you'll be late. And if you meet a lot of people in the room, try to figure out who's in the room, their background and their interest in the project. I don't want to, there's no way to emphasize that enough. You think that your customer is in session, but it may be that the person will ultimately make the decision as to where they work with you or not is a person one step down, the nurse, the resident. Because those people often have more time to spend with you and treat them well and they'll be helpful to you. And those are important people, don't just think of the senior people only as your customers, everybody in that room is as important as you work through this. The second piece of advice and this is going to be unfortunately, it's the nature of the topic, a collection of advice, but try to make it as interesting as possible. Do not rush to conclusions. To everybody with a hammer, everything looks like a nail, to everybody who's the database programmer, everything as the database program. Try to avoid that. Keep your eyes open, and remember there are two kinds of things that you don't know going into a situation. That was called the known unknowns, things that you know that you don't know, and what's called the unknown unknowns. There are things that you don't know that you don't know that you don't know. This may sound silly, but that's a critical problem. If you don't know that there's something you don't know, how are you going to find out? So the known unknowns are often easy, you know you don't know them, so you ask. The known unknowns are hard and you have to sort of fish for them. Is there anything else I should know? So you ask questions, is there anything else I should want to know? Would you like to add anything? Is there anything obvious that people new to this area do not understand? What are the common mistakes that people make when they start here? What are students confused by to give you an example that will return too many times in radiology work sessions? The images are shown left to right flip. So the left on the brain on your screen, shows the right part of the brain and vice versa. Either you know that or you don't. So you walk into a practice, you listen to radiology, they will never mention it. They assume that everybody knows this, but you don't. You resign your software's the images have shown the right way around, left on the left, right on the right, you'll cause a lot of trouble in radiology, things like that are important. And you keep not rushing to conclusions. So you must listen, really listen hard and make sure you understand. You want to ask more questions than to pretend that you understand what's going on and pay the price. Later I observed that when I go with students to meet their clinical matters from my classes as project and they also they're very quietly and then they go back in there confused. This is your chance ask questions. And often what helps us to try to restate the problem in your own words. Not just listen, but say, okay, let me try to somewhere else in my words, what I think your problem is. In the process of your stating the problem, they will understand whether you really understand what the problem is or whether you're confused and this exercise helps. And this is actually in some ways the basis for a lot of these documents by writing a detailed specification and sharing it with your user part of it is for them to verify that you understand what their needs are. And the only way that they will ever be able to do that is if you express it clearly and often in writing as well. The other thing I would like you to keep in mind is that the problem is not always what it appears to be. So you want to really try to understand what the problem is and what it is not. So sometimes what the clinicians feel the problem is is not the actual problem. Sometimes it's just a concept of some secondary issue that is easy to resolve. I wish I could show this image on top of this image. Maybe that's a trivial problem, it's just as a technical limitation of the system. Sometimes the problem is more fundamental and it's hard to solve. And you have to move and this is where the picture on the top left comes in of the brown car model, you would like to move your users in the discussion from how now to what now. You want to move them from I use a shovel, so I need to keep my driveway clean. I use a shovel is the how, I need to keep my driveway clean is the what. And this is their real objective, okay? So try to move them out of the details because that's where the new solution is going to come from ideally. You would like to understand the context of the problem. Why is the problem presented as significant? How many people are affected? How serious is the problem? Why are the current solutions not working? What has been tried before to address this and why is it not working? Is the problem really quality affordability or user skill? So, when you come up with any solution to any of these problems, we have a problem. What is the problem? Deep down. Our current solutions are not good enough. If that's the case then the problem is quality. You need to design something that performs better. Maybe the problem is affordability, you have perfectly good solutions, you're just way too expensive. So we need to simplify that solution in some way. Maybe it's cheaper hardware, whatever it is. Or is the problem that we have a perfect solution for an expert but a less guilt user cannot use as a solution. So depending on what the driver is, you may end up going very different directions. So ask yourself is a problem quality, affordability or is it we need high skilled users and we need to simplify in some ways? You need to identify the lay of the land. So what comes before this and what comes after this process or after what we do? If we're writing software to guide prostate biopsy, what comes before is the radiology images and the specifications of the lesions. What comes after is that the report of the biopsy goes to port, which will then discuss what the next step in the process is. This patient needs radiotherapy to the knee surgery to the knee surveillance left alone for a year and come back for a new pipes. What happens the patient prior to this point? And what will happen after this, as we mentioned before? Where is the data coming from, if you're analyzing images, is that images coming from a database? Where are the results going to work for me? So where does my output need to go? Is there a custom database? Is there a standard database? Those are all critical pieces. And finally, what constraints does this impose on the problem? So all of these things may mean that we can only do things in a certain way. We need to be able to connect via internet to another system in the room because that's where our data comes from. We are operating in a situation where there is no internet connectivity. All of those things come into play and we usually understand the lay of the land. You have to mop out what comes before, what comes after, what comes in, what goes out and then you know what the outside constraints are on your system. Things to ask, Is this a time limited process? If it is, other things that we can do ahead of time, for example, in the case of the prostate biopsy, the whole process is 20 minutes. So your image analysis shouldn't take 15 minutes of those. Now much of the analysis, especially in here too with the MRI images that we should before can be done the night before. So organize the workflow that those things happen ahead of time. They're not happening in this critical time with a patient lying there. What are safety and private issues and other limitations of course of what computers can be used in what cannot? Many hospitals will not touch Mac computers, it's Windows only, ask about that. If that's the situation, if you develop your software on the Mac, you may find yourself stuck. Ask about regulatory and safety issues that may govern aspects of the problems, we're only allowed to do things a certain way. This is a vocabulary that's specified, your output should include this vocabulary. Ask about domain specific conventions. This is the left to right question in radiology, where the images are always shown left to right flip. You either know that or you don't. And you want to observe a procedure or two or 20 or 200 if possible. This is vital in enhancing your understanding of how now. There is no substitute to watching people work and not just one user, but multiple users at different levels because that's how you understand what's going on. Not what they tell you but what they're actually doing. Because what they tell you maybe the things they find hard, but you need to understand the rest of what they're doing because those maybe things that computers find hard and users find easy. So you need to understand how now fairly clearly. And there are a few traps to avoid here. As I mentioned before, do not let the clinician's idea of the solution necessarily bias the solution. They also don't know what they don't know, they start telling you well, we need to use this type of algorithm. That's why I say, okay, thank you, let me think about that. And the big issue, and this is where I have found myself falling into the trap many times, is the current way of doing things may not be due to technical incompetence. Medicine sometimes feels that's in the Stone Age technologically and we think, ok, well, these people are not particularly bright, that's why they're doing this. But there may be good reasons for some of the current practices and try to identify what is critical and what is accidental. The current methods, for example, may be constrained by legal or regulatory issues and it has to be done this way because it has to be done this way. And there may be a better way, but you have to change the laws first, and if you can't change the laws, you start doing it the way they are doing it. And finally is a list of sort of additional considerations as we conclude this section. Most of your needs may stem from how doctors and nurses interact with software in a particular application. But there are stakeholders however, who are outside of that list. So for example, hospital managers in this may require particular integration specifically EHR products. Information technology requires specific cyber security features. Distributors may need ease of installation or cloud based upgrades or all kinds of things like that. So the take home lesson if you remember nothing else from the slide is that the user may not always be a user. So when we think about software we think, okay, the user is a person who touches the software. The reality here is expand your notion of a user to that of a stakeholder. Your user maybe somebody who just gets the output of your software for them and they're going to do their work. That is also user, their needs need to be reflected. Your user maybe IT because your software needs to connect in a specific way to a specific thing. They're not really a user, they will never touch your software, but they're users, their needs need to be met. So the user is not always a user, that's a point that you need to keep in mind as you identify use on it. This concludes such sort of overview of user needs. In the next segment, we'll get a little bit more concrete. We will discuss the user's needs situation or how we identify them for the image garden neurosurgery project. Thank you
