5. High Fidelity Digital Prototype
For the high fidelity prototype, we chose to use Adobe Illustrator as our tool from making the high fidelity prototype. After doing the interviews and research before, we noticed that no matter how detailed design the paper prototype we made, users testing it were not able to fully grasp on our prototype was trying to do and how its navigation works. We incorporated all the necessary colors for our website, the necessary functionalities for the system were also incorporated in MarvelApp during this phase. Again, we did another user testing with these new design prototypes. The visual of the prototype aims to generate rich UI Design components. With more interactive effects and more detailed design, we feel it would be easier for users to give certain feedback to the prototype. With similar-to-real content that is provided in the prototype, the users also could judge the prototype in a real-life scenario that they have experienced before. With this high fidelity prototype, we expect users to feel natural when using the prototype, thus, we would gain meaningful insights from the user testing. The trade-off from making the high fidelity is that we have to make more effort and spent more time to get the outcome. As the time we have is very little, we feel like this strategy to do high fidelity will provide us with a better result than to test the paper prototype before.
To start with our high fidelity, we created a mood board in order to know the design guidelines for both UI and UX Design. We aim to have a minimalist design and very clear structure in order for doctors to use it efficiently and quickly. We decided to put not much of design or color aspect to the mood board because Easy Referral aims to create a very concise task flows for the users. With rich color and UI Design, it would appeal to more users, however, that reason is not our intended and initial purpose when making Easy Referral from the start.
The link to our high fidelity prototype can be found on https://marvelapp.com/68g67a6/screen/49264451 (Webpage for Physician and GP) https://marvelapp.com/a2g4b81/screen/49259774 (Mobile App for Patients)
At this stage, our users were able to see what exactly the application would feel like though it did not have all the functionalities. We incorporated all the necessary colors for our website, the necessary functionalities for the system were also incorporated in Adobe Illustrator and MarvelApp during this phase. There are two users type which is general practitioners and physicians that is aimed for this prototype users audience. The main focus of this website prototype is to create a clear flow for the next user testing that could be used by GP, Physicians, and patients. Described below are the detailed functionalities on our high fidelity interfaces.
On this high fidelity prototype, our group provides the basic homepage, login, sign up, and profile page that could be accessed by the physician and general practitioner. In the homepage, there are links that take the users straight to their interface page. If you are a patient, you could click the login as a patient which the page will take you directly to the prototype for the patient. This works too for physician and GP. Our group also made the profile page for both general practitioner and physician. The profile page includes information for general practitioners and physician where we feel it was important to extract general practitioner and physician information to our website system.
** General Practitioners - Creating referrals**
General practitioners are able to create referrals based on the patient's information and other description necessary to supporting the referral. First, the general practitioner would have to choose a date and time for the next consultation for patient and physician. Next, general practitioner has to choose the nearest physician. In the selecting process, general practitioner could see the physician's years of experience and the estimated cost from the physician. This was purposed to find the most suitable physician for the patient. Third, general physician has to fill the patient's information like their name, phone number, address, etc. General Practitioner also have to fill the referral title and description. There is an option to insert images if the general practitioners feel its necessary.
The task flow described below is based on the insights we gained. Such as the general practitioner could only choose the nearest physician. On the first iteration, we put this flow first instead of choosing date and time. However, by choosing date and time first on the flow, it is very beneficial for the patient, thus, they could pick the nearest date. Since the referral problem, as described in our research, is how the patient is left waiting and not knowing the exact appointment date, our group decide that by choosing the appointment date and time first, we could see the most available doctor at the time and decide to continue it or not.
In this function of making a referral, we feel there is too much content to put in one interface, thus, we divide the whole process into three ways in each interface/page. Once general practitioner completes the form, we feel confirmation is needed in order to double check all information on the created referral. general practitioner could see the referral information and description in the confirmation modal. When general practitioner feels the referral is appropriate, general practitioner could click yes. When the referral is missing something from the confirmation modal, general practitioner could cancel and when back to the process to complete the missing information. Once the referral is confirmed, it means that the patient is agreeing to have an appointment with the selected physician and designated written date and time. What all the patients have to do now is wait for the physician's approval.
** General Practitioner - History**
General practitioners are able to see any history of the referrals. GP could only see the referral that they made and can't see other patient/GP referral. They could see the latest referral or other options to see all the referrals that they made from the beginning they use Easy Referral. The interface only shows the latest referral because there will be a lot of content on one page where it is ineffective to see from the user perspective. To prove this, we will ask how the user feel about this in the next user testing.
If general practitioner clicks on certain referral, general practitioner could see the detail of the referral. This brings general practitioner to another interface/page. The details include information such as, which patient and physician the referral refer to or the pictures that the referral link to. Another feature is for the general practitioner to be able to chat with the physician that is based on the referral number. Thus, each referral made has different chat discussion. The chat feature is to make the communication from general practitioner and physician easy. It is also more convenient to keep track of any communication for the referral matter that is made between both physician and general practitioners. The chat interface is in another page or interface because of the context behind referral detail and chat platform is different.
Physician - Schedule
Physicians are able to see their own schedule. Schedule interface will be the interface that the physician see whenever they enter the system. It is because the physician could comfortably see their own schedule from the first load, thus, they have a lower probability to forget an appointment and another arrangement. If any appointments are agreed, the schedule table will also load all the appointments date and time in it. If the physician has another schedule, they also are demanded to fill their schedule or the system will indicate the physician is available at the time. By doing the schedule, general practitioners could see if a physician is unavailable at the chosen time. For example, physician have to go on October 10-11 to go to an international medical conference, thus, he has to fill the schedule that indicates physician is unavailable for the time.
Physician - Referral
Physicians are able to see any referrals history. There are two types of referral from the physician standpoint which is waiting to be approved type and latest agreed type. Waiting to be approved type means the referrals that indicate that they are waiting for the physician's approval. Latest agreed type means the referrals were approved by the physicians for the appointment date and time automatically registered on the schedule. These types are divided in order for the physician to effectively see the difference between both types. To see all the referrals, the physicians are redirected to another interface. This decision was made as there is a lot of content if all referral is put in one interface.
If the physician clicks on the referral card, they will be redirected to another interface/page where it shows the referral detail. The detail includes information such as which patient and general practitioner the referral refer to or the pictures that the referral link to. Another feature is for general practitioners to be able to chat the physician that is based on the referral number. Thus, each referral made has its own designated chat feature. The physician is able to chat with the general practitioner. This is based on the chance where the physician is confused by what the general practitioner says in the referral or the referral may need more patient information.
Once they see the referral detail, physicians could decide to confirm the referral. This confirmation is not based on whether or not they want to do a consultation with the patient, but it is to confirm the date and time.
When confirmation is made, the physician agrees to date and time proposed in the referral. If the physician is not agreeing/ canceling, they could contact the patient's phone and propose a new date and time for the consultation time. This would generate a notification feature for the mobile application specifically only for the patient. It will be described in detail in below section of the mobile application.
Scenario 1
General practitioner is having a consultation session with a patient. General practitioner analyzes the patient's medical condition physically and from pictures. General practitioner then decides that the patient needs to see a physician. General practitioner goes to his computer and creates a digital referral using Easy Referral website. First, general practitioner would search for the nearest physician available. General practitioner also will ask if the following place and time of the physician consultation suitable for the patient. If the patient said yes, General practitioner will continue to create the referral and wait for the physician's approval. After the patient consults with general practitioner, the patient could see their own referral in their phone and wait for the approval. If the physician approved the referral, the patient could go to the physician with the approved time and place.
Scenario 2
Physicians have accepted the referral by clicking the referral details. The physician sees the description and a little bit confused about the explanation that the general practitioner made. Thus, the physician uses the chat feature and ask the general practitioner what the meaning behind the data given in the referral is. The physician then is able to understand the data and continues to help the patient.
The link to our high fidelity prototype can be found on https://marvelapp.com/a2g4b81/screen/49259774 (Mobile App for Patients)
Patient - Common
On this high fidelity prototype, our group provides the basic settings and profile page. In the profile, we extract user information that only useful for the easy referral system. There are four menus that are put as the main menu at the bottom of the application. From left to right is the menu for referral, reminder/notification, profile, and settings. The interface the user will see first is the referral where it would be handily for the user to quickly see their own referral. The other menu is the reminder/notification where our group feels there is too much content for reminder/notification. Thus, we appoint another interface with its own menu on the bottom.
Patient - Referral
Patients are able to see their own referrals by choosing the referral menus. The interface will include all the referral in lists/card format. The referral card includes the important information about the referral, such as the title, date time, and brief description. From here, patients could see the detail of the referral by clicking the referral card. In the referral detail, the patient could see the referral description and any pictures the referral has. A patient also could see the general practitioner's referral. A patient could also see the physician assigned and see the status of the referral, whether confirmed or not by the physician.
If the referral has not yet approved by the physician, the patient could suggest a new date and time by clicking edit option in the schedule sub. The application also offers the notification where it will notice the patient with the latest update about their referral. For example, if the physician approved the referral, the patient will receive the notification on their phone that they have a booked appointment. Another example is when the appointment is near, the application will remind the user to get ready and go to the physical place or certain hospital.
Scenario 1
After consulting, the patient is waiting for the referral to be approved. However, the patient got a call from the hospital to arrange the schedule into the next week. Patient approved the new proposed date and time. Then, Physician approved the referral and patient will receive the notification on their phone that the referral has been approved. After a week goes by, the patient receives another notice that they will have an appointment in 3 hours, thus, the patient gets ready to meet the physician.
- The website must provide the ability for general practitioners to create a digital referral
- The website must provide the ability for physicians to see the digital referral
- The website must provide the ability for physicians to confirm the referral
- The website must provide the ability for physician to see the referral details
- The website must provide the ability for general practitioners and physicians to communicate easily by chats
- The mobile application must provide the ability for the patient to see the referral
- The mobile application must provide the notification feature to notify the user any progress with the referral
With the making of the high fidelity prototype, we have a clear and coherent task flow like illustrated above. The task flow illustrates how the future prototype or application works. In this prototype, we have decided both the UI and UX of the interfaces we made based on the task flow from the low fidelity prototype. The UI supported the detailed and appropriate content, thus, the user testing would feel more precise. For example, in low fidelity prototype, the prototype did not show any detailed information like physician phone number or the hospital address. This detailed information is shown in this digital prototype. The prototype also includes user interaction where the user could click on buttons or other components that could take them into another interface. This will bring the prototype level closer to the real application, thus, the user could judge it more naturally.