As part of my appointment as a Research Assistant at the University of Strathclyde, I had to design a clinical decision support tool for primary-care prescribers, which will help them reduce risky antibiotic prescriptions for Clostridioum Difficile.
The tool had to be designed so it can support a predictive algorithm created by the University's department of Mathematics & Statistics.
As this was the first large-scale project with multiple stakeholders I was involved
before deciding the research and design steps I wanted to understand the project.
Hence, I started by mapping the project and its dynamics (e.g. resources, expected outcomes, stakeholders). This way I wanted to decide on the methodology based on the specificities of the project.
I created a Logic Model (Figure 2a) in order to understand the project and a stakeholder map (Figure 2b) in order to understand the dynamics between the stakeholders and their expectations.
The next step, after understanding the project specificities, it was to find the suitable methodology for trying to come to the desirable outcome.
The User-Centred Design process (See Figure 3) was chosen as the most appropriate methodology for this project.
The process started with qualitative enquiries in order to understand the context. The results were analysed qualitatively in order to extract the requirements. Based on the requirements, a set 5 different paper prototypes were created. The prototypes were evaluated qualitatively about their feasibility. Lastly, a co-design session was organised in order to produce the final prototype.
In two enquiry stages 5 primary care prescribers were interviewed (3 GPs, 1
nurse and 1 pharmacist).
In order to get a deeper understanding of the participants' context, behaviours,
and concerns and therefore design for their real needs,
I mapped the results of the thematic analysis to empathy maps (Figure 3) in
order to better
understand the potential users and empathise with their needs.
The empathy maps guided the creation of personas (Figure 4) for the the potential users, which were used in order to communicate the findings to the research team and collaboratively extract the requirements of the users (Figure 4).
The results of the previous stage led me to design
a set of 5 potential prototypes, as there was no
single best solution, due to the limitations of the context.
As soon as these prototypes were ready the team started assessing their feasibility for implementation, in terms of how easy it was to develop them and if their functionality could be supported.
More stakeholders were included at this stage in order to get feedback on the prototypes.
The prototypes were assessed on their feasibility for implementation, in terms of how easy it was to develop them and if their functionality could be supported.
This assessment was based on a further qualitative enquiry stage with 3
2 observations with prescribers.
Based on the results of this analysis, the prototypes that were selected were carried to the next stage.
The final stage of the process was to co-design with prescribers
the final prototype tool.
3 general practicioners (GPs), who were acting as 'champions' for the whole project, were called to participate. Unfortunately only one was willing and available to participate.
The participant was initially asked to card sort the different options - the ideas behind the prototypes and not the prototypes themselves. Then he was asked, based on his top option, to design the prototype. Figure 7 shows a snapshot of the session.
As a direct outcome of the co-design session, a medium fidelity (interactive
prototype was created.
This prototype was communicated with different stakeholders and a health IT company stated interest in adopting it into their system.
Unfortunately, due to copyright regulations, I cannot present the final prototype.