Feature

Annual Budget

A SaaS platform that helps drive margin for over 200 of the top healthcare delivery systems in the US.

Summary

Healthcare admins use StrataJazz to plan for the next fiscal year.

When healthcare administrators plan for their next fiscal year, it happens over a series of meetings and requires input from different departments. In other words, you can’t plan it all in one sitting and there are a series of “phases” that planning undergoes. StrataJazz provides the analytical tools users need (figure 02) to generate data and make sound decisions.

The problem was that these tools or actions were done within the same workflow, however they were scattered across the StrataJazz platform. My Product Manager wondered if these actions could exist on the same page.

In addition to the current actions, customers requested new features that could only be done on the back-end. These features could not be developed for Stratajazz because specific actions were not appropriate for certain phases. While keeping Stratajazz flexible, it also needed parameters to avoid user error. The challenge here is how do we keep our platform flexible, but also ensure that the user doesn't unknowingly create errors on their end.

Our goal was to create a new feature in the current module that matched the annual budget planning process for finance and c-suite executives in healthcare.

Discovery & Framing

I collaborated with my PM to learn more about the problem we were trying to solve.

My relationship with my Product Manager was instrumental in learning more about StrataJazz's use cases, and their users. Since the scope of our project didn't include in-depth user research, I relied on my PM's subject-matter expertise, and ongoing conversations with our clients, to identify gaps in the user workflow, and understand what assumptions we were operating under.

Since I wasn't familiar with this problem space, I created these visual diagrams to validate whether my understanding of our users, and their use case, was consistent with what my team knew.

Problem Framing

One of the early challenges we faced was understanding our assumption of the budget planning process. At a high level, my team knew our customers facilitated this task in a sequence or phases. The challenge was how do we map these phases onto our platform. My contribution was helping my team visualize our ideas into visual diagrams, and continuously iterating until we felt that the phases met our goals.

Ideation

Exploring ways we can incorporate the concept of “phases.”

At a high level, I knew "phases" meant we would guide users along a process. Some early ideas incorporated different components like steppers, toggles, and checklists.

Eventually, I used a combination of my sketches and screen caps to frame my ideas. This was helpful in contextualizing our concept.

Actions & Wireframes

As a result of the iterations, the concept of actions came up. At a high level, we understood there there were different types of actions users could perform on StrataJazz. These actions or tools were fundamental to helping the user accomplish their tasks. However, executing specific actions were contingent on the phase of the process the user was on. This meant that some actions were more preferred than others, and some actions were not recommended at all for specific phases.

This was an issue for us because our guiding principle was to provide as much flexibility as possible for our users. The challenge was how do we provide all these actions as options, but also let the user know if they perform "not recommended" actions then they would be taking a risk with their data. In these wireframes (figure 11) I explored different ways we can show/hide these actions, and how to organize/label them as well.

Prototype & Usability Testing

Ultimately, we felt that an accordion-based design was the best choice for hiding/showing different actions. Putting actions in containers allowed us the flexibility to move them around based on where the user was in their process. We tested our prototype with other product managers, and eventually with customers. The purpose of our usability test was to validate our concept of phases, and to identify any usability issues in the design. Overall, we had validated our concept and identified specific areas of the design that we could work on.

Reflection

I designed UI concepts before the project ended.

While UI design was part of the roadmap, unfortunately my internship ended before we could move further. I designed some mockups, and handed it off to the design team (figures 21 and 22).

Looking back, I wish we had spoken to our customers sooner. While we were lucky that we validated our assumptions, we could have potentially spent the entire summer working on an idea that didn't resonate with them. It would have been great to perform some ethnographic research to get a sense of what an actual use case would look like. Even though our idea was validated, there was a high risk that they wouldn't use it or find it helpful in an actual use case.

Two things that really resonated with me throughout my internship was learning how powerful visual diagrams can be, and how crucial collaboration is for creating a great product. Ideas can get pretty heady at times so communicating ideas visually gives everyone the opportunity to be on the same page. I found collaborating through whiteboarding sessions an opportunity to learn more about the product from my PM, and that our better ideas came as a result of looking at the same problem through different perspectives.

As far as I know, this concept never made it into production after my internship ended. I don't have visibility into what happened with it afterward.