Secure Chat App

I interned at a healthcare software company in Maryland in Summer 2017. I was asked to design features for their secure chat app to incorporate a support ticket mechanism within it.

Problem Statement

One of the company’s large clients had service agents who used to get around 50,000 support calls a month. They needed to replace these calls with “support chats”, incorporated within the company’s secure chat application for web and mobile.

Users and audience

The target users of this feature are called case-managers, who work in the healthcare industry and take care of a patient’s rehabilitation needs once they are out of an active health procedure/treatment.

Team and my role

I worked as an intern with a professional UX designer on this project. The designer took a hands-off mentoring approach in order let me learn the entire end-to-end design process in a professional setting. I performed user research, drew up wireframes for potential solutions, discussed solutions with managers, developed high-fidelity prototypes in Adobe Photoshop, tested these prototypes within the company, and refined the prototypes based on what I learned from the user tests.


This was my first exposure to the healthcare industry. In the United States, the domain knowledge required to work in healthcare is exhaustive. Gaining the right amount of knowledge required to successfully deliver this product within the timespan of a short internship was the biggest challenge for me.
Another challenge was the fact that within this short time, we could not arrange meetings with actual case managers to test out our designs.

Design Process
Research/Business Analysis

I was tasked with this project in a vast domain I was completely new to, did not have a lot of time to grasp, or direct access to our target users. These were the steps I took to gain an understanding of the system I was going to design:

  • • Understand what Case managers do
    I did an extensive research on what case-managers do on the Internet, including various types of case managers, what their duties are, who they usually work with, etc.
  • • Gain knowledge from colleagues (aka use what you have)
    The company had several former healthcare employees working for them, and among them were former case managers. I went and talked with them about what they did, what a typical day looked like, pain points, and examples from their work life. I also understood the detailed business requirements for this functionality from my managers.
  • • Study the existing application
    Next, I gained as much information as I could about the chat application I was building for, including a complete walkthrough of the application on both, iOS and Android, and understanding how the client used our application.
  • • Persona Creation
    I discussed what I’d learned from my research with my mentor, and we began discussions on what our personas would be. We created two diverse personas and sketched out workflows for both of them, highlighting specific pain points for each flow. Finally, I presented my work to the internal team, so I could refine my understanding based on their feedback. I am not allowed to publish high-fidelity versions of my personas on my website due to the terms of my employment agreement.
Designing wireframes

I designed 2 workflows for how this functionality should work. My first idea was for a “chatbot interface” that would work in a conversational way to connect the case manager to a service agent, with the UI functioning the way voice assistants like Google Assistant or Siri work. I decided to go with this approach for these reasons:

  1. In 2016, data showed that messaging apps had more monthly active users than social networking apps, indicating how commonplace these apps have become. Having a conversational interface would make it instantly familiar to anyone using chat applications like iMessage or WhatsApp, and the voice assistant on their phone.
    I did an extensive research on what case-managers do on the Internet, including various types of case managers, what their duties are, who they usually work with, etc.
  2. This interface could closely mimic a real service call.
  3. Data has also shown that 89% users would prefer to engage with an AI-bot in order to speed up finding the information they require.

After some ideation and exploring, my second approach was a traditional wizard-form based approach that would get the required preliminary information from the case manager and connect them to an appropriate agent. These are some of the wireframes I drew for both the approaches:

High-fidelity prototypes

After refining the wireframes with feedback from my manager, I created high-fidelity prototypes of both my solutions in Adobe Photoshop (my work machine had Windows 7 - so no Sketch/Adobe XD). I then imported my prototypes in InVision so I could create clickable prototypes for user testing. I chose to create prototypes for the Android version of the app, so I could learn more about material design and Android interaction patterns. I cannot post my high-fidelity work for this project in my portfolio, as my employment contract with this company did not allow it.

User testing

I created a plan for user testing with my mentor, where we decided the kind of user-testing we would perform, with whom, and which tasks we should test. We tested the prototype with 5 participants within the company, using the think-aloud method. I iterated my prototype based on what I observed in the user testing. Here’s the whiteboard after I was done planning my testing:

User testing whiteboard
Retrospective and lessons learned

  1. As a designer, sometimes all the details for your next assignment may not be clear initially, but you can make them clear by proposing solutions based on user research and data.
  2. From my data, younger populations seemed to prefer chatbot interfaces, older ones seems to prefer a regular forms-based UI.
  3. The realism of a clickable prototype has to be managed well. Some participants in user testing will expect each screen to be mocked up, and each detail to coincide between screens.
  4. Bolder call-to-action buttons are quite important. Also, people tend to not read informative text, even if it’s in a contrasting color.
  5. I learned about designing for Android and subtleties of Material Design.
  6. People really like how user-friendly a Google Assistant like chatbot interface can be. This is mostly because the quick options at the bottom minimize user input by replacing the need to type an entire message vs tapping a single button. It also decreases the chance of a user entering in an input the bot wouldn’t understand. Here’s an example of the Google Assistant interface:
Google Assistant screenshot

This was my first professional end-to-end UX design experience and I learnt a lot of great things along the way. I am grateful for having got this wonderful internship experience.