"It's a required field in the database. We have to ask them for their date of hire."

In reality we didn't.

We could generate a recommendation for accident insurance without knowing when a customer was hired. We couldn't do that for life insurance. But accident, sure, no problem. It didn't matter when you were hired.

This sort of thing happens all the time when you're building software.

What happened next was unusual

"Make the database field optional."

Brad, the director of the backend development team, made a call. We didn't need to ask the customer for their date of hire to give them a quote for accident insurance. So we changed the database to make sure we weren't asking a question because of a field requirement.

It was the 11th hour of very complex website build. But Brad didn't make the call because we needed to move on. He was reiterating one of the guiding principles for our project.

Our principles grew from purpose

GEHA is the largest provider of health insurance for federal employees. In 2015 they engaged Will & Grail to help develop GEHAtotal, a new supplemental insurance division. We worked with them to clarify their purpose. In doing so we helped define the difference they could make by being a source of empowerment for customers. In an industry filled with jargon and complex products, we created a simple rallying cry: "Life. You got this."

The idea to only ask for information we needed, and nothing more, grew from this purpose. It stated how we could simplify the insurance process. And because it told us the how, this principle became a guide in difficult terrain. It became a tool for solving complicated design decisions.

Surprise, surprise...things got complicated

A core part of the GEHAtotal website is a tool that helps customers understand how much insurance they need. We ask folks a series of questions about their life and financial situation. Then we use that information to provide a recommendation.

Only asking for info we need became the tool's bedrock. We knew from the beginning that we were only going to ask questions that helped to empower the customer. We knew we weren't going to ask them what their occupation was. That might provide useful data for marketing. But we could only get that business intelligence by adding complexity to something that needed to be simple. Asking for occupation didn't empower the customer. In the end we built a tool that asks a scant 15 questions to give insurances recommendation for three products. (If you want a more detailed recommendation on life insurance, you can answer 11 extra questions.)

Most tools like this aren't free to use. You might not have to pay to use them. But you have to barter. An email address is a common currency.

The tool we built is truly free. It only asks for information needed to calculate a recommendation. It doesn't need an email address to perform its calculations. So it wasn't designed to ask for an email before providing a recommendation.

Having an email is a critical component in drip marketing to prospective customers. So we did design the system to collect emails. But the customer's recommendations aren't held hostage at the cost of an email. The tool offers to save their recommendations and email them to the customer, but even this is done after providing the results. Again we refused to ask questions that didn't directly benefit the customer.

Enter the new feature icebergs

Shortly after building out our recommendation tool we started to refine it. In the first version you had to answer all 15 questions. And you had to click through recommendations for all three of the insurance products: life, short term disability, and accident. We felt like that might be too much information, too much work for some customers.

If someone didn't want life insurance why were we asking them nine questions about life insurance? Wouldn't it be simpler if someone could get a recommendation for only one, or maybe two products? What if some people didn't even want a recommendation? What if their financial advisor already told them how much insurance they needed? Was there a way to make the process even simpler? We thought so.

To make that happen we developed easier paths through our tool. We called these shortcuts "Build My Plan". Like an a la carte menu, it lets customers choose what they want.

Now we can give someone a recommendation (and a quote) just for accident insurance. And we only have to ask four questions to give it to them. Awesome!

Getting to four questions wasn't easy

For one, we liked the idea of up-selling our other products. We figured some people might pick one product because they assumed they couldn't afford all three. What if they only picked accident insurance, but life insurance was only an extra $50 per month? Wouldn't it be awesome to show them a little button in the quote that said "Add Life Insurance for $50"? No doubt GEHA would sell some life insurance because of that button. But to add that button we would have to ask the customer 13 questions, not 4.

GEHA decided not to up-sell products in the tool. We talked through it and realized that was okay. Four questions ago the customer told us they only wanted accident insurance. Why, four short questions later, are we bugging them about life insurance? Bugging them required us to ask more questions than they needed us to ask. Bugging them wasn't simple and intuitive. It wasn't empowering. Bugging them wasn't right because we had already made the choice not to bug them. We weren't going to ask the customer questions we didn't need to.

In the end, it wasn't just a database field

What we really decided wasn't whether or not we were going to change a database field. We decided that we were going to remain true to our values. We decided that we were going to follow our guiding principle.

The GEHAtotal project made crystal clear how important, how essential guiding principles can be. When we define them we are better equipped to work through difficult decisions. We are more likely to build a product that supports our client's core values. And when we can infuse values into a product, we give the product purpose.

Building better software with guiding principles