Imagine you’re a wizard - a bonafide member of Hogwarts, a genuine gandalf the grey.
Now imagine, when you wave your wand to perform your magic, you need someone else to chant the incantation. You might be asking yourself - why can’t you wave the wand and chant the incantation? Well you can! You just need to learn how to chant magical incantations.
The same applies for solving coding problems as well as solving UX problems. You just need to learn UX, that’s all - there is no magical barrier that stops you from doing both code and UX.
Now that we’ve realised we CAN do UX as well as code, why would we want to do UX as well as code? Why not just leave it to someone who lives and breathes UX for a living?
##Why should I learn UX?
If you’ve ever built a feature alongside a UX person (or even a client for that matter), you’ll have had an experience where they have an idea in their head of how something will work. If you’re lucky, they’ll have tried their best to put it down on paper. Unfortunately, there will always be things that haven’t been translated quite right, or things that get taken for granted, and the nuances that make the feature awesome get lost in translation.
If you were able to come up with the UX for the feature, as well write the code, there wouldn’t be a problem of nuances lost in translation. The idea of how it’s supposed to work would already been you your head, and you would know how the feature was supposed to feel.
###Imagine you could read minds
Imagine you and your UX person/client linked via Vulcan mind meld. None of those nuances would be lost, the feature would feel right the first time round, and it could be built from start to finish in one swoop.
The above scenario is a reality - except the Vulcan mind meld you’ll be doing, is with yourself. Being skilled in UX is largely about having empathy, and being able to use this empathy to think of how to make something more usable.
Even if you decide that you don’t want to come up with UX for features, having the knowledge is still incredibly beneficial for other reasons. When you receive the spec from your UX guru, you’ll be able to look at it, realise why they’ve made certain decisions and not be building features blindly. If you know why something is supposed to be built, it may even help when you’re writing the code.
If I had a galleon for every time I’d seen a developer struggle with coding a feature, to then take a step back, look at the problem from a UX perspective and solve their problem, I would be a moderately well off wizard.
Lastly, you may have heard the phase “he/she’s a unicorn hacker!” shouted from the rooftops by recruiters and tech companies alike. What they’re referring to, is people who can cross domains. For example, developers who do UX. As much we all despise recruiters using terms like “Unicorn”, “Ninja”, and “Rockstar”, wouldn’t you secretly like to be referred to as being one?
We’ve covered why developers should learn UX - and that’s all well and good. Now we need to know how we learn UX. I’ll try to give you some ideas:
##How can I wield the power of a UX developer?
Firstly, let me quickly note that UX is not UI. They are different things. If you’re not sure of the difference, check out this article by Erik Flowers on the subject: http://www.helloerik.com/ux-is-not-ui
I think the first idea you’ll need to grasp in order to easily pick up a knack for UX, is that to solve a UX problem, you won’t be using the same logical thinking you use to solve coding problems. UX is all about making a feature work for people - and people generally aren’t logical beings by nature. The next time you need to build a feature, don’t think about how you would code it, or think about whether something is possible.
###Consider the impossible.
Spec out how the feature would work in a perfect world, with no constraints. Once you’ve got that, take a step back and think about how you might’ve coded that without considering the impossible, and how you might code it now. Whether it’s the best solution or not is irrelevant, it’s the way of thinking that matters.
As a thought experiment, think of something that you could write in code - it could be anything. And then throw everything you know out the window, and consider how you would build it in an impossible way. For example:
We’re going to code a sliding door. When you press a button on the door, the door slides to the right. After 10 seconds, as long as the door detects there is no one there, it closes.
Now for the impossible: research has told us that conversion will increase 9000% if the door is made of jelly, changes colour depending on the user’s mood, and when the door slides away - it turns INTO A UNICORN.
Impossible right? Maybe not - let’s think about the UX of the above:
We don’t need to make the door made of actual jelly - the door isn’t going to be eaten - it only needs to resemble Jelly. The mood changing colours - is that actually that we should be influencing the user’s mood with the colours? As for the door turning into a unicorn, maybe the UX is actually that when the door opens, there should be a unicorn behind the door?
Now we’ve thought about the UX, the impossible seems much more probable. While this example does sound complete crazy, and it is, you can probably imagine how this could work in a real world scenario.
The next key skill to hone in your quest to becoming a UX master is communication and empathy. What I mean by this is that by being able to communicate with all parties involved, and having empathy for whoever uses your product, you’ll the best understanding of what kind of experience is needed for your product.
Empathy is being able to understand that your way of thinking isn’t shared by everyone else, and that you should consider the user, and their thinking. This skill mostly comes from experience built up over time - however there are things you can do to enhance your communicative and empathetic abilities. Observing the results of testing, prototyping and field testing is a great way to help you empathise with how people use what you’re building. You’ll often learn that people think in ways you hadn’t imagined.
You may find that learning some basic design concepts will help with coming up with UX - there are base design ideas that most UX people will incorporate into their UX concepts without thinking about it. There is plenty of material on the subject, but I can recommend checking out Joel Spolky’s book on UI design is a good primer for developers: http://www.joelonsoftware.com/uibook/fog0000000249.html
If you have access to the UX person at your workplace, or a friend, ask them to pair on a UX problem, and learn by example. Developers pair all the time for the massive benefits involved, and the same can be done when coming up with UX.
Finally, realise that no UX or design is perfect - everything can always be improved and changed. Coming up with any UX concept is better than coming up with nothing at all. Question the UX that you see, and step back and question your own UX ideas. Get people’s feedback on your UX and try to understand the suggestions they might make.
In conclusion, picking up even rudimentary UX knowledge is massively beneficial for developers for a number of reasons. The initial hurdle of changing how you think about problems may seem too large to leap, but it’s really not. Learning UX as a developer is going to be tough, but it is possible and worth the trouble. Open your mind, and let your imagination run free.