We are currently QA (Quality and Assurance) and testing processes for our new PI version of SCOUT and an implementation for a new Carrier client.  It's a somewhat complicated process and absolutely crucial for the success and adoption of the software.  I just came across an article that does a pretty good job of explaining what it takes to implement new software in an insurance environment.

 Highlights:

Step 1: Establish priorities. Identify the critical, most used, end-to-end business transaction pathways within the enterprise portfolio for the application.

Step 2: Develop the Architecture. Create an automation test architecture using the appropriate functional test tools. Make sure that the architecture supports the automated test script processing, while minimizing test script coding.

Step 3: Develop Test Case Templates. The templates are used for automating the application. Identify the key fields to vary in using data parameterization.

Step 4: Move the Data. Identify a full data migration solution from the legacy system, based on the necessary elements of the new application..

Step 5: Execute. Build and automate as many of the end-to-end test transactions for the application as possible, within the iteration’s user acceptance testing (UAT) schedules. Then, execute the test scripts (automated test cases) during UAT, report defects, and maintain a testing status dashboard for project status results.

This is a pretty good road map, but there are always exceptions depending on the environment.  We strive to set expectations with every customer and make the transition as smooth as possible.

Check out the icons on these buttons in the 2011 Ford Explorer.  Any idea what they are for?

I came across this article from Insurance and Technology that describes, "UIs need to be crafted not only to meet the task at hand but also the type of user." Really?

QUOTE: In developing the various UIs within its product set, StoneRiver has identified three different personas:

• the internal insurance professional or administrator;
• the external customer, including agents; and
• the systems administrator.

Aren't all of these just people and aren't they all using the same application?

QUOTE: For example, internal insurance professionals understand the concepts and terminology of insurance, Griffin explains. They are looking for speed and efficiency and can deal with more complexity.

So insurance "professionals" understand the insurance we buy better than we do or are superior in their processing capabilities?  Complexity = speed and efficiency?

Now, we didn't hire a Human Factor Specialist to design our UI, but I also don't think we need to complicate things with 3 (or more) different UIs.  Sure, different users have access to different screens and information in the application, but do they each need a custom design?   I'm not trying to pile on the company mentioned in this article and truth be told, I'm the litmus test for new features and layouts for SCOUT.  If I can't figure out how to use it we go back to the drawing board. 

Required training is minimal, barriers to entry low, adoption rates high.  We promise not to make our client's lives more complicatied.  Quite the opposite.

A lot of people ask us where we came from and how we got started so here's the abridged version of the story:

A website and web-based application design company - through various connections in the Special Investigations world we were commissioned to build and design a case management system from scratch for West Bend Mutual Insurance (WBMI) out of West Bend WI. We gained insight to how a Special Investigations Unit (SIU) is run by some of the most respected SIU personnel in the business.  We worked shoulder to shoulder and discussed how this application should work and what it means to the company as a whole. 

The SIU at WBMI uses vendors to conduct various aspects of investigations so we had to have internal staff and external companies collaborate on investigations using a common platform.  Of couse, we went with a browser-based application built in JAVA so users could log in from anywhere with secure accress to the internet.  After 12 months the first version was released to the company and it's vendors. 

As WBMI and it's vendors used the application requests for upgrades and additional features began rolling in.  Based on this feedback we prioritized feature development and released updated versions periodically over night without any disruption to service.  After some time, when we felt the system was robust enough and could be applied  to other SIU environments we went tested the waters in the market.

Soon, Swiss Re signed on and we began building a few custom features to better suit their SIU environment.  Shortly after this success we brought in a user interface expert to redesign the asthetics of of the application (then called SIU Manager) for better usability.  This is about the time I was hired in.  The team and rebranded the company and product and SCOUT was born.  New business cards, catalogs, trade show booth, everything.  Our coming out party was the International Association of Special Investigations Units (IASIU) 2008 in Atlanta.

Below a photo of our original trade show booth, a magazine ad from Risk and Insurance and the homepage of our first website.

Risk&Insurance_ad_wcrops.pdf (10.02 mb)

A few sunny Friday photos of our development and creative staff at work on the new release of SCOUT and customer requests.

We're currently redesigning our investigation management software and I'd thought I'd share some of the process with you.  Obviously, these images are over simplifying the thought, time, and energy that goes into it, but ususally it's the simplest means of comunication that workbest for complicated issues.

It starts with the team gathering ideas from our customers and writing them on the whiteboard.  We also start to mock-up the user interface.