The research team went back to the product team and told them that we need to learn more about our users, their needs, pain-points and expectations before jumping to design.

Discovery research

Customers reported a strong desire to self-serve and were frustrated by a lack of helpful content / sign-posting. They mentioned it’s “light on information” and encourages them to “just get in touch.”

Customer service representatives said they spend most of their time handling queries that can be self-served online. This results in unnecessary calls to the call centre, contributing to high call volumes and long wait times, resulting in customer dissatisfaction.

Most customers didn’t notice the direct enquiry forms in the accordions and said they’d use the phone or general email (most salient information on the page).

Customer service representatives said they receive a lot of queries to the general email address. This results in queries needing to be redirected out to the appropriate teams, resulting in delayed responses for customers.

Customers thought the enquiry forms were “generic” because of the generic heading on the page, despite being direct to the relevant teams. Users also commented that the hierarchy of the form fields was “strange” or unconventional and it was unclear why identity information was being asked for. Users also noted the form doesn’t give an indication of when they can expect to receive a response.

Customer service representatives mentioned that the enquiry form is poorly designed as it does not capture the necessary details to validate the customer’s identity at the first point of contact. This results in unnecessary back and forth between agents and customers to verify their identity, resulting in delays in getting their queries resolved.

Design ideation

Following the ideation workshop, low-fi sketches were created and brought to a stakeholder session where we narrowed down which concepts to take to test with users.

This concept centers around a search-driven experience where users enter questions into a search bar, returning relevant FAQs. Selecting a result brings them to the associated FAQ category landing page (e.g. Policy Renewals), featuring related FAQs and a pre-filled enquiry form linked to the appropriate team.

Users who prefer direct contact can access a separate ‘Contact Us’ page with all communication options.

Challenges:

• Users must use search to discover support content, limiting visibility of self-serve options.

• Implementing scoped search requires significant backend work, including extensive content tagging and accommodating varied natural language queries.

The next approach showcases a curated list of top questions and organises contact methods into in-page tabs (enquiry form, phone, location). Each FAQ category links to a dedicated page with related questions and a pre-filled contact form.

We selected this concept as it balances self-service and direct support – giving users quick access to common queries while keeping contact options easily accessible throughout the experience.

The enquiry form is dynamic, and fields change depending on user selection i.e. if a user selects ‘Yes’ to ‘Are you an existing Vhi member?’, they are prompted to enter information to verify their identity. Identity validation fields are mandatory to help the user to get a response as quickly as possible. The form contains a ‘Query type’ dropdown which allows users to send their enquiry directly to the appropriate team. This helps users to streamline their queries which helps them to get a quicker response.

Seeing as there was no existing content to support FAQs (as desired by users) the research team facilitated workshops with the RI team to identify top queries from customers and generated FAQs and responses to test with customers.

We developed a mid-fi prototype which was then taken to test with users. It consisted of a ‘Help & support’ landing page with a sample of top FAQs (to promote self serve) and all methods of getting in touch (a contact form where the user selects their query type to direct it to the appropriate team, direct phone lines & location information).

The FAQ category cards link the user to separate dedicated FAQ landing page with direct enquiry forms for the appropriate teams.

Users repeatedly flagged that they disliked having to click through multiple pages of pagination to view all of the FAQ categories. They would prefer having all FAQ categories available on the landing page so that they can try to self serve before reaching out for help.

Instead, we placed all of the FAQ categories on the landing page so users could peruse them before reaching out to customer support.

Users didn’t value the “generic” options for getting in touch on the help and support landing page & suggested the page is “trying to do too much” and contributes to cognitive overload.

Users appreciated the pre-populated enquiry form on the FAQs landing page and liked that the form sends their query directly to the appropriate team. They also liked that the direct methods to get in touch are listed here, “[it’s] the right information when I need it.” 

To reduce overload on the help and support landing page, we moved the generic contact information to a separate landing page that is accessible from the H&S landing page.

Some users had difficulties locating the relevant FAQ under the current categories. There is a degree of overlap between the categories. For example, we tasked users with finding info on how to troubleshoot not recieving the PIN to access their claims statements in myVhi, the correct location is ‘App & MyVhi’ but some went into the Claims section.

*The solution we proposed was a scoped search function so that users could search within the FAQs. However, due to the extensive backend work required to develop this, it was considered as out of scope for MVP. 

As a work-around, the research worked together with the RI team to identify the FAQs which could belong in multiple categories and duplicated them across the different categories to help with findability.

The final designs encompassed all of the needs and preferences identified through user testing including:

1. Discoverability of self-serve content: A desire to see all FAQs on the help & support landing page to improve discoverability of self-serve content

2. Reduce cognitive overload: Removal of in page-tabs with generic contact options (enquiry form, phone lines & locations) & placing them on a separate dedicated ‘contact us’ landing page to reduce overload

3. Enhance findability: Duplication of FAQs which could belong in multiple categories + *scoped search in future release (post MVP) to enhance FAQ findability.