Wireframes For Insured Dashboard Redesign (2014)

Developed concepts to modernize and expand features on a customer portal.

Problem

The original dashboard (which I cannot share) was missing a lot of key details. There were lots of links and generic info. I wanted to give the user a summary of their account and emphasize actionable items, such as access policy documents or payment history. As a team, we captured several business priorities, like reducing paper documents, more self-serve options to free up call center, etc.

User Profiles and Use Cases

After talking with the project owner and interviewing a business subject matter expert, I captured several light personas defined by use cases:

My personas are defined by WHAT a user intends to do. A persona or use case becomes a trigger for a wireframe flow that meets one or more requirements.

Wireframes

I created detailed wireframes like this. Their function was “proof of concept” and exploration of other potential features. Clients need to see something to be able to better understand what they need:

I usually encourage clients to build components as needed, to think in Agile terms and embrace rapid iteration over perfection. As a result, wireframes for each screen are more detailed in key area and less in others.

Solutions on the dashboard above included:

  • Holistic view: I summarized all aspects of the user’s interaction with the company and categorized them into 3 columns with subsections. I also added a global summary info bar at the top (e.g., “You have 6 unread docs”)
  • Hierarchy: I showed content in order of importance/relevence, from top to bottom, left to right. Older and secondary content was concealed behind summary links.
  • Consistent Clickable Styles: I exposed the key actions as buttons or links. For example, under Payment, I added a prominent Pay Now button and a secondary link to View Invoice.
  • Relevance & Quick access: New and unread items highlighted. I exposed some key actions. For example, I added a pull-down to quickly switch the policy holder for those account that have multiple people on them.
  • Surfaced Meta-Data: To increase the relevance of each link, I tried to surface the key metadata from the item being linked to. For example, a document link came with a concise description showing document data, policy number, expiry date, etc. For the View Invoice link, I showed how much they saved on that invoice, due date, etc.

Ideation & Storyboarding

I developed a layout for the dashboard to standardize existing pages. Based on this layout standard, I explored various areas of functionality. The client didn’t know what exactly they wanted. They wanted to see options and get advice on what their client might be interested in seeing and how.

Most interactions dealt with looking up the right documents, managing access, and sending documents:

I mapped out user actions and screen transitions by connecting various wireframes, like this:

The client and I went through multiple iterations of each screen. I would start by making suggesting of what might be useful features. They would give me feedback on what they thought would work for their clients. I would make revisions and so on.

Prototyping

Even a rough functional prototype can help better “feel out” a solution than a static representation. Here’s a simple HTML prototype that the user could click through to test the overall flow. I also mocked up an alert email, which triggers the process. This way the client could start seeing the full story of how a user will to log into their dashboard:

The client would then take my concepts to his team for testing and further elaboration. My objective as to quickly concept and prototype UI ideas for them.