React Data Management Web App
User experience design and development of React data management web app
Expertise
Iterative Development, UX Design, UX Research
Client
The National Kidney Foundation of Michigan
Timeline
6 weeks
Challenge
The National Kidney Foundation of Michigan needed a way to improve the efficiency of its data collection from coaches.
Its coaches were collecting data and submitting the stats through spreadsheets manually, but it wasn’t always on time.
How might we design of a system for diabetes prevention so that coaches can coaches can easily submit data?
Scope
The scope of this project was to create a portal site for NKFM coaches that would be integrated in some way with their main site. It also needed to be compatible in some way with the ACCESS database they used for data collection.
Constraints
Our constraints included budget, tech stack and timeline. As a non-profit, the organization received a grant for the project and the project needed to fit within that budget. The database needed to be secure. We were also asked to complete the bulk of the build in 6 weeks.
Implementation
We developed a phased process in order to speed up our timeline and meet the constraints of the project. This included splitting our development over two phases and overlapping the first with our design work.
Our Goal
Our goal was to design and develop the architecture of a portal that coaches could use to enter data.
Our Solution
The portal 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.
Results
The portal has provided an opportunity to streamline data collection from coaches in the field.
NKFM staff rolled out the portal in phases, ensuring that coaches had adequate training for using the portal. We worked with the team to make UI tweaks the coaches found confusing. Overall, feedback from the coaches has been positive.
Our Process
Understand
The RFP process and initial discussions with the stakeholder gave us a clear idea of what we would be designing, but we still needed to know more before we could design.
Stakeholder Interviews
We started the project with a discovery kickoff between our team and the stakeholder team. Since we would be designing the technical architecture with the technical lead as well as the overall design of the apps themselves, we 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.
Explore
Technical Architecture Design
Once we had an understanding of the technical environment and needs, we were able to explore the potential solutions.
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. 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.
System Architecture Diagram
System Architecture Diagram
Environment Diagram
Tasks and User Flows
Following approval of the system architecture design, the 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.
Admin User Tasks
-
1
Add workshops
-
2
View submitted data
-
3
Export data
Coach User Tasks
-
1
View workshop
-
2
View participant data
-
3
Add or edit participant data
-
4
Submit data
Admin User Flow
Coaches User Flow
Validate
Iterations
We revised both user task flows after internal testing and discussions with the client. On the admin side, she realized that it would be much easier not to require the admins to add each workshop manually. The 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. We 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.
On 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.
Revised Admin User Flow
Old Design
New Design
Revised Coaches User Flow
Old Design
New Design
Design
Now that we knew how users would be interacting with the applications, we set up an ideation session with the team to think through layouts for data collection.
It’s easy to get lost in tables but needed the collective ideas of the team to think through all of the possibilities.
Wireflows
We created wireflows on the whiteboard to think through the screens needed for each section of the apps and provide direction for how to move forward with wireframes. These flows were part sketching and part wireframing.
Whiteboard Sketches
UX Wireframes
We designed each of the primary screens for the flow and asked for feedback from the developers as we went. The styling was to come directly from the CSS used on the Diabetes Prevention Program website, so there was no need to use a style tile. Instead, we referred to the major components for how elements would display.
Wireframes
Validate
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 prepared in Invision. Each of the coaches was located in Michigan, 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.
- 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?
- You are on the coaches’ home screen and you need to edit a session date because of an upcoming conflict. Where would you click?
- 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?
- You realize you need to input data for Session 18-AB and submit to the program admin. How would you do that?
- What are your impressions of the screens?
- What are your feelings after using it?
- 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, we revised the 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’ session screen were not enough. We added an additional label to indicate that the data was in a review or that is was sent back for editing.
Additionally, some changes were made on the admin side to clarify where admins should edit workshop data.
Create
Once the design was revised and approved, we began the core build of the portal.
Tech Stack
The portal was built using React and a .NET core. For both sides of the app, we imported the style sheet from the main site in order to retain the branding already in place.
QA and Beta Testing
We worked closely with the client to test and retest the portal. The data submission process was core to the design, and multiple users were invited to try the process. We also spent time tweaking the import and export process so that the data could be added to Access.
The client was careful to train and gradually roll out the portal to select coaches would could provide feedback over time.
Key Learnings
This was an extremely rewarding project, and we learned a lot. One key takeaway was that the timeline was not realistic. While we came close to delivering the portal within the six weeks, we needed additional time to fine tune and polish. the client understood this change and appreciated out honesty.
