Every software project is the result of a compromise

When you start a new project those involved have their own ideas about what the final result of the software under development should be, but this mental image may change with every subsequent revision. Let’s see why.

As soon as someone thinks: I would like to create software that deals with… a transformative process starts which, as evolution teaches us, is more concerned with adapting to the contingent surroundings than a sense of perfection.

This happens because all of the professionals and others involved in the creation tend to support their own positions, which at times are incompatible.
If you look at things from the various angles each position has some good points: all those involved want to reach a high quality result according to their point of view, which could be referred to performance, marketing, ergonomics or other aspects.
However, this meeting of different needs must tend towards a compromise, otherwise the objective can’t be reached and the software can’t be produced.

These positions may result in a long list of needs, whether technical or strategic, divided among four main figures: the user, the client, the developer and the UX/UI designer.

To allow us to consider the complexity and the essential mediation involved in software design, we are going to set out a general overview of some of these needs and the conflicts that may arise.

The user

Theoretically, the user should be the main focus of every designer and developer involved in the creation of a web app, a mobile app or any other software.
After all, the concept of user experience (UX) revolves around the user, i.e. the person who will have to use the software.

With infinite financial resources and all the time in the world it would be a more realistic goal, but with deadlines and on a budget the software house that manages the development must accept that it is not always possible to adopt the most useful solutions in every sense.
These two factors mean that there is less time to plan tailor-made components and functions. The result is a widespread use of existing components (the so-called libraries), that often help to streamline the work, but which are not always suitable for managing all situations.

Other times the client clearly states that they want to limit or even exclude certain benefits for the software user, for strategic, ideological or company reasons or because there are particular imposed legal policies which do not allow the designers to implement certain functions.

Ironically – and luckily for them – the users are the category that will be most likely to have their needs ignored. This is because it is quite common for companies and developers not to involve them in the needs analysis with suitable questionnaires and analyses, to cut short-term times and costs. This practice is not without consequences and we don’t recommend it, since it may ignore important needs which could come up in the advanced stages of development with higher implementation costs at that point in time.

The client

The main objective of the client is to see the finished software and to be able to use it.
On a project level this objective leads to needs that can relate to interface branding, the addition of elements for marketing, limitations imposed by previous technological choices, team collaborations with internal staff and the above-mentioned legal and ideological needs.
It goes without saying that software function and quality can be considered essential prerequisites – for the client as well as the designers – but it is important to point out how these aspects can deteriorate as the project progresses due to possible external factors that cannot always be avoided, which can have an effect both in the short and long term. The following are a few examples.

When the collaboration starts, the client must be open to new project management work methods introduced by the software house.
Finding common ground with the new work method, relying on the skills of the software house and keeping an open mind will avoid the renewal objectives being compromised by the fear of disrupting certain company habits created over the years.
After all, innovation means improving by accepting and adapting to change.

Once any possible friction owed to different approaches has been overcome, the client’s expectations must align with their budget.
As with the users, the budget immediately imposes limitations also on the client, determining the level of attention that will be dedicated to the project.

On a technical level instead, the client may not have the technologies that allow the development of the best possible software that they – or the software house – had in mind. There can be many reasons for this: particular network infrastructures, dated technologies or lack of hardware compatibility with the most recent innovations. Similar problems can arise when a new project must interact with other existing software, or when a client asks for a particular technological stack, different from the one usually used by the software house.

If the users are the first to be ignored, it is also true that when there is no more room for compromise – even when there is every reason to do otherwise – those managing the project do what the the client asks, because the client pays.

These scenarios always have consequences, but in light of an imposition designers and developers can only outline the possible future complications and proceed.
It is important to point out that these consequences sometimes cause issues with the new functions, either partially or totally and, in general terms, overriding the technical advice of the experts can cause delays and harm the client’s finances.

The developer

Whether we are talking about frontend or backend, the code does not just determine the aspect of the software, but its behaviour and the way it works like gears.

The first need of the developer is to assure that this engine works in the best way possible and that its future maintenance is as easy as possible to reduce stress, malfunctions and costs.
In fact, some of these aspects are also the goal of the client, but deadlines and budget restrictions often lead to friction between the client and the developer, as they have different ideas on how to reach their objectives.

To guarantee any benefits, the code must be simple, well-studied, commented and dealt with in a rational way, with a global vision of the project and all of the components that will be part of the software.
This leads to the adoption of the above-mentioned online libraries. Libraries are packets of various components whose aspect can be personalised and which can adapt to different needs.
Unfortunately, to maintain a high quality level it is not always possible to have total freedom in the customisation to allow the integration of every single request of the client or the UX/UI designer.

The issue that potentially causes friction is finding a balance between guaranteeing the quality of the code and the needs of users, clients and designers which often include particular customisations, which may harm the clarity of the code, at the same time improving user experience, marketing, branding and visual harmony.

The UX/UI designer

A designer is always on the lookout for formal solutions that are suited to the project objectives. It’s not just a question of “giving form to something pleasant”, indeed those who work with graphics – whatever the application sector may be – also plan for the coherence and consistency of the creative product.

To guarantee a good result, when it comes to software, the designer follows a series of rules, habits, good project practices and logical solutions.
They need to ensure that the interface and interactions are mutually coherent, ordered, understandable and esthetically in line with what is expected from a professional service.

As mentioned in the previous section, their frontend solutions may contrast with the limitations imposed by the developers: certain minor details (colour matching, text layout, margins, animations etc.) sometimes require a level of customisation of the component libraries that may compromise the maintainability of the code, making those choices inconvenient in the long term.

At other times, the ideas of the designers require the development of completely new components and, as we have mentioned, if there is not enough budget the team must choose an alternative strategy.
This is how the best potential UX/UI solutions change, going from ideal to real.

There are also situations in which the vision of the designer is not shared by the client – either in part or in whole – and this can lead to a heated exchange in which each party supports their position to convince the other to adopt the solution they feel is best, whether it is color matching, forms, layout, interaction mechanisms, etc…

Different needs coming into conflict

It is unrealistic to think you can meet all of these needs with a single software project without sacrificing some of them. From the analysis to the prototyping phase, all the way to the development, every day projects meet new restrictions that are overlaid and lead to constant compromises for the project team.
The goal remains getting the best result every time a new obstacle shows up and finding solutions that don’t contrast with what has been done so far.

Has your company dealt with a similar situation in the past? Are you sure that once the project was finished the compromise among the needs of the parties involved was balanced? If you want to chat with us about it, contact us.