Weave 2.0

This major redesign is ongoing, and solving problems ranging from accessibility, user flows, and technical engineering issues.

• Create an experience that supports multiple-location business

• Refresh code to reduce tech debt. This will set us up for more frequent deployments and the ability to iterate faster.

• Make the experience responsive (it’s currently restricted to a 350px wide window in the native desktop app).

• Update the design system for better accessibility and clearer hierarchy.

This project involved two Product Managers, three Product Designers, and seven engineers. One PM focused solely on the multi-location impact while the other PM was focused on the rebuilding of the code repository and shared user experiences, paving the way for each product team to add their product features to our “2.0 repo.”

The primary opportunities we discovered for multi-location businesses were:

• Sort & manage locations

• Admin dashboard providing access to high level information on each location (without fully switching contexts)

• View and manage all users and their locations and permissions/access

• Bulk configuration of location settings and features

• Phone experience with flexible connectivity (connect from anywhere, and allow locations to talk to each other)

• Reporting around communications and patient engagement

When I was put in charge of this project, our plan for delivery was to completely rebuild a new experience and replace our current desktop app in one major release.

I worked with our product and engineering leaders to change this strategy to one that would allow us to deliver value sooner and allow for a gradual release of the new app.

Our new plan of action is:

1. Rebuild the core functionality in a new code repository, architected to allow for multi-location functionality and reducing tech debt. This app will be accessible as a web app, while the current desktop app will remain.

2. Gradually build in each products’ features on the new repository. Users can begin to use the new web app and become familiar with the design changes.

3. When full functionality has been built into the new web app, we’ll replace the old desktop app. At this point the user will have the same experience in the native and web apps.

Now users get value out of our new app after just a couple of months, instead of 1 - 2 years. They can become familiar with this new app gradually as we release updates, and when it replaces the old desktop app they’ll be ready to hit the ground running.

As we started adding multi-location functionality to some pages, we needed to communicate this new feature to our beta group. We wanted to do this the least disruptive way possible. When a user is on a page that supports information from multiple locations at once, the location selector switches to checkboxes and we show a brief message explaining this new feature in beta.

It was clear that users wanted their selection to be persistent when navigating to a different page. When switching from a page that only supports a single location filter, we persist that selection. On a page that supports multiple location selections, if the user switches to a single location page we’ll change their location selection to only select the first location of the ones that were previously selected. This way their context remains partially intact. Along with the selection change we show the users a “toast” notification explaining the change.