St. Luke's University Hospital Network Mobile App

Combining health records, appointments and virtual visit systems into one seamless patient app experience

The Story

At the time of engagement, St. Luke's University Health Network (SLUHN) had an existing app that allowed users to find doctors and office locations. Their goal was to expand the feature set to provide scheduling of appointments via Clockwise and doctor.com APIs, patient health records via Epic MyChart SDK, and virtual doctor visits via American Well SDK.

The project goal was to bring together multiple disparate systems and databases, while creating a seamless front-end experience for the end-users who interacted with app.

⁠—

My role on this project was to act as an agency-side product owner championing human-centered product decisions.⁠

Responsibilities

Facilitation of requirements gathering with the client-side product team
Coordination with client-side product owner for requirements clarification
Guidance of the UX and UI design resources
Running daily agile scrum stand-ups and regular sprint planning meetings
Final acceptance testing of user stories and release candidates

Tools

Google Slides, Google Draw, JIRA, Confluence, Sketch, Invision, Zeplin, GoReflect

18

Months as
product owner

14

Client & agency
product resources

20

Off-shore agency
dev resources

3

Android & iOS
app store releases

Partial project sprint and release roadmap

Roadmap Activities

After initial requirements were elicited from the client then captured in JIRA as epics, an initial feature roadmap was defined.

Constraints being worked within:

Fixed price contract
Fixed release milestones
Fixed features per release

The roadmap was designed such that features would span multiple sprints before being completed. Stages of feature work would be staggered by sprint:

Sprint X: Systems analysis
Spring X+1: UX/UI definition
Sprint X+2: Backend dev
Sprint X+3: Frontend dev
Sprint X+4: QA & acceptance

As the project progressed and features/system were better defined:

New requirements would be captured in the backlog
Backlog would be groomed as business priorities evolved
Roadmap would be adjusted as needed prior to sprint planning meetings

Feature system flow used to create a shared understanding

and identify gaps prior to creation of wireframes

Requirements Gathering and System Definition

Diagrams were employed to guide requirements clarification meetings for more complex features.

This allowed the team to:

Identify gaps in the user's feature journey
Record a shared understanding of how the system in question would work
Contextual annotation regarding the user experience
Contextual annotation regarding technical details like systems accessed and data sources required

Captured client requirements for use by the UX design lead

when concepting and wireframing solutions

Capturing Requirements for UX

During requirements gathering feature requirements were captured using user stories within JIRA for use by the Lead UX Designer when ideating and creating wireframes.

Wireframe client review sessions were twice per week (aggressive) on a set schedule and used to:

Validate system understanding
Flesh out more granular feature requirements
Begin capturing details necessary for dev user stories

Usability testing session focused on
the appointment scheduling feature of the app

Observational User Testing

As the roadmap progressed and features were defined in wireframe form we would execute testing sessions to verify usability of the designs. Participants were recruited from customers of SLUHN, as well as their main competitor.

Testing was done:

In a one-on-one setting with clients watching from an observation room
Following an established script that would evolve as the sessions progressed and the client provided feedback
Using two low-fidelity InVision prototypes for A/B testing feature concepts with participants

Findings were synthesized, presented to the client and decisions were made on how to adjust wireframes accordingly.

Screen flow of the appointment scheduling feature including all the possible entry points and results based on the type of appointment and availability of specific doctors

Creation of Development User Stories and Supporting Artifacts

Highly detailed development user stories were created for each feature.

I worked closely with the on-shore solutions architect to validate the details and size of each story prior to sprint planning meetings with the dev team. Stories were modified and/or broken down as needed.

Each story was linked to supporting artifacts:

Wireframes with final copy integrated
Screen flows to visually document feature logic
Style guide and UI comps (if applicable)
Other supporting documents as required

iOS styleguide broken down into design system components

with comps done for screens with more unique design elements

UI/UX Guidance

As a natural extension of my role as product owner, I assisted in guidance of our UX and UI resources as necessary.

Method used to capture UX and UI for the dev team:

Wireframes were developed using a three-level atomic design system to create atoms (elements), molecules (reusable collections of atoms), and organisms (collections of molecules)
Wireframes were created for each screen and state of the screen
Final copy was captured within the wireframes, eliminating the need for a copy deck, to make the dev process more efficient
Screen flows were created for each feature
Wireframe annotations were captured within development user stories using JIRA
UI styleguide was created based on the atomic design system
UI comps were created only for screens that could not be easily created using the styleguide
Styleguide and comps were stored within Zeplin so the dev team could access measurements and assets as needed

Agile scrum sprint board used to manage development
progress, also referenced during daily stand-ups

Guiding Agile Scrum Development

In my role as product owner I was responsible for guiding the development team on execution of the experience vision.

This includes, but was not limited to:

Leading daily stand-ups, sprint planning and sprint reviews
Answering or facilitating answers to story questions
Final acceptance testing of user stories

Our "definition of done" required my testing and acceptance of each story, task and spike

Smoke testing on release candidates

Lessons Learned

Though we had a large amount of time for the project there was an equally large amount of work. An aggressive timeline and constant unknowns made the project challenging each day.

Agile scrum is tough in an agency environment

When there is a fixed cost, fixed scope and fixed timeline there is no room for ill-defined requirements and the inevitable scope creep that results

Rapid design sprints need a foundation of fully fleshed out technical feasibility evaluations and feature definitions

In the absence of this, design review meetings turn into forums for the client team to discuss and identify gaps that brings design iterations to a halt while answers are found

The right people with the proper titles need to be in the room when feature discussions happen

Ideally these people are identified and engaged earlier in the project and prior to implementation of features that will affect the daily workflows

Features are best developed when broken down so that each sprint results in a deliverable portion of the product

By attempting to implement full epics during a sprint, those epics were often not completed and would span multiple sprints, making it impossible to calculate team velocity

Conclusion

Regular retrospective meetings and team adjustments helped immensely, but unfortunately some problems were baked into the SOW and instead became lessons for future projects.

100k+

Patient users of the app post-launch

30%

Reduction in customer support

10+

Sprint retros to continue evolving as a team

100

Cups of coffee