Part 1: Foundational Research
Goal: The Entitlements platform was created to deliver risk-complaint and consistent customer/agent experiences across all servicing channels. API teams looking to onboard to the entitlements platform submit intake request forms and attend a weekly intake meeting. My major goal was to fully understand the end to end process from both a product and API user perspective, thereby identifying areas of opportunity to improve the overall user experience. Another goal was to free up the product owners time so that they could focus more on product strategy.
Challenge: Users go through an onboarding process that is arduous and time consuming, requiring a great deal of hand holding from the product team. There is a high learning curve for teams to understand and select what rules (access) they need for their API. User’s are also required to test that the API has been conditioned with the right behavior, before going into final production. With these challenges some API teams either select the wrong rules or bypass the whole process resulting in risk and compliance.
Outcome: I had several working sessions with the product team to learn the business processes. In addition, I conducted 30 minute remote, moderated interview sessions with eight users (four producers, two consumers, and two risk & compliance advisors). Key focus areas included: awareness, testing, notifications, risk & compliance engagement. These sessions culminated in an E2E journey map and a service design blue print.
Part 2: E2E Journey Map & Service Design Blueprint
Collaborating very closely with the product team, I created an End2End Journey Map and Service Design Blueprint. These artifacts were used to inform product and engineering strategy and roadmaps and most importantly uncovered areas that needed much improvement that were not evident.
A key slide from the Research Report
Key Takeaways & Recommendations
1. Requirements of a Self Service UI
2. Providing users a workflow that would provide transparency to the onboarding process = Guided workflow.
3. Providing descriptions to entitlements (rules) in plain English, including the justification of the WHAT Rule/Regulation it points to and the WHY.
4. System recommendation of rules based on context aware questions
Key slide from the Research Report
Key slide from the Research Report
Part 3: Future State Interactive Prototype
I begun the ideation process by creating a low fidelity prototype in Figma that would be a reference point for discussions with partners (I leveraged existing layout patterns from our design system). This helped the teams align on what features would make it into an MVP. Below is a sample of the prototype, beginning with a sample of a low fidelity wireframe.
Using existing UX patterns I was able to quickly create low fidelity wireframes for feedback
As the design lead, I planned and facilitated several weekly workshops with product and engineering leads to begin to visualize what the guided workflow would contain in a self service UI. We used Jamboard as a collaboration tool.
We quickly realized that we had to look beyond what the MVP could offer and begin to map out what a future state would entail. I presented the final clickable prototype containing 43 screens to an audience of 25 that included product, engineering and design leadership. I was successful in streamlining the onboarding process for API teams by envisioning what a self service experience would look like from both a UX and UI perspective.
Couple of key screens
Currently the engineering teams are looking to build out a more robust architecture that would be able to bring this vision to life.
Part 4: Capabilities Workshop
This prototype has led the engineering teams to take a closer look at their architecture and see the deficiencies that are present that would hinder them from creating this future vision. To move them in the right direction I led and co-facilitated a capabilities workshop. We begun by collaborating on what the main goal and outcome of the workshop would be.
Goal: Identify what platform investments are needed to be made over the next year that will enable the engineering team to build new features quickly and in a well managed way. Examples included simplifying configurations, enabling releases that are more agile but still well managed.
Outcome: the engineering team will be empowered to make crucial decisions on the current architecture that supports entitlements, which parts are being modernized, which parts will need to be rebuilt, which parts are completely new.
We collaborated very closely with our product and engineering partners to pre-populate the insights onto a Google Draw board. These insights were derived from both the survey and pre-workshop empathy sessions I planned and facilitated. Emerging themes were then added as column headers and referred to as capabilities. A final board was shared with workshop participants a day before so that they could prep.
On the day of the workshop voting was done for impact with either a low or high, followed by polling, done for effort using T-shirt sizes ranging from XS to an XL.
Final Thoughts:
This was a 3 hour workshop completed at the end of the year. We completed a lot in a short time, however, we were not able to complete the polling by effort section. The product and engineering teams are more aligned and are prioritizing stories to build out the architecture.
We completed two Retros, one specific to design and the second a combined retro with our partners. Our main takeaways included:
Efficiently gathering and organizing insights under the capability columns ahead of time made for an efficient workshop session.
The length of the workshop was not enough to complete all activities
There was not ample time for discussions as participants had to quickly vote and move to the next insight.