Dec 3, 2021
UX and the development process and release strategy
The choice we make to the way we go about the development process is impactful on UX, because this process dictates how fast can you get something into users hands, how you’re going to show them what you’ve made, if you’re able to change something that went wrong in a timely manner and if you can continuously provide a quality outcome on each version of the system.
The development process nowadays usually is Agile more than anything else, or at least most teams strive for it. The reason is because of the flexibility and control that this methodology brings to the table for clients and teams alike during the whole process.
Agile methodology brings some cool procedures that clearly affect the UX, one habit that is common is the sprint iteration, which creates the possibility to tackle issues that arise from unplanned situations or events in the overall planning of the tasks. These iterations give everyone an opportunity to optimize the products in an almost instantaneously reactive way to users feedback, be it about issues or improvements, and this is the best user experience we can provide, the experience of being listened to and the possibly of being a participant in the building process of the product.
Another nice thing about Agile is that it is designed to deal with change but with a fast delivery cycle, that means that we are always aiming to give to users a short window of time between updates or upgrades. There’s nothing worse than waiting for something that you need, it’s a sense of frustration and of time moving slower than normal, which fills you with some sort or level of anxiety. Having the hope that in the next cycle something will improve, possibly what you dislike the most about a product, is a good experience. We can’t please all our users, we must accept that there are always going to exist things they don’t like so, “hope” is the next best experience you can give after perfection, the hope that it will be better.
In engineering we put this into practical terms when we go about continuous delivery, a.k.a. CD, which means that there are automatic processes that take the code that is accepted by the team in some form or matter, and put that code running on the environment that can be tested by someone that is not the development team.
These processes of continuous delivery not only reduce the amount of human errors on deployments, because they are automatic instructions, but also reduce the time from the moment of consciousness of a need, to its actual delivery to the users. It also frees the development team from concerns that are not related to the coding part of the development and thus makes it easier for them to focus on those challenges, possibly leading to better code, and consequently to less bugs.
Another important part of the development process that is related to releases are the release notes. If we are talking about a big system or software that has many functionalities, each release can change or update something that the user would not really notice, this can happen because they are not using that specific functionality or because they have their own usage habit of the system that they don’t even look into other possibilities. Here is where the release notes come in play, they are like small descriptive summaries of what was changed or included in the new version, it allows the user to get an idea of what are the new functionalities, fixes, improvements or overall changes they are going to get in the version they are installing, and this type of communication helps with the sense of transparency and expectation management that provide comfort to end users.
Next post in the series:
Previous post in the series:
This is part of a series of posts listed here:
