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 the user experience of WC’s data tables.

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.


Unifying Tables

WeatherCheck is a very data-heavy application, much of my work on the enterprise product was around finding more useful ways of displaying and manipulating it. By far the most wide-spread way we showed our data was via a table. Its uses varied greatly.

We had the Weather Events table that would fluctuate between 0 events to 40. It had limited public views and different actions based on the user type.

Weather Events table when a user does not have an account

Weather Events table when a user has an account

Enterprise users had a table that listed all their entire portfolio of properties. Again, this could house as little as 15 properties (well technically two) or go up to the thousands based on the client. Users also had the ability to apply certain actions including searching, filtering, adding new properties (individually and in bulk), deleting, and grouping properties together.

Property Table

Although they have different uses and volumes of data, all tables needed to feel and work similarly no matter their use. The original tables were simple so that we could get the product out the door. As user feedback rolled in, updates were made.


Filterability and Searchability

One of the first pieces of feedback was that users were unclear on how the tables were sorted. This turned into a simple fix, we added an underline to highlight the column and used an arrow to indicate the direction of the columns. This added the sorting functionality across all columns.

In addition to sorting, we also added the ability to search and filter. Originally the filters were closed and needed to be activated with an icon. While this design was cleaner, feedback said that it was difficult to find so the default state was opened.

I added a skeleton UI for when a user is filtering or searching through properties. Often the search/filter state would not be needed, but it was there for when users searched through particularly large data sets and the system needed more time to think. This way users knew that the system was not frozen, just needed a few extra seconds to chug through data.

Once we added filterability and searchability, some users would complain that certain properties were missing. It turned out that users were forgetting that they had searched or filtered. So updates to this feature included a very clear state change when something was searched or filtered.

If users performed a search/filter that resulted in no properties then they would see this empty state. Throughout the application I always wanted to provide users with an option to remedy why they were seeing an empty state.


Bulk Upload and Error Handling

When WeatherCheck first launched, we had a very hands-on onboarding process. New clients sent us their property addresses as a .csv and it was uploaded by our engineers via the backend. Users could add addresses individually but not in bulk. Building out a user-friendly bulk upload would have taken considerable time and energy in a time where we had to be very thoughtful of what features we built out next.

Over a few months as new clients were signing up it became clear that a user-facing bulk upload feature needed to be implemented. I collaborated with the engineers from the very beginning, I needed to translate what they were currently doing into a user-friendly feature. As we were working through the process they mentioned how much time they would spend on failed uploads and cleaning data. Digging deeper into this issue I found that likely to happen fairly often to users as well.

I had to account for the following things:

  1. Incorrectly formatted .csv files
  2. The possibility of repeat addresses
  3. The possibility of non-existent addresses (or addresses deemed non-existent by our address validation tool)
  4. Longer upload times on larger data sets
  5. The possibility of the upload not working for some unforeseen reason.

In the design, I focused heavily on data confirmation and data mapping. From the beginning users have the ability to download a .csv template to see how their data should be formatted to try and prevent any upload errors.

After a user adds their .csv, they’re asked to confirm that they uploaded the correct one as we show the information back to them.

To further confirm that the data imports property, a user is asked to map their any columns that have data to the corresponding table headers. This is particularly useful when a user doesn’t use our template, this feature gives the user the ability to set a column to “Ignore.”

At this point the data starts to populate into the WeatherCheck system. First they’re uploaded to the system, then they’re standardized and verified, and finally they’re checked for weather events.

In the past we’ve had issues with verification, sometimes the third-party address standardization and verification tool comes across an address it says does not exist even if it does. For example, this happens with new construction addresses. In these cases we want the user to understand that the address was not verified, but that they can override this to say that the address is correct.

As an added precaution, users are able to download a .csv of any addresses that they said were not verified before the addresses are deleted from their account.

If for any reason a user cannot upload their addresses, or it takes too long. We have a Drift event set up to send a proactive, “If you’re having issues just send us your .csv and we’ll do it for you” notification to the user.



Although this wasn’t specifically mentioned by users, a bit of thought went into how we show pagination (I’ll be honest, bad pagination is a personal pet peeve).

The most basic pagination will always include the number of results and clickable page links. This way a user always understands the total number of records he/she is working with and has the ability to move between pages.

In addition to this, tables that tend to be data-heavy like the Property table will give a user the ability to select the number of records shown per page. The default view is 25 records per page, it shows plenty of data but it’s also not too heavy of an initial load.

Want to see more?

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