Project Background

In 2015, the Welsh Government introduced the Health and Care Standards which provide a consistent framework for healthcare staff to ensure they provide high-quality care:

Unfortunately, there is a severe lack of data on how clinicians are meeting these Standards, which need to be made more meaningful, whilst taking into account the significant pressure healthcare staff are under. It is very difficult for them to enter conversations about and improve their performance, and impossible to make judgements due to unawareness of how they are performing over time.

Client

Our client is Dr Joseph Connor (NHS).

Project goals

The project goal was to develop a user-centered and easy-to-use online platform that enables healthcare staff to communicate about the Standards in a meaningful way.

It should be embeddable into their routine, with minimal effort or time, and lead to honest, open conversations between managers and clinicians.

The platform allows clinicians to perform honest self-reports through a series of short questions, each linking to one of the Health and Care Standards.

Results are visualisable at different levels: by clinicians themselves, their managers, their hospitals, or their health boards. All responses are anonymised to promote honesty and privacy.

Requirements gathering

We gathered the requirements using an iterative approach. Gathering requirements was the first stage of our project — the Human Computer Interaction (HCI) phase.

HCI is the design, implementation and evaluation of interactive computer systems focused on the users, as the system being built is for users and to help them. This user-centered approach helped ensure the system is effective and efficient for the end-users.

We needed to interview/question the users of our system. Due to the physical constraints imposed by the COVID-19 pandemic, we decided to conduct semi-structured interviews via Microsoft Teams and a questionnaire using Microsoft Forms.

Due to the time constraints we also decided to send out a short, quick questionnaire in conjunction with a semi-structured interview to get the best results, instead of attempting to schedule longer interviews with multiple people.

Interviews/questionnaires

For our research to be useful and concise and to increase the chances for users to complete the form, it was imperative to not go into fine details. As a result, we asked general questions that would stimulate our users to give their honest opinion and their own ideas of how the system could work.

We decided to ask questions about how the users feel about the problem, the current way it's done, what they would like and how they envision the final system. Excerpts of the interview and questionnaire results are below:

Analysis of survey data

We analysed the questionnaire and interview responses to conclude the following:

• Users were concerned regarding the anonymity of responses, and preferred these to be anonymous, so they could be honest and not feel judged.

• Users wanted to spend minimal time on the self-report form (1-5 minutes).

• Users were interested in a combination of Likert-scale questions for objective valuations, and word-based questions to show their thoughts/comments.

• Visualisations and graphs would be very useful, as long as the interface was intuitive, readable, and the data is actionable.

Personas

After analysing our interview/questionnaire results and understanding our users and what they want better, we created personas for some of our main user groups: a clinician, department manager and head of hospital/health board.

We focussed on the most important details that would be relevant to how our system is built. These are the 3 personas we created:

Use Cases

We created a Use Case Diagram for the platform, for each of the 5 User Groups: Clincians, Department Managers, Hospitals, Health Boards and Administrators. Each user type performs different tasks, as detailed in the diagram below:

MoSCoW Requirements

After conducting our user research we formalised our requirements as a set of functional and non-functional MoSCoW requirements, and confirmed these were suitable with our client:

Functional Requirements

Must Have

• All users must be able to login with unique credentials

  • Sensitive information such as passwords should be cryptographically hashed & salted

• Clinicians and Managers must be able to complete a self-report

  • Self-report form must contain Likert-scaled questions

  • Self-report form must take ≤ 3 minutes to complete, on average

  • Self-report form must concern the user's performance against the NHSW Health and Care Standards

  • Self-report form must allow user to say whether it is being completed as part of a mentoring session, or by themselves

• Clinicians, managers, hospitals and health boards must be able to visualise the performance of themselves/their department/their hospital/their health board over time

• Visualisations must include:

  • Change in performance over time

  • Distinction between responses given during mentoring vs. responses given normally

• Managers must be able to manage and alter URLs (to training resources) linked to questions that are shown on the report page alongside the relevant question

Should Have

• Self-report form should allow user to respond to special question via 3 single-word inputs as answers

• Administrators should be able to manage and alter the questions shown to clinicians

• Users should be able to filter the visualisations

• Self-report responses should be anonymous to anyone other than the clinician who performed the self-report

• A mechanism to receive feedback from users about the platform and how it can be improved

Could Have

• Personal analytics which analyse scores and provide feedback on next steps

• Word cloud visualisation to show the single-word input responses

• Administrators should be able to manage and add users

Won't Have

• Any questions that aren't Likert Scale or single-word inputs

Non-functional Requirements

Must Have

• The system must not have perceivable latency as it processes user demands

• The system must be easily extensible and maintainable for the development of new features

• The system must allow effective simultaneous access by multiple users

• The system must be easily usable and provide the simplest / most intuitive UX

• The system must be supported on most Internet browsers

• Security and defensive mechanism to avoid and protect from threats / attacks