Supporting Rapid Development for Guidewire InsuranceNow
A UX Case Study in Patterns
Earlier this year, the payment screens for InsuranceNow Customer Service Portal, which had initially been written in Angular, needed to be rewritten in React. This project was the ideal opportunity to refine the flow and update the UI to reflect the look and feel of our Jutro Design System and UI Framework. However, time was short, and the initial development sprint was about to begin. We needed a quick start, so we turned to our new Jutro basic payment pattern.
Jutro Business patterns are reusable combinations of components that address a recurring user need.
Quick Start
After an initial conversation with the lead developer for the project, I shared the pattern screens for multiple form factors so that he could begin immediately. He, in turn, provided current screenshots of the existing payment screens for quick reference. I branched our InsuranceNow project in Abstract and added the screens and screenshots to the Sketch file. And so began our rapid iterative collaboration.
Free to Focus
Our out-of-the-box basic payment pattern provided us with 80% of what we needed before we even began, including form, flow, and functionality, all of which freed us to focus on the unique details of an app-specific implementation. As we proceeded to implement the pattern, we identified issues specific to InsuranceNow, and we even found opportunities for improvement.
It was important to provide a smooth transition into the new payment pattern for the user. We streamlined policy selection by creating a matching screen, using cards instead of a table. The Jutro payment pattern was simple and clean, which helped us filter out complexity and focus on the essentials.
While the basic payment pattern presumed an immediate payment, the InsuranceNow Service Portal permits a scheduled payment date, so we included that capability. We briefly considered using a radio button card for selecting the payment date, similar to our approach for specifying the payment amount. However, we opted for a straightforward single-card date picker for simplicity.
When a user adds a credit card by selecting “add new payment type,” the payment service opens in an iframe to securely handle the information. The payment service UI does not match the Jutro pattern look and feel and would have looked out of place if directly juxtaposed with the rest of the content on the screen. Because we could not alter the styling of the payment service UI within the iframe, we decided to display the “add new payment type” flow in a modal and styled our content so that everything within that microflow would be consistent in appearance and functionality.
The rest of the implementation was straightforward. Since our developer was experienced with collaboration in InVision, we used it to share screens in the flow, supplemented with matching screenshots shared in our Slack conversations.
Value of Patterns
While UI patterns are common across web applications, some — like our payment flow — are business patterns more specific to our industry. Patterns give us momentum with quick starts, free us to focus on important issues and opportunities, and promote shared consistency in form, flow, and functionality — including accessibility — across our applications. And as we implement patterns, we discover what works well and what needs improvement. The process provides an opportunity to continually strengthen our patterns, which contributes to a more robust design system.
