iOS/Android
Product Designer, Data Analyst
Figma
Create an application that helps patients identify exactly what sort of problem they are having prior to visiting the doctor.
We wanted to design a new app that allows patients to identify exactly where they are feeling what type of pain prior to visiting the doctor. The challenge was that patients often have to attend the doctor and consult about the issue during the appointment. Wouldn’t it be better to pinpoint the exact problem beforehand to allow the doctor to know what to do in advance?
On top of all that, the app must have the ability to allow communication and services to be handled between Doctors, Labs, Patients and Pharmacies.
The client gave me a document of how each section would function, throughout this case study, I will mention exactly what was written in the document and how I executed it.
For Redesign
I tried to get an understanding of what the competitors were doing with ideas like this, however I only got as far as finding an app called “Geopain” which had a very similar idea but weak usability. Since the client mentioned that he wanted users to see their blood sugar levels and other statistics, I immediately had an idea as to how he wanted the home page to be and went for apps with similar interfaces. The apps I gathered were Water intake apps.
Throughout the creation of the redesign, I conducted usability tests by having participants use both versions (before and after). This helped me get live results and an idea as to what users were preferring and why. To avoid biased results, I did not mention that I personally created the interfaces.
The patient view in Termardar is pretty much where the majority of users will be. Whilst the app will be used by other people such as Doctors, Pharmacy owners, etc. The vast majority of users will be patients therefore I had to focus on making it look as simple as possible.
The photo on the left is the statistics of the patient including body fat percentage, water levels/intake, Glucose levels, Blood sugar levels and cholesterol levels. The screen on the right is the categories of the app, If the user wants anything, it's all in that view pretty much. I thought it was a good idea to make the boxes big with larger photos inside mainly because people tend to understand the story quicker when there is a picture to it.
The client told me that he wanted the home screen to be a body to be filled with water indicating the water intake level. However I discussed with him that if we want to make the design focused on the app purpose, we’re avoiding a “Water intake” app design and stick to anything related to the medical field. He agreed on the idea and I still executed it without compromising the water intake percentage.
I wanted the pain identification to be quick and swift. When I was a child, coloring books was the easiest thing for me to do, therefore I thought highlighting the area of pain would be just as simple for a patient.
> The process:
When making the booking process, I obtained some ideas by looking at other designs such as “Calendars” and “Booking” apps. It was mostly inspiration from google rather than other apps.
> The process:
It was important that I made further steps not filled so the user has an idea as to how the structure of booking the appointment works.
Problem & Solution: I wasn't entirely sure how I was going to implement the booking system as well as the doctor’s profile on the same page.. I brain stormed different ideas and came to a simple classic solution (Which I should have thought of earlier) and that was the toggle box option. In summary it allowed me to put 2 sub screens in 1 big screen meaning that the patient would not feel as though he's on an entirely separate page that has a different purpose.
A page needed to be done for the patient/user to have the option to check anything such as his doctors, pharmacies, payment options, etc. I realised there was a lot that the patient would need to check, but I also wanted things to be as compact as possible rather than including tab bar space.
I had a deep thought and remembered different apps such as ebay would have a section where it says “My orders, My wishlist, etc”. With that in mind, I wanted to implement something similar and came up with this design.
This design reminded me a lot of a previous project I made called “Find a Player”, I used the same concept and believe it was executed fairly swiftly.
I didn’t encounter any problems making this page, I knew exactly how I wanted to lay it out and went to work straight away. I used a few inspirations from apps such as Uber and Badi, but apart from that, all went swift. Users can filter their search in a click of a button or even type out a search themselves. On the right is the list view, I mentally split the boxes in half, on the right is the CTA and the doctor reviews (The more important info) and on the left is the picture of the doctor as well as the view profile button.
The communication screen goes for all users in the app (Patients, Doctors, Pharmacy owners, etc). Doctors will have a slightly different view to other users, they will have 2 tabs “Patients” and “Assistants” to help them differentiate since they are required to work quickly.
I made the design fairly similar to the app “Whatsapp” since it is an app that people use almost on a daily. People like using stuff that they are already used to and dislike having to figure out how new apps work.
I encountered no problems when making this page.
When an appointment is complete, the patient will receive a report as to how the appointment went, the statistics and what medicines he will need to order.
I layed it out as follows:
Having the details of the patient on the top along with a color saves hassle for the doctor as well as the user. It will have a background of a color they like making the user feel more special and have a sense that it belongs only for him.
Having icons near the name of the tab helps differentiate for users wanting to read quickly.
Lastly, in the prescription tab, people would much prefer to see an image of the package/product along with the name of it rather than just seeing the name. Prescription names can often be overwhelming so having an idea of how it looks helps everyone.
Requirement 6: Ordering medicines
When receiving a report, some patients will be required to order some prescriptions. There is an order icon within the prescription box. To have everything easy and straightforward for the user, he will only need to click on that which takes him to a page that shows all available pharmacies within the area that have that.
In blue is an indicator that stock is sufficient inside that pharmacy, whilst written in red is stock that is limited for that pharmacy. This allows the user to make a better decision to what store to travel to incase it gets purchased.
Users can also filter pharmacies by the distance, rating, etc.
Requirement 6: Ordering medicines
When receiving a report, some patients will be required to order some prescriptions. There is an order icon within the prescription box. To have everything easy and straightforward for the user, he will only need to click on that which takes him to a page that shows all available pharmacies within the area that have that.
In blue is an indicator that stock is sufficient inside that pharmacy, whilst written in red is stock that is limited for that pharmacy. This allows the user to make a better decision to what store to travel to incase it gets purchased.
Users can also filter pharmacies by the distance, rating, etc.
Requirement 7: Payment
Payment module handles all the invoice details and how the patient will pay his/her dues.
This is the main screen of the Payment module.
This module handles two kind of information
Right now, on this screen invoices are selected. All the details of the invoices are shown below in the list.
Options
If the user selects “Options”, then the following screen will display.
This screen allows users to add new payment methods or choose their most desired payment method.
Patients can add a new payment method by pressing the “+” button on the right side of every method.
Add Card
On this screen, patient can add the following card details
After adding all the details of the card, there is a button of “ADD CARD”. After pressing this button, the card will be added as a payment method.
Pay
After adding card details, the user will be able to pay the invoice.
I designed this with a lot of trial and error. I wasn’t sure what to put at first, but after browsing around for different invoice examples, i came to the conclusion that the following was suitable to note down:
I put total and invoice number in blue since it is information that users look at the most.
The Doctor View is what the doctor will see when accessing the app. It includes the Doctor’s daily Hospital schedule(What patients at what time), the patient reports, the list of patients, and the doctor assistants.
When a patient books an appointment and the doctor accepts it through the notifications tab, it will automatically be placed into his schedule on the home screen.
The doctor would be able to select different dates and see what is going on that day. There is a small dot indicator on the left of the screen alongside the time; this displays the progression of the day, when an appointment is complete, it will be filled in blank giving the doctor a relax in the mind showing that it is now completed.
Communication for the doctor to any other users on the app has been discussed in the “Communication” tab in the patient module.
Reports/prescriptions for the doctor to the patients has been discussed in the “receive reports” tab in the patient module. However, if the doctor wants to review reports he has completed himself, in the second image above, there is a drop down box where the doctor can select “Today”, “Reports” or “Patients”
In the reports section, the doctor will see in either green or red towards the right of every previous patient whether he has completed the report or not. Having them highlighted in red or green indicates whether the doctor has to do it or not.
If need be, the doctor could book an assistant that has different experience compared to the colleagues that are currently around him. I made it so that the doctor could sort by the rating, distance, etc and even search for a specific sort of assistant.
The booking process looks exactly the same as the booking for the patients with the doctors being able to check the Assistant’s profile and select a time that suits them both.
In terms of making the designs themselves, I knew I needed the name of the doctor as well as the address and a photo, however when seeing the other design on the internet, I knew it made sense to include the rating as well as the Doctor’s Specialty since it gives more detail to the user and helps them make a quicker decision.
The photo on the left is the Doctor’s daily schedule. It is split between Time and Events to make it more structured. The longer the event, the bigger the box will be. When the event is complete, that section of the page will be grey and no longer have color, giving the idea to the user that anything before the color is done and does not need to be worried about.
The photo in the middle is the patient's reports. Every patient will need a report to be done based on the appointment he just had. The reports that are completed have a green button on the top right whilst the ones that are still due have a red box meaning it needs to be done.
The image on the right is the list of the Doctor’s patients, if he wants, he can call them or shoot them an email.
The stock report was a very interesting challenge for this part of the module. In all honesty, prior to completing this screen, I had no idea what a stock report even was, so I turned to look at my best friend, Google. After browsing for roughly 1 hour, I had a solid idea as to how the stock report was meant to be structured and went straight to work by sketching out a plan.
This is the orders screen that the pharmacy owner see’s. There are 3 tabs:
New orders:
The “New orders” screen shows the new orders that have arrived. There is a button for further details as well as a button for dispatching the items.
Pending:
The “Pending” screen shows the orders that have been dispatched and are now pending . In green it shows the estimated delivery and in orange it shows estimated collection. Putting different colours helps differentiate the two.
Completed:
The “Completed” screen shows the orders that have been completed. It shows the day the delivery arrived and details of the product incase the customer calls asking about the product they bought in their last visit.
Invalid stock:
When an order comes of the product which is not in the stock of the pharmacy, the system will mark it red. After clicking on the details(red detail button) the system will ask for the alternate order.
When the product is unavailable, the system will ask the pharmacy owner for the alternate order and provide options “Yes” and “Back”. If the pharmacy owner doesn't want to suggest an alternate order he can press the back button and if he wants to suggest the alternate order he can press Yes button.
Pharmacy owners can suggest the alternate medicine or same salt or formula which he thinks would be better for the patient.
When the pharmacy owner clicks on the “Yes” option the system will show the list of medicine from where he can select other medicine and send a request of this alternate medicine to the doctor so that he can accept it and will proceed according to it. The following screens will show this process.
When an order is placed, both the patient and the Pharmacy owner will be able to see where the product is and have the ability to track it.
iOS/Android
Product Designer, Data Analyst
Figma
Create an application that helps patients identify exactly what sort of problem they are having prior to visiting the doctor.
We wanted to design a new app that allows patients to identify exactly where they are feeling what type of pain prior to visiting the doctor. The challenge was that patients often have to attend the doctor and consult about the issue during the appointment. Wouldn’t it be better to pinpoint the exact problem beforehand to allow the doctor to know what to do in advance?
On top of all that, the app must have the ability to allow communication and services to be handled between Doctors, Labs, Patients and Pharmacies.
The client gave me a document of how each section would function, throughout this case study, I will mention exactly what was written in the document and how I executed it.
For Redesign
I tried to get an understanding of what the competitors were doing with ideas like this, however I only got as far as finding an app called “Geopain” which had a very similar idea but weak usability. Since the client mentioned that he wanted users to see their blood sugar levels and other statistics, I immediately had an idea as to how he wanted the home page to be and went for apps with similar interfaces. The apps I gathered were Water intake apps.
Throughout the creation of the redesign, I conducted usability tests by having participants use both versions (before and after). This helped me get live results and an idea as to what users were preferring and why. To avoid biased results, I did not mention that I personally created the interfaces.
The patient view in Termardar is pretty much where the majority of users will be. Whilst the app will be used by other people such as Doctors, Pharmacy owners, etc. The vast majority of users will be patients therefore I had to focus on making it look as simple as possible.
The photo on the left is the statistics of the patient including body fat percentage, water levels/intake, Glucose levels, Blood sugar levels and cholesterol levels. The screen on the right is the categories of the app, If the user wants anything, it's all in that view pretty much. I thought it was a good idea to make the boxes big with larger photos inside mainly because people tend to understand the story quicker when there is a picture to it.
The client told me that he wanted the home screen to be a body to be filled with water indicating the water intake level. However I discussed with him that if we want to make the design focused on the app purpose, we’re avoiding a “Water intake” app design and stick to anything related to the medical field. He agreed on the idea and I still executed it without compromising the water intake percentage.
I wanted the pain identification to be quick and swift. When I was a child, coloring books was the easiest thing for me to do, therefore I thought highlighting the area of pain would be just as simple for a patient.
> The process:
When making the booking process, I obtained some ideas by looking at other designs such as “Calendars” and “Booking” apps. It was mostly inspiration from google rather than other apps.
> The process:
It was important that I made further steps not filled so the user has an idea as to how the structure of booking the appointment works.
Problem & Solution: I wasn't entirely sure how I was going to implement the booking system as well as the doctor’s profile on the same page.. I brain stormed different ideas and came to a simple classic solution (Which I should have thought of earlier) and that was the toggle box option. In summary it allowed me to put 2 sub screens in 1 big screen meaning that the patient would not feel as though he's on an entirely separate page that has a different purpose.
A page needed to be done for the patient/user to have the option to check anything such as his doctors, pharmacies, payment options, etc. I realised there was a lot that the patient would need to check, but I also wanted things to be as compact as possible rather than including tab bar space.
I had a deep thought and remembered different apps such as ebay would have a section where it says “My orders, My wishlist, etc”. With that in mind, I wanted to implement something similar and came up with this design.
This design reminded me a lot of a previous project I made called “Find a Player”, I used the same concept and believe it was executed fairly swiftly.
I didn’t encounter any problems making this page, I knew exactly how I wanted to lay it out and went to work straight away. I used a few inspirations from apps such as Uber and Badi, but apart from that, all went swift. Users can filter their search in a click of a button or even type out a search themselves. On the right is the list view, I mentally split the boxes in half, on the right is the CTA and the doctor reviews (The more important info) and on the left is the picture of the doctor as well as the view profile button.
The communication screen goes for all users in the app (Patients, Doctors, Pharmacy owners, etc). Doctors will have a slightly different view to other users, they will have 2 tabs “Patients” and “Assistants” to help them differentiate since they are required to work quickly.
I made the design fairly similar to the app “Whatsapp” since it is an app that people use almost on a daily. People like using stuff that they are already used to and dislike having to figure out how new apps work.
I encountered no problems when making this page.
When an appointment is complete, the patient will receive a report as to how the appointment went, the statistics and what medicines he will need to order.
I layed it out as follows:
Having the details of the patient on the top along with a color saves hassle for the doctor as well as the user. It will have a background of a color they like making the user feel more special and have a sense that it belongs only for him.
Having icons near the name of the tab helps differentiate for users wanting to read quickly.
Lastly, in the prescription tab, people would much prefer to see an image of the package/product along with the name of it rather than just seeing the name. Prescription names can often be overwhelming so having an idea of how it looks helps everyone.
Requirement 6: Ordering medicines
When receiving a report, some patients will be required to order some prescriptions. There is an order icon within the prescription box. To have everything easy and straightforward for the user, he will only need to click on that which takes him to a page that shows all available pharmacies within the area that have that.
In blue is an indicator that stock is sufficient inside that pharmacy, whilst written in red is stock that is limited for that pharmacy. This allows the user to make a better decision to what store to travel to incase it gets purchased.
Users can also filter pharmacies by the distance, rating, etc.
Requirement 6: Ordering medicines
When receiving a report, some patients will be required to order some prescriptions. There is an order icon within the prescription box. To have everything easy and straightforward for the user, he will only need to click on that which takes him to a page that shows all available pharmacies within the area that have that.
In blue is an indicator that stock is sufficient inside that pharmacy, whilst written in red is stock that is limited for that pharmacy. This allows the user to make a better decision to what store to travel to incase it gets purchased.
Users can also filter pharmacies by the distance, rating, etc.
Requirement 7: Payment
Payment module handles all the invoice details and how the patient will pay his/her dues.
This is the main screen of the Payment module.
This module handles two kind of information
Right now, on this screen invoices are selected. All the details of the invoices are shown below in the list.
Options
If the user selects “Options”, then the following screen will display.
This screen allows users to add new payment methods or choose their most desired payment method.
Patients can add a new payment method by pressing the “+” button on the right side of every method.
Add Card
On this screen, patient can add the following card details
After adding all the details of the card, there is a button of “ADD CARD”. After pressing this button, the card will be added as a payment method.
Pay
After adding card details, the user will be able to pay the invoice.
I designed this with a lot of trial and error. I wasn’t sure what to put at first, but after browsing around for different invoice examples, i came to the conclusion that the following was suitable to note down:
I put total and invoice number in blue since it is information that users look at the most.
The Doctor View is what the doctor will see when accessing the app. It includes the Doctor’s daily Hospital schedule(What patients at what time), the patient reports, the list of patients, and the doctor assistants.
When a patient books an appointment and the doctor accepts it through the notifications tab, it will automatically be placed into his schedule on the home screen.
The doctor would be able to select different dates and see what is going on that day. There is a small dot indicator on the left of the screen alongside the time; this displays the progression of the day, when an appointment is complete, it will be filled in blank giving the doctor a relax in the mind showing that it is now completed.
Communication for the doctor to any other users on the app has been discussed in the “Communication” tab in the patient module.
Reports/prescriptions for the doctor to the patients has been discussed in the “receive reports” tab in the patient module. However, if the doctor wants to review reports he has completed himself, in the second image above, there is a drop down box where the doctor can select “Today”, “Reports” or “Patients”
In the reports section, the doctor will see in either green or red towards the right of every previous patient whether he has completed the report or not. Having them highlighted in red or green indicates whether the doctor has to do it or not.
If need be, the doctor could book an assistant that has different experience compared to the colleagues that are currently around him. I made it so that the doctor could sort by the rating, distance, etc and even search for a specific sort of assistant.
The booking process looks exactly the same as the booking for the patients with the doctors being able to check the Assistant’s profile and select a time that suits them both.
In terms of making the designs themselves, I knew I needed the name of the doctor as well as the address and a photo, however when seeing the other design on the internet, I knew it made sense to include the rating as well as the Doctor’s Specialty since it gives more detail to the user and helps them make a quicker decision.
The photo on the left is the Doctor’s daily schedule. It is split between Time and Events to make it more structured. The longer the event, the bigger the box will be. When the event is complete, that section of the page will be grey and no longer have color, giving the idea to the user that anything before the color is done and does not need to be worried about.
The photo in the middle is the patient's reports. Every patient will need a report to be done based on the appointment he just had. The reports that are completed have a green button on the top right whilst the ones that are still due have a red box meaning it needs to be done.
The image on the right is the list of the Doctor’s patients, if he wants, he can call them or shoot them an email.
The stock report was a very interesting challenge for this part of the module. In all honesty, prior to completing this screen, I had no idea what a stock report even was, so I turned to look at my best friend, Google. After browsing for roughly 1 hour, I had a solid idea as to how the stock report was meant to be structured and went straight to work by sketching out a plan.
This is the orders screen that the pharmacy owner see’s. There are 3 tabs:
New orders:
The “New orders” screen shows the new orders that have arrived. There is a button for further details as well as a button for dispatching the items.
Pending:
The “Pending” screen shows the orders that have been dispatched and are now pending . In green it shows the estimated delivery and in orange it shows estimated collection. Putting different colours helps differentiate the two.
Completed:
The “Completed” screen shows the orders that have been completed. It shows the day the delivery arrived and details of the product incase the customer calls asking about the product they bought in their last visit.
Invalid stock:
When an order comes of the product which is not in the stock of the pharmacy, the system will mark it red. After clicking on the details(red detail button) the system will ask for the alternate order.
When the product is unavailable, the system will ask the pharmacy owner for the alternate order and provide options “Yes” and “Back”. If the pharmacy owner doesn't want to suggest an alternate order he can press the back button and if he wants to suggest the alternate order he can press Yes button.
Pharmacy owners can suggest the alternate medicine or same salt or formula which he thinks would be better for the patient.
When the pharmacy owner clicks on the “Yes” option the system will show the list of medicine from where he can select other medicine and send a request of this alternate medicine to the doctor so that he can accept it and will proceed according to it. The following screens will show this process.
When an order is placed, both the patient and the Pharmacy owner will be able to see where the product is and have the ability to track it.
iOS/Android
Product Designer, Data Analyst
Figma
Create an application that helps patients identify exactly what sort of problem they are having prior to visiting the doctor.
We wanted to design a new app that allows patients to identify exactly where they are feeling what type of pain prior to visiting the doctor. The challenge was that patients often have to attend the doctor and consult about the issue during the appointment. Wouldn’t it be better to pinpoint the exact problem beforehand to allow the doctor to know what to do in advance?
On top of all that, the app must have the ability to allow communication and services to be handled between Doctors, Labs, Patients and Pharmacies.
The client gave me a document of how each section would function, throughout this case study, I will mention exactly what was written in the document and how I executed it.
For Redesign
I tried to get an understanding of what the competitors were doing with ideas like this, however I only got as far as finding an app called “Geopain” which had a very similar idea but weak usability. Since the client mentioned that he wanted users to see their blood sugar levels and other statistics, I immediately had an idea as to how he wanted the home page to be and went for apps with similar interfaces. The apps I gathered were Water intake apps.
Throughout the creation of the redesign, I conducted usability tests by having participants use both versions (before and after). This helped me get live results and an idea as to what users were preferring and why. To avoid biased results, I did not mention that I personally created the interfaces.
The patient view in Termardar is pretty much where the majority of users will be. Whilst the app will be used by other people such as Doctors, Pharmacy owners, etc. The vast majority of users will be patients therefore I had to focus on making it look as simple as possible.
The photo on the left is the statistics of the patient including body fat percentage, water levels/intake, Glucose levels, Blood sugar levels and cholesterol levels. The screen on the right is the categories of the app, If the user wants anything, it's all in that view pretty much. I thought it was a good idea to make the boxes big with larger photos inside mainly because people tend to understand the story quicker when there is a picture to it.
The client told me that he wanted the home screen to be a body to be filled with water indicating the water intake level. However I discussed with him that if we want to make the design focused on the app purpose, we’re avoiding a “Water intake” app design and stick to anything related to the medical field. He agreed on the idea and I still executed it without compromising the water intake percentage.
I wanted the pain identification to be quick and swift. When I was a child, coloring books was the easiest thing for me to do, therefore I thought highlighting the area of pain would be just as simple for a patient.
> The process:
When making the booking process, I obtained some ideas by looking at other designs such as “Calendars” and “Booking” apps. It was mostly inspiration from google rather than other apps.
> The process:
It was important that I made further steps not filled so the user has an idea as to how the structure of booking the appointment works.
Problem & Solution: I wasn't entirely sure how I was going to implement the booking system as well as the doctor’s profile on the same page.. I brain stormed different ideas and came to a simple classic solution (Which I should have thought of earlier) and that was the toggle box option. In summary it allowed me to put 2 sub screens in 1 big screen meaning that the patient would not feel as though he's on an entirely separate page that has a different purpose.
A page needed to be done for the patient/user to have the option to check anything such as his doctors, pharmacies, payment options, etc. I realised there was a lot that the patient would need to check, but I also wanted things to be as compact as possible rather than including tab bar space.
I had a deep thought and remembered different apps such as ebay would have a section where it says “My orders, My wishlist, etc”. With that in mind, I wanted to implement something similar and came up with this design.
This design reminded me a lot of a previous project I made called “Find a Player”, I used the same concept and believe it was executed fairly swiftly.
I didn’t encounter any problems making this page, I knew exactly how I wanted to lay it out and went to work straight away. I used a few inspirations from apps such as Uber and Badi, but apart from that, all went swift. Users can filter their search in a click of a button or even type out a search themselves. On the right is the list view, I mentally split the boxes in half, on the right is the CTA and the doctor reviews (The more important info) and on the left is the picture of the doctor as well as the view profile button.
The communication screen goes for all users in the app (Patients, Doctors, Pharmacy owners, etc). Doctors will have a slightly different view to other users, they will have 2 tabs “Patients” and “Assistants” to help them differentiate since they are required to work quickly.
I made the design fairly similar to the app “Whatsapp” since it is an app that people use almost on a daily. People like using stuff that they are already used to and dislike having to figure out how new apps work.
I encountered no problems when making this page.
When an appointment is complete, the patient will receive a report as to how the appointment went, the statistics and what medicines he will need to order.
I layed it out as follows:
Having the details of the patient on the top along with a color saves hassle for the doctor as well as the user. It will have a background of a color they like making the user feel more special and have a sense that it belongs only for him.
Having icons near the name of the tab helps differentiate for users wanting to read quickly.
Lastly, in the prescription tab, people would much prefer to see an image of the package/product along with the name of it rather than just seeing the name. Prescription names can often be overwhelming so having an idea of how it looks helps everyone.
Requirement 6: Ordering medicines
When receiving a report, some patients will be required to order some prescriptions. There is an order icon within the prescription box. To have everything easy and straightforward for the user, he will only need to click on that which takes him to a page that shows all available pharmacies within the area that have that.
In blue is an indicator that stock is sufficient inside that pharmacy, whilst written in red is stock that is limited for that pharmacy. This allows the user to make a better decision to what store to travel to incase it gets purchased.
Users can also filter pharmacies by the distance, rating, etc.
Requirement 6: Ordering medicines
When receiving a report, some patients will be required to order some prescriptions. There is an order icon within the prescription box. To have everything easy and straightforward for the user, he will only need to click on that which takes him to a page that shows all available pharmacies within the area that have that.
In blue is an indicator that stock is sufficient inside that pharmacy, whilst written in red is stock that is limited for that pharmacy. This allows the user to make a better decision to what store to travel to incase it gets purchased.
Users can also filter pharmacies by the distance, rating, etc.
Requirement 7: Payment
Payment module handles all the invoice details and how the patient will pay his/her dues.
This is the main screen of the Payment module.
This module handles two kind of information
Right now, on this screen invoices are selected. All the details of the invoices are shown below in the list.
Options
If the user selects “Options”, then the following screen will display.
This screen allows users to add new payment methods or choose their most desired payment method.
Patients can add a new payment method by pressing the “+” button on the right side of every method.
Add Card
On this screen, patient can add the following card details
After adding all the details of the card, there is a button of “ADD CARD”. After pressing this button, the card will be added as a payment method.
Pay
After adding card details, the user will be able to pay the invoice.
I designed this with a lot of trial and error. I wasn’t sure what to put at first, but after browsing around for different invoice examples, i came to the conclusion that the following was suitable to note down:
I put total and invoice number in blue since it is information that users look at the most.
The Doctor View is what the doctor will see when accessing the app. It includes the Doctor’s daily Hospital schedule(What patients at what time), the patient reports, the list of patients, and the doctor assistants.
When a patient books an appointment and the doctor accepts it through the notifications tab, it will automatically be placed into his schedule on the home screen.
The doctor would be able to select different dates and see what is going on that day. There is a small dot indicator on the left of the screen alongside the time; this displays the progression of the day, when an appointment is complete, it will be filled in blank giving the doctor a relax in the mind showing that it is now completed.
Communication for the doctor to any other users on the app has been discussed in the “Communication” tab in the patient module.
Reports/prescriptions for the doctor to the patients has been discussed in the “receive reports” tab in the patient module. However, if the doctor wants to review reports he has completed himself, in the second image above, there is a drop down box where the doctor can select “Today”, “Reports” or “Patients”
In the reports section, the doctor will see in either green or red towards the right of every previous patient whether he has completed the report or not. Having them highlighted in red or green indicates whether the doctor has to do it or not.
If need be, the doctor could book an assistant that has different experience compared to the colleagues that are currently around him. I made it so that the doctor could sort by the rating, distance, etc and even search for a specific sort of assistant.
The booking process looks exactly the same as the booking for the patients with the doctors being able to check the Assistant’s profile and select a time that suits them both.
In terms of making the designs themselves, I knew I needed the name of the doctor as well as the address and a photo, however when seeing the other design on the internet, I knew it made sense to include the rating as well as the Doctor’s Specialty since it gives more detail to the user and helps them make a quicker decision.
The photo on the left is the Doctor’s daily schedule. It is split between Time and Events to make it more structured. The longer the event, the bigger the box will be. When the event is complete, that section of the page will be grey and no longer have color, giving the idea to the user that anything before the color is done and does not need to be worried about.
The photo in the middle is the patient's reports. Every patient will need a report to be done based on the appointment he just had. The reports that are completed have a green button on the top right whilst the ones that are still due have a red box meaning it needs to be done.
The image on the right is the list of the Doctor’s patients, if he wants, he can call them or shoot them an email.
The stock report was a very interesting challenge for this part of the module. In all honesty, prior to completing this screen, I had no idea what a stock report even was, so I turned to look at my best friend, Google. After browsing for roughly 1 hour, I had a solid idea as to how the stock report was meant to be structured and went straight to work by sketching out a plan.
This is the orders screen that the pharmacy owner see’s. There are 3 tabs:
New orders:
The “New orders” screen shows the new orders that have arrived. There is a button for further details as well as a button for dispatching the items.
Pending:
The “Pending” screen shows the orders that have been dispatched and are now pending . In green it shows the estimated delivery and in orange it shows estimated collection. Putting different colours helps differentiate the two.
Completed:
The “Completed” screen shows the orders that have been completed. It shows the day the delivery arrived and details of the product incase the customer calls asking about the product they bought in their last visit.
Invalid stock:
When an order comes of the product which is not in the stock of the pharmacy, the system will mark it red. After clicking on the details(red detail button) the system will ask for the alternate order.
When the product is unavailable, the system will ask the pharmacy owner for the alternate order and provide options “Yes” and “Back”. If the pharmacy owner doesn't want to suggest an alternate order he can press the back button and if he wants to suggest the alternate order he can press Yes button.
Pharmacy owners can suggest the alternate medicine or same salt or formula which he thinks would be better for the patient.
When the pharmacy owner clicks on the “Yes” option the system will show the list of medicine from where he can select other medicine and send a request of this alternate medicine to the doctor so that he can accept it and will proceed according to it. The following screens will show this process.
When an order is placed, both the patient and the Pharmacy owner will be able to see where the product is and have the ability to track it.
A mobile app where you can listen to your favourite podcasts all within the same app
A website dedicated to managing the rental of an apartment, including an associated app for additional services
An app for gym users who want to track their reps and weight they used on different lifts.
A mobile app where you can listen to your favourite podcasts all within the same app
A multi platform app designed to take the pain out of organising and finding players for sports, games & events.
