Are You Making Your Users Do the Backend Job? (B2B Perspective)

Why do some interfaces feel like a natural extension of our thoughts, while others seem built just to cause us pain (remember those forms asking you to enter your birth date with a mile-long select menu instead of just letting you type it)? How do you create the kind of effortless interaction that makes a design truly great? Why have consumer apps already figured out this balance, while B2B software is still so painful? \ If you’ve traveled to London in recent years, you might have noticed how convenient the public transport payment system is. Or, more likely, you didn’t even pay attention – because being able to just use your bank card as you go feels like a basic standard for a modern city. \ But it wasn't always like this. Previously, there was a zone system, and passengers had to calculate their entire route before heading down to the platform. For example, if you had a pass for Zones 1–2 but needed to visit a friend in Richmond (Zone 4), you couldn't just pay the difference at the exit gate. You had to find a ticket machine at your station of departure and buy a special "extension ticket" from the border of Zone 2 to Zone 4. If you didn’t do this, the exit turnstile in Richmond simply wouldn't open. \ Now, all these calculations have been automated. You no longer need to choose fares or think about travel distance – you just tap your card at the entrance and exit, and the system calculates the final cost on its own. \ What does this have to do with product development? Both follow the exact same laws. \ The Law of Conservation of Complexity Tesler’s Law states that a certain amount of complexity cannot be removed from an interface entirely. There are two options for how to distribute this complexity: you can either put the burden on the user to keep the architecture clean, or shift it to the development team, creating messier and less efficient code under the hood. Sometimes this even means distorting how the algorithms actually work, but it guarantees that the interface matches the user's mental model. \ With the switch to the new fare system in the London tube, the complexity was shifted from the passenger to the system’s shoulders. Users didn't need to do calculations anymore, but the system itself didn't get any simpler either. Instead, they built a layer on top of the system and calculated the cost based on the factors built into it – zones and time of day. \n Designers would always prefer this option – making life easier for the user, even at the cost of complicating the system under the hood. But in digital products, this rarely succeeds completely, for a few reasons: Cost. This extra layer between user simplicity and backend language costs money. It needs to be maintained, it complicates development, and businesses aren't always ready to pay for it. Legacy. Old architecture often dictates what to show on the screen. Rewriting it is expensive, and building on top of it is sometimes impossible. Distance from the user. If a product team talks to users rarely or superficially, they don't understand their mental models well. Instead, the team starts perceiving their product's architecture as an unyielding reality. People who work inside a product for a long time inevitably develop a cognitive bias: the system's internal entities seem obvious and natural to them, even though to the user, it might just be a bunch of confusing words. Different types of users. Sometimes, it’s impossible to please everyone. Tech-savvy users want full functionality and maximum flexibility; they are ready to dig into documentation to customize everything. That same interface scares off those who only need basic features. \ Many B2B teams solve this problem with a buffer layer between the user and the system – for example, by hiring an army of Customer Success Managers who figure out clients’ needs and configure the system for them. \ Today, this layer is increasingly being replaced by built-in AI copilots: the client describes the task in their own words, and the system builds the necessary process itself. For example, building an analytics dashboard in Mixpanel used to require an understanding of how the tool works and basic analytics knowledge. Now, you can describe your request in plain language, and the system will generate the charts you need. Why this problem is harder to overcome in B2B. In consumer app design, we deal with tasks the designer knows from daily life: buying a ticket, sending a message, ordering food. Putting yourself in the user's shoes here takes effort, but it's usually much easier. In B2B, the user is often an expert in a domain where the designer is not. And the problem isn't that the designer can't figure out the domain, but rather that they don't live in that same reality with the same daily problems. \ Take an interface for setting up transaction monitoring rules. The analyst writing a rule keeps several things in mind at once. For example, a monitoring rule to detect structuring – when someone intentionally breaks a large transfer into dozens of small ones to fly under the radar. The analyst forms a hypothesis about fraudulent behavior, which must be based on their professional experience and available data, so they don't block half of their normal clients – like small businesses that simply make many small payouts every day. \ They also think about the load on the team – someone has to review every single alert. If they write a condition that's too broad, there will be so many alerts that the team won't be able to clear the queue. Then there's the regulators' perspective – when auditors come and ask why they chose a threshold of 10 transactions instead of 5, they need a documented answer. Finally, they think about the colleague who will open this triggered alert three months from now and needs to understand what to do with it. \ Behind every number in this interface lies a judgment that needs to be justified, documented, and passed on to the team. Building a bridge to this kind of mental model is much harder than doing it for someone buying a train ticket – because you first need to understand the reality the user is actually working in. What to do about it. Here are a few practices that actually help narrow the gap: 1. Listen to the user's words and way of thinking In interviews, users describe their work in their own language. You shouldn't always immediately try to translate it into the language of the interface and tasks – sometimes the phrasings, metaphors, and units of measurement the user thinks in can tell you a lot more. It is important to listen to their own framing rather than immediately translating it into feature talk. \ Since all my best B2B examples are under NDA, I'll have to explain this principle using a well-known B2C classic – Airbnb. In 2022, the team noticed that the way people travel had changed. Previously, the interface of any booking service was built around the database structure. To return results, the system strictly required three exact parameters: Where exactly, which exact dates, and how many guests. \ But research showed that people don’t talk like that. A person doesn't think in SQL query parameters. They think something like: "I want to go to a cabin in the woods for a weekend in July" or "I don't care where, as long as it's close to the beach." \ Generally, people became more mobile and flexible, but the interface forced them to name exact travel parameters: sitting there guessing dates on a calendar, checking different neighboring cities, and verifying if there was even any free housing available. The interface stemmed from the backend's needs, not the human's logic. \ As a result, Airbnb launched the "I'm Flexible" feature and a search by categories ("Lakefront", "Treehouses", "Camping"). They rebuilt the search logic around how people naturally phrase their plans, saving them from having to enter rigid constraints before they even decided on a place. \ \ 2. Dig into confusion during usability tests When a user stumbles on a task during a test, it's easy to assume that a simple tooltip will fix the problem. But hitches are rarely cured by tooltips – most often they signal that the screen's logic has diverged from actual work practices. It could be an unusual order of steps, inconvenient data separation, or terms that aren't used in the industry. \ Questions like "How is this process handled in practice?" or "What would you call this action?" help you see exactly where the interface stopped matching reality. 3. Rely on existing mental models If users have experience with similar products, they will lean on familiar patterns. This doesn't mean blindly copying competitors, but when a pattern has become an industry standard, it's worth reusing. Motion design is a good example. \ For a long time, Jitter was the go-to browser-based motion tool for designers, and since it was built on a Figma-style interface, anyone who already knew Figma could pick it up without learning a completely new tool. So when Figma introduced motion natively at Config 2026, it didn't have to invent anything new either - the pattern had already proven itself. 4. Dive into the domain Read the same communities, articles, and blogs that your users read. Not to become an expert yourself, but to understand what concepts already exist in the user's head before they even open your product. Also, sales engineers, support leads, and customer success managers are great allies here: they have spent years manually building this exact bridge between the user and the system, and they know exactly where it sags. 5. Catch backend "leaks" in the interface Look for specific symptoms: fields named exactly like database columns, "Advanced" sections that hold everything that didn't fit into the general settings flow, and mandatory form fields that exist only because the API requires them. Even after all this work, a gap remains. The user still has to learn the interface, and the interface still carries traces of the architecture. The goal isn't perfection; it is reducing how much translation the user has to do and keeping whatever compromises remain predictable enough to plan around. \ If a B2C app is confusing, the user leaves. But when it comes to B2B, the user sometimes has no choice but to stay, deal with the cognitive strain, and build messy workarounds. This leads to hidden business costs: critical human errors, hours wasted on manual data translation, and the constant friction of working with tools that don't match how people actually think. \ The gap never fully closes, but every bit of work you take off the user's plate frees up attention they can spend on the job itself.