I joined WeatherCheck as the founding designer in October of 2017. While I worked on all marketing and product designs through October 2019, this is a case study of the evolution of WC’s top-of-funnel and consumer product: the Single Property Report.

SERVICES: UI/UX, Wireframes, User Research, Product Design, Application Design
YEAR: 2017-2019

About WeatherCheck

WeatherCheck is a SaaS company that protects one of the most expensive assets a person purchases–property–against undiagnosed hail damage. Each year hailstorms across North America cause more than $10 billion in damage. But because the damage is often not discovered until months or years after an event, mitigation and repair costs escalate. Add to this that often insurance companies will not approve a hail damage claim if more than 365 days have passed.

WeatherCheck pinpoints the size of hail and indicates whether damage has occurred to an address with 90+% accuracy. They’re able to get such a high accuracy without putting any devices on a structure; it’s all pure data, data, data. So the onboarding of a new property only takes a single click.

Primary users are enterprise-level customers in the insurance and mortgage spaces, but in this case study, I’ll focus on the evolution of WC’s top-of-funnel/consumer product: the Single Property Report.

My Role

Founding Designer at WeatherCheck

I started with WeatherCheck as a contract designer in October of 2017. The co-founders were looking to design a prototype of their flagship product (7 core features) in time for an accelerator presentation….in 2 week’s time. Miraculously, after many long hours of downloading domain knowledge and late nights working on the initial UX/UI, I delivered a working prototype in time for the presentation.

I took on more contract projects with WeatherCheck until I was hired on as the founding designer in February of 2018. I lead all UI/UX design efforts, set up design standards including our design system. I also lead digital marketing.

In my time with WeatherCheck we’ve been accepted to Y Combinator (W19) and won numerous awards including being named a Top 5 Finalist in Startup of the Year 2018 and winning Insurance Information Institue’s and InsurTech Connect’s Inagural Resiliency Award in 2019.

Phase 1:


WeatherCheck’s real product is the sheer amount of data they collect and analyze predominantly around weather and location-based assets. In the early days when they were pitching investors and sales prospects, they needed a way to a) show that they have the data they say they have, and b) show that it’s accurate.

After a few meetings with requests of “Oh, I want to see my address,” the Single Property Report (SPR) was born. Eventually, this turned into the start of the B2C funnel but that wasn’t until the redesign in early 2019.

Initially, we had two versions of the SPR: one for consumers just checking their address and the other for the enterprise application. The focus of this case study is the consumer application but it’s important to note that both versions are closely linked. The consumer version is a distilled version with only key features and goes back 365 days.

The consumer version is further broken down into two parts. A site visitor can search an address to see the size and date of all hail events that occurred there. For a nominal fee ($10/month) they’re able to sign up for continuous monitoring to get text message alerts when hail has affected their property.

At this point, the high-level goals of this project were to:

  1. Have a working proof of concept prototype within an incredibly aggressive timeline of 2 weeks
  2. Search for and display the address, an image of the address, and the past year’s hail data associated with the address
  3. Have this tool available for sales and investor meetings

Phase 1:

The first Single Property Report

It’s obviously a lot to download domain knowledge and design out a full prototype in 2 weeks. This first design was meant to be proof of concept, something to test against.

User does not have an account

There are 4 main components on the public SPR:

  1. The property image
  2. The hail events table
  3. If a user has not created an account: A CTA to sign up for ongoing monitoring
  4. If a user has created an account: A list of tweets geo-targeted by the property’s address and filtered by weather events

The initial assumption was that people would challenge that there was hail at their property (“It never hails here!” or “I didn’t see it hail so your data must be wrong!”) so I wanted to add as much property identifying information as possible (e.g. roof type, property age, etc.) to subconsciously drive the point of “Here is all the property information that you know is correct, so by default, the hail information must also be correct.” Unfortunately due to time and capacity constraints, the design was pulled back to just show a large Google areal view of the property.

User has an account

The main focus of the page is the hail event’s table showing the date and the hail size. Pretty straightforward. The hail icon was added with the intention of helping a user visually differentiate between other perils (snow, wind, flood) that were in the pipeline.

Gathering Data:

User Research, Analytics, and Company Business Goals

This first iteration of the SPR was live for about a year with minimal changes before the redesign. In that timeframe, I gathered user input and analytics to help shape the next version of the Single Property Report. Company KPIs also shifted so that played a role in what came next. I’ll highlight the finding’s in this section and speak to the solutions when analyzing the next design iteration.

Company Goals:

As the company matured, we realized that we need to:

  1. Drive more traffic to the marketing website, 
  2. Increase the number of people that searched an address, and
  3. Increase the number of people that created a free account to meet growth KPIs.

While these goals are predominantly a marketing question, goals 2 and 3 were also design problems. I had to ask, what are the best conversion practices? Are there any design elements that are currently hindering the address search or sign up?

The company also agreed that the paid version of the property report was not enticing enough in it’s current state so we dropped it and focused solely on the free version.

User Feedback:

User feedback really fell into three camps:

  1. Users that didn’t understand the value of the report / said, “I know the weather at my house.”
  2. Users that didn’t know what to do after searching their address.
  3. Users that understood the premise but were worried that filing an insurance claim would increase their already high insurance premium or worse, they’d get dropped by their insurance company.

With the first group of users, it started to become clear that not everyone needed to create an account. Some people lived in areas of the country where there really was little hail risk (quick meteorological note: hail can form anywhere thunderstorms occur). It became clear that we needed to narrow our audience further.

Of course there was still the matter of finding the proper language to refute the “I know the weather at my house” statement. But upon closer inspection, I realized that there was a bigger problem around language. Around 30% of the people were resistant to the idea of WeatherCheck because they were under the impression that WeatherCheck put a device on their property in order to monitor it.

The second group of people, the ones that didn’t know what to do after searching their address were expected. Talking with users, they would say “Now what?” “What does it mean I have 1.5 inch hail?” “What should I do next?” Users weren’t satisfied with the simple diagnosis of “Everything ok,” or “File a claim” that the system was able to give.

While we were comfortable answering these questions at length after a quick in-person analysis at meetings and events, the WeatherCheck system wasn’t mature enough to answer this in-depth on its own for the digital masses. To us, it was more important to have a high level of accuracy than misdiagnose a problem. At the same time, engineering resources were stretched thin. Backend architecture, data intake, and data accuracy were higher priorities at this time, and understandably so. So in order to answer these questions, I used Google Tag manager to trigger different educational email campaigns based on the status of the property.

In terms of the third group of users, it became even clearer that we needed to push on education. Homeowners often said that they were afraid to file an insurance claim in case their premium went up. They were unsure about what happens next after they file an insurance claim. But more importantly, there were many misconceptions around what you should and should not do when filing an insurance claim.


  1. I had Google Analytics and FullStory (a website recording software) at my disposal and the findings were interesting.
  2. Through Q4 2018, 65% of all visitors were new.
  3. The states with the most addresses searched were KY (understandable since that’s where WeatherCheck is located) and top hail states like Colorado and Texas.
  4. 62% of addresses searched had 3 or fewer hail events within the past 365 days.
  5. An unexpected trend was that about 14% of address searchers would search more than one address.
  6. About 23% of users who would type in an address never make it to the Single Property Report (this was very concerning).

Phase 2:

The Single Property Report 2.0

Ideally, all user feedback and goals would have been answered by the redesign but in order to keep the design focused I needed to prioritize. The top 4 goals were:

  1. Analytics: Understand why 23% of users who would type in an address never made it to the Single Property Report and come up with a solution
  2. Business: Increase the number of people that searched an address, and
  3. Business: Increase the number of people that created a free account to meet growth KPIs.
  4. User Research: Answer the question, “I don’t know what to do after searching an address”

Phase 2:

Goal 1: Decrease User Drop-Off

The first course of action was to understand why 23% of users who searched their address did not make it to the report. After diving further into Google Analytics and watching various FullStory sessions, three things became clear:

  1. Very few mobile users would make it to their address report, they would remain on the home page indefinitely. Thankfully this was quickly addressed via a bug fix.
  2. About 70% of the time (on both desktop and mobile) it would take the system of a few extra seconds (~10-15) to process before it could load the page. It became clear that this was a larger architectural issue that would take engineering a few months to solve.
  3. Users would sometimes type in an address that was unrecognizable by the system even though it was correct. For example, a user would type out a city like “Culver City” instead of “Los Angeles” and the system would not register the address.

The following changes decreased user drop-off rate dropped from 23% to 9%.

Once Engineering implemented the mobile bug fix there were still the other 2 problems to fix. After some research and discussions with Engineering, we agreed that implementing an address autocomplete and validation tool was the best course of action to fix the CulverCity/Los Angeles issue.

This way, as a user was typing out their address they’d get an autocomplete dropdown of suggested addresses. In addition, our validation tool would kick in and reformat the address, solving the Culver City/Los Angeles issue. This also caused us to add in better form validation logic. If a user input an address WeatherCheck did not recognize, they received an error message and were not able to click through to the property report.

The final problem of the long load times wasn’t so much as solved as it was bandaided over. Like I mentioned earlier, solving this problem would take larger architectural changes that were out of scope for the time being. So in the meantime, we implemented a load screen to show the user that the system was not frozen, just working through data.


The user drop-off rate dropped from 23% to 9% as a result of these changes.

Phase 2:

Goal 2: Increase Address Searches

In order to tackle increasing the number of addresses searched, I had to understand the baseline. Prior to the redesign:

  1. Only 6% of all site visitors searched an address
  2. 1% of people who searched an address created an account

The numbers were lower than I initially anticipated but considering we weren’t running any ads it wasn’t completely dismal. The only way users are able to search their address is via the consumer-facing website, so this meant that a redesign was in order. But because most users searched their address from the home page, I was able to focus first on the home page, then the rest of the site.  (This is a bit auxiliary to the Single Property Report but bear with me.)

After the launch of the new home page, address searches increased by 100%. Searches on the home page remained steady at this new rate (12% of all visitors) in the subsequent months.

Old design

The original design was very flat and didn’t explain well what the company did, many people didn’t know that we were a SaaS company. It was also text-heavy and not very interesting.

New design


The first thing I did was try to visually explain what WeatherCheck did. Plus the goal was to make the headline a lot clearer while keeping it short. After A/B testing some copy, we landed on very to the point language. By this point, we also had a few high-quality write-ups from Forbes, Business First, and TechCrunch so I added those logos high on the page for social proof.


By this point, the company had also shifted more towards enterprise users so the company description was revamped to incorporate them. The blue banner with hail facts helps put actual numbers (and consequences) to the problem that WeatherCheck is solving.

Product shots and CTA:

The new home page uses product shots to continue to explain the problem and how WeatherCheck is the perfect solution.

Finally, the “Search your address” CTA is re-iterated in the footer. Unlike the original design, this version focused on one CTA: Search an address.


After the launch of the new home page, address searches increased by 100%. Searches on the home page remained steady at this new rate (12% of all visitors) in the subsequent months.

Phase 2:

Goals 3&4: Increase User Accounts

It makes sense to combine Goals 3 (Business: Increase the number of people that created a free account to meet growth KPIs) and 4 (User Research: Answer the question, “I don’t know what to do after searching an address”) since they both lead to a user creating an account.

The report changes and then the CTA A/B testing resulted in 9% of all address searchers creating an account. To reiterate, that was up from our starting data point of 0% account creation. And to further put this into perspective, WordStream puts the average conversion rate at 2.35%.

In terms of the Single Address Report, the first thing I did was shrink the Google Satelite banner, it was just too large and taking up too much above-the-fold space. I also added a new summary card to help give a quick overview of the report. Eventually, we had plans of adding new data (other weather types like wind and snow, property information like roof type, etc.) but those were still in the pipeline so this first iteration of the summary card showed the address, largest hail event and the date of the event. This summary card would grow into a place that a user could take a quick look at and understand immediately what the damage status of the property is, “Ok,” “Damaged,” or “Needs further inspection.”

Weather Events table:

An initial design assumption was that more people would have more hail events (4-6 a year) than they necessarily did (0-3). And depending on the area of the country, some people didn’t have any at all. So there was a focus to provide some sort of information even when there weren’t any hail events.

This table was also redesigned to clarify the damage status for users and help streamline the way for future perils. At the end of the day, the most important question a user is asking is “Is my property damaged or ok?” The secondary question is “What caused the damage?” So the icons changed to simple, colored attention marks. There was also plenty of space left for future actions like “Generate a storm report” and “Request a drone inspection” for each individual event.

The Sidebar:

The left sidebar space continued to be a floating space for different modules that we tested. We knew that the current News module needed work and wasn’t fulfilling our ground-truth needs–it wasn’t local enough–so that became a placeholder as we tested out new concepts.

Download the report:

A late request from the Sales team came in about the ability to download a property report to a PDF. Many of their prospects were asking about specific addresses and hail storms prior to meetings to confirm the validity of our data against their records.

Until this point, the only way for anyone see the weather events of an address was to either have an enterprise account or search for it and create an account. So this was a feature that would help streamline more business prospects.

An added bonus was that we could now tell users that they should print out a report and mail it to their insurance provider when filing an insurance claim, increasing our visibility within the insurance provider company. The end goal was that insurance carriers would be meeting with our Sales team about implementing WeatherCheck for their portfolio of properties while at the same time receiving these reports from their insureds when they file a hail roof damage claim; proving our point that homeowners care about their home and would see WeatherCheck as a valuable addition to their insurance policy.

Non-signed up User:

Two of the 3 main goals of this redesign were centered around acquiring new users, it was all about finding the right balance of showing enough information to make a user interested in signing up for WeatherCheck without giving too much away.

So this version we hid the colored icons that showed the severity of the impact an had a neutral “?”. Only users that created an account would have access to them.

This version also included more CTAs to sign up and create an account, one specifically with a very clear “Don’t know what to do next? Create a free account!” CTA. I initially designed 2 versions, one with a signup button, the other with a sign-up form directly on the page. Once we pushed these changes live, I set up an A/B test through Optimize to test out the best option.

This CTA testing included using our Drift integration as a further hint to create an account.

A more subtle addition was including some statistical data around hail damage and continue to answer the “Why do I need this?” question. The initial goal was to pull hail statistics like “Most recent hail storm” for the Metropolitan Statistical Area or state but that was scrapped as being too big of an ask for not enough of a return. I still felt it was important to iterate some of the statistics from the home page so I pulled a static number for the United States.


The report changes and then the CTA A/B testing resulted in 9% of all address searchers creating an account. To reiterate, that was up from our starting data point of 0% account creation. And to further put this into perspective, WordStream puts the average conversion rate at 2.35%.

Phase 3:

The Single Property Report 3.0

After having the previous report live for a better part of the year, it was again time to revisit it and see what updates needed to be made.

User has an account

User feedback was that they wanted to see a big image of their property. This was further corroborated by FullStory, the first thing a majority of users did was move the satellite image around.

So I split the screen in half and turned the satellite image into a full-height image. It made the report feel cleaner, but like it had more data without actually adding anything new. This also sets the stage for us to start adding satellite services and images (such as drone footage or images taken by adjusters).

I continued to play with the level of information that should be shown to non-registered users. This version continues to have the hidden icons, but another version takes an even further step back and simply shows the number of hail storms that have affected the property without naming the size.

There was also a design to test Single Sign On (SSO) via Facebook and Gmail since studies show that this helps improve conversion rates.

User does not have an account; version A for A/B testing

User does not have an account; version B for A/B testing

User does not have an account; version C for A/B testing


This version of the report remained in the backlog as other enterprise features and new data intake points were prioritized.

Want to see more?

Due to confidentiality and patent-pending technology, please request to see more work for WeatherCheck.