Fight for the Users
As a software engineer, you find yourself mostly just building a tool. Sure, your CEO will describe it as a new way of doing business, or paint this grand vision for the future. However, when it comes down to it, you are building a tool. Your CEO may be right and it may actually change the world, but the tool doesn’t change the world, it just enables people to change the world. And what do you need when you need to get people to use your tool? Well, mostly just two things:
The tool must be understood well enough to be used effectively, and it must be able to solve a problem or variety of problems.
— Me
When developing the tool, this generally comes down to balancing usability and features. The hardest part is ensuring that you maintain that balance. From my experience, more often than not, there will be more pressure for new features over usability. Sure, there is always a certain level of usability, but new features usually sell better. They provide more “wow” factor. It’s at the point when you are onboarding and training customers that the usability (or lack thereof) rears its ugly head. A lack of usability means you don’t gain traction with your users, and you fall prey to attrition.
If people don’t realize they are holding a hammer, why would we add another head to it? They don’t even know how the first one works.
— Again, me (and I know it’s a clunky analogy, but it’s what my brain said in the moment)
Honestly, your tool may do amazing things. It may enable users to solve some really tough problems, but if the tool doesn’t help guide them, they may never “get it”. You can always have training sessions, but some learn better with self-service (that’s me). Also, self-service will often lead to more organic growth with the product, especially if it has network effects (see Andrew Chen’s book The Cold Start Problem, which I read recently). A user being able to learn how the product works on their own will really pay dividends in the long run. They don’t always have to reach out when they have a problem or are trying to do something new. If the initial experience with the product walked them through the right steps for understanding the capabilities available to them, the lightbulb would go off sooner. Sometimes, you will want to design the tool (or some features) for the power user, but a majority of the functionality will need to be easily understood by the masses.
I think as engineers, it is our responsibility to push back when we need to focus on usability. Others will think about it now and again, but more often than not, if a feature is hard to develop, it’s probably hard to use. Unless (and I’ve rarely come across this personally), you are engineering very complicated mechanisms that are designed to intentionally make it easier to use (accessibility comes to mind). Having lots of buttons and tabs to click just to get to what is important will not make sense to new users. It isn’t very “discoverable”, and users may have short attention spans while trying out new tools. If it takes too long or feels too hard, it won’t convince them that it is better than whatever their current process is. Worst yet, they may find another tool out there that is easier to use and does almost the same thing yours does. Now your job got even harder, as your tool has to be better than that tool, and now it has to be even easier to use (and you have a tougher time proving it because of a sour prior experience).
Ultimately, it is everyone’s responsibility in the company to ensure the tool is easier to use, but engineers are the ones executing on making the tool a reality. If we aren’t the first ones thinking about usability, it is unlikely others are. By speaking up more often, it builds a culture that encourages usability. It plants a seed in others to think about it too. The more the usability of the tool comes up in conversation, the more likely any minor nuances that would be brushed off become reported (and likely, prioritized). Fight for the users.