Too much freedom at the design stage is a trap that is easy to fall into when you're disconnected from the business and technical layers. Every product is an interconnected system supported by an infrastructure that dictates what is feasible within a specific project iteration.

Not understanding this is the first step to desynchronizing the design and the implementation itself, and as a consequence, it leads to the product development process getting drawn out. API (Application Programming Interface) is like a dictator who sometimes won't take no for an answer.

Better or faster?

The product development process is nothing more than a series of decisions, and each of them has a different character and level of importance. One of the most common decisions is whether we want to implement a given solution better or faster. Better usually means longer development time and higher product quality.

On the other hand, faster is the safe option, which often involves the use of native or already existing solutions. Deciding “which button to press" is a complex process, in which you need to analyze factors and conditions that are invisible at close range. Arguments may vary depending on project dynamics, as well as business goals, deadlines, competencies, or financial resources.

In the initial phase of the project, when the main goal is to verify the concept, this cheaper and faster option will lead the way. The solution’s quality or usability are then in the background and do not have as much value as immediate implementation and production readiness.

A lot changes when the product becomes stable and quality turns into a success factor as well as a competitive advantage. Then, the "better" approach turns out to be more important and the solutions taken are more complex and qualitative, which often implies changes in the product infrastructure. The organization now needs to prioritize them and encounter enough time and resources to make them a reality.

If the design team is not aware of what the right approach is at a given stage of product development, the solutions they propose will be incompatible with the actual goal. Say, a need for new functionality will arise, and the designer will apply the best possible solution. A moment later, it may turn out that the solution he proposed is impossible or too expensive, and the whole thing needs to be simplified or at least broken up into phases. The design process then goes back to square one, and the company has just wasted time and money.

Product or organizational infrastructure is usually an advanced and complex network. A solution that seems simple at the design level may collide with an invisible iceberg when it comes to technical analysis. Do we want the product categories in our application to have icons that improve usability and design aesthetics? Great.

It turns out, however, that the CMS on which the store is based did not anticipate the need for such a field. Is it possible to add one? Sure, but it will take time, and the technical debt can cause performance problems. Is it possible to bypass the CMS and insert the icons directly in the product? Again, yes, but product categories change so dynamically that it will require excessively frequent releases of the application and, consequently, it will have the opposite effect than expected.

So how to decide? Well, it depends on whether you want to do it better or faster.

Business aesthetics

Everyone knows that a product's visuals are subordinate to its usefulness. However, the designers' ambitions are constantly present in the product development process, which sometimes means that the solutions they come up with may turn out to be inconsistent with the pursued business goals.

Do you want an example? No designer in the world likes sales banners. Some people omit them completely in their projects, others choose the wishful option and try to remove all the flashy marketing from such banners, changing their aesthetics to subtler and less invasive.

However, the reality is different. The marketing banner, which needs dedicated space on the home page, is a hen that lays one hundred thousand golden eggs for the company budget each month. All you can do when the designer argues that the banner is ugly is to respond with a polite smile. So how can you approach it differently? By not losing touch with reality.

The vast majority of digital products we deal with have specific business goals – usually selling services and products. In order to reconcile these goals with the visual aspect, it is necessary to develop rules and guidelines that should be followed by the marketing team when coming up with advertising creations. This will allow you to create aesthetic products without losing out on their marketing value.

Too many PMs spoil the broth

Design and development are two stages of the process that should work closely together. Any discrepancy between the design and its implementation decreases the efficiency of the entire process. This is particularly evident in products where various companies are involved in the design and development phase.

Avoiding chaos in communication is almost impossible, even with the help of tools such as design systems, which serve to facilitate the process of transferring the project from the designers to the development team. Due to the human factor and the lack of fluent communication, the product development process will constantly run into speed bumps, and the final effect may be qualitatively different from what was expected.

Let's take this example – designing the signup process according to the best practices will most likely result in encountering API limitations that will not allow the design to be successfully implemented A better solution would be to analyze technical feasibility before starting the design phase. Then, adjust the design to the conditions and the environment in which it is implemented while trying to find small improvements to this infrastructure in order to improve the user experience. It sounds good, but it's almost impossible in a situation where design and development are carried out in two different places, by two different teams, and at different times.

How can you avoid that? Limit the number of subcontractors, someone will say. Of course, this is easier said than done, especially if the tender has already been awarded. Another way out? Document everything. Designers need technical knowledge, and developers need to understand the intentions behind every visualization. Documentation is not the cure for all evil, but it will certainly contribute to improving the process of asynchronous knowledge exchange.

However, knowledge alone does not guarantee high quality of implementation. It must go hand in hand with a conscious effort to increase control over the entire process and capture a perspective on its development from a bird's eye view. It turns out that it is valuable to create a role in the team that will be responsible for coordination, directing the development and product quality, combining the competencies of many teams, and anticipating problems through appropriate schedule planning.