Bensonn Anspach
UX Designer, SAFe 4 Agilist & CSPO

St. Luke's University Hospital Network Mobile App

Product owner and UX/UI Guidance

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 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.⁠


  • 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


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

Months as
product owner
Client & agency
product resources
Off-shore agency
dev resources
Android & iOS
app store releases
Partial project sprint and release roadmap

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

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

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

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

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

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


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

Patient users of the app post-launch
Reduction in customer support
Sprint retros to continue evolving as a team
Cups of coffee