An app is not a website with more buttons. Here is how app UX differs, how to tell you need a designer, and what the work looks like on a new product, a redesign and an optimization.
If you are building a SaaS product, a CRM, an admin panel or any web app, you have probably heard that user experience matters. The practical questions are harder: when is it time for a designer, what do they actually do, and is it better to build something new or fix what you have? This is a short guide from practice, without promises that can't be kept.
A website is mostly read and looked at. An app is used: people work in it, often every day and often under pressure. That is why app UX differs from website UX, even though both share the same foundations. I covered the foundations in the article on what UX design is, and here I go a step further: toward SaaS products, CRM systems, admin panels and other web apps.
How an app differs from a website
Nielsen Norman Group describes complex applications as software for broad, open-ended goals and nonlinear workflows, used by people trained in their field. According to their explanation, such products usually work with large amounts of data, involve collaboration across roles, and carry high consequences when something goes wrong.
Not every app is that complex, but the problems they list show up in ordinary SaaS too:
- Learning. People want to start working right away, so they learn by trial and error.
- Workarounds. Users find a way that "sort of works" and stay with it, and over time lose a lot of time.
- Crowded screens. One tool serves beginners and experts, so the screen quickly becomes cluttered.
- Too much information at once. A decision needs more data, but not all of it can sit in the same place.
You can skim a website, but you have to master an app. The designer's job is to shorten that mastering.
Six signs you need a designer
None of these proves a problem on its own, but if you recognize three or more, it is worth looking at the product through the eyes of someone who doesn't know it.
- Support keeps answering the same questions. If users can't find a basic thing, the problem is the screen, not the users.
- Important features are barely used. A feature that exists but can't be seen or understood doesn't exist for the user.
- New users drop off in the first days. The usual cause is onboarding or a first screen that doesn't say where to start.
- Every new feature adds a new button. Without a plan, the interface grows like a pile, not like a whole.
- A developer built the interface on the side. That is perfectly understandable for a first version, but after that it makes sense for someone to take over the whole.
- You don't know why users leave. Without research only guesses remain. That is why the article on why UX research is crucial is useful here.
What a designer does on an app
The flow depends on the project, but the order is mostly the same:
- Understanding users and tasks. Who uses the product, what they are trying to do and where it is hardest. This is the basis for everything else.
- Mapping flows. By which path the user reaches the goal and how many steps it takes.
- Structure and navigation. What sits where, how it is named and how people move between parts of the app.
- Key screens. Tables, dashboards, forms, filters and empty states, because these are the places where people spend the most time in an app.
- Prototype and testing. A clickable model that is tested before developers spend time on code.
- Component system and handoff to developers. The same elements look and behave the same everywhere, and developers get a clear specification.
Examples from my work: on the Balkanaukcija platform the focus was on searching and browsing vehicles and on simpler bidding. SimpleCRM was a tool for tracking leads with integrations and a form builder, and the Vakel Wallet admin panel was about monitoring transactions and managing user and employee accounts.
Onboarding: where mistakes happen most
The first reaction to a problem with learning a product is usually a run of screens with explanations. NN/g research shows that such tutorials often fail: they interrupt the user, get skipped and are quickly forgotten.
Help that appears when it is needed works better: a short tip with a concrete step, an explanation next to a more complex feature, and help that is easy to close but also easy to find again. In practice it is also the fastest way to check whether the problem is in the instructions or in the flow itself.
New build, redesign or optimization
Three different jobs, and it is worth knowing which one you need:
- New product. You start from users and flows, and only then screens. The best case is a designer who joins before the developers.
- Redesign. The app works but is hard to use. Often the functionality stays the same while navigation, layout and clarity change. That is how it went on the vPay app, where functionality had to stay the same because the app already had approval from the regulators.
- Optimization. Targeted fixing of one part: onboarding, sign-up, order processing, a dashboard. The fastest and cheapest option when it is known where users get stuck.
If you aren't sure where you are, start with a check. You can find a short list to go through yourself in the article website UX check in 30 minutes, and I explained the difference between a check and a deeper review in the article on the UX audit.
If the app was built with AI tools
More and more often I get inquiries about apps that first came to life with tools like Lovable. That is a good way to get a first version, but the screens appear in the order they were requested, not by the logic of the users. Then the UX work becomes about order: what is primary, what is secondary and by which path to go. I write about this in the articles on vibe coding and app design and on using Lovable.
What to prepare before the first conversation
You don't need anything special, but this speeds up the start:
- A link to the app or prototype, if there is one.
- One sentence about who the users are and what they mainly do.
- Three places you think don't work well.
- What must not change: technical limits, deadlines, approvals.
- Any data you have: where users drop off, what support hears most often.
What working together looks like
I wrote about what you can expect, and what not, in the article on working with a UX designer. The price depends on the scope, so it is best to have the explanation at hand before the conversation: how much UX/UI design costs. I explained the connection between design and business results in the article on how to measure the profit value of UX.
What next
If you are working on a SaaS, a CRM, an admin panel or another app and want a second look, send me a link and three things that bother you. I'll look and tell you what I would fix first, with no obligation. You can read more about how I work on the UX/UI design services and UX consulting and audit pages, and you can send me a message through the contact page.
