NKFM Coaches App and Admin UX

Design of system for diabetes prevention coaches to submit info

Design Summary

The National Kidney Foundation of Michigan contracted with Standard Beagle to create a portal system for its diabetes prevention program coaches to more easily submit data. Working with my team, I designed the architecture of a portal that would have an app on one side where coaches would enter data, a central database, and also an app for administrators to receive and download the data.

My Role

• Project Manager
• UX Designer

Design Process

Discovery research

The RFP process process and initial discussions with the stakeholder gave me a clear idea of what we would be designing, but I still needed to know more before I could design. We started the project with a discovery kickoff between our team and the stakeholder’s team. Since I would be designing the technical architecture with the technical lead as well as the overall design of the apps themselves, I needed to understand how all of the pieces would work together. We peppered the stakeholder and head of IT with questions to understand their internal server structure, HIPAA requirements, and how coaches were currently submitted data. Since data also needed to be reported to the CDC, we had to understand how the client would ideally be collecting data.

The constraints we faced included budget — as a non-profit, the organization received a grant for the project —  and the database, which needed to be secure.

Technical architecture design

The client had all of its data in an internal Access database. Direct access was not possible — the cost and effort would have been too great for the budget and it wasn’t necessary to meet the MVP. The simplest way to build a system to submit data was by building two applications connected to a central database. on one said, admins would upload initial information for a workshop, including the coach, participants, and sessions. On the other side, the coach would enter the basic data needed, then submit it. The admin would be able to review the data and export it to add to their Access database.

We recommended using Microsoft Azure, which met the security requirements. Both the coach and admin interfaces would be single-page applications, built in React, using GraphQL backend.

Task and User flows

Following approval of the system architecture design, my next task was to design the user task flows for both the admin user and the coach user. Each user type had specific tasks it needed to be able to accomplish.

I revised both user task flows after internal testing and discussions with the client. ON the admin side, I realized that it would be much easier not to require the admins to add each workshop manually. My admin flow focused instead on importing a spreadsheet with all the data in the correct form and then allowing the admin to edit any information needed. I also needed to make sure that this data was viewed and approved before it was sent to the front end. Admins would be able to hold workshops and then publish later to ease their workflow.

One the coaches side, the client explained they needed a way to allow coaches to edit dates of sessions, just in case of a snow day or a need to reschedule for holidays. Also, when the data was submitted, we wanted there to be a flag so the admins would know that new data was sent.

 

Team Whiteboarding

Now that we knew how users would be interacting with the applications, I set up an ideation session with my team to think through layouts for data collection. It’s easy to get lost in tables, but I wanted the collective ideas of the team to think through all of the possibilities.

UX Wireframes

I typically sketch out wireframes before I digitize them, but this time I started in Balsamiq. Why? My dominant arm was in a sling after undergoing shoulder surgery, and I was much faster using a mouse and keyboard with my left hand than using a pencil. I designed each of the primary screens for the flow and asked for feedback from the developers as I went. The styling would come directly from the CSS used on the Diabetes Prevention Program website, so there was no need to use a style tile. Instead I referred to the major components for how elements would display.

User Testing

Fortunately, despite the budget constraints, the client agreed that user testing would be beneficial to include in the project. The client helped recruit six program coaches to test the wireframe prototypes I prepared in Invision. Each of the coaches was located in Michgan, so we leveraged Zoom to conduct and record the tests. Our goal was to answer this question:

Are users easily able to easily save and submit data to program administrators?

Evaluation Criteria

The following criteria will be used for evaluating the proposed solution:

• Does the user understand how to navigate through the screens?
• How fast does the user learn to use the interface so they can accomplish basic tasks?
• How often do users make errors using the website, how serious are the errors, and how does the user recover?
• Does the user like using the portal?
• Can participants see UI elements (font size, text area)?
• Are clickable elements the appropriate size for participants?

Testing was conducted here: https://invis.io/MESMO4XWNRG#/370035241_Current_Website-Button

Testing Scenarios

Because the wireframes designed for the site only represent a small fraction of the pages that will eventually be developed, the scenarios that will be tested are intentionally designed to be open-ended and to gather honest feedback and insight from participants.

1. You are a DPP coach entering the portal for the first time. You have been provided a username and password from program administrators. How would you go about logging in?
2. You are on the coaches home screen and you need to edit a session date because of an upcoming conflict. Where would you click?
3. You are back on the coaches home screen and would like to review Amy A’s data from Workshop 18-AB. How would you do that?
4. You realize you need to input data for Session 18-AB and submit to the program admin. How would you do that?
5. What are your impressions of the screens?
6. What are your feelings after using it?
7. Can you describe any elements that might be missing?

Feedback was positive. Most participants were easily able to follow the user flow. The main feedback was to make additional labels for data submissions status and improve the clarity of the data submission box.

Client and User Iteration

Using the feedback from the user testing, I revised my wireframes and submitted them to the developers to build out the applications.

Some changes were made throughout the development process. For example, we discovered that the additional labels we added to the coaches sesssion screen were not enough. We added an additional label to indicate that the data was in review or that is was sent back for editing.

Additionally, some changes were made on the admin side to clarify where admins should edits workshop data.