Conflicts arise in every software company among designers, managers, and customers. In this article, we describe some popular cases and offer tips on how to solve them.
Conflicts between the software manager and the clients related to the design
This type of situation could arise when working on a project with a short fixed deadline and budget, and at the same time, the client has extremely scripting requirements for the design. The end customer may have requirements regarding the style guide of the design, the use of specific elements that are not common, etc. In this type of situation, the implementation time following all the rules in a script may be unrealistic.
In this type of situation, it is good to discuss with the client what are the most important requirements for the project in the specific period.
In this way, we will get an idea of MVP (Minimum Viable Product) and we will be sure that we will be able to deliver on time. In practice, there are indeed many punctual clients, but they also pursue specific goals and are bound by the completion of the project within the set time or budget. That is why proper communication in this type of situation is key. It would help us understand the correct expectations of the client, not those that are thrown in a document that may even be irrelevant to the current period.
Through good communication and clear formulation of priorities in the project, we can build different Milestones, tied to achieving the ultimate goal. However, we must not forget that good design alone does not provide a finished product. It is only one layer of it.
This type of situation can occur when a customer wants us to report system errors to end-users. The client may think that it is a good experience for the user if we point out the exact mistake. Example: “error 404”. For most people in the software industry, this is a standard mistake. However, this is not the case for the standard user. The average user would not be able to read system errors. In other words, for him, they would be meaningless and confusing.
In such a situation, it is good to understand the reason why the client wants to visualize system errors directly. If there is no good reason, then we should advise him to replace them at UI / UX level with the appropriate messages. In the current example, this could be the following message:
“The file you are trying to access is not available.” In this way, the user will gain a better idea of the error and the situation in which he finds himself. As a result, it may take appropriate action, otherwise, we risk increasing the Exit Rate of our software product, because this type of solution reduces its usability directly.
Conflicts between the manager and the director related to the design
Due to lack of resources, the company director may insist that the Front-end Developer create a UI / UX solution and implement it. In practice, this is possible, but the result will be in question. However, let’s not forget that Front-end Developers are people focused on implementing a specific design and how it works. They could use ready-made frameworks that contain ready-made components, but very often these people may not have specific UI / UX skills and the result can be disastrous.
In such cases, it is good to understand the purpose of the project. If we are developing a software product that is targeted at a wide audience, then it is good to consider a better segmentation of work and processes – in other words, to hire a UI / UX Designer. Otherwise, the result may not meet consumer expectations and the product we put on the market will collapse.
The director of the company may have developed his wireframe and insisted on its implementation without consulting UI / UX Designer. The wireframe in question may be inefficient in terms of system flow. It may contain various problems directly related to the usability of the product. For example, too many pop-ups, the essential information on the screens is not positioned correctly, to use the wrong elements, etc.
In this type of situation, it is good to understand what we aim to achieve with this wireframe. Whether it serves more as a guide for the design team and whether they could turn it into a real IU / IX user experience. In this type of situation, I would say that communication is key again. As software managers, we need to understand what the goals are to provide the best solution to the situation. However, we must not forget that in the company we can have specific specialists who can give a better solution to a specific problem.
Conflicts between designers in the team
A possible conflict situation in the team of designers could be created if they work on one project – one software application and there are no established principles of work. In this type of situation, there may be conflicts about what type of elements to use. Some elements may be placed on one screen and others may be used on the other screen for the same functionality. This would not only reduce usability for the end-user but also the realistic implementation of this type of design would be problematic.
In this type of situation, there must be established rules and principles of operation. It must be established what are the so-called common elements that we will use and will be present in many places in our software product. If designers are working on XP pair-programming Agile principle, then this would be extremely important.
This type of rule should be established at the very beginning of the design activity. In this way, we will achieve consistency and unity in our design. If for this purpose, the two designers cannot reach a consensus on common elements, then this responsibility can be delegated to their Team Lead and he can establish the specific principles and design patterns.
Another similar type of conflict situation can occur when designers on a team use different tools. If one uses Boostrap and the other Get.Foundation (or another similar tool) that his colleague is not familiar with. The first goes on urgent leave but asks his colleague to finish the work he has started on a specific design because the project is extremely important. In this type of situation, the second designer, no matter how collegial, may not be able to cope with this task. The reason is that he simply does not have access to the tool, and has never worked on it.
In this type of situation, it is again good to follow specific rules and regulations for working in the respective teams. There must be uniform practices to be followed by all. In the specific example, one could migrate to using a single tool for different design projects. In this way, not only will this type of situation be avoided, but the company could also save money on unnecessary licenses.
Conflicts between UX / UI Front-End colleagues and Back-End colleagues.
This type of situation can occur when designers insist on the implementation of the design. Example IU / IX Designer noticed that one of the confirmation buttons is two pixels to the left of the design he made. He noticed this on Opera 10.63 and constantly made scathing comments to the Front-end team that they could not implement his design properly.
This is a completely real situation. Here, however, we need to know the audience of the specific product. It is quite possible that users who use the specific product do not open it through this version of Opera or with mass adoption products this audience is extremely small. In this situation, the designer will not be right and his comments will rather create unnecessary tension between the teams. In addition, the severity of the problem must be taken into account. Let’s not forget that front-end developers can work on other tasks, the value of which is higher than the effort to adjust the button. To do this, we need to know our audience. To know the behavior of our users so that we can make the best decision in this type of situation.
Another similar type of problem situation may be caused by cases where the intended design is too heavy. It contains many animated elements, special custom elements, and more. In this way, the implementation of the design itself could become extremely difficult. Each custom element should be slice separately and implemented instead of using a ready-made framework based on common elements. In this way, front-end developers will take a lot of time to implement the respective design. In some particular cases, this type of approach may even reduce the performance of the software product.
In both cases, we have a problem. One is related to the time needed to implement the design – not a good resource utility and increased execution time. Otherwise, we will have a product that does not “behave” well in the environment. To avoid this type of problem, it is good to define the main goals of the design at the concept level. It is good to impose specific rules and practices to be followed in its implementation. In this way, we will achieve not only common and transparent practices but also a balance between the teams, their tasks, and the goals of the project.