Disclaimer: This is a co-authored blog post, where the participation of everyone involved was key. We want to thank our Solutions Architects for doing a great job here. Hope you enjoy it!

We have heard thousands of times how important it is to meet users’ needs to achieve product success. For that reason, UX has been gaining popularity and has earned a seat at the table where decisions are made. But is building a successful product just the responsibility of the UX team, or should everyone on the team be involved and align with users’ needs?

We are truly convinced that UX must have a place at the core of any organization, and that board members must strive to spread UX foundations beyond the design teams. At Making Sense, we are advocates for users, which is the reason why all teams are involved with users’ needs. Today we gathered three of our most experienced Solutions Architects to unveil the reasons why we should keep the user at the front of any decision when designing software architecture.

Here, JD Raimondi, Fernando Gekdyszman and Bernardo Cases bring their perspectives on how architecture and UX are intrinsically linked.

1. When building software systems, what exactly is the relationship between user experience (UX) and system architecture?

Fer: In my opinion, it’s easier to understand the relationship when you focus on the concerns that every architect should bear in mind. Depending on the architecture concern, the relationship can look more obvious (e.g. Accessibility) or might seem a little bit harder to find, but it’s always there. If we think about concerns like “Regionalization,” there will be a specific feature related to the user experience that dictates boundaries of how the architecture should be designed. If we think about more technical concerns like “Performance” or “Stability,” just imagine yourself using your home banking application and seeing a small graphic spinning for three minutes until you get a confirmation message.Or even worse: getting errors 3 times out of 4 when you try to transfer money. I’m guessing you would at least think twice before using this application again to transfer funds. But there are architectural concerns that affect the business indirectly and the impact on the user experience is still there, even though it is not that straightforward. Let’s take separation of concerns as an example. As technicians, we know the benefits of having multiple small parts interacting between each other to create a behavior based on the interaction of these small parts. Let’s put the end user in the center for a moment. If we really advocate for having small pieces, each one with a well-determined responsibility, this makes the product grow and the architecture become simpler. And that means faster. If we bring end users’ feedback into our product backlog and change our product according to that feedback, having separation of concerns enables rapid development and decreases the cycle time which starts with the user asking for a new feature and ends with the feature becoming released. Solving a user’s needs faster improves the engagement between the end user and the product.

Bernardo: When designing a system, you need to consider every aspect possible to define your architectural design. UX is a key piece, because it will define the focus of the actual users of the system, priorities, different points of views and flows. Having a clear picture of this will give you the chance to define the best architecture for the goal.

JD: You can think of the User Experience as everything (not just the UI) that builds what the user sees and how they interact with the system, including how the information is presented, where and how much. As for the system architecture, you can think of it as the underlying decisions and structure to make that happen. So, of course, they need to be aligned. Most importantly, the architecture needs to support the UX so that the product becomes the best that it can be.

To Fer’s answer, I think he’s on the money — we’re not really talking about different things, but just different aspects of a single goal: building the best product that a user wants. The example about the separation of concerns is not a purely technical task. It allows us to adapt faster. Which allows users to have a better product quicker. It’s all for the same goal!

2. What are the best practices of system architecture for providing the best possible products for users?

Fer: I think being successful in architecting systems strongly depends on the architect knowing the business he/she is architecting for, and how he/she knows the potential audience using the product being architected. Knowing the amount of concurrent users will give the architect the size of the infrastructure. Knowing the distribution of those users will give the architect an idea when to expand or shrink that infrastructure. Another good practice I can recommend is to think about architecture in different layers. Application, Data, Integration architecture diagrams will help anyone understand details on different slices of the architecture itself. Runtime architecture diagrams will give the appropriate level of detail when we look at the whole.

Bernardo: When defining an architecture considering all the important aspects mentioned before, you will end up with, in the best case, only one option or maybe multiple options. At this point, it’s important to do the exercise of analyzing the pros/cons of each, along with trade-offs. Putting this on the table will help you make the best decision with the right compromises, and work from the beginning to overcome the compromises. There is no such thing as software without compromises, so making sure we made the right ones to get the best software possible is key.

JD: Most importantly, it needs to support the kind of experience that we desire for users. In some aspects, the how is obvious. For instance, the architecture needs to allow for quick responses to the user, even when there are multiple systems involved, so that they know that their action did have an impact in the system. In some other cases, it’s not so obvious. For instance, the architecture for security of information might require a particular experience to be built, which might be different from what the UX Analysts initially had in mind. It’s work done together so that the experience complies with everything that a user would expect from the product. Both the visible parts (fast, easy to use, error-free, etc.) and the non-visible parts (available, robust, quick to adapt, etc.).

3. How do different types of users require different architectural decisions?

Fer: If you have already done the exercise of putting your user in the center of your landscape, then you are there. All your decisions will be following business reasons and end user habits. Let’s take an example: Notifying a user that something happened. Is she at her desk every day, all day long? Maybe we will need a SMTP server to send emails to her. Does he perform 90% of his job using his cellphone? Send him a push notification. The focus should be on the problem we are trying to solve. If we are successful in applying the mindset of getting the end user in the center, all the (architectural) decisions will be taken with the customer as the priority.

Bernardo: The different types of users don’t just involve personal demographics, but also the device, the environment, the connectivity and the collaboration between users. For example, a real-time collaborative software may require an event source architecture, to ensure the best possible experience for the users interacting with each other. At the same time, you maintain traceability of the users’ actions and integrity of the information in time.

Users on the road may require a server design and infrastructure to ensure data integrity and the ability to keep working even if the connection is lost. The number of cases is infinite and the options are infinite too.

JD: Different users have different needs, and if those needs are not met, then both the UX and the architecture are failing their job. As an example, think of accounting software. Some users might be keeping track of their day-to-day expenses and those users need a quick turnaround time, integrations with multiple data sources, and an orderly way of accessing that information in a non-confusing manner. They need a way to reconcile information that does not match up exactly, and they might need to search for specific transactions. As such, these users require their experience to have multiple systems involved, quick data access and search capabilities. In the same piece of software, an accountant doing the end-of-month reconciliation might not be so concerned about the speed at which transactions are gathered, assuming they are captured at the end of the month. They are more interested in being able to manipulate big chunks of data and create reports out of it. They might be interested in creating reports for the Revenue Agency that are appropriate. So speed is not that important to them, but manipulating lots of information is. The user’s experience itself is what is different to each role, which in turn will create different technical requirements for each of these users, and the architecture needs to support both.

4. How do ever-evolving users’ needs impact software architecture planning?

Fer: Having these types of users (or this level of volatility for the requests we receive) makes decoupling a must. The ability for interchanging parts of the architecture without messing with the rest is key to adapt your architecture to the changing needs of this type of user.

Bernardo: Architecture needs to be designed around user needs, and changing needs need to be part of the architecture. This may not mean a specific design, but instead could mean do not go far down the road on designs that you know can change, or assume the user needs to force a decision. Sometimes it’s just better to keep things as simple as possible to be able to react to changing needs. Do not over-engineer, do not assume complex use cases, do not assume stuff will remain stable forever. Do not make defining the complete architecture a high priority thing if not needed at the time.

JD: It’s very important that the architecture is defined with enough flexibility to accommodate changing user needs. Furthermore, it is sometimes a good practice to NOT make decisions until they are needed. Sometimes, making a decision too soon can lead you on a mistaken path that is hard to fix. However, at the same time, not making a decision might lead to inconsistencies in design that result in a lot of rework no matter what happens. It is important to know which decisions need to be taken soon and which ones should not be taken. For user experience, most decisions that need to be taken immediately are about the freshness of the data, how frequently it is going to be accessed and the level of feedback that users will get. Decisions that can be taken later may involve integration with third party products. For decisions that can vary depending on each case, we have what information to collect from users and what level of feedback we’ll get from the application in the wild.

5. What are your methods for bridging the gap between Software and UX needs?

Fer: I think agreeing on a common language is key. We as technicians will need to learn how to call things flowing into our system (Domain Driven Design helps to achieve this across the development team as well). Keep conversations with non-technical people in the least technical point of view possible. To get a better understanding of the client’s business, it’s necessary to properly communicate with the Product Owner when presenting on product development.

Bernardo: Communication and interaction between UX and Engineering. Both teams need to be educated in the work the other team is doing and how they are doing it. An open table to discuss and evaluate solutions for the good of the user is key. Teams that fail on that will likely make decisions that do not align, compromising the quality of the product in terms of user experience, reliability, accessibility or any other aspect. Decisions need to be made as one team.

JD: Very much like gaps in other aspects, it is a good idea to bring to the table the best possible outcome for each side and see what can be done from each to get closer to the other. Good UX usually comes from well prepared information, fast responses, nice visual designs, clear indications, possibility of self-management, cheerfulness in completing your own tasks and engagement. Good architecture usually comes from robustness, error correction, resilience, high availability, integrity of the data, and so on. They are not exactly opposite, but they are not the same either. Once you consider what is the core of each requirement in these aspects, you can easily find a way to approach the goals from the other discipline.

6. Are there situations where good architectural practices go against good UX? How do you deal with those?

Fer: Short answer is NO. You can have the best Ferrari in the market, but if you need to go through a path full of rocks with it, even the best decisions taken by the best engineers won’t make sense. Thus, the product is useless for that specific user. We always need to step back and think that what we build is to solve someone’s problem. If our architectural decisions don’t fit with this scenario, it’s just a bad decision.

Bernardo: There are always compromises on either side. UX will want to provide the best possible experience and the architect will want the most robust architecture. It is not necessarily one against the other but making the right compromises is key. Also try to think outside the box, and do not tighten yourself in a very rigid architecture that you know. There could be other unexplored options that can meet the needs. Always remember that the best architecture is the one that does the job the best. Also UX needs to consider common requirements for the type of software we are building to prevent unrealistic UX goals. I know JD and Fer for sure mentioned this, but security is maybe the one aspect that is most often in conflict, because security always requires compromises on the UX side. It’s never fun for the user to go through security, but it’s not something you can compromise.

JD: It is true that there can be a gap, especially when architectural needs go against good UX. A common case to be cited is security. A secure system takes all sorts of verifications, which goes against the usual good practice of providing users a slick and quick experience to get their task done very quickly. Haven’t you been bothered by a CAPTCHA that you wished wasn’t there? What about email verification before you could use your account? These sort of things happen all the time, and the challenge is to find a middle ground which is acceptable for the domain in terms of the UX and architectural decisions. This middle ground really changes depending on the occasion, as you can imagine that a real-time app for health monitoring has different important aspects than, say, a reporting application for quarterly business analysis.

7. Any final thoughts?

Fer: Principle 11 on the Manifesto for Agile software development states that “The best architectures, requirements, and designs emerge from self-organizing teams.” I don’t want to be the Agile evangelist everybody hates by recalling a piece of the Manifesto. My intention here is to stress that in most cases, having only the architect focusing on the CX will not be enough. Involvement of the whole team will be required if we are really looking for adapting not only the architecture, but every single part of our solution to improve the customer experience.

Bernardo: Think of software architecture as one giant topic that requires coordination between team members, a great understanding of the target users, a comprehensive analysis of the high level requirements and a creative mindset to find the optimal solution. The best software appears when UX and Architecture are designed together and work seamlessly.

JD: Some people will say that both UX and Architecture design are more of an art than a science. I disagree — they are sciences, but very complicated ones. It’s just too many variables, and it just so happens that experience gives you a fine advantage. My point here is that difficult challenges like these can be addressed without problem — it’s just about finding the right approach and identifying what’s missing on your way to the best solution. UX and architectural work require a lot of thinking, which is why teamwork is also essential.