5 Good Programming Habits That Will Make You a Great UX Designer
Think like a programmer, act like a designer.
Do designers need to know how to code?
Before we answer this question, let us admit the truth. As designers, it’s easy to get annoyed with developers. Perhaps, they can’t get the alignment of a button right or the functionality beautifully designed by you is deemed “technically unfeasible” by them or even worse they put some shocking color combinations on the screen and say nonchalantly “it does not matter” and so on………
The reality is that we get annoyed with developers mostly because we don’t understand their world. The same goes for developers’ lack of understanding of design — they get pretty annoyed with us too. And I know this because I have spent most of my career trying to fill both the shoes at some point or the other. As designers, we put our blue sky hats and think everything we design is doable. And as developers, we put on our fiery red hats and write shiny code with design considerations, the last thing in our backlog list.
Bridging this gap might require us, as designers, to know a little bit more about development.
This is not to say that designers need to be full-time programmers, but I’m a firm believer in having a basic understanding of some technical concepts. Programming is much more than writing lines of code. It is all about the logic, the mindset to solve problems and making complex things simple that defines a good programmer. In short, thinking like a programmer is a good way to be a better designer.
Once you start doing it, you learn faster, iterate more, and start building creative solutions which are feasible. And the key is to act like a designer while you think like a programmer to get the best of both worlds.
And here are some programming habits which can help you to be a better designer.
Variable names are important
Kendrick Lamar nailed it when he said.
“If I’m gonna tell a real story, I’m gonna start with my name
Names are everywhere in software. We name our functions, classes, arguments, packages, and whatnot. We name source files and the directories and everything within that. Your name should reveal the intent. Choosing good names takes time but saves more than it takes when the going gets tough.
Always remember, the name of any variable, function or class should answer three big questions; why it exists, what it does, and what it is used. This not only requires good descriptive skills but also a shared cultural background that transcends across boundaries and no one can teach you this better than you, yourself.
Thinking like a programmer, you start picturing a variable storing value as you, let us say, design a toggle button on the screen. You need to put a default value to the variable –will the button be on or off initially? Clicking on the button will change the value of the variable. How will the default value be used if the button is not clicked? and so on…. Your mind churns out multiple logical possibilities that make your design robust and feasible.
Good programmers document everything
It doesn’t matter how good your software is, because if the documentation is not good enough, people will not use it. Even if they are forced to use it, they won’t use it effectively or the way you’d like them to.
And nearly everyone understands this. Every developer knows that they need good documentation, and most do try to create good documentation. But they fail.
Why is it so?
Because documentation is nobody’s favorite thing to do. Everybody wants to be a good developer. That is why we have exciting catchphrases like DRY, KISS, SOLID, etc. But when it comes to documenting the code, there is not even a single catchphrase.
That said, documentation isn’t just for other developers, but often for our future selves as well. When we return to a project after a period of time, we will appreciate the work we put into clear and up-to-date documentation. Whatever be the deadline, whatever be the workload, whatever be the excuse of not documenting, any software having no documentation is a dead Dodo. Simple as that!!!
And the same applies to designers also. Good documentation is liking casting your thought process in stone. Sharing it can help others learn, not only the what and how, but the why!
Debugging is a lifesaving skill
If I were to sum my programming career into two hard truths, they will be the following.
· Anything that can possibly go wrong, will go wrong.
· Code smells and it smells badly at times.
And the only skill that is required to counteract these bitter realities is debugging.
Yes, Debugging. No one (or almost no one!) starts off programming with a love for debugging. Instead, it’s often a source of frustration and dread. “How many hours am I going to waste fixing this bug?”, a lot of us wonder. We’d rather go back to building cool stuff. (Because who doesn’t like building cool stuff!?)
Yet it’s hard to find a developer that we admire that doesn’t consider debugging important. That’s because they know that it’s an invaluable source of growth for them. There are a few situations that will test your abilities as a developer to the extent that debugging will. That’s why you should start approaching debugging as a learning opportunity. Sure the pain will still be there but you keep it under control by doing it the right way.
Similarly, as a designer, troubleshooting (or debugging) is the process of closing the gap between what you actually designed and what the user wants. Troubleshooting is the most essential skill you can learn! It takes both knowledge and skill (and sometimes a lot of luck) to be good at troubleshooting. You need to develop the capability to isolate the problem, assess dependent and independent variables, and test it iteratively till you get it right, to the satisfaction of the user.
The more troubleshooting you do, the faster and more efficient you become at it and the better will be your design.
You Aren’t Gonna Need It
YouArentGonnaNeedIt (often abbreviated YAGNI) is an Extreme Programming practice which states:
“Always implement things when you actually need them, never when you just foresee that you need them.”
Even if you’re totally, totally, totally sure that you’ll need a feature, later on, don’t implement it now.
There are two main reasons to practice YAGNI:
· You save time because you avoid writing code that is not required
· Your code is better because you avoid polluting it with ‘guesses’ that turn out to be more or less wrong but stick around anyway.
Remember, good Programming is a few brief moments of sublime elegance embedded in months of niggling, exacting, precise trivialities. Make that sublime elegance stand out by eliminating the unnecessary. This not only earns you, accolades but also gives others a readymade platform to add further, learn more, and work as a team.
In designing, we call this minimalistic design. The main idea in minimalist design is to say more by showing less. Minimalist design is clean, crisp, and timeless. Unnecessary objects and flashy flourishes are left on the drawing board. Only the absolutely necessary is included to get the message across.
Remember the key of minimalism is keeping the design to the “bare minimum”.
Make the simplest thing that could possibly work
Extreme programming mentions two golden rules to write simple code.
· First, implement a new capability in the simplest way you can think of that “could possibly work”. Don’t build a lot of amazing superstructures, don’t do anything fancy, just put it in to make it work. Make the code pass the Unit Tests for the new feature (and all features, as always).
· Second and this is critical to the rule, refactor the system to be the simplest possible code including all the features it now has. Follow the rule of OnceAndOnlyOnce and the other code quality rules to make the system as clean as it can possibly be.
Always remember, we’re not looking for the quickest way; we’re looking for the simplest result. So, we first break the existing method into pieces. That leaves the existing test cases running. Then we modify (simply, now) one of the little methods to handle the next test case and so on.
Similarly, a good design minimizes human and computer interactions to the bare minimum. And when there is no interaction, there is no user experience at all. And the ultimate aim is to create a design having no experience at all. Yes, great UX designs have no user experience. They just Incorporate naturally occurring patterns and rhythms that merge with the daily activities of the user. That is the ultimate sophistication.
Simplicity, in design, is about minimizing and refining the process to the point it becomes obvious to the user. But that doesn’t mean stripping down complex tasks or losing important information. Instead, it’s about finding a sweet spot between UI elements and their usability so that users find it easy to complete one task after another without breakage in rhythm. Always remember a simple UX is simply non-existent. In other words, an experience-less experience. That is, it!!!
As Steve Jobs has rightly said.
“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
About the author
Ravi Shankar Rajan is an information technology program director working in Mumbai, India. He writes on a variety of subjects ranging from programming, leadership, creativity, and even dabbles a bit in poetry. Connect with Ravi on LinkedIn and Twitter.Subscribe to his blog “The Perfect Programmer” for the latest articles on programming, creativity, and much more…...