Towers Built on Sand - Part 2

A Case Study in Fixing Foundational System Flaws

Yesterday, we mapped the problem space of Healthcare Systems (HCSs) being implemented in Hospital Quality Reporting (HQR). We left off having a diagram of the user groups and their objectives that combined to make individual user stories. Let’s pick up where we left off.

Step 3: Creating Process Flows.

With consensus reached around our user groups and their goals, it was time to diagram how we expected each user group to accomplish each goal. As seen in the process diagram,



we set the user’s objective from the previous exercise as the objective for each process. In this particular process, we diagramed the steps needed to create a new HCS in HQR from the perspective of an HCS administrator. We took a first pass at this process as a UX team, making assumptions and guesses about what steps would be needed as we went. When we had given each process our best shot, we again collaborated with our teammates from the rest of the product team, getting input from developers and others. This collaboration helped refine these processes, and in most cases, simplified them greatly. Assumptions were tested and were resolved through this collaboration, leaving us with a full set of processes that made sense to both the UX team and the development team. 

With the product team in unison, we presented these flows to the stakeholders. Because of the time spent collaborating and hammering out the imperfections as a product team, the resultant processes were strong and made sense to the stakeholders. Concerns were addressed, and questions were answered because we had thoroughly considered the processes from all the angles we could think. 


Step 4: Transitioning to Mid-Fidelity Designs. 

Having come to agreement on the process flows, the next step was simply to fill in each process with the requisite screens and to work on interaction and visual design. Though labor intensive, this step began to solve itself. With the objectives set, and the process agreed upon, the hard decisions had already been made. Creating designs was merely a matter of following our established design principles, and making sure that screens moved the user in a logical progression through each step. In order to keep our eyes on the proverbial prize, we included the process flows with every set of screens to make sure we were always focused on whether the current designs helped to achieve the desired end result. As the designs began to fill out, the number of pages being designed became very large. Large design files tend to be easy to get lost in, but because we had laid the foundation of this project so thoroughly, we found that navigating the design files became as simple as referencing which user type and which objective was being accomplished. 

When the UX team had designed all of the mid-fidelity pages for a given user type, we would check in with our product team collaborators. These meetings continually became more and more straight forward, as the big decisions had already been made. Instead of big, paradigm-defining decisions being discussed, conversation was instead turning towards subjective opinion about header language and button placement. As each flow was created, the other flows would gradually fall into place. Eventually, all of the requisite pages had been designed and were ready for testing. One last check-in with stakeholders was required to show them the designs and how things were progressing.


Step 5: Usability Testing.

By this point in the process, the designs for HCSs inclusion into HQR have taken form, and we have a good sense of which parts we are all confident in, and which parts we need to test with users. Usability testing will be performed next in our process, so working with the team to recap any loose ends we’ve left will be our current focus. By building slowly and methodically, we’ve hammered out all of the questions that we are able to answer, but there are still questions that remain. Usability testing is a good opportunity for us to get answers to these questions, as well as to test the interactions we’ve been working through. With data from usability testing, we can now make final changes to our designs. 


Step 6: Versioning.

The designs are finished, the usability testing has gone swimmingly, and now it’s time to hand things off to the development team. Well, almost. This last step is vitally important. Development will need to assess the designs and decide how they will divide up the work for development and release. The UX team should be involved in this process, as releasing a major initiative like this will require delicate planning to ensure the users receive an experience that builds upon itself and makes sense to them as it rolls out. Selecting the portions of the designs that are attainable from the developers but that also will make sense to users is a balancing act, but careful collaboration with the product team can lead to a product rollout that doesn’t result in a flood of help desk tickets. 


Summary

Big projects can be big problems if they’re not approached the right way. Systematic and methodical approaches to big system shifts can help break that big problem into manageable chunks. By collaborating with all of the relevant parties, defining the problem to the best of your ability, and mapping out the processes involved, you can tackle even the biggest challenges and know that you’re minimizing the possibility of doing re-work down the road. This approach may seem tedious and slow, but it’s important to remember that strong foundations lead to strong towers.