Design challenge: How I designed a pet insurance product page for the FWD SG app using design thinking
This case study showcases my approach for a design challenge that I completed during my application process with FWD Singapore back in 2022. All works and findings are fictitious solely for the purpose of demonstrating my approach to this challenge using design thinking.
The challenge
FWD is introducing a new product — Pet Insurance. How would you design the product in the app?
Please feel free to make assumptions by stating them in your deck and the response can be done in any manner that you deem the best way to illustrate design thinking.
When I first received the brief to the challenge, I was equally worried and excited at the same time. On one hand, there was not much information to work with, while on the other, I was free to make any assumptions I wanted.
As with my usual approach, I laid out a vision and mission for the scenario in the form of an overall objective and design objective.
Overall objective:
Design and implement FWD’s newest insurance product — Pet Insurance — into the FWD iOS and Android apps by leveraging on design thinking to achieve a bottom-up, user centric product offering.
Design objective:
Create an engaging Pet Insurance product page that resonates with pet owners and maintain overall brand consistency by utilising the existing Group design system, brand guide, and relevant visual artefacts (including photos, videos and other media).
It is important to start a project with objectives, and I find that as a designer, framing the objectives into these two objectives helps to clearly define my goals.
- The Overall objective is the goal of the project, written from the point of view a business or user objective.
- The Design objective is what the final design should look and feel like, in correlation to the overall objective.
The Project Plan
Once I’ve got the objectives defined, it was time to plan out the project. Since I am given the liberty of taking assumptions, it is important for me to note them down and refer to them as I go along in the project.
The scenario provided is very board — simply “FWD is introducing a new product — Pet Insurance” — therefore many assumptions need to be taken to anchor the scenario down to be more realistic in a typical product development cycle.
I also found it important to plan out the overall Project Plan, along with roles and responsibilities of different team members.
Why is that important?
Understanding the roles and responsibilities allow me to properly scope my responsibilities in the project.
For example, it is very clear that product pages on the FWD Apps are webview pages rendered in-app. Thus, this involves the owner of the website, assumed to be the Head of Marketing, and the need to involve copywriters for the content.
This is also why you will see later that the prototype draft does not have proper content — simply because it is nonexistent at this point, and also in a real world scenario, it will not be handled by a Product Designer.
The Design Plan
With the Project Plan laid out, it is time to jump on the Design Plan, or rather, a strategy of sorts.
One of the most common (also tested and proven) design thinking strategies will be the Double Diamond methodology.
I have chosen to apply this strategy to this project right from the start, with the assumption that no content or copy has been written yet.
Why do I do this?
By applying design thinking right from the start, we will not be simply validating what we have created, or also known as a ‘disaster check’. Instead, we will be embracing the power of design thinking to allow potential customers to co-create the entire product from scratch.
This will allow us to leverage on the design thinking processes to better informed about the product market fit, demographics, user needs, and more. Thereafter, the insights gained can be used to to steer product and design decisions.
While the double diamond approach can be applied in a linear way, we should use it in an iterative manner, where we do not just move between the different phases from left to right. After all, the art of design thinking is to rapidly understand users, define problems to solve, rapidly ideate, test, and repeat.
Defining a Product Vision before we start
One modification I have made to the traditional double diamond approach is to start with a product vision. Jumping head on into the discovery phase can pose a risk — what are we trying to discover? Why are we doing this?
Therefore, by outlining a product vision right at the start, it will help guide the team towards a specific direction. This becomes the Northstar of the proect. Thereafter, it is important for us to revisit this vision during the iterative process.
Discover
Being new to the FWD app, I spent some time studying the Information Architecture and how products are presented. It turns out that all the products on the FWD app follow a consistent IA. Therefore, inserting the new Pet Insurance product should be simple.
I also did a quick desk-bound competitor research to find out how other insurance companies were presenting their pet insurance on their websites.
Define
*Note: From this point onwards, all materials are purely assumptions. There were no real user personas defined for this project, as there is no actual user research done.
Customer Personas
When it came to the Define phase, I created three proto personas to demonstrate the typical process of crafting user personas. In my experience, user personas tend to be design artefacts that are created early on in a project (especially by consultants) to beef up a design proposal, and archived somewhere, never to be seen again.
I prefer to utilise personas in two practical ways:
- Distill them down to archetypes. Archetypes are broad categories of the main users of the product. They are useful to quickly recall what types of users there will be. For example, we may have a archetype called “The Karen”, and they probably have to be treated with extra TLC.
- Whenever in doubt, ask ourselves: “What would ________ do?” Back to the Karen example, when we are designing a feature and want to imagine how a user will use it, we can ask ourselves “What would Karen do?”, or “How will Karen use this”. We can almost immediately imagine how a Karen will behave in that scenario 😅.
For this design challenge, I crafted three personas, and mapped out a user journey for each of them.
After I’ve got the User Personas created, I can then put myself into their shoes figuratively and imagine how they will experience the product.
Note: This is a highly imaginative process and might not come intuitively to non-designers. Role-playing as personas is also actually a relatively fun process. While role-playing, we actually have to take on their personalities and imagine how they behave when using our own product!
Priority Matrix
A priority matrix is an extremely useful tool to define design decisions. It is visual, and it allows team members and stakeholders to prioritise features and information with different perspectives.
For this scenario, I chose to plot UX against Product in the X-axis, which I find to be a typical use case. As a product designer, I find myself having to weigh the product (or business) objectives against a user experience one. I’m not saying that they are always on opposing ends of a spectrum — I’m highlighting that usually features and information that have a higher business value tend to be a little clunky when it comes to UX.
Next, the Visibility of a piece of information is measured on the Y-axis.
Why do I do this?
In my experience, business stakeholders do not speak UX even though they use that term a lot. Most of the time, UX refers to themselves. By pitting UX and Product on two ends of a spectrum, it allows us to focus on weighing the UX and Business value of prioritising any feature or information.
This will inform us:
If a feature is a priority to be built, and what value it brings.
If a piece of information should be obvious to users, and what value it brings.In the example here, a Call to action button needs to be super obvious (High visibility) as it has much business value (Product).
App Information Architecture
As mentioned in the Discovery phase, the arrangement of products within the FWD App is relatively straightfoward.
In my proposal, I take the assumption that the Pet insurance is placed behind “Personal Accident”, but before “Maid”. Since the Pet Insurance product is brand new, it is highly likely we will promote it via the Promotions and Latest tabs. However, within the full product catalog, it will be dependent on the various product stakeholders where Pet ranks in the overall Information Architecture.
Brand identity, mood board
Lastly, since this challenge requires me to design a product page, I put together a simple moodboard to get a sense of the look and feel of the final design.
One of the key items of the Pet Insurance product will be how it is presented, or branded. The most obvious portion will be photos and imagery, which is a constant in all FWD product pages.
I will probably suggest testing different images and mood boards with focus groups to identify what images resonate best. An educated guess will be happy owners smiling with their cute pets.
Design & Deliver
Finally, we’re done with our design definitions! In a typical design phase, we should be brainstorming many ideations. However, in the context of my design challenge, designing a new product page doesn’t allow a lot of room for ideations, as I’ve taken the assumption that all product pages should look consistent on the FWD SG app. Therefore, the final prototype is designed to look as close to other product pages as possible, with the exception that the quote builder having an interesting spin to it.
View the prototype below:
On the app, I will not suggest placing the Pet insurance product upfront, as I assume that the products displayed on the home page are prioritized by performance. That being said, the Pet Insurance, dubbed “Pet First”, is slotted into the product catalog and promotion pages.
The new Pet Insurance product will definitely be part of the “All products” page under the “Buy” tab. However, the trick here will be where it is prioritized from an Information Architecture (IA) pov. In my opinion, it boils down to getting the stakeholders of each insurance product category to come to a common consensus. I will assume that while it is a new product, Pet Insurance will not come before some of the key FWD insurance products like Critical Illness, Vehicles, Life, and Personal Accident.
An Innovative Pet Insurance Quote Builder
- Note: This is a feature born entirely out of imagination.
Pet insurance is an immature product in the market. Given that there so many different types of animals that people have for pets, I imagine a few things:
- Pet owners would want to know if their pets are insured.
- There are different criteria for different pets, since animals have different life expectancy than humans in general.
Therefore, having an interactive calculator can potentially provide a fun user experience to find out about insurance coverage for different pets.
Wrapping things up
To conclude, it was an extremely fun design challenge and I enjoyed every bit of effort put into it. I completed the challenge in less than five days, spending only a few precious hours on my evenings after work. I am happy to say that the effort paid off, as my submission eventually got me the role.
What’s next?
Earlier on, I discussed about the Double Diamond design thinking methodology being used in an iterative manner. In our project, the next steps will be to put the design solution that was designed to the test.
Focus groups, workshops, user interviews, or any other means of UX research can be employed within reasonable means to achieve results.
Thereafter, it will be a continuos iterative process. Te important thing to note here is that during this iterative process, we keep ourselves on track by always referring to the Product Vision.
This case study was adapted from my original submission that was created all on FigJam. Take a look below!
