Now, I want to move up a layer. Not only between microservices, but in the interaction between applications. I would call it architecture applied to applications, where their behavior is strictly connected and influences the other ones. Like it is for microservices, the goal is a better user experience.
ARCHITECTING A GOOD PRODUCT
The architecture is built to scale up and manage all the single pieces overall. Every application should play like an instrument in an orchestra. The applications need to follow rules, strategies, and logical and technical design. If one of them doesn’t play as expected, the whole concert becomes a low-quality performance. If direction is improvised, the applications won’t run in harmony. The entire user experience relies completely on the whole architecture.
The importance of a good design describes all the interactions between every application in detail as the minimum requirement for an acceptable user experience. This so-called UX (User Experience) design is the goal of the final product.
DIFFERENT USERS, DIFFERENT DESIGNS
Happiness is extremely subjective. Consequently, the UX is also very subjective. We should consider in this design how different users react based on age, skills, expectations, and so on. There may be several different designs with different interactions and even different applications involved. For each of the users, the product should be easily usable in a reasonable time. The analysis of user behavior will help in this. The best way to accomplish this is offering a limited number of users the final tool as a beta and receive a feedback to build a model of interactions between the components in the UX.
WHO WANTS TO BE A PILOT?
The complexity of a GUI doesn’t necessarily mean a cryptic interface. To drive a sports car, you need a good understanding of the theory behind driving and practical experience. But sport cars aren’t built just for car enthusiasts, so they need to have a sophisticated electronic layer to manage all the critical behavior and correct all the possible mistakes that a “normal” driver could make. This complex environment should be simple and intuitive for the user to help them focus on driving. So, with a glance, the driver should be able to use the navigation system, enable the cruise control, activate fog lights, and so on. All of these components are the applications in a UX architecture.
IS IT NICE? NOT ENOUGH
Aesthetics can’t replace usability. You can spend all of your development time making the best icons and all the best possible nice animations. However, if UX is bad, the whole system won’t have success. Instead, the opposite is true. If applications are well built and their interaction makes the end-user happy, even a less-polished look will be acceptable if the product ends up being successful.
The Interaction Design Association (IxDA, https://ixda.org/) defines the interaction design between users and services. It also defines the interactions inside services and between applications. IxDA offers some guidelines to follow in order for a product to be standardized. This means for users that a product defined by IxDA standards is inherently usable because all similar products run in the same way.
And again – feedback, feedback, feedback! Not only in beta testing but also when the UX is generally available. The more info you get from the users, the better you can tune applications’ interactions, and the better the overall user experience.
This article was originally published here.