UX and the art of coding
When a developer is coding, there’s something very individual and unique going on in that task, it’s like an artisan working on it’s piece of textil or pottery. There are limitations to how far they can be creative, but there’s a lot of freedom still to work within those boundaries.
For the end users the impact of good code can make all the difference in the world, it can make something that is being done seem like it had no waiting time, it can be make it so your device sounds like it’s an helicopter trying to take off, it can make the difference in seeing pixel level inconsistencies in the alignment of a specific set of interface elements.
Good code is something that usually is associated with being easy to read, easy to change or easy to manage. If you can imagine that code is like a big essay being written by a lot of different people during a large interval of time, then you can see how things can get messy really fast. And if you try to read a messy essay you won’t get the full value of it, well a computer will struggle as well with bad code.
Badly written code will probably have performance issues, security issues, maintenance issues and eventually logic issues. All of the above can be translated directly into user experience problems. Maybe the functionality is all there and it’s pretty awesome, but if the code that is written doesn’t live at the same level of quality, eventually you’ll get into difficult situations.
A device that can’t deal with the amount of CPU cycles that is being requested by the software will eventually block it, causing those annoying errors that nobody saw coming and can’t consistently reproduce. Another typical situation is code written in a way that doesn’t follow best practices in terms of security, and then you get a user that can change another users’ data because a piece of code got stored in the wrong place.
For example, imagine a complex business logic that is written into the code that is not commented or is not self explanatory in the naming of methods, variables and such, and now a new team member changed something that was actually correct but didn’t consider the impact of it on a different part of the system because the dependency of that piece of code was not clear, and from this a new bug got released to the end user, that will have a bad experience.
It’s really not that hard to understand how UX gets affected by the coding itself and all the best practices we should use, because the code that runs the logic, be it on the client or the server side, written by a human or generated by a low or no code tool, is what actually makes up the system the user interacts with.
Next post in the series:
Previous post in the series:
This is part of a series of posts listed here: