SaaS Product

Overview

This year the company took on a new endeavor to make our platform available as a SaaS product. This way we can give our clients complete control of producing instances of our product based on rules they create according to their specific needs. Components of our software include rules engine, correspondence module, form builder, and events manager. This way we could spin up brand-agnostic instances of our support portal, HCP portal, and patient app.

Since all of these were new components I had to work closely with product and development to define how these components work and what the UI could be.

Rules Engine

The product is all centered around a “rules engine” where users define triggers and actions they want to happen when a conditions are met. Creating the UI for the rules engine was a challenge since there were so many moving parts. My goal was to create an interface that the user could easily understand and always orient themselves in the process. I also had to keep in mind that our users wouldn’t always be technically savvy, so it was important that the UI clearly explained the process.

I started this process with a remote whiteboarding session with the product owner where we defined the steps that would be included in the process and reviewed existing examples I found from internet searches. The examples that I found all seemed to be overly complicated or overly simple for our purposes so I went to work on creating a UI for a complex process represented in a simple flow.

I represented the process in three chunks: the rule, the trigger, and the action.

To help others understand the flow of the rules engine I created a user flow presentation.

Form Builder

Our software also called for the need to send out forms to collect data whether it be patient’s information through patient registration or creating questionnaires to send out to patients regularly through their patient app. The form builder was to be created as a drag and drop module where the user could create new form fields that they defined, or used existing data inputs to pipe into the form.

Patient App Brainstorm

In addition to the administrative portals, we wanted to create a patient app that would have reusable components that get turned on and off depending on the needs of the program. To get a full idea of all the features we would offer I ran a remote brainstorming session using the applied user story mapping to help us think through a patient’s typical journey and define what features we could offer that would benefit them at different touchpoints.

Patient App Design