Digitizing a Healthcare Market

by Taivara, Technology Innovation

Burdened by Paper

A startup came to Taivara with an idea.

Organizations that provide care for the developmentally disabled ran almost entirely on paper. Every activity that care workers did, every medication they gave, every hour they worked had to be recorded in a binder full of information. At the end of each week that data would be entered into a computer system.

The issue was that these care providers lived highly active lifestyles. They took consistent trips to the zoo, park, pool, etc. Carrying a binder greatly hindered their ability to provide care for their consumers, and all the data entry took hours of people’s time each week.

There has to be a better way!

Why carry a binder when you already carry a smartphone? Why write when you can tap? Why convert paper data to digital data at the end of the week when you can do it on the go?

The solution was clear. The implementation? That’s where Taivara comes in.

The startup handed Taivara a typical binder and said, “Turn this into an app design.”

The Startup Catch-22

The startup was in its earliest stage at the time. To be frank, they simply didn’t have the budget to build a fully-functional product.

The startup was stuck in a catch-22. They couldn’t get customers without a product to show them. They couldn’t build a product until they had investment. They couldn’t get an investment until they had customers.

Luckily, we had the solution. Without writing a single line of code, we created a prototype that would look and feel like the real deal. Doing so gave us the ability to put the product in the hands of our customers while only spending a fraction of the budget.

Don’t Judge a Book by its Cover

The mobile app was just the surface. The reporting was easy, but in order to make it a proper product, it needed a proper client management and billing system. One that can be spun out to a new customer at the drop of a hat. Customers would need to handle their clients’ schedules, medications, and service plans in a simple-to-use display. All that information would need to talk to the mobile application and be stored safely and securely…

Not a problem.

Not Your Typical UX

To get the mobile user experience right, we had to understand the context. Typical UX principles like user acquisition and retention had to be thrown out the window. The job of our user was to provide optimal care for the client and properly record it, not play around on their phone. They only needed to get in, get out, and get back to work.

Many of our users were not native English speakers and, therefore, needed an intuitive UX that maximizes the use of the universal language: the tap.

Asking the Right Questions

When we finished the prototype, we had to see how the market would react. We conducted in-depth-interviews for our client with their potential customers.

The goal: Understand what elements of the product they thought would and wouldn’t work. The key was to understand the true needs of the customer by diving deep into their current processes and needs. Rather than simply build a feature they asked for, we had to understand what they were truly trying to accomplish and come up with a solution.

The Reaction

Overall, the customers loved the product. They all agreed the product would save them tons of time and money.

They all committed to purchase the product once it was available and a few design tweaks were made. Our client had broken the catch-22.

The First Round

The committed customers sparked the attention of investors. Realizing its potential, they gave the startup their first round of investment.

Money in hand, the startup returned eager to start the build.

Time to Build

Even though our client was funded, we still had to ensure we were using our time and their money wisely.

Building a mobile application takes time. Typically, mobile apps have to be built twice. Once for iOS and once for Android. This application needed an extensive API back-end as well for customers to manage their data.

We decided the most cost-effective approach would be to develop the product with a Ruby on Rails back-end and a React Native front-end.

Rails allowed us to quickly get the API up and running. It gave us the ability to use a lot of “out-of-the-box” technology rather than building functionality from scratch, saving our client a lot of money.

React Native allowed us to build one mobile app instead of two. We were able to export the React Native app to both iOS and Android saving us time and our client, even more, money.

Need help bringing your next digital product to life?

Be our next case study

Share This