 Hi everyone, and welcome to this session on user-oriented design and innovation, which is a part of the developer track, because it's partly related to development of apps, while also taking a bit of a broader perspective on these issues of design and innovation with the HIS2. My name is Magnus Lee, I'm working at the University of Oslo, where I lead this DHIS2 design lab project, and also doing research. So in this session, as I mentioned, we will take a bit of a broader perspective on design and innovation, and particularly oriented towards addressing the needs of end users. The reason for this being part of the development track and app development track is that apps and app development is an important part of this design issue, as it provides this arena where we actually can have the flexibility to design and innovate more new things that are not part of the generic features of the HIS2. So again, it's not just about apps, but also more about design approaches, the project structures, and the capacity that is needed in order to drive these kind of innovation processes. So just a few words about the design lab for those who did not attend the small session yesterday. This design lab project at the University of Oslo includes a group of master students, I think, from 15 to 20 students who are now, and also some researchers that are collaborating with the HIS2 practitioners on multiple levels, both here at the core team and also in implementation groups, HISP groups in different countries, to try to look at what are the current kind of innovation and design practices, specifically related to designing for end users, and how can we kind of strengthen these practices and try to make the HIS2 more usable and relevant to what is becoming increasingly diverse audience of users, both within health, but also now increasingly also in other contexts and multiple contexts within health. And we do this by working with practitioners in, for example, particular implementation projects. We have been working with HISP India, HISP Mosa Bik, and others to see how these implementation processes unfold, and then to test out and look at and explore the challenges of doing innovation in these contexts. So the structure of this session will be first to try to define some concepts and to make some kind of nuances with these concepts, for instance, what we mean by user-oriented design and innovation and what we mean by usable and relevant technologies. And then we will look a bit more concretely at some key challenges of doing this kind of design and innovation in the context of implementing the HIS2. And then finally discuss some plans we have in the design lab for the future, which also includes, hopefully, some collaboration with potentially some of you that are attending this track. So moving to this concept of user-oriented design and innovation, our aim in the lab with this is to, as mentioned, make the HIS2 more usable and relevant. We see that there are many different user groups and there are some user groups that have great value of the HIS2 in decision making, for example, getting data and presentations of data that supports work processes. Well, there are a lot of other user groups that could have more benefit of the HIS2 if we were to design and innovate more with these different groups. And I constantly refer to this term usable and relevant throughout this session. And with that, I basically mean that some of you know, this term usable and relevant throughout this session. And with that, I basically mean that something that is usable and relevant have user interfaces and functionality and features that are both perceived as easy to use and learn. So it has kind of usability. It's easy for users to use it. Of course, pending or relative to the task that it's being supported. Advanced tasks also needs kind of advanced systems, but not simple tasks should not be very difficult to do with a usable software. But also related to whether the system is perceived as providing value to the work of users. So these are very interrelated, but also a bit kind of separate aspects. One is about making something that is easy to use. And the other is about making something that really provides value to the work of the user. Meaning that it supports something in a better way than something, or it solves an issue, makes work easier or more efficient, these kind of things. And I think what is important when we talk about these concepts, because there is a kind of common misconception that design for user-oriented design is about finding the right colors of buttons. What is the right label for this and that menu or so on and so forth. But it's also a bit more kind of deeper. That's certainly a part of it. But it's also about what is kind of typically said as building the right thing. Something that is actually relevant in this context for the given set of users. And then building that thing right. Meaning, for example, making it easy to use and understand and learn. And I think it's just important to have that in mind. That it's not just about fancy user interfaces or user interfaces with the right colors and labels and texts, but also about what is actually a useful thing in this context when we are designing. So when we are implementing the HS2 and we want to support the work of some users, for example in hell, what kind of features would make this the right thing for them to provide value to their work. And just a bit about why this is relevant. There are some obvious benefits of investing in thinking about these aspects of designing with users and thinking about usability and relevance and so on. One is that typically systems that are easy to use and learn requires less user training. And also you might have a higher user acceptance. Maybe also less errors, for example, during data entry or during use, which again increases data quality and makes better decisions based on that data. But also, and maybe increasingly important with all these app resources and the possibility of developing radically new tools for the HS2, is that it also helps drive designing and evaluation processes of totally new kind of tools that support the work of different types of health workers or other, or workers in other domains. And of course also these local innovations. Let's say you're doing a design and innovation project in a specific implementation. We often see that things that are relevant in one context might also be relevant other places. So based on these local design processes, that also might feed into being generic innovations. For example, published on the DHS2 app hub, which Austin talked about yesterday. So one issue with DHS2 and also which it shares with a lot of other kind of generic software solutions is that what is the right thing for the users and the right thing or the right way to build it and so on and so forth, could typically vary across contexts. So something that is very usable and relevant in Uganda at certain contexts there might not be relevant in other place and so on and so forth. And this makes it very hard for the core team to design kind of one size fits all solution that works perfectly anywhere. So typically what is usable and relevant depends a lot on the practices and the way things are organized in the specific context where the system is going to be used. And this is very hard to then accommodate when you're designing for multiple contexts. Thus, doing these kind of user oriented design processes should also be an important aspect of the implementation of a DHS2. So when the software is taken into a concrete context, then it is important to work with the specific needs in that context. And again, apps is then one approach to kind of addressing very specific needs in this context. And because of this, in this design lab that we are running here, we have a very particular focus on the implementation level design as we call it, where some of our quick questions are how can DHS2 be customized and extended to meet very particular needs. So needs that are not met by the generic features or let's say user interfaces or functionality that is not ideal in that context, how can kind of that be responded to on the level of implementation without going through the whole kind of JIRA cycle and making all the changes in the kind of generic bundle of the DHS2. Then also what are appropriate design methods. So what kind of methods can be used to, for example, engage with users prototype and evaluate with users and so on and so forth. And then what kind of resources could be provided from the side of the core developers and from the design lab and from the generic level to better support this. And again, one very good example here are these app development resources both for web and Android, for instance makes it much more efficient and easy to develop apps and tools based on specific needs but then also what about for example methods and processes, implementation guidelines and so on. So these things are stuff that we are exploring in the design lab. So just to say a bit about what we mean about innovation and also kind of who we are designing for and how. And I think two key questions is what are we actually building when we are implementing the DHS2. And I will touch upon the difference between the concept of digitisation and digital innovation which are two related but different things. And who are we then building these things for. So who are these things that we're designing and developing relevant for. So this is just to kind of get on the same page on what we kind of mean by innovation and design and to try to create maybe some ideas and awareness around this. So there is an important difference between what we call digitisation and digital innovation. So digitisation that refers to actually making kind of a digital version of the analog system so taking something analog and making it into something digital. So some would call this putting electricity on paper. So for example taking a paper based system and then kind of making the exact same system but with a digital system. Then digital innovation, that is actually a bit of a more extensive thing where some have defined that combining digital technology in a new way and also potentially with physical non-digital components which enable some kind of social technical change and create new value to the adopters or the users. So this means that in contrast to digitisation where you're kind of building the same system in a digital format with digital innovation you're doing something new using these digital capabilities which results not only in that okay now something is not analog anymore, it's digital. It actually enables some kind of social technical change, changes in work practices, changes in how people work, the services that they can offer, these kind of things and thus then creating some kind of new value for these adopters of this technology for instance the end users. And if we look at implementations of a lot of software including the H2 in many countries, I think we can see a lot of traces of digitisation that things that have been on paper is transferred into a digital format but for at least some user groups it kind of stops there. So previously for instance data was entered on paper now it's entered on a digital surface desktop computer for example. So this is an example for that specific user. This is an example of a digitisation process. This gets a bit complicated because for the people that are using this data there you might have some kind of digital innovation for example, because they might use the data in different ways because it now comes in a digital format and can be used in other ways but for one user group this is the case. And a recurring thing that I experienced by being out and talking to users different places in the world for example with the H2 is that a lot of end users actually still prefer paper forms. So then this quote is from a user somewhere saying that I prefer the paper forms because it's easier to fill out, it's easier to carry around, easier to comment, it's more flexible in kind of any way and it doesn't require an electricity. So for this user moving to the digital world hasn't kind of provided any from their perspective and the additional value to their work specifically. It might have provided value to someone benefiting from the data outputs but for them this is clearly not kind of an advancement to move to a digital world through the digitisation. And I suspect at least when I talk to implementers around the world I think this is not kind of a surprising thing. This is something I experienced many places that users, especially data people that enter data without actually using that data much. Let's say I'm from a health facility somewhere doesn't always see the benefits of having just a copy of the paper form in a digital format typically just more cumbersome to enter data. So I will give a couple of examples of what at least hints of digital innovation if we were to kind of do more digital innovation looking things with this kind of example. So at the University of Oslo we have this course which the design lab is engaged in where we have students over 100 students actually working on building DHS2 apps as their kind of project work for the semester which also provides an environment where we test a lot of app development resources. And here we try to give a case where we try to see is there anything we can do with this data entry application so that it provides a bit of additional value compared to how it is currently that now it's kind of a copy of the paper form but otherwise it's kind of still the paper kind of wins because it's flexible. So we had some students making for example this application where you get an overview of deadlines and different types of forms and when they are due. So here we can for example see a specific clinic and then they can search their different data entry forms which is then data sets in DHS2 for those of you that know DHS2 well where they can see okay which forms are due soon which are overdue and expired and so on and so forth and then you can even get an overview of different health facilities and when and now how many forms have a different status so these red ones are something that is overdue actually so they need to look like they have a lot to do the user that is using this. So what is happening here is that it's not just a kind of digitization thing anymore it has some hints of digital innovation it's trying to you know add some additional value which was not possible in the analog paper based regime and I think the point is that there are a lot of examples of this out there when working with users and implementations we see a lot of these things that you know could be added to provide additional value to DHS2 and to the end users of course and which is it will be interesting if we were able to act more on these kind of things. En and another example which is a more extensive kind of digital innovation thing is a case where we supported health logistics management especially reporting consumptions from health facilities of medicines equipment and so on and so forth where they earlier had the bi-monthly kind of reporting regime so they reported every bi-month they think they have to bring up these paper books where they have registered different transactions and then they calculate it and then they send it through the DHS2 and then it's used for distributing medicines and planning and so on so the users there again they prefer the paper based regime or the hospital store workers because these paper forms were very flexible and so on and so forth and of course we experimented with what can we do to make it a more useful tool for them and then someone created this commodity dispenser system which kind of removes the need for all this bi-monthly reporting and rather introducing a dispensing system where the user every time they dispense commodities they register it here so then you eliminate that kind of replace the paper based system for that and then the reports are generated automatically based on the data that you enter kind of continuously through the system which again then reduces the reporting burden that you have to do every bi-month so that's also an example of trying to kind of think differently and building something which provides value also to the kind of data entry side of the DHS2 and again this is things that are powered by you know building in this case web-based applications for the DHS2 so you can quickly think in four weeks or something these students had built an app that were able to address some of these basic needs in this use case I just also wanted to highlight some of the kind of real innovations from out there I think also an excellent example of some kind of digital innovation where they are having new value so someone is this smart display app by his Buganda where they as they describe it so need that you know decision making users are sitting in a room and they are doing you know meetings where they are discussing and so and then they saw that okay maybe we could you know support this specific activity that they are doing by building an app that has this kind of slideshow of different graphs that they can kind of use as a discussion arena an excellent example I think of small but important digital innovation for DHS2 Yes, so that was a bit about digitisation where it's just digital innovation and again I think there is a lot of potential to move more of our design work also towards digital innovation and not just digitisation part of course there is always a lot of digital innovation going on and I think maybe the data output side has radically improved a lot of aspects related to decision making and so on and so forth but still there is a lot of potential in thinking you know beyond the digitisation of paper reporting for example then another very relevant question is who are we building for so for whom is the systems we are building relevant and I found this very interesting thing in the news a year ago or something where a UK start-up created and then I'm quoting here creates an uncomfortable toilet to increase workers productivity which is called standard toilet and you can see it here on the left hand side there is a toilet which is tilted slightly forward which makes it uncomfortable to sit on the toilet for a long time and the point is according to them then to limit the time that their workers are spending in the toilet because people are sitting on their phones and spending a lot of time in the toilet which also brings a semblance to a Norwegian innovation many years ago in the late 1700s which is called the fold-out mine toilet which was built on the same principle and the user of the toilet will get tired of sitting on it so they spend as little time as possible on the toilet an interesting question to ask here then is who is this relevant for because here there has obviously been a design process and kind of an innovation process trying to solve some kind of issue which obviously is relevant beneficial for someone but it is obviously not made thinking about the real end users as it says in the quote here the main benefit is for the employer not the employees and I think that's also relevant when building information systems and software for reporting who are we building and who are we involving in our design processes and who are we trying to make the system relevant for is it for example IT project managers are they the ones driving the process deciding on all the needs and what should the system be and for whom is it the health managers on the top level the health hierarchy is it clinicians like nurses and doctors if they are users of the system or is it the data entry clerks for example and I think at least one group of users that might be sometimes neglected in some of the projects I have been involved with at least is the data entry clerks with this data entry thing as a readily available example that is for some people and maybe also for let's say nurses that actually are occupied with talking to patients and working with them they also have to do this routine reporting and then if the data entry tools are not providing any value then it is a burden rather than the benefit to go to digital formats so the point being that there is a difference between digitisation making digital versions of paper processes and then trying to provide new and valuable capabilities for different users and there is of course a kind of question who are rebuilding something relevant for is it for top managers is it for clinicians and nurses is it for different people yes so that was just to establish some kind of concepts and maybe create some kind of thoughts around this now I will move a bit towards specific issues and challenges of doing user oriented design innovation during DHS2 implementation so as I mentioned in the DHS2 design lab we have been working a lot with implementation groups in concrete projects that could last couple of years or three years close to now and I thought I would share some kind of thoughts and issues that typically we have seen being faced in this by these practitioners so a question that we think a lot about is how do we strengthen this capacity for user oriented design innovation how can we promote more of building useful tools, apps and promoting customising DHS2 to suit and be usable and relevant to different types of end users and I think there is at least based on my experience three kind of dominant and important aspects in these processes which is both related to that software but then also to the practices of actually implementing DHS2 and the competence and awareness and user orientedness in the implementation practices itself and also whether the projects that the projects that the DHS2 is implemented through for example in collaboration with ministries of health or with different types of NGOs just the structure and the scope and the mandates of those projects actually allow or provide any fertile grounds for doing any digital innovation and design with and for end users so I thought I would say a bit about these three different aspects I think starting with design flexibility of DHS2 Let's say we were engaged in implementation projects we are implementing DHS2 within let's say NGO that has certain names and goals and then we are discovering what kind of other requirements and user needs in this specific case then DHS2 provides us with some kind of options on how to address these needs and typically the default mode would be to try to leverage the generic kind of core features of the DHS2 so using the kind of bundled apps and the generic functionality as much as possible to address these needs meaning for example that okay we can use the data app to do this and that and then we can use graphs in this and that way we can configure and set up programs and then if that falls short if there are requirements that are beyond what DHS2 generic features can couple now there is an increasing kind of buffet of third party apps, generic apps which are available in the app hub or you might find them on Github sometimes also which kind of increase the amount of features that can be supported out of the box which is great I think so I think again this you know feeding innovations from the local to the global increases the chance that we have actually generic features that could support different needs then there are also of course the possibility to build custom apps from scratch or maybe based on customizing some of the generic bundled third party apps where you actually don't have the flexibility to know design exactly maybe what is needed and you know come up with new features and so on or in the worst case if any of these are kind of not applicable to dismiss the requirement or renegotiate to redefine the requirement to make it fit with something that we have available generic or also maybe unfortunately from my perspective try to solve it through end user training so meaning that you kind of maybe see it as easier to instead of trying to address these requirement by building a custom app for example you rather try to train the users and make some manuals and training so that they can kind of learn to work with the flaws of the system or the things that are you know let's say terminology sort of way things are organized so that it's kind of still still works even though you haven't had the need to actually implement any changes and of course just to mention that this arrow also goes in the bit of another direction because of course when you are in the implementation context you typically also have in mind what is possible to do with DHS2 which then also actually you know shapes there is kind of a communication between of course on one hand the requirements and the needs and the you know the scopes and the aim that you initially set in the project define those requirements that you want to address but also these projects typically evolve over several years of course and then there might be told the new requirements coming up at one point and then again you will have to deal with you know how do you address them through generic means or through building custom apps and I won't go too much into detail on this because of the time limitations here but there are of course pros and cons with each kind of approach to addressing needs using generic features and third party apps is of course faster and easier than starting to develop custom apps and building things from scratch at least traditionally had been so on the other hand the design flexibility is limited you have to deal with what you kind of have the generic features and for the third party apps you also have maybe some uncertainties regarding the maintenance of that app if it's a third party app and it's not developed and maintained by the core team you don't know what this is going to be maintained in the future possibly then you have maintenance costs on your implementation on the later part for custom apps then you actually have the flexibility to design exactly at least partly exactly the right thing and the thing exactly right referring back to what we talked about earlier according to the specific user needs but of course then you have to develop the app and that app has also to it has to be maintained locally unless you are able to kind of make it into a generic feature so it could be more costly As a note to that I would say that this app development platform resources which Austin talked about yesterday is a great kind of example of how to try to keep the flexibility of developing custom apps while actually trying to eliminate or externalise some of these costs of developing and maintaining apps so with this app development platform now you actually have a lot of flexibility to design things but a lot of the aspects that goes into an app is actually maintained and developed by the core team so the weight of that maintenance and development becomes less so it's going to be very exciting to see in the future how much you're able to kind of make it keep the flexibility in order to design new features new functionality, new user interfaces based on local needs while actually trying to have as much as possible of the development and maintenance work kept on the core team or on the generic level Of course this option of dismissing or solving it through end user training is not an ideal thing many times but it happens a lot I've seen it in many places because it doesn't require any custom development but then of course the usability and relevance of the software might suffer if you're not able to build actually what is needed and what is the ideal thing in that context then again data quality, user acceptance and the potential benefits of digital innovation might then suffer so that was a bit about this technical flexibility thing moving back to this triangle again the one of the elements of capacitating user-oriented design innovation is about having flexibility and I think then the app development platform and also SDK for Android is a great kind of advancement in this field making it possible to easier and faster and cheaper create innovations increasing the capacity here but then also it's about design methods and approaches so how do we actually then design when we implement the HSI to how do we go about engaging with users and doing these kind of things so there are a lot of these design methods that have been developed to guide the kind of user-centered or user-oriented design so there are for example this human-centered design approach something called participatory design which emphasizes a lot of participation from end users and these have some kind of typical steps that needs to be done in kind of an iterative manner typically in order to try to build both the right thing and building that thing right as they say so one of them is to try to when designing systems you should always use the existing practices and needs of users as a starting point and this means that it is a projectivity to try to understand what is needed by the end users and of course this always happens in an IT project there is kind of a phase of requirement definition and requirement analysis and defining requirements but typically the argument in these user-centered or user-oriented approaches is that this should not be dominated just by the IT project team and by top level managers but also involving the users that are actually using the system on different levels so for instance when building a reporting system based on DHS2 one should then engage also with for example the people entering data at the lowest level and so on and so forth and then understand what are their practices and needs and then analyzing and ideating how can we then support this in a good manner and I think by looking at implementation projects different places around DHS2 there is a lot of this going on already and some places there might be very dominated by top level managers and not maybe that much of user activities and in other project there is a lot of going into the field trying to understand how the users work mapping out their tools and processes and then basing the requirements on that which I think is great. Another important aspect typically promoted by these approaches is that there is an ongoing iterative prototyping and evaluation process so based on this initial understanding of the needs and the practices of the users one develops prototypes which are then ideally built very low fidelity at first maybe just using paper for instance trying first to test out the concept so is this the right thing starting with that understanding what would be a valuable addition to your work and what could make things easier and what could address your challenges and then maybe gradually building more high fidelity prototypes starting also to address how do we build this thing right meaning more about is it intuitive and easy to learn to understand and so on and so forth so in the DHS2 example that would be experimenting with DHS2 one issue typically with DHS2 is that since it's possible to very easily configure quite a high fidelity prototype with the kind of generic DHS2 sometimes it could be to jump past and more what is the right thing which is maybe that you see when developing apps where you have more flexibility and you can really explore what is the right thing in this setting not just kind of bringing always bringing the same data entry app regardless of what you learn in the when you try to understand the practices and the needs so how this typically looks in the DHS2 context in many places would be that you have this process of understanding the practices and the needs talking to users so maybe you ask them tell me about your work going out there in the field then they explain that okay we do this then we do that then we use these tools to gather data then we send it for approval here and there and then what I think is very interesting is that if you are a very kind of experienced DHS2 implementer then you already know have a lot of concepts in your mind so you know okay when the user is saying okay we do this and then we have this report then there is kind of a analysis process going on in the head of the DHS2 expert listening thinking about you know data elements programs, stages, tracker custom form that's what we need for this and then this is kind of an ongoing mapping from the real world into the world of DHS2 and the kind of capabilities that are available there and sometimes we also think that okay here we actually need a custom app but again this is typically matched towards what are the budget of the project and what are the scopes and the aims and sometimes maybe custom apps is not an option and I think what is interesting is sometimes the output of this process going and talking to users and then analyzing and thinking about what could be built sometimes this translates into kind of a digitization initiative at least for some users that you know now you're going to do this not on paper but on a digital copy of paper and sometimes it actually results in you know more digital innovation kind of things and I think again this is you know why this kind of can result in two things is one how you do this first thing how do you actually go about you know talking to users what are the right techniques for you know observing them or who to talk to and what to focus on when talking to them which is quite difficult at times because you get a lot of information and then how is this analysis and ideation process going so what are you actually doing systematically to take this rich description of the world and the practices of the users into a kind of very concrete design so as one aspect other is you know is it viable to think in terms of customization and building custom apps how much flexibility do we have to not just use generic features but actually you know experiment with with hopefully new kind of features and then as I will turn to quickly now is the and then also you know what are the kind of scopes and the mandates in the project is the room for thinking outside the box or has it already been defined that this is going to be you know like this then maybe this isn't actually feeding that much into anything and then also typically in the implementation there will be something that is resembling this design approaches that I talked about regarding prototyping and evaluation where based on requirements gathered and the way you have kind of mapped this into DHS2 you present an early version of the DHS2 configuration for eksempel and you know ask how is this addressing the issues and is it working according to requirements and then the users might say great but we have some issues here and there and then of course it's the same process again what is viable here, is it possible to build custom features and is it not and also to mention this again here since we typically start with the quite high fidelity prototype prototype that has a lot of functioning functionality we might sometimes then skip the very fundamental question of what is the right thing here maybe the users have been talking about a lot of issues that they have but then we keep dragging in the same the same generic app for any kind of problem instead of moving out of the box and trying to build maybe a custom map which could be the way we are doing design as a practice or it could be because we are suffering from a very tight project scope and mandate for eksempel og så on and so forth så har vi også denne quickly turned to what I have hinted a bit about that this last thing in this maybe also returning to this triangle that there is the design flexibility of the software that we are designing with is of course an important determinant on the kind of space we have what kind of design practices we are adopting, what kind of methods to be used for analysing innovating and ideating is an important aspect but then also this the way the projects are geared and structured is obviously also a potential enabler or disabler maybe if that's the word to actually innovating and designing based on user needs so some of the challenges that we have seen many times I think is that some of these implementation projects let's say for NGO again or Ministry of Health or whatever is for instance design more as a kind of waterfall process that is very heavily defining things in the beginning and then planning the whole maybe three, four years of development in advance and then there is very little room to kind of change the focus as you know the project moves along so let's say and that has been a constant problem in many countries also including Norway where you start to plan the solution and then it's going to take four or five years to build it but then as we get into the third year for example many of the requirements has already changed meaning that meaning that you're kind of aiming at moving target all the time and if you plan too much in advance it's very hard to kind of adapt to changes along the way and that also then results in or another very difficult part of some project is that defining what is the right thing to build is not actually part of the scope and the mandate so as for example his group when you are working with a client it's not part of your mandate to explore what is the right thing to build which is an essential part as I talked about in innovation so if the project already has defined that okay what we're going to do is to take these paper forms and we're going to make them electrify them and then we're going to have these kind of data outputs supposed to resemble the old system and so on and so forth then there is actually no room for going down to the basics and exploring what could provide additional value in this context this also relates to another point which is about when you are building this system it doesn't typically just require very technology focused change but might also then require changes in organizational structures so let's say you're innovating the way approval processes are going on maybe you can make less steps and make it easier automate things and so on that would also then of course require organizational changes which then again might be beyond the kind of scope and mandate of either the specific his group in charge of designing something or the kind of technical team so then there needs to be some kind of collaboration which could be very difficult and then I think maybe one of the most prominent issues is to you know if it's not defined clearly that there is a aim and is a need and is a reason for engaging with end users in the way projects are defined then of course that is not going to be a part of it it's not budgeted in and it's not kind of designed into the way working and there we have seen a lot of very different approaches in different implementation groups so some for example you know really based the whole project around user oriented design principles that okay we're going to work in this iterative manner and we're going to extensively bring end users into the process prototype and doing these kind of things while some projects there are kind of a total lack of that kind of focus it's totally geared towards you know IT the IT management of the project and there is no kind of budget or flexibility to work with users at all and then of course finally this again this issue with the software of course the flexibility of the software is from the outset a very core and to rely on generic features that also of course shrinkens the space of you know the ability to explore alternative ways of doing things if you're only going to use the standard standard applications for example yes so so that was some of these kind of overall challenges and I think this is relevant for a quite large audience because as for example an implementation group specialising in implementing the HS2 of course this is important when thinking about how do we design and what kind of practices are we designing with and how are we negotiating these kind of mandates and projects and then also from the customer organization side you know creating awareness around the need for thinking in terms of users and innovation and design making that part of the projects I think there is a kind of long way to go there in many projects to and it is of course difficult the balance between making projects scopes and mandates that have flexibility for finding potentials for innovation while at the same time making sure that it's not getting out of hand because you need to have some kind of clear objectives that's a very difficult thing and it's one thing that we're also exploring together with some of his groups in the design lab you know what what kind of mandates and scopes are kind of balancing the need for you know control and trust and so on with the kind of right type of flexibility for allowing innovation and user oriented design to happen and also not just you know building the thing right but also then explain what is the right thing to build in this given context So finally I will just wrap it up I hope some of these topics, phenomenon and challenges that I touched upon was interesting to some of you So I will just say a bit about what the future plans for the DHS2 design lab are So what we already do and what we want to continue to do is work very closely with his group but also groups in different countries such as India and Mozambique and so on but also with other DHS2 practitioners maybe independent implementation specialist groups or user organizations in exploring developing and documented best practices around these kind of design and innovation things especially trying to work together on looking at what are the current practices of trying to design and innovate and maybe also implementation of DHS2 in general and then looking at what do we have any space and opportunity to test out new kind of techniques and ways of working with mandates and processes to increase our kind of innovation capabilities and we're also in the process of discussing to establish some kind of DHS2 design and innovation community So let me know if anyone finds these things very interesting and would like to be part of a more open and global initiative of exploring these things and then we're also working on this DHS2 user oriented design and innovation toolkit where we want to combine this kind of related to these app development resources but also focusing on the capacity related to conducting and negotiating the mandates for user oriented design and innovation in projects. So last slide I just wanted to say that please write on the community of practice in this session Q&A which I think is linked in the chapter or contact me on my email address at any time if you have any questions thoughts or ideas related to the things that I discussed in this session or if you have any experience with doing user oriented design and innovation and have some interesting experiences with success or with challenges or if you have been involved in any concrete projects where you have been again either successful or found a lot of challenges with trying to work with users and innovation and of course also if you want to learn more about these things or if you want to collaborate with us in this lab on exploring methods and understanding challenges about this please write a post on the community of practice or send me an email yes so I guess that would it for me thank you very much for joining the session and hope to hear from some of you regarding these things and I'm looking forward to see the future of DHS2 especially related to innovation and apps and supporting increasingly diverse and dynamic audience of users with usable and relevant tools thank you