Designing the Dashboard at Covie

Covie makes insurance data more accessible. It offers an API and developer tools to collect and monitor insurance policies.

In early 2022, we embarked on building the first version of a user dashboard. We already had customers connecting data who were manually onboarded with the API. With policy data flowing through the system, we needed to ship as soon as possible.

This post is about the design iterations of the dashboard. You can also read about one of the coding challenges I faced if you're interested.

Version 1

I took a fairly literal approach to the initial design. The structure of the API could almost be mapped onto the layout of the dashboard. Spoiler alert: this was a mistake.

Navigation

Aside from billing and account wide settings, the general experience of the dashboard would be within the context of a single application. This context could be easily switched via an application selector which was front and centre on the main sidebar.

At the bottom of the sidebar, with a clear seperation from the primary navigation, were links to account settings and the user profile.

Sidebar v1

Welcome Screen

There was no welcome screen in terms of what you'd typically find in most dashboards. I figured as everything was centered around a single application, why not just present the users exactly that?

It offered information you'd expect to find on a welcome screen such as recent data and stats, but nested underneath a set of tabs to access other key functionality pertaining to the application.

Welcome Screen v1

Integrations

Integrations are an extension of an application. It inherits its configuration and is largely there to provide more granular control over what type of policies can be linked and how often they are refreshed behind the scenes.

Once an integration had been created, the user would be prompted to install the embed snippet on the website. We'd hold this view in place until we detected the code was successfully installed.

New Integration v1

Once an integration had received data, we'd proceed to show an overview. This looked almost identical to application overview - which became a source of confusion for some users. This is something we'd address in the future.

Integration Overview v1

Policies & Links

The policies screen provided an overview of all policies linked via the current application. Users could search and filter and inspect a policy in more detail.

Selecting a policy would take you to an overview with key information about the policyholders, carrier and limits.

It was decided to raise links to a primary item on the navigation to allow users to quickly monitor link performance. A link might have been abandoned or experienced a failure, which would be useful to inspect.

Policy v1

Fundamental Issues

The initial version of the dashboard got us off the ground, but it certainly wasn't perfect. There were some fundamental issues with how I'd designed it. Some of this was down to not properly understanding the user base but also from suffering with tunnel vision.

Terminology

One of the first issues that we picked up on was that some of the terminology was causing confusion. The two culprits being applications vs integrations and links vs policies.

These entities made sense at the API level. It gave the backend team a clear way to structure and delegate ownership. In a user interface, it was a bit of a mess.

While we could introduce some form of improved onboarding and learning tools, it was decided we had to rethink how we package up and present this information to the user from the ground up.

Unexpected Guests

The dashboard was designed with developers in mind, however we found a lot of the users were just not developers. Most users simply wanted to sign up and link policies as fast as possible, ideally without touching any code. There were also a few technical features such as webhooks and API credentials that were sitting front and centre and often overwhelming these less technical users.

Rebuild vs Rewrite

A redesign had to happen no matter what. The question mark was whether we would work with the code that we had or start from scratch. I had already been working on some ideas of how we could rethink the way in which we present the data to the user, and I was dreading trying to wrestle the existing code to make it work.

These fundamental design issues mixed in with some performance concerns meant that in the summer of 2023 I decided to completely redesign and rewrite the dashboard from the ground up.

Version 2

This was a massive opportunity to take stock and really iron out major kinks in the design from the initial version. Taking onboard customer feedback and drawing upon our own experience, a few key design decisions were made:

• Drop the notion of integrations and links
• Focus on the application, sources and policies
• Clearer onboarding and welcome experience

Restructure

There were clearly issues with how we were presenting the data in the initial version - it was confusing and annoying to use. We needed to simplify things, ideally without having the change the API itself.

Navigation

The first rethink was how to handle navigation. I wanted to avoid the battle between applications vs integrations and links vs policies.

An application would still need to sit at the top level. This is key for users to test in sandbox mode and map applications to their existing workflows. I shifted the application selector to the top bar to de-clutter the sidebar and give a bigger indication that the application is dictating the experience.

This left the sidebar with just three top level navigation items:

• Dashboard
• Policies
• Settings

Below this would sit a new "sources" panel. Sources are essentially a rename of integrations to something friendlier. As we expected most users to only have a small number of sources within a single application, we felt it was safe to include them here. There'd also be a fallback page once the list got too long. Moving sources out the top level navigation also helped subconsciously communicate that anything they interact with in the sidebar is not a dependent of a source.

Navigation

Welcome Screen

The main change to applications outside of moving the selector was dropping the default application welcome page. As the whole dashboard experience is centered around the selected application, the functionality the previous area offered should just be better spread out and integrated in the dashboard as whole.

We shifted technical features such as policy settings, webhooks and API credentials inside settings. This wasn't at the detriment of developers, as they can still access the features they needed, we just put them in their own space. This kept the UI minimal and was less confusing for every day users.

We shifted to a more traditional welcome screen but with an emphasis on modular prompt cards. Depending on the users activity, we would display helpful reminders here to help them complete their onboarding process. This would include things such as:

• Creating their first source
• Linking their first policy
• Topping up their account balance
• Links to documentation

There would also be an area to view most recent policies in a format we introduced called "inbox".

Welcome Screen

Inbox

To make policies feel more actionable, we introduced the notion of an "inbox".

Essentially, any policy that was linked would move to a users inbox by default. Once they performed a key action such as sending the policy to one of our integrations or manually updating its status, we'd mark it as archived - moving it out of the inbox.

Policy Inbox

Policies

The policy view itself also got a nice refresh. I was constantly tinkering the the v1 design and in the end it was nice to just bin it and start from scratch.

Rather than trying to display everything all at once, nested data such as policyholders and vehicles were listed and would throw up a slide over when selected.

This area would also introduce new functionality such as marking as archived and sending to policy to a connected integration.

Policy View

Page Layouts

Working on a larger screen, I get pretty tired of dashboards that have a sidebar and a centralised main content panel. I know, I've built plenty of them myself.

I've been experimenting with a left sided approach, where I build up pages using a series of vertical panels and variable max-widths. These can expand to fill the entire screen when needed or on smaller pages, they just hug the content. It's then balanced next to a nice off white to indicate a "void".

Putting my coding hat on for a second... a component system to build these type of pages really helped speed up the rebuild - especially on form based pages that can often be found in settings.

<Page size="sm">
  <Page.Padding>
    <Page.Title>Users</Page.Title>
    <Page.Description>
      View all users associated with this account
    </Page.Description>
    <UserList>
  </Page.Padding>
  <Page.Divider />
  <Page.Padding>
    <Page.Title>Invite User</Page.Title>
    <Page.Description>
      Invite a user to access your account
    </Page.Description>
    <UserInviteForm />
  </Page.Padding>
  ...
</Page>

The Void

Rebuilds can be daunting but also extremely rewarding. You learn so much working on a project from start to finish and being able to approach it again with all the new knowledge allows you to ultimately build something that is much improved.

There were a number of key lessons that I learned from this project that have made me an all around better designer and engineer.

Identifying Usage Patterns

While I try and put my customer goggles on when designing a system, sometimes they can do things that you don't expect. In this case, we didn't really have a reference point. We built a product that we thought would attract a certain type of customer and in the end we attracted largely the opposite.

Every user comes in with different levels of expectation and capabilities. They key is building something which strikes a balance between being easy to use for the every day user but offers the extended functionality for power users.

Rethinking Data

On the initial version, I essentially mapped the API structure to an interface. I'm pretty sure there's an API to UI generator that could do a similar level job!

With the rebuild I tried to rethink how we could transform the API when displaying things. I aimed to do this without having to many, if any, changes to the API itself. I think the only thing we ended up changing was functionality to support the "inbox" feature.

Consistency

While more of a coding problem, it did ultimately translate from the design. There was a lot of variance between pages on the initial build. We ended up with a bunch of reusable components, but I found actually constructing pages could start getting out of hand as we didn't have a structural barriers in place (see the page example above).

I was a lot stricter with the rebuild to ensure we had more structural components to keep padding, spacing and text sizing more consistent.