Jelena Racković · · 4 min read · UX
One product, two screens: designing a mobile app and the web app behind it
In many of the products I work on, the mobile app is the star. It is what users download, what the client shows investors and what appears in the press release. Almost nobody talks about what sits behind it: a central system where content is managed, users are supported, data is checked and the whole operation is quietly kept running. Designing both together is one of my favourite challenges, and the hidden half is often the more interesting one.
The app everyone sees
The app gets the attention, and rightly so. It has to be fast, clear and pleasant, because people use it in their pockets, in a hurry and without patience for anything clumsy. Most of the design budget and almost all the excitement go there.
But every tap in that app depends on something behind the scenes. Someone has to publish the content it shows, approve the accounts, answer the support tickets and see what is happening across thousands of users. If the central system is weak, the app stops feeling magical very quickly, because the people running it simply cannot keep up.
The system nobody mentions
Central systems are rarely glamorous. They are tables, forms, filters, roles and audit trails, used by a small team for many hours a day. The users are not consumers who can delete the app; they are colleagues who must use it whether they like it or not. That changes the priorities: clarity beats charm, speed of work beats visual surprise, and consistency matters more than anywhere else.
Affordable now, ready to grow later
Clients usually want the central system to be inexpensive, and that is a fair request: in the early stages, money should go where users can see it. The trick is to make it cheap without making it a dead end. I design the first version around the handful of tasks the team truly needs from day one, and I leave clear room for what will come later, such as new roles, new modules and new markets, without building any of it yet.
That room is structural rather than visual. Navigation that can absorb new sections, a permissions model that can grow, layouts that handle a table of ten rows or ten thousand. When the time comes to scale, the system extends rather than being rebuilt.
Why the choice of libraries settles half the work
The most important decision, and the one most often made too casually, is the technology and component library behind the central system. Choose a mature, well-supported library and a huge amount of work is already done: tables with sorting and filtering, form validation, date pickers, accessible dialogs, sensible defaults. Choose badly, or build everything from scratch, and the team spends months reinventing what already exists.
So I take part in that decision early, alongside the developers. We pick a foundation that matches the stack, then I design within it, adapting its components to the product’s tokens rather than fighting them. Paired with a shared token set, the same visual language can run through the app and the central system, even when they are built with different technologies. The result looks like one product, costs a fraction of a custom build and is far easier to maintain.
Two screens, one product
From the outside, the app and the central system look like two different products. From the inside, they are two faces of the same one, and they work best when they are designed together, sharing language, logic and tokens. The app earns the applause. The central system earns the client’s peace of mind. I like designing both, and I have learnt that a good decision made quietly in the back office often matters more than a beautiful screen in the front.
Is your design system starting to fade?
I’d like to hear about it →