Processed

Background

Background

PROBLEM

Problem

  • Manual workflow 
    Doctors called customer support team to request, activate or deactivate tokens
  • Time-consuming
    Customer support team dedicated substantial time and efforts in token management activity
  • Error-prone
    Vital details communicated over the phone, which increased human errors
  • Manual workflow 
    Doctors called customer support team to request, activate or deactivate tokens
  • Time-consuming
    Customer support team dedicated substantial time and efforts in token management activity
  • Error-prone
    Vital details communicated over the phone, which increased human errors

SOLUTION

Solution

Designed a token management dashboard for the medical providers that include features like: 

  • Request a new token - hard or soft token
  • Edit mail and e-mail addresses for token delivery
  • Activate or deactivate tokens
  • Cancel or replace tokens

Designed a token management dashboard for the medical providers that include features like: 

  • Request a new token
  • Edit mail and e-mail addresses for token delivery
  • Activate or deactivate tokens
  • Cancel or replace tokens

Designed a token management dashboard for the medical providers that include features like: 

  • Request a new token - hard or soft token
  • Edit mail and e-mail addresses for token delivery
  • Activate or deactivate tokens
  • Cancel or replace tokens

DURATION

Duration

September 2019 (1 month)

Designed a token management dashboard for the medical providers that include features like: 

  • Request a new token
  • Edit mail and e-mail addresses for token delivery
  • Activate or deactivate tokens
  • Cancel or replace tokens

September 2019 (1 month)

ROLE

My Role

Product Designer

Product Designer

EXPLORATORY RESEARCH

EXPLORATORY RESEARCH

Interviews

Interviews

Conducted multiple one-on-one discussions with the product owner, product manager, and technical architect to understand current practices. 

Conducted multiple one-on-one discussions with the product owner, product manager, and technical architect to understand current practices. 

  • Medical practitioners who prescribe controlled substances are the primary users of these tokens
  • Third-party vendors develop and deliver tokens
  • Rely mostly on 3rd applications, and doesn't use System Admin(SA) much.
  • The team received a lot of phone calls to make modifications once the doctors raised requests.
  • Use the SA portal as an interface between the system and 3rd party applications.
  • Medical practitioners who prescribe controlled substances are the primary users of these tokens
  • Third-party vendors develop and deliver tokens
  • Rely mostly on 3rd applications, and doesn't use System Admin(SA) much.
  • The team received a lot of phone calls to make modifications once the doctors raised requests.
  • Use the SA portal as an interface between the system and 3rd party applications.
  • Medical practitioners who prescribe controlled substances are the primary users of these tokens
  • Third-party vendors develop and deliver tokens
  • Rely mostly on 3rd applications, and doesn't use System Admin(SA) much.
  • The team received a lot of phone calls to make modifications once the doctors raised requests.
  • Use the SA portal as an interface between the system and 3rd party applications.

PERSONAL OBSERVATIONS

The interviewees had several personal assumptions made for the existing architecture. I decided to document all the decisions for future enhancements.  
Since this project was a part of an audit process, it was necessary to prioritize certain areas and deliver an MVP before the audit

The interviewees had several personal assumptions made for the existing architecture. I decided to document all the decisions for future enhancements.  
Since this project was a part of an audit process, it was necessary to prioritize certain areas and deliver an MVP before the audit

DOCUMENTATION

DOCUMENTATION

User persona

User persona

Based on the data received from the interviews, I was able to establish some facts about the two primary users of this project: the medical provider and the support team. 

Based on the data received from the interviews, I was able to establish some facts about the two primary users of this project: the medical provider and the support team. 

Based on the data received from the interviews, I was able to establish some facts about the two primary users of this project: the medical provider and the support team. 

Medical provider

Medical provider

Artboard

Support representative

Support representative

Artboard_1

SUCCESS METRICS

Quick - For both, the doctors and the support (Calculation - time required to complete a process)
Smart - Automate the process wherever required, consider all edge cases 
Empowering - Allow the doctor to take hold of the token management process 
Cost-effective - Reduce support calls and in a way reduce efforts towards the process (Calculation - monitor the number of support calls towards token management daily)

Quick - For both, the doctors and the support (Calculation - time required to complete a process)
Smart - Automate the process wherever required, consider all edge cases 
Empowering - Allow the doctor to take hold of the token management process 
Cost-effective - Reduce support calls and in a way reduce efforts towards the process (Calculation - monitor the number of support calls towards token management daily)

DOCUMENTATION

DOCUMENTATION

DOCUMENTATION

User flow diagrams

Service blueprints

User flow diagrams

I started creating user flow diagrams in versions to communicate a clear understanding of product upgrades over time.

I started creating user flow diagrams in versions to communicate a clear understanding of product upgrades over time.

I started creating user flow diagrams in versions to communicate a clear understanding of product upgrades over time.

Old user flow

Old user flow

New user flow

New user flow

DOCUMENTATION

DOCUMENTATION

DOCUMENTATION

Service blueprint

Service blueprints

Service blueprint

As the product consisted of multiple actors(users) and 3rd party APIs, I collaborated with the system architect to accurately understand the technical functionality of the APIs and represented them along with the user journey to provide a holistic view of the system.  

As the product consisted of multiple actors(users) and 3rd party APIs, I collaborated with the system architect to accurately understand the technical functionality of the APIs and represented them along with the user journey to provide a holistic view of the system.  

As the product consisted of multiple actors(users) and 3rd party APIs, I collaborated with the system architect to accurately understand the technical functionality of the APIs and represented them along with the user journey to provide a holistic view of the system.  

Soft token flow

Soft token flow

Service_Blueprint_Soft token – 1@2x

Click on the image to open in a new tab

Hard token flow

Hard token flow

Service_Blueprint_Hard token@2x

Click on the image to open in a new tab

PERSONAL OBSERVATIONS

PERSONAL OBSERVATIONS

Service blueprint diagrams helped both front end and backend developers to get a holistic view of the product. 
Many suggestions were provided by the teams, for example: Include API names, flag names, etc.
Few members didn't understand a few intricate details included in the diagrams. I decided to add legends at the bottom to aid the teams to understand the diagram.

  • Service blueprint diagrams helped both front end and backend developers to get a holistic view of the product. 
  • Many suggestions were provided by the teams, for example: Include API names, flag names, etc.
  • Few members didn't understand a few intricate details included in the diagrams. I decided to add legends at the bottom to aid the teams to understand the diagram.

Service blueprint diagrams helped both front end and backend developers to get a holistic view of the product. 
Many suggestions were provided by the teams, for example: Include API names, flag names, etc.
Few members didn't understand a few intricate details included in the diagrams. I decided to add legends at the bottom to aid the teams to understand the diagram.

UX DESIGN

UX DESIGN

UX DESIGN

Low fidelity Sketches

Service blueprints

Low fidelity Sketches

VISUAL DESIGN

UX DESIGN

VISUAL DESIGN

High fidelity design

Service blueprints

High fidelity design

Below are some of the screens of the prototype.

Below are some of the screens of the prototype. Due to NDA, I cannot show the exact prototype of the entire system. 

Below are some of the screens of the prototype.