User Experience is the Most Important Feature
As an engineer, I know firsthand how easy it can be to become lost in the minutia of a particular coding problem, or the roadmap of a product plan. As engaging as this can feel in the moment, it is imperative that we also remember to take a step back as often as we can to look back at the tools we are building through the eyes of the end user. This is not just a task for UX designers — everyone who builds something should understand how it is being used, by whom it is being used, and what problems they are going to solve with it. The end user does not just have to be an external customer either. When I am building an internal API for example, it is equally as important for me to understand what my coworkers on other teams will be thinking and looking for when they begin consuming my new source of data.
Nobody wants to use fancy, bad tools
You see, no matter how elegantly-coded, infinitely-extensible, or fault-tolerant a solution might be, if it is miserable to use, it is not a good solution. This becomes magnified as the problem space where the tool is to be used grows in size. If customers have the option to choose a SASS provider with a big name who has three times the number of features but a site that is surprisingly unintuitive and hard to use — they will often still pick a smaller provider who makes a tool with less features if it is easier to use.
Perhaps it is the intangible nature of the technology domain that makes this feel like such a hard principle to embrace. Let me bring this into the “real” world a bit for an extended metaphor to illustrate my point.
Table stakes
What if, instead of building web software, we were building kitchen tables? If I built you a table that uses dozens of distinct pieces, each of which is easy to swap out for another with different gadgets, that would be a pretty fully-featured table wouldn’t it! What if you could plug in a computer and the whole surface turned into a screen, or if the legs could change temperature to heat or cool the room? I bet you see where this is going though — is this megatron of a table any good? Can you tell from just that hectic feature description? No, of course not. Some part of you instinctively wants to look at it in your kitchen and see for yourself. Is it sturdy? Does it function as you expected it to? Is there a leg sticking out in the middle where it should not be? (It is a design pattern, we have to do it that way because of the leg dependency injection framework… *troll*)
Bringing it home
If your kitchen table does not work as a table — it is not a good table. It does not matter how many design principles were applied to it’s construction, if it does not solve the problem the customer will be using it for, it is not good. The same principle can be applied to software, and is why I constantly need to be reminded of this. The most important feature is the user’s experience. No matter how clever I think my ideas are, if the problem that my customer is solving is not well matched by the tool I want to build, it is my job as the builder to return to the drawing board and make the tool do what it needs to. After all, software is still a tool to do a job, no matter how much fun it is to build and talk about!
