User-friendly software is a goal for anyone who builds or designs it. It’s a very tough challenge. Code, best practices, and browser-restrictions all get in the way, clouding up the human-factor.
For example, let’s look at user-restrictions. It’s easy, in code, to make a decision firm. Let’s say Plan A offers 5 users and Plan B offers 10 users. The logic to add a new user might go through a path like this:
That’s what the software says. Clear as day, hard and firm. There are no considerations beyond that. But what if someone needs only 6 users? Just ONE more? Is the best solution forcing them to upgrade to Plan B? Maybe it is, but I’m not so sure.
What if that same conditional could be more like:
Is it better to have a happy customer with 6 users on a 5 user plan than a frustrated customer with 5 users on a 5 user plan? Forcing that customer to make a decision bumps up the chances they will leave. And if they don’t leave, odds are they’re hovering around the 5 user limit “making it work” to avoid the upgrade. So now they’re inconvenienced by the product, and that might leave a bad taste.
I’m aware that a line has to be drawn somewhere. Allowing 20 users on Plan A is surely too much, but paying extra attention to the edges is an interesting thought. If this were done manually, human-to-human, a real person might say “it’s no big deal, you can have one more user” in an effort to keep the person happy. Why shouldn’t software do the same thing?
Generally, rules are rules, and so it’s expected (even by customers) that they live within their plan restrictions. But wow, what an opportunity to go the extra mile and make a customer that much happier!
User-restrictions are just one of many areas where we can consider being less robotic. So, yeah, humanizing software. That’s what I’ve been thinking about lately. We’ll see where it takes me.