UX beyond front-end development
A black screen and white letters.
As developers, we tend to think that this is all what is needed to deliver software.
But we often forget that we don’t write code exclusively to interpreters and compilers: everything we create is done aiming a final user or another human on another end of the software life cycle.
This is not something new, this concept is already known and it’s called UX — User Experience. It reminds us that if a feature doesn’t provide good experience to the users it should be improved. This is greatly discussed on design circles but when it comes to development we don’t always remember it.
The thing is, we should.
UX is everywhere
According to Wikipedia, the term Front-End refers “to the separation of concerns” and it represents “the presentation layer”. Generally it is associated with web-sites and applications. It’s in the buttons the user presses and in the requests that are communicating with the API.
But the curious thing is: not only front-end is about interfaces and experience. From the terminal the developer uses to the APIs that are being built, all has users interacting with it.
Everything that requires an input from a person during the development life-cycle has UX on it, but we often forget that.
When you write code with others — in the company you work or even in open source projects — you are delivering value to your teammates through the quality of the code you write. If you make code that is bad written and hard to maintain you are demotivating your team and decreasing the quality of the software that is going to be delivered.
It is important to apply UX concepts to the project not only aiming the final user, but also on every level that surrounds the development of the software.
There are some things that a developer could do to assure a good UX for the team and for himself/herself.
Introduce new developers the right way
If you don’t make a good initial onboarding to new developers, they won’t know established patterns before getting hands-on and will probably break more code than he or she should break before getting it right.
Sometimes good developers will take too long to realize what to do and where to go just because they don’t know who maintains the project or whom to ask when a doubt arises. A good initial heads-up should clear the path so the developer can focus on the task knowing that he/she is on common ground.
Write good documentation
Every time you add a feature and forget to add it to the documentation you are taking a little piece of code quality with it. The next developer that adds a new feature will, unconsciously or not, not add it either and a mindset of poor maintenance starts to run as default for this project. Those are broken windows, and if you don’t fix them, the cycle will never die: more bad code will be created and the project will get harder and harder to maintain.
Remember that coding is a social activity. Everything that is coming from the tip of your fingers is affecting other people and what comes from theirs is affecting you. If we don’t take others into account, a cycle of mediocre code is set and the quality tends to get lower.
Write good and readable code
It’s a common scenario: a developer is focusing on delivering the features that were given. He feels behind schedule and runs through the week writing code like a machine. By Friday he wrote everything that was asked and all is working as it should. He goes home and next Monday receives other tasks.
Then, another person has to give maintenance to that code in order to finish some tasks that are dependent of that feature. When the code is accessed it feels like hell gates are opened instead. Everything is badly written and all is spaghetti code.
Sometimes that scenario is not only the developer’s fault, maybe the tasks were bad calculated and he had to run to meet a deadline. Maybe the company rules are too strict and he had to write something he was ordered. But something is always true: writing code that “just works” is not what a good developer should aim for.
Make use of good practices and stay always learning. One day you might have to come back to a code you’ve written that wasn’t readable and that may add more work hours than it should.
There’s always room to improve
These are some tips to improve UX among developers, but there’s always other things that can be done like tests to prevent errors or code review to make coding a constant learning activity among peers. You just have to remember that coding is a social activity, and it should be human-oriented.
Conclusion
According to Wikipedia, User Experience is
“the practical, experiential, affective, meaningful and valuable aspects of human–computer interaction and product ownership”.
That tells us that in order to create ownership for a project among developers, coding must be a meaningful activity. It should keep us feeling good when working and it should create value on every step of the project. The experience of coding must be human-oriented.
Coding is not only about black screens, it is also about users: product users and code users.
Do you want to work in a company that provides amazing user experience to it’s developers? Join us at Jusbrasil, we’re hiring!
