Some of you may have been wondering what happens before a new release of Twona AMS takes place.
When developing any new functionality for our Twona system, we follow a clear structure, which is consistent with SaaS product development. It consists of a well-defined series of steps that allows us to design, develop, deploy, and maintain the system in the best way possible.
Here is a bit of what happens :
Ideas and planning
Where do new functionality originate from? That depends. Sometimes new functionality is linked to user feedback which comes from tickets, or conversations with their customer success managers; other times, we follow the market to see what functionality is out there that could be interesting for our users and we evaluate it; a new feature could also be the result of an internal business objective that we aim at achieving.
Whatever the source of this, we always assess what the impact of the functionality would be on other features already in the system, how it would affect user experience, whether this is something that all or most customers would benefit from and use, and how it would affect our existing infrastructure.
During this phase, we also make sure that the user requirements (internal or external) are clearly defined, looking at all possible scenarios.
All this information is gathered in our Product Development board, in the form of cards, which will go through several process steps if they are validated by the product owners. If the card gets validated, the next phase will kick in, that would be the design phase.
Design
When we talk about design, we are referring to the visual interpretation of the application screens that will contain the new functionality. These are often referred to as wireframes or mockups. When we create these, we also make sure that we cover the interactions and integration with existing features, and we involve the technical and customer team to generate a result that is consistent with the rest of the application and will be seamless for customer experience.
Here we define a lot of possible scenarios of how the functionality would be used, where it would be accessed from, and how it will show to users with different access levels to the platform.
Development
Here is where our front and back-end developers get to work! They will be writing code (clean and modular ;)) to implement the wireframe design, integrate it with the existing software, and make sure that all is compatible and it will create no disruptions to user experience.
The development takes place in servers separated from our own platform, to make sure that nothing is compromised.. When it is ready, it is moved to the testing environment.
Testing
During the testing phase, several departments will be involved.
Initially, the development team performs a test to confirm the functionality is working as expected, but more importantly, they perform some integration tests. These make sure that the new functionality is not going to break anything that was already in place.
When this is confirmed, product owner and customer success get to test the functionality. Several eyes see more than two, so we always make sure that not only the originator of the request for new functionality gets to test it, but at least one other person does, although often testing is performed by at least 3 people, sometimes taking different roles and user permissions when performing the test..
If any issues are identified, it means we are back to the development team. A proper description of the issue is registered in our Product Board and the card about the functionality is sent back. The development team then works on the areas that are not working as expected, usually have questions for the requestors, and get back to coding.
The full process above is repeated until the functionality passes all tests.
When this happens, the functionality can be put into the production enviroment.
Deployment
At Twona, we have a rule to not deploy (send to production) on a Friday afternoon. Although we very rarely experience any issues when doing a deployment, we want to make sure that if we do encounter an issue, this is sorted quicky, without robbing anyone of their weekend.
So, we normally plan for deployments during the day. This is posible because there is little to no disruption to our client’s work when deployments take place, they are rather transparent to their operations. The reason for this is that we use a process where the old functionality/current version of our system does not get disconnected until the new one is in place, so the users will not notice anything until that happens and the new release is appearing in their screens.
The work starts by preparing the deployment environment : servers, databases, any infrastructure changes (if any , as we normally do these separately). When we start the deployment to the production environment, this is constantly monitored for any issues. When the release is completed, a notification is sent internally so that account managers can keep an eye on their clients for any potential ticket that may be related to the deployment.
Documentation and Communication
This phase does not really start now, after the deployment, but from the moment the development starts on the new functionality.
We make sure that new functionality is added to the online user guides, and start the preparation of newsletters with information on the changes. Very often, we distribute this information before the deployment is done so that our users get to know what is coming and how it will look when they log in to the system.
We also organize online webinars regularly to communicate and explain about the new releases, especially when these cover several items, or when the functionality is very new or very different to what our users were experiencing before so we can make sure that they can continue to make the most out of our tool.
Customer feedback, support, and continuous improvement
And mentioned before, we closely monitor our user experience after a release. This happens proactively through interactions with clients via their success managers and during trainings/online sessions about the new functionality, and more reactively through reaction to tickets that customers may have raised.
We do receive a lot of positive feedback as a reaction to new features, but of course there are also improvement points that customers may notice. We definitely react immediately to any comment that would indicate a bug/malfunction of the functionality or any other area of the application as a result of the release, and those are given priority and sorted with urgency.
However, we do take all feedback very seriously, and even though not all requests for improvement or changes are seeing the light immediately, they are always studied by the product team in combination with customer success to define whether these are individual/customized requests or they would benefit our customer base.
As mentioned, many of our new features start off as a customer feedback request, which is why we appreciate any input we receive about the tool. We are always looking for opportunities to identify areas for further enhancement.
Of course, we have our regular development and update cycles, but we aim to combine both our own views and expertise on the market with the needs of our customers to make the best artwork management system possible.