Syren - AMS

Client wanted to create an AMS, initially on the Salesforce stack but eventually changed direction to off platform.  They were a group of ex-insurance agency owners who were sick of the traditional AMS and were looking to create an AMS built by industry professionals.  Most had used everything from Epic to other more modern (but still lagging behind) packages on Salesforce.  

Problems to solve:

How can we make this more exciting?

• What’s going to stand us apart from the typical AMS screens?
• Is there something incredibly annoying about the other UIs that we can try to avoid or solve?
• How do we grab someone’s attention when they’re walking through a conference and they’ve seen a ton of the same AMS over and over?

Research:

Interviewed the agency owners on the team to find out a deeper look into their day in the life.  I combined the use of a google form as well as directly one on one calls, while taking notes and asking more questions that I came up with on the way to further clarify.  Also after years of supporting insurance software, I had years of complaints about another system that I had supported that I combined with their interviews.  I also went through and read reviews on several industry forums of other AMS's from legacy 90's - 2000's to more recently, the web based platforms from the 2010's onward into Salesforce based systems.  (The reason I went back as far as the 90's legacy software: the industry is very slow to adopt new tech, and a lot of the reviews of the newer systems mentioned features from the older software as being superior, so I wanted to find out what and why that was.)  

After determining with user personas which can be viewed here.

And several user journeys:

(Snippet of the summary from the User Journey 1, it's big...)

 The different tasks of an agency based on the type of interaction.

After finishing the personas and doing research on the pain points for current and past AMS's, I was able to determine the following:

Main Problems to solve for all: 

• Clean up the noise between emails and notifications and task lists 
• They don’t have time to be pre-emptive so offload that task somehow
• Without adding more noise 
• Automate things but let the users still feel like they have the power over that task and their job. 
• Make sure the AMS works in such a way that it doesn’t cause E&O problems.

Removing a constraint: Email - Retention

Things to focus on for the design: 

1. Consistency 
2. Reduce time - remove the distance between the user’s goals and completion of tasks. 3. Cognitive Overhead - Avoid tasks that make a user have to hold onto something in working memory while they’re doing the next steps to completion. 
3. Confusion - allow for patterns across the software for interaction, things that are the same should work the same, things that are different should work differently. 5. Allow for system tasks to overflow easily from one type of user to another. a. So for instance with the air traffic control systems, the approach users will have blended systems with the en-route. In the same case for us, we should have sales and service with some blended objects/or tasks. But for a main command center style layout could help with similar Action Zones throughout the app. 

Sales

Tactical Considerations: 

• Eliminate the time and steps taken to get to a sale’s completion. 
  
• Less things for a user to remember while they’re on the phone with a customer. - Better overview of stats as a sales person so they don’t have to spend the little time they have in between calls to make sure that the system is actually showing accurate commission information. 
  
• Be preemptive with customer insights, carrier information, and easily show user if they’re hitting their goals without making them do extra math or mental work. (Looking at you reports!) Sales staff are on the go and the clock is their opponent. 
  
• Logging calls should be basically immediate, not something users have to make sure they’re being diligent with. 
  
• Allow for fields that can be added on the fly for just that record but still reportable. 

Service 

Tactical Considerations: 

• Would want to make this customer feel like they’re using a tool and not something that’s doing all of the work for them. 
• Design the interface to show important information urgently and clearly, without using annoying notifications which eventually end up being silenced or ignored in the sea of notifications people get all day. 
• Like flicking you on the forehead to get things done, it’s gentle and persistent.
• Allow for tasks to have divided screen views so that forms could be easily compared and information doesn’t need to be persistently held in one’s working memory.
• Less errors and work. 
• Looking for ways to speed up the things that they’re working on but not entirely replacing their work.
• Command center for flight control.
• System should be realtime, so if Service updates a field, Sales staff see it being changed in real time. 

Management 

Tactical Considerations: 

• Expose and surface key data points - just one dashboard is better than six of them. - Finding ways to trust that something is being processed (staff), things are automated without having to worry about the aspect of staff. 
• Making simple to read dashboards and data points that show the things that he’s afraid of missing, rather than showing all of the data at once. Reduce the noise. 

Design concepts: 

Sales: 

• Incorporate stats pages like found in fantasy sports apps. 
• Key all time stats, daily, weekly, quarterly, goals and benchmarks. 

Service: 

• Aviation style interface with modules (Action Zones) that change to meet users' needs at the moment. 
• Quick information and task relay without having to dig for relevant information. 

Management: 

• Combination of the two 
• Should have access to key statistics of users’, carriers’, and company’s performances at a glance. 
• Should also have the ability to see the day to day data that Service is using, just less granular per employee and more of a birds’ eye view of the circulation of the business at a team level.

Other ideas that might be useful for staff: 

• Stock style tickers that communicate recent sales in the company, rate changes and new information from carriers, etc. 
• When setting up the application, it asks the user questions about what they want to see, and it shows them these modules as they’re added so as to teach the interface.

Essentially the track to take is, the intention of design should be based on immediate need and preemptive need for information recall.  

Next stages in research:

With those intentions in mind, I decided to look into other systems that were built for jobs that had immediate and preemptive need for information recall.  The first thing I thought of was the job of air traffic control.  I began to do research on the systems that they had to use and found some awesome articles related to UI/UX and the redevelopment of their systems during the 90's when tech moved from pen and paper to fully digital systems.

When Paper Meets Multi-Touch

This article was extremely useful in getting me "off the ground" with my research.  I found a few other studies relating to this in trying to understand how some of these systems were designed.

From that, I came up with these wireframes:

 

Low fidelity wireframes of the interface:

 Client was really excited by the possibilities and was planning on using these to guide the design after they'd gotten investors to fund the project.