Frankenstein products and how to recognise and create one

Digital products are complex but also – in contrast to physical infrastructure like buildings or bridges – malleable. This characteristic is usually a big advantage – they can be improved, rebuilt, and expanded. They constantly evolve and are being developed according to changing requirements. 

Very often, however, this process deviates from the route that was set upon their creation. Or sometimes, they are integrated with other products. Or sold. Or bought and rebranded. And suddenly, users are confronted with a very unique creature – Frankenstein digital product that – even if working properly – looks a bit strange and sometimes scary. Let’s dive deeper and try to understand what these processes look like and how to avoid such digital monsters that do not comply with the standards of good user experience.

They lurk all around us

Everybody knows them as they are everywhere. Actually, with the pace of digital transformation and the complexity of systems and platforms, with multiple teams (sometimes composed of hundreds of specialists) collaborating on a big project, it’s unavoidable.

Think about the intranet consisting of several different tools that have been connected over the years or an e-commerce platform that redirects you to some third-party solution to accomplish the payment process. Maybe there’s some strange GDPR popup window that distracts you upon entering the website, which looks completely different than the website itself. Or the FAQ section that you are trying to access that does not resemble the branding of the company.

There are multiple examples, and I can bet that you encounter them daily, both in your digital workplace and outside your professional experience when browsing the internet or using different apps. The Internet and the digital domain is a huge and colourful collage.

Sometimes it’s just a small nuisance, and you hardly notice them when you get used to their presence. But in some cases – especially when dealing with a new product or platform – it might be frustrating, especially when you need to accomplish the process quickly and expect everything to go smoothly and without distraction. And when seeing these stitches, you might feel slightly uncomfortable that something wrong is happening. If you are tech-savvy, you might even think about the security of your data. If the system has been quickly assembled in a messy way, is it safe and well-tested?

In most cases, though, the Frankenstein products are harmless beings. They are just the outcome of processes that happen inside the organisation that has brought them to life or even the carelessness of their creators. They might be complex to handle and surprise you in an unpleasant way, but – in most cases – you should not be afraid of them.

While for the typical user, it might be just a glitch and a small frustration, for a designer or product manager, especially one working in a big organisation, it is good to understand the underlying mechanism and patterns that lead to the naissance of a typical Frankenstein.

The anatomy of a Frankenstein product

What defines the Frankenstein product, then?

In my working definition, it must consist of at least two modules that differ visually, and structurally (or in both aspects) and this inconsistency must be visible to the user. They often – but not necessarily – are bound by one navigation section in an effort to make the tool look consistent and assure the user that it’s not phishing activity or a malfunction of the system.

They are usually full of small, inconvenient surprises. You can be redirected to a strange-looking part of the system, or the process can suddenly be aborted. The application’s design can change, and the navigation pattern might be altered. Often some strange activity is happening in the address bar (if we consider web applications operated in the browser).

There are also more subtle cues that only a trained eye can spot. When you see the difference in the size of the headings or shape of the buttons or a different style of icons, you might get this sneaking suspicion that the creators were not either very honest with the users or meticulous enough.

Even worse when somebody has not properly stitched different organs at the deep level. In this case, you might be asked to provide your password several times when trying to accomplish one process. Of course, the organisation can argue, that they have several systems and each one of them requires separate verification, but as a user, you usually don’t care about the architecture of the digital ecosystem of your bank or healthcare provider. The burden, in such a context, is transferred to the user and not the implementation team, causing discomfort and a bad user experience.

The less obvious consequence of such collage systems is that they might not transfer the data between each other, which results in asking the user for the same data again and again even when the data has already been filled in the other part of the ecosystem. 

The illustration compares the navigation and header sections from several parts of the LinkedIn ecosystem. Notice different shades of blue, typography style in the header section, or the location of the user avatar (or lack of it) which is an access point to account settings. Some tools display a “Back to LinkedIn” link, which might be quite confusing from a mental model point of view (Have I left LinkedIn then? But it still resembles LinkedIn, doesn’t it?).

The flaws and disadvantages

One might argue that if the tool does the job if the process can be accomplished and the technology works, it does not matter how the tool looks, and being so meticulous is just academic. But it does matter for several reasons. Let’s discuss them and show the arguments for avoiding messy digital products.

  1. Challenging mental models – when there’s no clear structure or the navigation is inconsistent, it is much more difficult to get the idea of the product and understand the principles of navigation and interaction with it.
  2. Hindered learnability – products that are difficult to understand are more difficult to learn, which implies the need to prepare more tutorials and spend more time onboarding the users.
  3. Lack of efficiency – very often broken processes and inconsistencies result in longer processes and suboptimal structure – (e.g., they require more clicks to accomplish a specific process) and that means more cognitive workload and more time spent in the application.
  4. Need for more support and Q&A – lost and confused users will reach out for help more often and more energy will be put into providing them with the necessary support.
  5. Bad user experience and dissatisfaction – being surprised by unintuitive solutions will often result in disappointment and frustration.
  6. Cybersecurity threats – design inconsistencies might sometimes be exploited by criminals who might try to mimic those inconsistencies.
  7. Undermining the credibility of organisation – clients generally expect good quality of the design and professional-looking tools. If they see the stitches, their image of the organisation might be challenged.
  8. Difficult to maintain – if the system has been developed without a consistent design system, the maintenance will be more demanding, and the cost will grow with time.
  9. Difficult to develop – the complex structure, legacy solutions, and technical and design debt will cause issues and challenges for the team developing the product further since they will need to take care of all existing inconsistencies, libraries used, and exceptions created.

As you can see, Frankenstein products cause trouble for users but mostly for organisations that bring them to life. Are there any positive aspects then?  

The benefits – sometimes quick and dirty is good enough or it is the only option

Obviously, digital Frankenstein products exist for a reason and might also have positive aspects – especially for the organisation that maintains them. The existence of such entities might be positive from several perspectives.

First, when creating a product consisting of several modules that already exist, organisation can ship it sooner. Such ugly creatures might not meet the visual standards and offer perfect consistency but will allow users to accomplish their tasks. By adopting such an approach, the organisation can test the market fit and ship the next versions of the products quicker.

This approach can be especially valuable to early-stage startups when time and skills are usually scarce resources and time to market is of utmost importance. This strategy requires less investment but there’s always the flipside and the risk of disappointment and rejection of such a product is higher.

By trying to stitch together several components, the product team can quickly add the necessary functionality. It might seem that the functionality is more important than the quality and sometimes – especially in the case of systems used only internally – that is exactly the case.

Employees can learn about the product, accept its imperfections, and ignore inconsistencies. Business value and the ability to run the business operations are most important than the quality of design and user experience.

But in the case of products that are offered to the general audience and are often judged based on the design, this strategy might be short-sighted. Very often users give product just one chance and the team behind it has only one chance to make a good impression. Most users prefer nice, shiny, and minimalistic products to shapeless, untidy monsters.

Why do they appear? How to minimize the risk of creating your own?

The inevitable appearance of Frankenstein applications is a consequence of several elements innate to organisations and human nature. It can be explained by observing and understanding the way big platforms are being created and developed, the processes happening at the organisations, the structure and product management processes, and last but not least, the specific human nature, which is all to blame.

Let me name a few typical reasons:

  1. Poor product management and lack of product and experience strategy
  2. Lack of design awareness in different teams
  3. Lack of consistent design language: Organisations may not have a consistent design language or style guide that is used across all digital products. This can result in inconsistencies in design and user experience.
  4. Mediocrity and poor performance: we need to admit that in many organisations the expectations are not set high enough and junior and inexperienced team members are left without support and supervision. That leads to deliverables that are of not very satisfactory quality.
  5. Mergers and acquisitions: Organisations that have undergone mergers or acquisitions may have different design and development teams that have different styles and approaches. This can result in a lack of consistency in digital products.
  6. Different stakeholders: Different stakeholders within an organisation may have different design preferences and priorities, which can result in inconsistencies in digital products. For example, marketing may prioritize branding and visual appeal, while engineering may prioritize functionality and efficiency.
  7. Lack of communication: Organisations may have a lack of communication between design and development teams, which can result in inconsistencies in digital products. Designers may not fully understand the technical limitations of the product, and developers may not fully understand the design requirements.
  8. Teams working on different parts of an ecosystem are not coordinated properly: after some time, small differences in visual standards and discrepancies in the application of the rules lead to big differences and gaps between different modules.
  9. Legacy systems: Organisations may have legacy systems that are difficult to update or integrate with new systems, resulting in inconsistencies in digital products. These legacy systems may have different design and development approaches than newer systems.
  10. Limited resources: Organisations may have limited resources for design and development, which can result in a lack of consistency in digital products. They may need to prioritize other aspects of their business over design consistency.

What can you do then, as a product manager or designer?

  • Make sure that you have a design system in place and that all team members know how it works and WHY they should use it.
  • Use the design system – many organisations have amazing design system but just ignore them
  • Take time to plan any new feature or product and think about how it should be incorporated into the existing structure of the product and digital ecosystem
  • Secure the time to review the design of new features or modules and compare them against the patterns and guidelines.
  • Enable synchronizations between the teams working on different products

Frankenstein products reveal the structure of the organisation or the history of the product

It is fascinating when you know how to look that the subtle cues in the systems can reveal either the elements of the history of the organisation or the way it is structured.

Several patterns can be observed, and we can try to review them briefly. Each scenario might result in a mutilated product.  

  1. Merger – the product consists of two or more systems that have been connected because of the M&A activities when the organisation acquired a product that is somehow complementary to the core product but did not invest in meticulous integration, choosing the ad hoc solution.
  2. Siloed design or development – when different teams are responsible for different parts of the ecosystem, they might use different visual standards or components which are connected after being finished. Quite often, that results in structural or visual inconsistencies. Creative teams without governance and tools quickly introduce differentiation in the ecosystem of the products because humans are extremely creative.
  3. Regional business structure – sometimes, organisations are divided into regional or country units. In such a case, especially when the structure is rather loose or there’s much independence in the organisation, very often each region develops its own tool. Those platforms are often inconsistent because they are developed by different internal teams or external agencies without global coordination or a lack of a design system.
  4. Hasty and careless rebranding – when the organisation changes its brand, there are a lot of things to consider. But it’s not rare that some systems that are used less frequently are rebranded only partially. The need to change the product visually sometimes is reflected only in the key elements (like the logo or specific parts of the system e.g., navigation or font or colour) while the rest stays as it was before, which obviously results in a Frankentein-ish experience.

Why it’s so difficult to avoid them?

In theory, yes, but in practice, it’s extremely difficult as there are so many factors and phenomena that will naturally create such digital entropy and decay of consistency.

To avoid breeding Frankenstein products, the organisation – especially product managers, designers, and lead developers, need to resist the chaos and temptations of cutting corners constantly and actively.

The main reasons why it is so difficult to avoid creating inconsistent digital products are:

Divergence of interests – in an organization, everyone has their own area of responsibility and their own metrics. If the speed of operation or the expectation of delivering funnality at all costs has a higher priority, design quality and consistency will naturally fall.

The requirement to deliver quickly – if the pace is the only criterion, there is always a trade-off and – supposing that the team will not be extended, the consistency and quality will be to some extent sacrificed.

Tight deadlines and limited budgets – resource constraints arise in every organization. If expectations are unrealistic, the team will look for solutions that may seem optimal for achieving short-term goals but will lead to trouble and chaos in the long run.

Lack of understanding of the long-term consequences of hasty action – taking shortcuts works well in select situations if there is an awareness that speed is being favored over accuracy and consistency. However, if this style of product management is the standard, it inevitably leads to product erosion and deterioration.

The invisible costs of spoiling the product – Initially, the costs of acting quickly and executing projects without standards are invisible. Minor inaccuracies are visible only to those who know the product well. However, such minor cracks tend to turn into deep cracks and cause big problems over time.

Lack of understanding of what a product’s lifecycle looks like – The pace of work on a product with a limited scope and a small team is inherently fast. As the team grows, there is more resistance from the organisation and it takes more time to make decisions and coordinate work. Additionally, the complexity of the product means that adding more elements requires more attention and coordination, as well as testing and checking for consistency. If these dynamics are not understood by the management team, which requires a constant pace of development, this will lead to shortcuts and inaccuracies.

The worst enemies of Frankenstein – the design system and the strict governance

One of the main tools that will prevent the creation of a monster is the design system. This set of guidelines and ready-made components dictates the structure and rules that must be applied when creating any new screen or module.

The design system defines the navigation structure, the colour scheme, the headline sizes, and the icons that can be used – in a word, it limits the creativity of individual team members and imposes top-down consistency.

Just as it is impossible to run a large company without clear guidelines on what its business cards or logo should look like, it is impossible to do meaningful work with large teams and digital products without such a tool.

The effectiveness of the design system in avoiding building Frankenstein also depends on consistency and the governance model adopted. It is not enough to create and publish a design standard, the organisation has to control its adoption and application because team members may not follow the agreed rules for many reasons (lack of awareness, wrong understanding, lack of competence, wrongly understood creativity).

Testing is necessary – not only technical or security testing, but also experience testing – visual and functional. The use of patterns, colours, sizes, iconography – everything should be checked to avoid inconsistencies. An experienced eye can quickly detect any module that is not pixel-perfect, but the Q&A team needs the time to run such an evaluation.

Of course, building and implementing a design system in the organisation is a demanding, time-consuming, and relatively expensive process. However, in the long run, implementing such a system will bring big savings and protect the product from the Frankenstein curse. Teams will work faster, new features will require less work (because the components will be ready for re-use), and less time will be spent on testing and talking about what a particular element of the system should look like.

How to heal your Frankenstein or at least make it more pleasant looking?

If the data structure of the system is properly designed and the user architecture is not fundamentally broken and inconsistent, there is a chance that with a proper approach, effort, and some patience, the tool can be rescued. Building and maintaining a consistent design system, as previously mentioned, can help a lot.

There are typically several approaches to healing such mutilated products.

If the problem lies in a module that was forcibly added, then the product team must think if the functionality of the transplanted organ can be built into the core product with more care and attention. Sometimes, it might be the question of proper styles as the user does not care about the quality of integration. In other cases, a reduction can help – getting rid of specific, hastily added functionality that can be removed and built with more diligence.

But if there are issues on a deep level, the information architecture is broken, then sometimes the only solution is a complete overhaul or even rebuilding the product from scratch. It definitely requires a much bigger investment and time, but for every product, there are limits to its life and immunity to uncontrolled design and development. The price will be paid anyway in maintenance, credibility, and, probably most important, the frustration of the users.

Be forgiving when you meet one…

With constantly changing technology, the growing complexity of our world, and defects of organisational management, it’s impossible to avoid hastily built products. But as we discussed, some situations justify their existence. Therefore, as users, we should have indulgence for such distorted souls.

…but don’t build your own

But as designers and product managers, we should have more perseverance in the daily fight for consistency and proper methods. With modern product management tools, design systems, styles in Figma, awareness, and empathy, we should do better. When we stand up for our work, there’s a good chance digital Frankenstein products will not scare other human beings so often.


Want to know more about Frankenstein products? Let's talk!

    Do you wish to receive the latest information related to the topics of business and innovation design, as well as information about Edisonda's activities, projects, and offers?

    Please select the channel through which we can contact you (consent is voluntary):

    Information provided in the form will be used only in order to reach back to you. Contents of the correspondence might be archived. More details could be found in our privacy policy.

    Michał Madura
    Senior Business Design Consultant

    +48505016712 +48505016712