Let’s be real for a second.
Insurance apps are full of repetitive, predictable flows:
Add a driver → Fill a form → Click Next → Review → Pay → Done.
Do we really want to rebuild the same steps every single time?
Guidewire took one look at that chaos and said:
“Developers deserve better. And faster. And less repetitive stress.”
That’s why Patterns exist in JDP (Jutro Digital Platform).
If Jutro Components are the LEGO bricks, Patterns are the pre-built LEGO sets that already look like a car, a house, or a spaceship, you just customize the colors and stickers.
So… what exactly are Patterns in JDP?
In simple words:
Patterns are reusable, ready-to-go UI flows built from multiple Jutro components, designed specifically for insurance journeys.
You don’t have to reinvent multi-step forms, document upload flows, payment steps, quote summaries, or review pages.
Patterns say:
“Here’s the structure, logic, layout, UX rules you handle the business details.”
It’s like having a friend who pre-cooks the entire meal but lets you choose the spice level.
Why Patterns Exist
Because every insurance app ends up building the same things over and over:
- Customer information
- Addresses & contacts
- Vehicle/Property details
- Coverages
- Payment
- Review & confirm
- FNOL (First Notice of Loss)
- Claims submission
- Multi-step workflows
Instead of 500 teams reinventing the same UI steps, Guidewire packaged them as patterns.
This saves:
- Time
- Complexity
- Bugs
- Arguments
- Weekend deployments
- Developer sanity
And honestly?
It works.
Patterns vs Components
Components = the buttons.
Patterns = the entire form created using those buttons.
Examples of Patterns in JDP
Patterns come in handy for flows like:
- FNOL submissions
- Quote & Buy
- Payment processes
- Add / edit / delete flows
- Multi-step wizards
- Timeline flows
- Coverage selection
- Document upload + validations
- Policyholder details updates
- Review & summary screens
These are patterns because every carrier needs them, and the core logic rarely changes
When Should You Use Patterns?
Use Patterns when the flow is:
- multi-step
- repetitive
- data-heavy
- tied to a backend entity (policy, claim, account)
- predictable
- already known to users
*Don’t use patterns when:
*
- you need highly custom UI
- you’re designing a unique section that doesn’t fit the mold
- animations or speciality layouts matter more than structure
For 80% of insurance flows?
Patterns are perfect.
In One Line
Patterns in JDP are reusable UI flows that let developers skip repetitive work and focus on actual insurance logic, not layout, spacing, or step navigation.
Top comments (0)