top of page

Crafting a seamless Search Journey

Designing an enhanced user experience for the search feature in Allied Solutions' CenterPoint application - which is used by Credit Unions. The goal of the enhanced search bar is to simplify the users' tasks and boost their work efficiency. 

groups

Team

​Senior UX Researcher

UX Researcher

Lead Designer

UX Designer (myself)

checklist

What did I do?

  • Thoroughly understanding prior research

  • Creating and publishing a user survey

  • Creating high-fidelity prototypes and design components

  • Actively participating in moderated user testing

Background - About CenterPoint

Allied Solutions' Center Point offers multiple solutions like loan tracking, filing insurance claims, verifying insurance, uploading proof of insurance, Collateral Protection Insurance (CPI), and Escrow Billing.

These solutions help Allied's clients i.e., Credit Unions and Financial Institutions to protect their loan portfolio and take necessary actions when a loan is defaulted by the borrower.

person

Understanding the users

Who are our users?

Our user archetype for the scope of this project is the users of CenterPoint. These users work in various roles like Loan Officer, Debt Collections Manager, Collateral and Escrow Services Manager, and many others. These users work on legacy software and are not so proficient with technology. They work with huge amounts of customer data daily.

Users.png

What is the current user journey like?

  1. The user enters the search term in the search bar present in the dashboard. The following are the search terms that the users can use:

    • Borrower Name and Address

    • Loan Number

    • Property Address

    • Vehicle Identification Number (VIN)

    • Collateral Details

    • Policy Number

    • Notice (for lack of insurance) Reference ID

  2. Once the search term/search query is entered, the user hits enter or clicks on the search CTA.

  3. Search results matching the query are displayed in multiple tabs like Loans, Unmatched Insurance, Claims, etc.

  4. The user selects a record and performs the required actions (match/ upload insurance, file a new claim, etc).

​

The following user flow diagram is created to get a better understanding of how users perform the search task, and their areas of user frustration. The diagram shows the users' emotions through their search journey, highlighting the problem areas in the flow.

User Journey Image

User flow for the current search bar functionality (Yes! I created it)

manage_search

Understanding the Problem Space - Current State

While analyzing the performance of the CenterPoint Dashboard, we received many complaints in the form of feedback from the users. One of the major complaints from the users is having to navigate back to the Dashboard each time to perform a new search operation.

​

Additionally, data from Google Analytics revealed that users are struggling to understand what they can search from the search bar. Users searched terms like "How to add user", "upload file" etc, which were not anticipated.

Blurred image of current design

Screenshot of the current design of the search bar on CenterPoint

Highlighting the user pain points

fork_right

Navigation

After finishing their current task, users need to navigate back to dashboard for performing a new search. 

ads_click

Multiple Clicks

Their day-to-day work requires users to search for the same record multiple times. Currently, this is resulting in repeated searches and multiple clicks

help_center

Purpose

Users struggle to understand the purpose of the search bar. (Terms like "how to add user", and "upload file" were searched - Google Analytics)

grade

Popular queries

 Each time users need to query for all open claims, they need to perform the same action over and over again.

flag

Business Goals

  1. Reduce the number of calls to Allied (because, if a user cannot find the information they are looking for, they will call Allied directly to ask them to do it for them).

  2. Enhance customer experience and thus gain customer loyalty.

  3. Reduce the search abandonment rate.

  4. Making the search bar accessible, contributing to a more inclusive experience.

edit

Setting the redesign goals

To dig in deeper into the problem space and to set our design goals, our team created a survey on Maze and made it available on CenterPoint. After over 15 responses, common patterns started emerging.

​

The following are the additional issues that are resulting in poor search experience for the users in their own voice:

​

  • "When putting in an account number, other accounts generate under the search and they aren't associated with that account number I searched for".

  • "It would be amazing and awesome if you made it so we can search by the last digits of the VIN instead of the first digits."

  • "It would be nice to have a list of all open claims without having to search".

flag

Product Redesign Goals

  1. Reduce the number of times an account is searched via the search bar, aiming to decrease the number of searches to number of accounts accessed ratio.

  2. Reduce the number of clicks per search

  3. Reduce the number of search operations executed to find a single record.

polyline

The Process

For the Search feature's design, I conducted a comprehensive analysis of websites showcasing effective utilization of design patterns, particularly focusing on filters and search functionalities. I leveraged this research to inform and guide my design decisions. Also, I iteratively designed multiple versions of each flow and developed prototypes. 

Moodboard created by analyzing search features in various products on the internet

Moodboard created in Lucid by analyzing search features across the internet

Screenshot of the design iterations

Screenshots of the design iterations I created

Once the design iterations were done, our team of researchers and designers gathered together for a design critique to discuss the pros and cons of each concept. The critique was based on the user archetype, feasibility, and viability. The updated designs from the critique session(s) were then validated with the users and the final modified designs were then handed-off to the dev team.

DesignProcess.png

The Process Flow

repeat

Design Iterations

Iteration 1 : Simple search

The first iteration is to have a simple ever-present search bar on the page header. When the user focuses on the search bar, they will be shown the three most recent searches. Once the user starts typing in some information, suggested searches will be shown in the search tray.

Iteration 2: Narrowed Search Scope

In this iteration, I added a dropdown to narrow the search scope. This type of design is very popular on websites like Amazon where the user can search within multiple categories. This design will help improve the search performance by limiting the search scope in the backend. Also, the dropdown would eliminate confusion about the different search terms the users can query for.

Iteration 3: Tag-based Design

This design also helps users to narrow their search scope by providing them with smart tags they can apply to their search. Users can add single or multiple tags based on their search goal. 

​

However, during the design critique sessions I realized that this design can confuse the users, as they usually use legacy systems and are not very tech-savvy. As this can be a much unfamiliar design pattern, this might result in high learnability for the users.

Iteration 4: Quick Search

Since multiple users mentioned having 'All Open Claims' readily available instead of them having to search every time,  I conceptualized this design to accommodate that need. Apart from the open claims, I added a couple of other quick queries in the search tray.

​

Researchers pointed out that 'All Open Claims' was the only action that multiple users asked for and we do not have enough research data that indicates having additional actions.

Iteration 5: Advanced Search

To provide users more control over their search queries, I designed an Advanced Search feature. Users can see this button on the Search Results screen. This screen gives the users the freedom to select the Search Category (Loans/ Claims etc) and add Search Criteria based on their needs. Users can add as many filters as they like and perform the search operation. 

​

But the drawback of this design is having the Advanced Search button visible only on the Search Results screen. Instead, it should always be displayed to the users. We are also not sure if this would be too technical for the users to understand and use. We decided to test the feature with some modifications, and capture users' reactions.

rule

Design Validation

Once these iterations were created, designers and researchers gathered together to critique each concept. During these critique sessions, we hypothesized the following:

​

  • Having the search bar on the header and making it available from every screen will reduce unnecessary navigation.

  •  Having recent searches (3 entries) would reduce the number of times a user would search for the same record, improving efficiency by reducing the time on task.

  • Having a category dropdown to filter the categories would improve the findability of information.

  • Having an advanced search feature would help users narrow down their complex searches.

With these hypotheses, we created the following design, which is an amalgamation of the above iterations to test with the users and validate our designs.

Blurred image of designs used for user testing

thumbs_up_down

What did the users say?

After prototyping the above designs, we showed them to 11 users to gather their feedback and reactions. We conducted moderated user testing remotely via Microsoft Teams.

Ever-present Search bar

  • Hell yeah!

  • "It's gonna save a lot of time for me".

11_11_green.png

Recent Searches

  • Users see a lot of value in this feature.

  • They are positive that they will use this feature more frequently.

  • Users' responses ranged from 7 to 10 entries for the number of recent searches.

  • This feature will help alleviate users' cognitive load.

10_11_green.png

Advanced Search

  • Diverse opinions

  • Few users find it overwhelming.

  • Some users felt this feature could let them narrow down the search results and help them find the right record.

  • "I would say I should never have to go to advanced search based on everything you have shown me”

7_11.png

Quick Action - All Open Claims

  • Users were excited to see this feature.

  • They feel this feature is going to be lifesaving.

  • The placement of the button on the top right of the 'File a Claim' widget was well-received

10_11_green.png

Category Dropdown

  • Only a couple of users mentioned that this feature can be helpful.

  • "Looks like an unnecessary extra click".

  • This might be a redundant step as the items in the dropdown are also present in the tabs on the 'Search Results' screen. 

  • The responses from the users were surprising to us.

3_11.png

Action items for the final designs

  • Since the category dropdown feature was not received well, there is a need to add a detailed hint text to let users know about valid search terms.

  • Increase the most recent search entries from 4 to 10.

  • Tweak the search bar design to match the Affinity Design System.

  • Make the search bar component accessible, confirming AA standards.

web_asset

Final Design

The final design for the search bar is created based on user feedback and discussions with the engineering team about possible infeasibility. The following are the modifications made:

  • A clear and detailed hint text is added to the search tray to let users know what they can search for, eliminating confusion.

  • Added Focus state to all the interactive elements like the search bar, recent search items, and close/ clear buttons, confirming AA standards of accessibility.

  • Accessible color choices are made from the design system for all the interactive states in the design.

Component Design

In creating the design components, we ensured that each component included all necessary states, such as default, hover, active, and focused. Our strategy focused on maintaining consistency across the design system, enhancing reusability, and streamlining the handoff process to developers by providing a comprehensive and easily accessible library of components.

Blurred image of design components

Components created in Figma confirming to AA Accessibility standards

Release Strategy

Following comprehensive usability testing, we determined that only the Minimum Viable Features (MVF) would be included in the current release of the search bar redesign. Advanced search capabilities and other explorations will be deferred to subsequent phases and releases. This decision was strategically made to optimize development efficiency and prioritize features that offer the greatest value within the shortest possible timeframe, ensuring we maximize return on investment (ROI) and align with our agile development goals.

Final Prototype Video

local_library

Learnings

  • Knowledge of the entire design process from research to dev handoff.

  • Creating, publishing, and analyzing user surveys.

  • Participating in moderated usability testing and asking follow-up questions.

  • Designing high-fidelity prototypes and working on Allied's Design System to create new components.

  • Learned that a feature as straightforward as a search requires multiple iterations and usability tests to deliver what's needed to solve the user problems, by not overcomplicating the product for them. 

  • Technical knowledge - Deeper dive into Figma.

fast_forward

Next Steps

This feature enhancement is not a single-release task. It spans multiple sprints based on business priorities, value proposition, and resource availability. The following are the possible next steps for this task:

  • Adding a type-ahead feature and providing suggestions as users type in the search query.

  • Implementing Advanced Search feature. 

  • Implementing button-styled tab design. The designs are already created and tested with the users. Implementation can take time due to engineering and PI constraints.

bottom of page