Zachary Wall
UI and Product Designer

Contacts

A web app designed to help users more easily find their contacts' information.

Date: 2019
Industry: Insurance

Role: Lead Designer
Tools: Sketch, InVision
Deliverables: Mocks, Style Guide, Prototypes

Overview

I was tasked by our client to find a better way for their agents to search through their database of company contacts. Each type of contact has other associated types of contacts, so displaying that relationship in a direct was was key to the core functions of the product.

Contacts

Objective

Since the current system was roughly 20 years old - and many of its users had been using the system since it launched - the main objective was to update the interface to be familiar enough that older users wouldn't be confused (or have their workflow interrupted), but also make it intuitive for new employees and users.


Approach

We started the discovery process by holding meetings where users walked through the current system and how they use it on a day-to-day basis. I conducted informal interviews at the end of each meeting, asking about core features that users liked and disliked, what features users would add if they were creating the new app, and if there were any external systems they utilized while they were using the current solution (ie. were they copying information into a word processor or emails, etc.).


Wireframes

The first round of wireframes I did for the app brought up a huge assumption I had about how users would want to search for contacts. I had created a universal search box that would pull all types of contacts (companies, locations, and people) all into a single result source, thinking this would allow users to quickly search everything. What I found was that this really confused users who were used to the current system (where they first had to select a type of contact, and then search within that type only). It seemed so counterintuitive to me, but the feedback was unanimous - so I removed the universal search and create type-specific search inputs.

Below you can see a few different options I presented for search, as well as the general flow of the app. At one point all interactions were happening on a single screen, but this quickly became cumbersome to the users, so we broke out each type of content into its own screen in the end.

Design

During my first meeting with the client stakeholders, I was shown a few other applications that the same pool of users use, and that the company was looking to redesign. With that in mind, I set out to create a simple design system that could be utilized in the future, and easily expanded upon. This not only will make it easier for our team to design consistent apps in the future, but will make the user experience and dev handoff that much better going forward.

I am also in the processes of updating previously designed apps for this client to use the new system and styles.

Lessons Learned and Improvements

This application is still in development, and hasn't piloted yet, but the iterative design approach worked well and taught me that my first assumptions about user interactions are not always correct. I also wish I would have implemented a consistent design system while working on previous designs for this client. While the visual style is consistent, dev is much harder to keep up with due to utilizing different components across multiple apps, even if many serve the same function.


I hope to get each app updated in the future to use the same Sketch library and design system, and work with our internal dev team, as well as the client's dev teams, on updating components across the board.