Why UX Is More Important Than Coding
We all know that software is vital for pretty much everything people do today, but I firmly believe that the quality of code is secondary to user experience (UX) when it comes to your project actually succeeding.
Fundamentally, it’s because software is written for people to do things—it should be making their jobs easier. So if you just start coding in a vacuum without understanding what your users need to do, there’s no way you can be sure you’re coding the right thing.
We’ve all seen the results: systems that have to be scrapped, or that people actively avoid because it makes their jobs harder, wasting everyone’s time. And this isn’t just about the user interface or how a solution looks; UX goes much further than that.
You need to look a lot deeper to understand the person the software is written for, get the full picture of what they’re trying to achieve, and recognize where the blockers are. Only by doing that first can you then map out an approach that will help them get to where they need to be.
Importantly, you need to do all of this UX research before you start coding, not as a sounding board while you’re coding. It’s about having a conversation with your users (and potential users) and getting their feedback in a human-to-human way, rather than simply counting votes.
This is something that anyone can do, but it requires skills beyond simply being a good programmer. Extroverts who chat with users frequently would likely have a different perspective from developers who have innate preconceptions of what a solution should look like, based on their technical background. I’m not saying developers shouldn’t be involved in UX; you need a team with different skills and perspectives to get a complete picture, and you need them to collaborate both internally and, more importantly, with users. UX design is a team sport, not a personal mission.
Once your team and organization has decided you should be doing UX research before you start writing code, how do you actually do it?
The short answer is by talking to your customers (and people who could be, or who you want to be, your customers). Start with an exploratory phase where you find out what their problems are in a very broad way, and then focus down on the strategy. That’s understanding what the potential solutions for the problem look like.
Once you have this, you can move onto the tactical phase and do the more traditional bits of UX, like usability testing. And remember, this isn’t a one-off exercise. It’s an ongoing effort, because user needs change, and your software has to evolve with them.
Before you start your next software project, move away from your mouse and keyboard, pick up the phone, and talk to your users, hopefully with a UX engineer by your side. Then you can be sure your wonderful coding is exactly what’s required, rather than being the wrong thing for your customers’ needs.