AI Always Finds Room for Your Feature (but That’s a Problem)

Turning an idea into an MVP has become incredibly easy with the help of AI. You describe the idea, with no need for technical terms, and in no time at all you have a product that works, at least at first glance.

Yet sometimes the result leaves much to be desired. In fact, this happens so often that someone decided to dedicate an entire website to low-quality AI-generated content, the so-called AI slop.

Let’s make it clear right away that the purpose of this article is not to talk about AI itself and give an overall judgment of it, but to describe a specific common problem that can arise when using AI to design a digital product, especially when this happens without the supervision of an experienced technical expert who knows the design process, its rules, and the shared standards.

A problem of space and costs

What often happens is that, once the product starts to look almost finished, its creator immediately starts thinking about how it could evolve: “We could add this feature”, “But what if the user wanted to change these settings?”, “We should also cover this case”.

AI sets itself no limits: it reasons about individual pieces and executes; it doesn’t suggest cutting this or that feature, nor does it usually worry about keeping the product internally consistent.

Want a new menu item to get to your favorites faster? No problem, even when adding that item means reducing spacing or font sizes, making the whole interface harder to understand.

And before long, a simple, linear product with a clear purpose starts turning into a jumble of features, not always consistent with each other or with the ultimate purpose. But why does this happen, and what does AI have to do with it?

When building was expensive, cost was a filter

Before the development of digital products moved substantially into the hands of AI, an entrepreneur who wanted to build their digital product knew they were facing months of work, split between design and development.

Besides affecting the financial investment, the timelines pushed people to think carefully about what they intended to build. In particular, during the design process:

• Priorities were set
• The architecture was the starting point on which individual screens were built
• Conventions that users recognize were respected

The result was a coherent project, following a logical thread from the first development to the addition of secondary features. It was often not enough for a single user to request a specific new feature, because to recoup the costs it had to be something other users wanted too, and in line with the product’s overall direction.

AI has lowered the cost of work

With AI, a new feature is often just a prompt away. This means that the temptation to add something often turns into concrete action and, in fact, becomes the new modus operandi.

There are undeniably some upsides too: a single client’s need, a small fix, and so on reach production sooner. But there is also a downside, a phenomenon so widespread that it has a name: feature creep.

Feature creep is defined as the addition of excessive features to a digital product, going beyond those the user actually needs. The push toward this behavior very often comes from the desire to please users (and, as a consequence, increase the product’s activity and revenue).

But why is this a bad thing? Shouldn’t satisfying every user be a product’s highest aspiration? The answer has several facets:

• On the one hand, adding features can weigh down the software to the point of compromising the product’s smoothness.
• On the other hand, the architecture becomes complex, redundant, and hard to navigate. A lot of information, perhaps without even a hierarchical order, creates confusion for the user.

In practice, this way of working is the opposite of the KISS principle, considered one of the golden rules of software development.

How to avoid the trap of building too much, and building it badly

We gave it a try, which you can find in this reel. We asked AI to build an app with a single function: translating conversations in real time. The result fully shows the risk you run when all control is left in the hands of AI:

• An overloaded layout, with lots of information on the same level.
• Many more features than necessary.
• Inconsistent components: the same information appears in several places on the platform and, conversely, the same spot sometimes shows different information.

We had actually already developed this conversation translator: it’s called VoiceLink and you can find it in the stores. Without false modesty, we can tell you that the result we achieved is of a very different quality from the one we got with a single prompt.

But the difference isn’t made by the tool itself; quite the opposite: we work with the support of AI ourselves. The difference lies in designing the application as a set of paths, meant to be followed as easily as possible, and not as a mere cluster of screens.

What to ask yourself when designing an application

A series of questions can help you build a product that makes sense for the people who use it. Having a professional guide you in this phase means being able to answer these and other questions that will help you develop a quality application.

What really matters? Before deciding where to put a new feature, you need to decide what is actually needed. Setting a priority serves to guide the user’s eye toward the core feature.

Without a clear hierarchy on the screen and the reference points each of us is unconsciously used to, the cognitive load of whoever uses the application increases and the ease of use decreases.

Who will use the app, and in what situation? AI designs for a generic user. It’s up to us to specify a particular type of user. For example, in the case of the translator, we can imagine that the person using it might be standing, facing another person, perhaps with their phone in one hand and luggage in the other.

Imagining a typical usage situation lets us design the application specifically for the user, down to the smallest details:

• How big the buttons should be
• How much text to show on each screen
• Which screen orientation to support, in the case of a mobile app

Where do I add a new feature, and what changes in the rest of the product? It’s not enough to ask where to make room for a new feature; you also need to evaluate how it integrates with the existing ones. Things to avoid:

• Duplicate features
• Excessively long menus
• Convoluted paths to find a feature

In a well-crafted process, the application’s architecture takes precedence over the individual screen: it is designed first and carries greater weight. Every new feature, therefore, should go through it first.

Is standard behavior maintained? People learn to use an application by watching how its individual components behave. If, from one screen to the next, or even on the same screen in different situations, the application doesn’t always respond in the same way, for example by showing different information in the same spot, the user gets lost.

Are the cases where something goes wrong handled? What happens when, for example, the microphone doesn’t have permission, there’s no connection, or the translation is wrong? Are error cases handled?  In a test setup some of these situations might never occur, but real users have abilities that even the best QA team couldn’t dream of.

If you want someone to help you develop your application, whether it’s already at the point where features are overflowing and it’s better to cut back, or you’re still in the design phase and want to do things properly, Mabiloft is the company for you.

We can help you develop your digital product by following a time-tested process, carried out by people who know what they’re doing. Don’t hesitate to write to us, with no obligation.