Telemedicine service is a medical activity in which one medical institution (hereinafter referred to as the inviting party) invites other medical institutions (hereinafter referred to as the invited party) to provide technical support for the medical institution's treatment of patients by using communication, computer, and network technologies.
The telemedicine service has a clear management specification, so in the process of carrying out the telemedicine service should strictly abide by the relevant laws, regulations, information standards and technical specifications.
The challenge for our design work was to find ways to optimize the experience of replacing the original telemedicine services in the healthcare system by adhering to the existing consultation process specifications under the premise of technical specifications. It's not too much of a stretch to say that this project was a "dance in shackles" for the designers.
Since there are four personas involved in a telemedicine consultation (applicant doctor, organization administrator, consultation specialist, and review specialist), and the motivations and behaviors of each persona vary greatly, as well as the understanding of each persona by the team members, we chose user profiling as the entry point for our user research.
We collected information about the four personas through both surveys and active listening. Due to resource constraints, the collection samples were relatively small, so the character archetypes still need to be improved.
Because neither the collected information nor the construction program of telemedicine consultation released by the Commission of Health Planning is sufficient to establish our control of the overall process of the whole telemedicine consultation as well as combing the details. We needed UX stories to help the team build up **** knowledge, as well as discussions to be able to restore the scenarios from the user's point of view and identify pain points.
Product Definition
In this session, we focus on the user's goals and what problems the product can solve for the user, so the user profile highlights the value in this session.
Backbone story
In this session, we kept exploring the entire telemedicine consultation process and ended up with a storytelling description, which was then broken down into whole chunks of steps that were as complete as possible but without details.
Splitting the story
In this session, we refined each step and split it into clear tasks, while discussing whether the user has better options and what to do if something goes wrong.
Communicating and confirming
In this session, we prioritize the split steps, and exclude the unimportant ones from the release plan for now.
The discussion process is not shown, and the final result is shown.
The telemedicine consultation process is centered around four roles operating on a request form, so the status of the request form is the core of the entire information architecture. Each role operates based on the status of the consultation order.
Our team used a previously defined component-based management tool to quickly lay out the page. The home page layout was divided into left and right sections, with navigation on the left and content areas on the right. The left side of the navigation consists of the entrance to request a consultation and the status of the consultation order. Since requesting a consultation is the core requirement for the role of the requesting doctor, we need to put the entrance on the navigation so that the requesting doctor can access the requesting consultation process on every page. The right side consists mainly of to-do items for the applicant doctor and consultation statistics.
Scenario A - Avatar & TODO
The TODO area consists of the applicant doctor's avatar information and the TODO entry.
Excellent: highlights the doctor's personalized to-do list console;
Poor: to-do list is not prominent enough;
Scenario B-To-do list
The to-do list area only displays to-do lists and is modular.
Pros: to-do list entry is clear, roles can quickly find their own work entry;
Cons: it's easy to make the page dead;
In the end, we chose Option B because, as the first version, we still want to help users build up their habits quickly, so the page needs to be cleaner and more streamlined, and the optimization of the user's experience can be part of the ongoing iteration later. part of future iterations.
The core scenario in the telemedicine consultation service is video consultation, in which the whiteboard is the core function, and the video function is relatively weaker. However, we still support full-screen expansion of the video, so that users can utilize the space of the video to display the consultation information. At the same time, the chat room function as a supplement, you can carry on the text conversation and related electronic information circulation.
1. In this project, we aim to create a more usable and easy-to-use teleconsultation service for the physician community. We achieved our goal of optimizing the consultation request process for the role of the requesting physician, as well as the experience of remote video consultations for each physician role.
2. However, we still have a lot of points to reflect on and optimize. Due to our lack of understanding of the industry background, our user research is still not perfect, and although it can help the team better reach a unified goal, we need to keep practicing how to use user research to better drive design decisions.
3. Because of the first version, we didn't do much to differentiate the user interface for each role due to many development cost constraints. But in fact, each role has its own tasks and motivations to focus on, and better focusing on "user value" is the most important direction we need to focus on in future iterations.