Squeeze
The problem
The average household spends an estimated $21,378 per year on recurring household bills.
This is ~ one-third of annual income (= 21% of all consumer spending), equal to $5.3 trillion annually.
Most consumers overpay on their recurring household bills, due to:
Increasing Prices: Many bills increase over time due to human behavior, shifting market conditions, expiration of promotional rates, and life events.
Fragmentation: Without a centralized platform to deal with recurring bills, knowing when to shop them or keeping track of pricing & providers can be frustrating.
Lack of Time: Consumers don’t have the time or desire to spend hours online filling out multiple forms for each bill, or to continue to reshop them each renewal cycle.
SPAM = No Trust: In too many cases, filling out forms online comparing rates results in unrelated third-party spam, unwanted phone calls, or both.
The solution
Real-time Price Comparison & Passive Reshop: Providing multiple quotes from trusted providers in minutes, and then automated reshop on our customer's behalf at each renewal period.
Centralization: Squeeze allows consumers to shop and keep track of most of their largest recurring bills all in one trusted place – saving them time and money.
Fast Onboard & Enhanced Profile AI: Third-party data integration and intelligent, cross-form data sharing allow squeezers to onboard any bill in just minutes. Passive reshop continues to do the work for them, so they don’t have to.
Squeeze = No SPAM: By respecting our customers’ privacy, we continue to protect our brand for the future, helping extend our customer LTV.
Auto Insurance: Redesigning the flow
The flow is the most important part of the platform, and we were seeing a drop-off due to:
- Users were confused about what was completed via pre-pop, and what still needed to be added
- While we were able to keep the flow short in terms of pages, the amount of information that was on each screen was becoming an issue, especially when there was missing info/alerts.
For the following revision, we focused on meeting the user's current expectations based on competitive analysis. We knew the following
- More pages did not necessarily mean a worse experience.
- Less information on the page gave the user the ability to move quickly while increasing their feeling of completion.
Auto Insurance: Tile Sheets
While we’ve taken some time to take a look at the flows, the dashboard was the meeting ground for all of the Squeeze product offerings. The information that was displayed there needed to be contextual to where the user was at within their Squeeze journey. Below is what we defined as a Tile Sheet, which are modules that would be shown at specific parts of the auto insurance experience.
Note: auto insurance is just one of seven product offerings that we had at the time, so there were tiles sheets for each offering as well. On top of that, I’m only listing the tiles for the POST (After quote) experience. There are also tile sheets for the PRE and MID states for each offering.
Auto Insurance: Quote pages
When a user completes a flow, they receive their quote page. Meeting certain requirements would place them in one of these states:
- Real-time quote
- Manual quote
- Missing policy
- Expired
- MA Only
- Manual Refresh
Auto Insurance: User Testing
We internally went through two separate rounds of user testing, specific to online check features for auto insurance. Examples of the insights we found can be found in the PDF below.
Squeeze design system
Given the depth of the Squeeze product, discovery was done and processes were created to make sure that each part of the team has the SSoT (single source of truth) when viewing designs and deliverables.
Below is the documentation and process for implementing a feature as expansive as a design system.
Jam artifacts: What does success look like (top)? What does failure look like (bottom)?
Scope + Principles
Principles
- Documented process (both macro and micro level)
- Should scale for future updates/projects
- Auto-update to confluence
- Scalable naming conventions for sketch symbols and confluence indexing
- Sharable symbols
- Bring all confluence pages up to speed with embedded Invision links
- Atomic elements in symbols
- The expectation is that all “conditions” & “Functions” are documented in design format
Risks
- “Source of truth” system will require its own QA process
- Symbol breaking/overrides
- Too complicated to use
- The process is not scalable to other team members
- Having to redo the process yearly
- Spend 10 days on a file system that becomes obsolete (right away)
- The solution takes too long to update each time we complete a design cycle
- Constant crashes/slowdowns
- The “source of truth” file is too large. Devs/QA can’t navigate. Chokes CPU
QA Handoff terms
Design System: A specific sketch library that is referenced in all working sketch files moving forward. Holds all of our main elements (tiles/buttons/elements) in order to keep our designs consistent. The DS should be used as a library, and should never be used in design explorations.
MASTER sketch file: The main sketch file for all verticals. Like the DS, the MASTER files should be used for handoff and documentation, and not exploration. At the end of a PRD project, the MASTER should be updated with the new elements. This is the file that is referenced both in the MASTER and PRD confluence pages.
MASTER confluence page: The main confluence page for all verticals. Will be used to document all assets functionality. Will include a change-log that links to all updates that are made in the PRD processes.
PRD sketch file: A working sketch file that holds all elements for a body of work, including the discovery, wireframes and designs. Will not be linked to confluence.
PRD confluence page: These are the same confluence pages that we’re currently building out. The functionality and documentation doesn’t change. Should be used to let teams know what has changed.
Handoff: The preparation of files for both the DEV/QA teams.
SSoT: Single source of truth. The reason for this project is to make sure that everyone on the team has access to the latest designs for every vertical.
Our current process
Below is our current project process.
While it’s agile enough to allow for quick ideation and delivery, it lacks the ability to retro previously made UI/UX in order to give the DEV/QA team a SSoT.
Proposed process
Main updates:
- Introduce a Design System (DS) file.
- MASTER files (confluence/sketch) will be created in order to showcase the SSoT.
- These will either be created at an offer or vertical level. I’ve documented the pros & cons to each at the bottom of this page.
- The handoff and asset prep process will happen after the design process. This will now be a 1-3 day process, depending on the impact of the new content to the DS / MASTER files.
- While PRD confluences will remain to showcase newly updated functionality, the master confluence pages should act as a repository of vertical assets (forms/tiles/quote pages) with the addition of a changelog section link to each new body of work.
- The 3 working PRD sketch files (discovery/wireframes/design) will be rolled into a single Vertical-ProjectName.sketch file for easy version control. As we continue to scale, we’ll need to make sure that the files that we’re creating as easy to find. As of now, we’re creating 3 files per body of work. With the introduction of the design system
What we gain:
- All pages should be treated as SSoT moving forward
- Additional speed in terms of page creation using the DS symbols
- Will retain the ability to have versioning for all explorations throughout the discovery-design process.
- The process of using the flows in the MASTER as the embedded elements for confluence page makes sure that we won’t need to update every time there is a global change.
- The process for global changes will be sped up if all of the SSoT elements are in a single offering invision file.
Additional considerations:
- Both DEV and QA will receive the assets at the same time, meaning that there will be additional time between the design sign-off and the finalized handoff.
- Higher emphasis on process, especially when it comes to updating the DS and MASTER files.
Sketch file structure suggestions
As we build out the MASTER files in sketch, we’ll need to decide how we want to document each
Option 1 - Vertical specific MASTER
This system breaks each vertical into its own MASTER files.
Pros:
- Less files that we need to open when there is a global update
Cons:
- Potential for the files to become larger
- With larger files, comes the potential for crashes and issues with sketch
- The page structure (sketch file organization) will need to be different, as structures that work for a single vertical file may not work for a multi-vertical file.
Option 2 - Offer specific MASTER
This system breaks each offering into its own MASTER files.
Pros:
- Smaller, more digestible files
- Less content in the file theoretically should be easier to find things
Cons:
- Global updates (like a navigation update) will take a little longer to update via invision.
Sketch in-file management
As we scale to a more automated process, we’ll need to be aware of our in-file content structures to make sure that all master files match the same structure.
In-file management will be built out using the page's features. This should give us a top-level view of all vertical assets.
Title: Used as the snapshot screen both for sketch cloud as well as invasion.
Tile sheet: All tiler iterations would be documented in artboards so that they’re quick to find. These tiles should be symbols that are pulled directly from the DS. Tiles should not be created in the MASTER, but should be created and references from the DS.
Dashboard: All dashboard screens should be documented here. These screens have primarily been used to show the tiles in context.
Index: All iterations of the index pages will be documented here.
Quote results: All iterations of the QRP will be documented here.
Quote details: If applicable, showcase the QDP interactions.
Flows: These are the functional flows that we’re building out for PRD projects. The screens that are referenced here should be symboled at the PRD level, making sure that any small tweaks to the UI make their way throughout the document.
Forms: Vertical forms will be documented here.
Misc: Hold over for any additional items that don’t match the categories above.
.svg){kind=icon}
