myorb

Client.

myOrb is a public-cloud healthcare company. Originally founded in London in 2012, it has been built from the ground up to be a totally private system, protecting its user’s information myOrb and includes advanced analytics, informatics, demand and workforce planning. Their mission is to digitalise the NHS processes to ultimately improve patient outcomes, by improving speed and accuracy of patient visits. One product I head up as a UX Designer, is the electronic requesting system, replacing the paper-based processes currently.

Discovery.

Before launching a product, it’s important to understand the clients requirements and expectations in order to provide a solution to the problems being currently faced. Facilitating an initial discovery workshops allows me and the team to deeply understand the current pain points within the NHS but also to set expectations of realistic outcomes, taking into considerations constraints that may appear such as budgets, timeframes and feature prioritisation, with the main purpose of ideating and defining the project objectives, requirements, and gain alignment on the next steps.

After understanding with NHS clients, we then understand how the users, GPs and doctors are currently working in create patient requests and to understand what challenges they are encountering, through user interviews. This allows us to understand their needs and ask the smart questions to uncover the current situation and problems being faced. From here, we can start to form task flows and journey mapping to discover how the user carries out their tasks from start to finish, highlighting the current problems in place.

After narrowing the scope to identify the core issues, we created the problem statement to work towards for the products MVP:

“GPs and doctors are currently using paper-based processes for patient requests, which is inefficient and causing duplicate, untraceable and sometimes undelivered requests, meaning patients are suffering the consequences.”

Defining.

Once discovering the problems and gathering information from the users, to understand how they are currently operating and ideating solutions, we can then hone in on the specific problems within our limitations. Defining the problem involves synthesising all the research previously done, from the market, client and users to focus in on specific issues that we can provide a solution to.

Problem.

Now we have a clear problem to focus on from the users, we can then start idea generation in how best to solve the current problems the GPs and doctors are facing. In order for us to provide a solution to the problem, we created a solution statement to allow us to have a distinct solution:

“GPs and doctors need an electronic requesting system, that allows them to create, track and manage all patient requests with the hospitals in order to improve patient outcomes with speed and efficiency.”

Solution.

Once the fundamentals had been agreed, both with the users and the team we could then look at design execution. The user journeys and initial ideas to providing the solution were shared with the GPs and doctors in order to confirm the relevant steps would be feasible in their every day roles. We started designing with each step in mind, to go through the user journey for electronic requesting in meeting their goals and aims.

Once we had designed a first concept, we wanted to to do usability testing on the workflow with the GPs and doctors to ensure that the process was feasible. This was a vital step in order to prove the validity of the solution, whilst designed as wireframes, before finalising a high-fidelity design.

With colour theory and accessibility in mind, I helped build out the design system to ensure consistency across all products, using the ‘Blue’ call to action buttons to help guide the user. After user feedback, we designed a dashboard navigation, with a side menu and a main display to ensure GPs can work on a screen with maximum width. Giving the user full control through the process was hugely important, introducing tool-tips and a stepper to ensure the status of progress is easily visible, these are just a few of the considerations behind the design decisions.

Figma Link

Next steps

• Further validation for clinical information required
• Using clinical support decision to guide GPs on creating requests
• Allow saving a request as a draft
• Expand the product to other hospitals

Usability testing

In order to continually validate the medical information supplied in the request forms, constant feedback and validation is required from the GPs to ensure that all the required data is included when creating a request. The current version is an MVP, which allows a GP to create, track and manage a request so testing of further features will allow the product to evolve.

Challenges and constraints

One of the biggest challenges as a designer is having availability from the GPs and doctors, as they are understandably very busy and it can be hard to find time to run workshops. This is why I treat the meeting time of high value, with full preparation in order to leave the meeting with all information required and agreed next steps. Managing this time is important, valuing the time spent speaking to the specialists is critical to getting the best resources from the user base, which ultimately shape our design decisions.

Another challenge is to stay focused on feature prioritisation, whilst taking into consideration wider factors but staying on task with outcomes. There are unfortunately a large range of issues in the medical field currently, which GPs often express, however we need to remain concentrated on what is realistic expectations that the team can deliver, within a timeframe.

Client successes

Successfully bringing live an electronic requesting system to London hospitals with a range of modalities, from ultrasound and cardiology with thorough testing and positive feedback from the clients. Hearing and seeing the impact being made on the GPs and doctors daily roles and providing them a software to provide a solution to their paper based problems.

On a personal level, seeing my designs come to life from initially meeting with the stakeholders and client to understand their issues they are currently facing, to then generating ideas with the team to produce an efficient, usable, and streamlined electronic requesting product. Through vast ideation and collaboration, having the product live in Kingston hospital and seeing the enhancement in results in the form of business intelligence tracking and analytics proves the product has been successful in meeting the needs of the client and users in the early phases, with many more iterations to come.