QIS App

Designing and validating tools to help save time and money

The Quality Improvement Solutions (QIS) app helps organizations in Health and Human Services be more efficient with compliance tasks by replacing paper based processes with digital tools.

My Role

I was part of a small team of collaborators that assembled to invent and deliver a solution. I was responsible for the user-research, interaction design, and visual design for ‘QIS’—a web‑based application for ILC (Integrated Life Choices).

The Challenge

The project originally started when Integrated Life Choices (ILC) approached us to help them excel in their ability to acquire and manipulate data related to their practice. Organizations are required to document the quality of service they provide through Quality Assurance (QA) checks to make sure they are meeting certain requirements and standards. 

QIS became a Software as a Service solution to ILCs original problem. QIS would help organizations by assisting in the process of capturing data, alerting them of opportunities, providing tools for data analysis, and archiving the data.

This involved designing a mobile app that could be used on location to obtain data and designing a web platform that could interface with that data.

Goals, Capabilities, & Features

To properly identify what we needed to build we used abstraction laddering techniques. We started with a very abstract “Goal” of the product and moved further into a concrete solution by breaking down capabilities of stakeholders. From those capabilities, we could start identifying features to be built.

You can navigate your way down the ladder (ie: from a goal to a capability) by asking ‘How?’. Likewise, you navigate your way up the ladder by asking ‘Why?’.

An element is the smallest piece and the most concrete. Elements are things like buttons, paragraphs, links, etc. A collection of elements comprise a component. Multiple components working together become a feature. Multiple features work together to achieve a capability. Capabilities are abilities stakeholders must have in order to meet their goals.

So let’s break this project down:

Goal

The purpose of this project is to support the activities of ILC staff that improve the quality of life of their clients. The Quality Improvement (QI) goals they have set to help fulfill this purpose are:

  1. to increase the number of potential QI opportunities that get identified,
  2. to increase the number of approved QI opportunities that get completed, and
  3. to reduce the amount of time needed between identifying and completing QIs.

The following are the capabilities that ILC staff need to have to achieve these goals.

Capabilities

  • Collecting Information - need the ability to collect data
  • Securing Information - need the ability to assure the security of the data collected
  • Viewing Performance - need the ability to view and analyze the data
  • Reporting Findings - need the ability to export and share the data
  • Monitoring QI - need the ability to identify quality improvement opportunities
  • Maintaining System - need the ability to assure the quality of the system and guarantee access
  • Empowering Customers - need the ability to obtain and empower new customers

Features & Feature Sets

Each capability has a collection of features that work together to allow the stakeholder to complete that ability.

Features with the tool icon were developed as end-to-end tools in the system. Features were also color-coded to keep track of whether or not it was completed, in progress, unfinished, or a future iteration. This allowed us to identify the value being provided as well as understand what features were absolutely necessary for an MVP.

The Approach

Throughout the project we conducted a series of interviews all using prodding questions about current strategies and workflows. This approach was necessary to understand the reasoning process a typical user from ILC might use. It was also our only available method due to the confidential nature of the company’s work.

This allowed us to quickly understand the day-to-day challenges of service professionals and managers. From these results, we created personas. A persona could give us a glimpse into the kind of user that might be using a tool and how that tool could enhance their ability to do their job.

Sketching Interfaces

Instead of formally wireframing, I opted to sketch them on paper. I used paper prototyping techniques to bring the designs to life and evaluate them with our users. This helped me work rapidly and led me to consider more ideas & validate them in interviews. Sketching also gave me an opportunity to visual the user flow and quickly problem solve by observing how a user would interact with the structures I was creating.

Mockups

I used Sketch to create hi fidelity mockups to validate the product with stakeholders and act as a visual reference for development. Below are UI mocks for the mobile app.


I also used Principle and FramerJS to crudely prototype interactions that became difficult to explain. This approach was beneficial in showing stakeholders design ideas for validation, or for explaining animations to our developer.


Scenarios

In order to effectively communicate with the developer, I laid out powerpoint slides that broke down the design decisions from the abstract capability that was being served to the concrete interface. The slides walk through each component, explaining the UI and outlining the constraints for the interaction.

Scenarios were a great way to use language to create constraints on the design. I wrote constraints in the ‘Given X, When Y, Then Z’ form of Behavior Driven Development. Using these constraints, our developer knew how elements were supposed to work, and could write test that validated each scenario.

One of these was created for each feature we developed. Below is an example from the Data Viewer feature:

Prototyping and Usability Testing

I worked closely with the developer to bring our designs to life as a working prototype. Communicating requirements face-to-face and discussing constraints and possibilities with the aide of the slides I created was an effective means to prototype quickly.

Our dev cycle was two weeks long. So each feature (ie: Data Viewer from above example) was completed within that timeframe. The design was done in the first week of the cycle and the development was done in the second week. We reserved Friday and Sunday as our “Handshake” days. We preferred using the term ‘Handshake’ instead of ‘Hand-off’ because it more appropriately identifies our collaboration. Handing things off isn’t collaboration, it’s cooperation.

Staggering our production like this also meant very little downtime. I would be designing for the next feature while the developer was programing the last one. We worked in the same room which meant we were both always available to each other.

We worked collaboratively, tested constantly and iterated progressively.

Introducing QIS

QIS is mobile app paired with a web-based tool that helps organizations in Health and Human Services be more efficient with compliance tasks by replacing paper based processes with digital tools.