Banner
Back to works

Ebix E-App

  • Client: Ebix Cash

  • Product: Insurance Solutions

  • Platform: Java

  • My Role: Sr. UX/UI Designer

  • Team Size 6 Members

  • Project Duration 12 to 16 months


Tools we used

Pen paper Figma Figma photoshop illustrator Figma

The Product

The Policy Processor’s E-App (TPP E-App) is a single solution designed to help carriers build rich, interactive and intelligent electronic applications for Agents/Advisors, Consumers and Call Center operations.

The Goal

  • To create an efficient user experience platform as a One Stop Solution for all lines of Life Insurance business (i.e. Life, Annuities, Wealth, etc.)
  • Our goal is develop a framework to support D2C (Direct to Consumer), Agent, Light weight, it can be support for any third party systems (ios, Android), and it can be on the go
  • Currently it’s been used as an exchange model

Problems/Challenges

  • Data capture process is very complex
  • Forms are too lengthy in the application
  • Usability guidelines not implemented properly
  • Difficulty to access the application for Disable users
  • Help/Training not provided
  • Data capture from external sources
  • Application supports for English language only
  • Time to fill the application

Solution/Outcome

  • Changed the form layout
  • Data categorized logically
  • Improved Information Architecture
  • Audited the portal aganist Heuristic Evaluation principles, performed UI audit, and Implemented/Evaluated WCAG 2.1 – Level AA guidelines and provided remediation support to Dev team
  • Chatbot provided
  • Multi lingual support (I18N)
  • ROI increased
  • Our user interface helps to speed up data entering.

Scope of Work and Timeline


Timeline

Qualitative Research

  • A qualitative user research method was employed to learn more about the user's perspectives and motivations
  • User interviews were conducted with three different age groups of users (Agents, Company, Technical Architect). Each group had two to three users participate
  • A questionnaire with primarily open-ended questions was prepared
  • Based on the data, users' empathy maps were constructed to satisfy their needs

Qualitative Research Questions

  • What problems do you have with the current system?
  • What features do you hope to see in the product?
  • What kind of issues are you having with the current application? (Business/Technical)?
  • Does the App appear to be successful in reaching the primary goal?
  • How many different services will you be able to supply with this product?
  • What are the requirements of users?
  • What are the most significant customers and users?
  • Are users able to obtain the information they require?
  • How long does it take a user to fill out the basic information?
  • Are you able to make connections with potential customers?
  • What is the new business's success rate?
  • What are your hopes and recommendations?

Focus Group

Focus group interviews with a group of participants (between 3 and 6) are conducted to learn about the opinions of a group of users regarding a product.

Group Discussions

  • Our team had JAD (Joint Action Discussion) sessions with the product architect, developers, and other managers at this strategy level
  • Technology (UI Frameworks, Database) and third-party service access were discussed
  • Limitations, approvals, timeframes, and financial plans were discussed in detail by our team

Requirements Gathering

During the discovery phase, we gathered all of the materials listed below that are relevant to the business requirements.
  • Business Requirements
  • Technical Constrains
  • Product Template
  • Field Appendix (Application forms)
  • User Profile Templates
  • UW Rules, UW Notes, Auto Assessment, Correspondence, Forms and Letters

S.W.O.T Analysis

S.W.O.T. analysis is a list of our product’s main strengths, weaknesses, opportunities, and threats in an ordered format.

Strengths Weakness Opportunities Threats
  • Allows carriers to quickly deploy formal/informal applications for all lines of businesses
  • Support medical and non-medical (e.g. lifestyle) questionnaire collected via an agent, fulfillment or consumer
  • Helps carriers achieve return on investment through a short implementation project life cycle
  • New Lines of Businesses like General, Health, Motor, etc.
  • New and open market to capture in Latin America and Europe
  • Join forces with other insurance firms to increase the number of people who use the online application
  • Web aggregators such as ipipeline, unqork, and others pose a threat
Internal External

Competitive Analysis

Conduct a competition analysis to determine the strengths and weaknesses of the product's present and potential competitors.

Product Features

Objective:
Streamline and speed the sale of life insurance and healthcare products with a simple e-application that eliminates the need for NiGO applications
Strengths:
  • Not in Good Order applications are no longer accepted
  • Reduces the time it takes for a cycle to complete and enhances the placement ratio
Objective:
Life, Annuities, Retirement, Accident, P&C Consumer, Commercial, and Specialty insurers can use Unqork's no-code enterprise application platform to quickly construct enterprise-ready solutions for all product lines

Strengths:
  • Develop enterprise-grade applications quickly and compliantly across all of your product lines
Objective:
TPP E-App (The Policy Processor's E-App) is a single solution that enables carriers to create sophisticated, interactive, and intelligent electronic apps for agents/advisors, consumers, and call center operations

Strengths:
  • Third-party underwriting rules engine integration
  • Using Chabot's virtual assistance
  • Third-party plug-ins (such as Google Analytics and A/B Testing) are supported
  • BYOD is encouraged (Bring Your Own Device)
  • The application process is simplified and speeded up

User Experience

  • Not in Good Order applications are no longer accepted
  • Reduces the time it takes for a cycle to complete and enhances the placement ratio
  • The application procedure is simplified and accelerated
  • Increase fulfillment turnaround time by 80 percent
  • No follow-up is required for missing or incorrect information, and all processing is done without the use of paper
  • Self-service applications reduce the number of inquiries asked
Fill-able, configurable forms
  • Data entry with guidance
  • Status and error reporting
Usability/Rich Look and Feel
  • Rich widgets and ad controls library
  • Flexible form layouts
  • Full support for themes, skins, and branding
  • Application copying and cloning to simplify data entering
A variety of data entry modes
  • Expert user data input mode
  • Agent/advisor data entry with guidance
End user data entry with rich simplified progressive data entry mode

Personas

User Journey Map

It visualizes how a user iteracts with a product and allows designers to see a product from a user's point of view
User Journey Map

View full image

Process Flow

A userflow was created from the key insights obtained in the storyboard.

Information Architecture

Rapid Prototype/Paper Wireframes

From the userflow we were then able to start thinking about the low-fi prototypes and the necessary components that would need to be on each screen.

1. Get Quote

2. Add Beneficiaries

3. Health

4. Personal Info

5. Payment

6. Review

7. Agree and Sign

Digital Wireframes

The digital wireframes were created and mapped out a user journey from the moment they open the app and entering the data like adding Beneficiaries, Health information, Personal information and Secured payment. And we have provided a wonderful option to the user to review the total application in a single page. If something’s not quite right, user can edit the application.


1. Get Quote

2. Beneficiaries

3. Add Beneficiaries

4. Health

5. Personal Info

6. Payment

7. Review

8. Agree and Sign

9. Confirmation

Style Guides

We decided to create the main UI elements that would be provide and clear and concise visual language aimed at directing people where to go, making them feel assisted and at ease.

Colours

The colour palette we chose was directed by our branding criteria. We maintained a high level of contrast on all of the screens and we were able to check these using the WebAIM colour contrast checker.

Typography


Typography

For the typography ‘DM Sans’ was chosen as the typeface. This particular typeface has been especially designed with accessibility in mind. It has been designed for people with learning disabilities and takes into consideration the shape and position of each letter and glyph.

Typography


Icons

Feather is a collection of simply beautiful open source icons. Each icon is designed with an emphasis on simplicity, consistency, and flexibility.

Source: feathericons.com


Typography

Visual Design Mockups

Desktop

1. Beneficiaries

2. Add Beneficiaries

3. Health

4. Personal Info

5. Payment

6. Review

7. Agree and Sign

8. Confirmation

Mobile

Mockup
Mockup
Mockup
Mockup
Mockup
Mockup
Mockup
Mockup
Mobile mockups

Usability Goals

Review the Usability Standards Checklist before moving on to the next level.
S.No. Parameter Description Verified Not Verified N/A
1 Usability Should test a web page's or application's general usability, including appearance, clarity, and navigation   - - - -
2 Branding The branding should be validated. Visual brand language is a "alphabet" of design components – such as shape, color, materials, finish, typography, and composition – that express a company's values and personality directly and subliminally through captivating images and design style - - - -
3 Page Layout The page layout should be checked. The aspect of graphic design that deals with the organization of visual elements on a page is called page layout. It usually uses organizational composition principles in order to achieve specific communication goals - - - -
4 User Interface / Visual Design The GUI controls should be validated. GUI testing is the process of confirming that a given application's graphical user interface (GUI) functions properly and that it adheres to its documented specifications - - - -
5 Functional Correctness It is necessary to ensure that the application works properly. Validating links, calculations, information displays, and navigation are all part of this - - - -
6 Verification
of code
Should verify that the code used to create the web application (HTML, Java, and so on) was utilized correctly - - - -
7 Browser Compatibility Should ensure that the application performs consistently across a variety of browser types and setups - - - -
8 Device Compatibility Should ensure that the programme performs consistently across several devices - - - -
9 Accessibility Check out the WCAG2.0 Web accessibility guidelines - - - -

Usability Testing

Usability testing is a method of evaluating a user interface design by putting it to the test on real people. With a group of five users, we conducted Qualitative Usability testing to assess the following areas.

Navigation Presentation Content Interaction Accessibility
  • App organization
  • Menu Organization
  • Labeling
  • Layout
  • Fonts
  • Use of color
  • Page content
  • Task functionality
  • Visual affordance
  • Widgets
  • Task flow
  • Feedback
  • Visual affordance
  • Widgets
  • Task flow
  • Feedback
  • Color check

Qualitative Usability test findings

This usability study was split into two parts. From wire-frames to mock-ups, the findings of the initial study led the design process.

Usability Findings

  • Web application layout is not working properly in all required browsers
  • It's tough to move from one screen to another
  • Tab navigation not working properly in all stages (Active/Completed/Error State).
  • Enough space is not provided between field labels, columns, rows, and error messages
  • Hypertext links are not easy to identify without needing to 'mine sweep' (e.g. underlined)
  • The readability of text is terrible
  • The importance of the button is uncertain

Accessibility Findings

  • A “Skip to Content” or “Skip Navigation” link is not appearing in all screens
  • Few of the functions are not accessed via a keyboard
  • HTML heading tags (<h1>, <h2>, <h3> etc,) are not following the proper order in the screens
  • Tab order of the form fields is missing

Accessibility Testing

Accessibility

Web Content Accessibility Guidelines (WCAG)

  • The Web Content Accessibility Guidelines (WCAG) 2.1 establishes guidelines for making Web content more accessible to individuals with impairments
  • Here, we check that the web page's content meets the requirements necessary to pass the success criteria set out by the Client
  • There are two levels of success criteria: WCAG2.1 guideline level A and level AA
  • Achecker, WebAIM, NVDA screen reader, or client-specific tools are used to evaluate the created web pages

A/B Testing

  • A/B testing (also known as split testing) is a technique for comparing two versions of a website or app to see which one performs better
  • A/B testing is essentially an experiment in which users are presented two or more variants of a website at random and statistical analysis is used to discover which variation performs better for a certain goal
  • An A/B test that compares a variant to the existing experience allows you to ask specific questions about changes to your website or app and then gather statistics on the impact of those changes. Individuals, teams, and corporations can utilise A/B testing to make small adjustments to their user experiences while collecting data on the results.

Test #1

Goals: The goal of this study was to remove distracting features on the page and increase user attentiveness. We started with the Beneficiaries section, Plan Details, and Stepping Navigation, which allow users to focus on the application's common components throughout.  

A

1. Beneficiaries info

To reflect the beneficiaries, we used primary color to accentuate the beneficiary names and only included text without a background color.

2. Plan Details

The quote's plan information was recorded and displayed on a highlighted bar to tell the user of the plan they chose and the price they must pay.

3. Stepping Navigation

The horizontal navigation was layered on top of the stepping navigation.

B

1. Beneficiaries info

The beneficiary information was moved to a grey colored bar beneath the plan details section.

2. Plan Details

On a fully covered bar, the plan's elements are highlighted.

3. Stepping Navigation

The stepping navigation was adjusted vertically and to the left.

Results

After performing the A/B test for about 4 weeks, we gathered statistical data, and Version-A obtained 70% more positive results than Version-B.

In version-A, we achieved good results by combining the beneficiaries and plan information in a single row and balancing the data with accent colors. In version B, we chose full width to emphasise the plan details and beneficiaries. Background colors were used to draw attention to the piece.

In the navigation area, we offered vertical and horizontal alternatives. We utilized the same design elements to represent the tabs in both scenarios. The tabs' orientation, on the other hand, has been changed. The tabs in variant-A were horizontally oriented. In variant-B, the tabs were arranged vertically. Both types of tabs are correctly focused. In this app, we limited the phases to six. When it comes to exhibiting a list of tabs, vertical tabs are more user-friendly than horizontal tabs. However, we are currently just using 6 tabs in this application.

The data display is particularly important to the users in these A and B variations. Version-A, on the other hand, was preferred by 70% of respondents due to the elements' lower visual burden. After getting findings from A and B, we reviewed the reports and determined that the majority of consumers require a basic data display. Finally, Variant-A was incorporated into the finished product.


Test #2

Goals: The trial's goal was to quickly enroll recipients. Make it simple for users to submit critical beneficiary data.

A

Beneficiary cards are provided with form components on the inside to quickly collect beneficiary information. Each card contains a separate button for removing recipients. We added the Add Beneficiary button once we finished with all of the cards.

B

To add beneficiaries in this version, click the "Add new" card. When we click the "Add new" card, a model window with form elements appears, allowing us to collect beneficiary information. We added an add photo function in this version to collect the beneficiary's photo. On hovering the card, you can change or delete beneficiaries.

Results

After a two-week A/B test, we gathered statistical data and discovered that Version-B had 83 % more favorable results than Version-A.

Variant-B had a beneficiary portrait instead of numbers, as well as hover interactions, which contributed to the positive results. Variant-A also has the unique capacity to collect data rapidly and efficiently. When comparing A and B, B takes slightly longer to collect data, yet users still require it. Finally, we incorporated Variant-B into the final application based on user input.

Analytics

Our clients do not receive information on traffic and drop-offs on their websites just because we develop and launch them.

Our goal is to offer them with real-time data on how our programme is being used. In order to track user activity and actions on the site, analytics must be included in our web apps. Google Analytics is a strong analytics tool (a web analytics service offered by Google)

Several lines of Google Analytics tracking code can be seen in the code of our website. The code records a variety of events when your users visit our website.

To integrate with Google Analytics, we use the GTM (Google Tag Manager) tool in our application.


The image below is from a live application that shows the total number of page views.

Deliver/Launch

Beta launch

Launching our product in beta, or purposefully releasing an unfinished product to users with known and unknown flaws, is a wonderful approach to find and fix the most severe bugs, usability friction, and poor performance before releasing it in its final form.

Deploy

We uploaded the final result to the cloud.

Development Phase

Functionality Testing

  • Internal assessments will be undertaken to guarantee that the application is tested in a number of browsers and devices, as the client has requested. Usability evaluation
  • Any problems you may have will be addressed. This method will be followed until all issues are fixed and all client criteria are met After that, the code will be checked in and built
  • We will handle any issues that arise after the build is sent to the Quality team

Final Thoughts

  • Keeping the team organized and motivated was the most difficult component of the endeavor We only had three weeks to complete our study and prototype, so each day felt critical, and we needed to stay organized to stay on top of things We were intended to hold daily stand-up meetings every morning, but we didn't always manage to do so, and I believe this made the team feel dislocated because we weren't always clear what everyone was working on. It's a valuable lesson to remember for future endeavors
  • We faced some difficulties initially in the project when deciding on the user journey and the best path to take. We had several great ideas, but I believe some of them over complicated the project more than it needed to be, especially given we just had to present an MVP (minimum viable product). In the future, I believe I would push to guarantee that we focus on the most crucial, necessary features of what is relevant to the end user, and that we store the additional ideas for later development
  • Overall, I am pleased with the project's end result, and I believe that working on a real client brief taught me a great deal. It would be fantastic if we had more time to work on this and could run a couple more iterations of the design process to validate some of our assumptions and obtain feedback from real consumers

Thankyou

For taking the time to go at my work! If you'd like to participate,
See more or contact us for additional information.


Check out some of my other case studies.