Less Customization, More User Input
“Implementing modern policy administration systems should improve efficiency, processes, and functionality. Unfortunately, the tendency of insurance carriers to want to ‘do things the way they always have been done’ compromises these potential advantages in many cases.”
This is a pretty dire warning from Novarica, a research and consulting firm for property/casualty and life/annuity insurers.
Even if you’re not in that particular field, I’m sure you can relate. If you’re selling enterprise Software-as-a-Service solutions, you know customers want very specific things from your code. The Sales team promises a solution that matches what the customer is used to and Development delivers.
But Novarica gets even more doom-and-gloom with this statement:
“Giving in to the need to feel comfortable by allowing requirements to reflect the current state rather than new (and generally better) business processes leads to over-customization, which generally increases delivery and operational risk, project costs, and maintenance and upgrade expenses. In addition, best practices native to the solution can end up being removed inadvertently, and the entire project as well as the overall business case can be jeopardized.”
I won’t go over the pros and cons of SaaS customization, instead I’ll focus on the idea that “best practices” can suffer with over-customization and how we can correct that. If you’re interested in actually hashing out the pros and cons, here’s some links I thought were a good read:
The Four Faces of Mass Customization
How much ERP custom software application development is too much?
The Long-Term Effects of Heavy ERP System Customization
Top 7 reasons why to avoid (much) customization
Returning to Best Practices
As SaaS professionals, we shouldn’t allow customers to customize themselves into a hole or allow “the entire project as well as the overall business case” to be “jeopardized.”
There is a reason I’m typing this article on Medium and you’re reading it now. They have given me, as an author, all the tools I need to publish my thoughts easily AND have you read the content easily. Technically, Geocities did the same thing… with EVEN MORE features! There are so many “amazing” features Geocities had that Medium doesn’t have. You’d think Geocities would still be around and Medium wouldn’t stand a chance.
Our industry’s present thinking is this: “We have so many customers with so many different wants, let’s just let them customize everything.”
I would argue that what we have is a very shallow understanding of the customer.
In the Geocities example, the customer may say they want a bright green headline, but what they really want is people to read their content. A shallow understanding hears what they say, but misses what they want.
It is the responsibility of a SaaS provider to help their customers make decisions that are good for their business, even if that means they have to give up that metaphorical “bright green headline.” We are doing our customers a disservice if we’re not addressing the root problem they have. We are doing our business a disservice if we are constantly burning development money on customization that doesn’t solve the root problem either.
What’s Better Than Customization? User Input.
Here’s a solution that goes for a deeper understanding of the customer:
- Establish a good relationship with “high-fidelity” users (i.e. users who are representative and are willing to offer helpful input.)
- Discover the root cause of the user’s feature request. Use 5 Whys and Kano Analysis.
- Synthesize a solution that works for most of your customers. Maybe it works for all! If it won’t work for most, dig deeper with 5 Whys and Kano Analysis. Your customers are your customers for a reason. You provide some sort of solution that fits all their needs, else they wouldn’t be your customers.
- Roll out the original solution you’ve come up with to the customers.
How to Roll Out Your Solution
Remember that Novarica quote, “Unfortunately, the tendency of insurance carriers to want to ‘do things the way they always have been done’ compromises these potential advantages…”
How can we implement the right solution to an often-reluctant industry?
Put the user feedback in front of users.
Numerous studies have shown the positive effects of users being made aware of other users’ input.
So let’s say we have Updates on the homepage of our application where we post release notes and such. If we also include the user feedback that helped shape a released feature, we will:
- Get more buy-in for the feature. “Customers who are empowered develop positive attitudes towards a brand. And when they have a hand in creating a marketing offering (e.g., when they create new product ideas), the ‘Ikea effect’ occurs — they tend to value and like their creations generated by each of their co-creation efforts.” (Customer Empowerment in the Digital Age)
- Encourage users to offer their own feedback — a positive feedback loop. E.g. I see other users offer feedback, the company listens, the product changes, I offer my feedback.
Novarica prescribes the same thing. “Get input and review from key users before the project begins. Make them feel some ownership and buy-in, even if they aren’t part of the decision making process. Include them in updates as the project proceeds.”
Customization is the nature of SaaS, but perhaps it should be considered a last resort, after you’ve fully understood the customer and properly rolled out a solution you believe most benefits them. If customization is needed after the user input/understanding process, then it is time to get it in the sprint. But developing custom solutions before exhausting that process is lazy design, and often happens because a team is “unable to make a product decision.”
When someone says “it’s designed to be customizable” they are too often saying design decisions haven’t been made at all.
Case Study: Connections Homepage Navigation
The navigation buttons on our homepage were “designed to be customizable.” As a user, you can adjust what the button says as well as where the button takes you. Going over a table of all the homepage buttons and links told me that there were 931 values stored in our application. But when I filtered for unique combinations of both name and link, I ended up with only 26!
97% of our users were using the same buttons as everyone else, even though we had “designed it to be customizable.”
How can this be? We designed it to be customizable, why aren’t they customizing it? Well, it falls right in line with the fact that 95% of users don’t change their settings at all.
But there was also 1 more interesting fact. One button accounted for approximately four times as many custom changes as any other button. That button actually took users to another navigation page, and users were struggling with what to call it because our default didn’t make sense in their situation; they needed it renamed. So we allowed them to rename the button. Isn’t that what users wanted?
The users said they wanted to customize that button (a shallow understanding, e.g. the “bright green headline”). But what they really wanted was navigation that made sense to them (a deeper understanding).
So if we deal with the actual navigation problem, and remove buttons that have been “customized” as a workaround to the real problem, we ended up going from 26 to 14.
That secondary navigation page had 690 values stored in our application, of which 12 were unique. Of that 12, 6 were also available on the homepage, 1 was unused by any client, and 2 went to the same place. That’s 8 redundancies that could be eliminated, leaving 4 buttons that were actually unique and useful.
Because navigation was the user’s real problem, I propose moving those 4 buttons to the homepage for a total of 18 possible homepage navigation buttons. Because of our SaaS model, not all users will see all 18, most will see around half that. And that’s certainly navigable.
Another upshot to making a decision as opposed to leaving it customizable: we can make the design much easier to look at, understand, and use — which is ultimately what the users want. With only 18 possible options, we can do stuff like make the wording more concise and add matching visual elements like icons.
Now we just need to roll out these changes in a way that fosters user adoption and encourages more user input in the future.
The next challenge that needs a decision made is the order of the buttons. Is it alphabetical? Is it by what most users use most? Is it customizable, e.g. users can drag-and-drop? I think the lessons here tell us that whatever we choose as the default, we should “be right the first time” because even if we give them a custom option, nearly all users will leave it as is.
