Aya DocFlow

Internal tool built to increase throughput of document processing at Aya Healthcare

Time Frame

2019-2020

Scope

Product Design, Visual Design, User Research

Deliverables

UX Design (web)

Company

Aya Healthcare

Aya Healthcare is a healthcare staffing company that bridges the gap between hospitals and nurses/physicians. Aya's software offerings enable it to place A TON of staff at hospitals across the country and one of the key technologies that is vital to this process is Docusign.

Contracts would need to be signed by the nurses, placement agreements by the hospitals, leasing agreements between Aya and landlords - the list goes on and on.

Historically, whole departments of Aya staff would use the exact same Docusign login information to send out tens of thousands of documents to be signed every year.

This was not scalable and left a lot to be desired in terms of automation and visibility of who was taking what actions in the system.

As teams grew, these limitations became more apparent, and as a result, the DocFlow project was born - we would integrate the Docusign API into our internal system (NOVA) to enable document envelope creation in house.

Project Goals

1 Functionality

We wanted to emulate the functionality that we were currently using in Docusign to mitigate the disruption to the service teams who already had workflows dependent on the software.

Strategy

Combination of talking with managers (to see how they thought the work was getting done) and the staff doing the work (to see how the work was actually getting done).

This would help us understand what features we needed to pull from Docusign and what new features we could potentially build to facilitate an improved workflow.

2 Visibility

As the teams using the existing tool grew, it became unwieldy and hard to keep track of who was doing what.

Our new internal tool would need the capability to show who was sending out envelopes, making changes to templates, and more.

Strategy

All actions would be “tagged” with username and a timestamp, making it easy to see who was doing what and when.

Access to different features would also be based on permissions to reduce the chance of unwanted actions.

3 Automation

As documents were set up in the system, we wanted to save this work and be able to re-use it to avoid doing the same tasks over and over again.

This would reduce the manual labor involved, increasing throughput and reducing the chance of errors.

Strategy

At launch, envelope creation time should be a similar amount of time to using Docusign directly.

After 6 weeks, we were expecting to see a significant speed increase from defaulting content.

We would also use the number of errors as a proxy for the effectiveness of our automation.

Wireframes

There turned out to be so many features that the users wanted, but didn't really need (especially for an MVP version of the feature). I took the research I had done on Docusign, along with the pared down requirements list and started wireframing out different ways we could solve this for our users.

Iteration

Because Nova is such a mature product, we already had a pretty defined set of styles to work with. I was able to get feedback on my preliminary wireframes from the various stakeholders and then jump into higher fidelity mockups using pre-existing UI components.

Being able to get to mockups that “looked like the real thing” helped a ton in gathering feedback from different teams that weren’t used to seeing wireframes.

Mappings

Since one of our project goals was “Automation”, we decided that in addition to pulling in existing functionality from Docusign, we wanted to build out the ability for the system to map our internal data to the templates that were stored in Docusign.

This way, once a team member sent out a document one time, all of the data they entered would be mapped to the template, and could be defaulted to the next time that document was sent out.

We created an interface to manage/review these mappings as part of this project.