product design
at Kaiser Permanente
As a product designer at Kaiser, I crafted many flows that would help patients and members stay on top of their healthcare needs. One of the domains I worked in was pharmacy, designing products that allowed patients to manage their prescriptions. Below is just one small example project, but what I would like to highlight is my process, and examples of resulting artifacts that can be used in discussions with stakeholders, which lead to full alignment and frictionless buy-in when high-fidelity mock-ups are revealed.
The ask was simple, how do we allow onboarding members transitioning from a previous healthcare provider to transfer their existing prescriptions to Kaiser? Working tightly with the product team allowed for a seamless process.
building alignment from the top
When working with complex products, I like to have as much alignment as I can during the most upstream parts of the process. As represented by the illustration, most of the design work happens when drafting the requirements and working along with the product team. It’s important to have clearly identified what stories will be worked on and their respective levels of priority. The goal is that if you do more upstream work in garnering buy-in, by the time you get to high fidelity, there should be no surprises during the design reviews.
requirement mapping
Mapping the requirements simply means bucketing them and drawing out a path according to your chosen UX strategy and order of operation. For this project, the first thing the user would need to do is create a list of their current prescriptions and their respective details. Smaller stories aligned to that task would naturally be grouped. The “user lists allergies” requirement doesn’t have a natural affinity with the other requirements, so it sits on its own. Finally, the last major requirements grouping has to do with where to send the prescriptions.
I used this simple map in my discussion with the product team to make sure that all the requirements were accounted for and that the order seemed correct. This is an especially helpful exercise if the number of requirements is huge (see my case study at Amazon). It also provides yet another opportunity to align on the higher-level strategy without getting sucked into nitty-gritty discussions about UX solutions.
wireframing
Now that requirements are accounted for, prioritized, and ordered, I can start thinking in more detail about specific UX solutions. The only real complexity with this feature is how the user will be able to list and provide details for each prescription that would need to be transferred. The ideal UX in my mind would be a simple input box where the user would just have to input the first 2 or 3 letters of their prescription name, auto-suggest would pair down the number of possible options, and the user makes the selection. However, no such catalog existed on the backend, this would have to be completely manual. These wireframes provided quick ways to delve into solutions.
Option 1
On the initial state, the user would be presented with a form to input details about their first prescription. After filling it out in full, the user would need to add the prescription to a list (“add to cart” if you will). This list appears adjacent to the form. At this point, the user can choose to move to the next step in the flow, or stay on this first step and continue to add prescriptions to the list.
Option 2
Similar to the above, however, the full list is on a separate page from the form. The user is initially presented with an empty state list and the primary call to action would be to add the first item. When the user clicks the call to action, a modal with the form appears. When the user submits the details, the modal is closed and the user returns to the list.
Option 1: Creating an adjacent list of prescriptions
Option 2: Inputting prescriptions via modal
High fidelity
Using wireframes in design reviews is a great way to keep stakeholders objectively focused on the UX solutions, pros and cons. We decided on the first option as a team because it felt more simple, the user did not have to move back and forth between the main screen and a modal. Unfortunately, I did not have the opportunity to user test this experience, as research allocation went to higher priority areas of the website. But as far as getting agreement and buy-in on the design, when high fidelity was put before the product and leadership team, it was smooth sailing, due to the upfront effort to get immediate alignment.
