Why you should start with a Figma mockup
Today you want an icon for a feature, tomorrow you need to change the grid, the day after variations should behave differently, and the mobile version can be “fixed later” — and suddenly a simple design update stretches into months of revisions and constant rework.
To avoid that, it’s better to prepare a mockup in advance so both you and the developer can clearly see the expected result and what it takes to achieve it.
Nowadays, you can quickly and affordably build a mockup in Figma, including with the help of AI tools. You do not need to design the whole site; a mockup that reflects the target changes is enough.
For example, if we want to adjust how products are shown in the catalog by adding variation info, the mockup should include the following:
the product cards themselves;
active and inactive variations;
long and short product names;
products with and without an image;
the mobile version;
the “out of stock” state.
With such a mockup, the developer already has a ready-made brief: where the block goes, how the selector behaves, where the main scenario ends, and where the details begin. As a result, they won’t waste your time or theirs guessing, and they can start working toward a clear outcome right away.
If you do not have time to prepare a mockup, you can build a low-detail wireframe with a list of states. That is also a good starting point for a technical brief.
I can help you build the structure and prepare a mockup so the target result is clear from the start and fewer revisions are needed during review.
Which features should be shown in the CS-Cart product list
The main question is simple: which data actually helps a customer choose a product while browsing the catalog? If the product is complex, such as an electrical component, the customer will almost never choose it by name alone. They need parameters. But that does not mean you should dump the entire product tab into the catalog card.
In the catalog, you should show only the features that help quickly filter out unsuitable options. Usually that means 3–5 key parameters. For example:
size;
material;
type;
power;
compatibility;
required mode availability.
If a feature does not help with decision-making in the catalog, it does not belong in the product list. The more clutter in the card, the harder it is to read.
There are two more rules:
The order of features should be the same for all products within a category. If one product shows type after material and another does the opposite, the catalog becomes harder to read.
Icons are useful only when their meaning is obvious without guesswork. If an icon does not make reading easier and instead forces the user to think, it is better to use plain text.
Why it is worth checking what CS-Cart and UniTheme2 already support
Another common mistake is writing code to solve needs that are already covered by existing settings. That is why, before development starts, it is worth going through the standard capabilities of the platform, or the theme if the front end is being modified.
For example, CS-Cart already supports displaying product features and grouping them by feature, while UniTheme2 can control the number of features shown and align the catalog layout.
So sometimes the task is 60–70% solved with settings alone, and custom code is needed only for one option: for example, admin icons, unusual variation behavior, or special responsive logic.
We recommend working in this order:
Break the task into parts.
Check what can be handled with built-in settings.
Identify which functions must be implemented manually.
The official CS-Cart and UniTheme2 documentation can help here. It saves time and budget, and reduces the risk of issues after updates.
Send me the store link and a short description of the task. If needed, I can help with the mockup, UniTheme2 customization, or another CS-Cart theme.
What to consider in the mobile catalog version
The mobile version is where good ideas most often fall apart. On desktop, there is plenty of room. On a phone, there is not. If you simply move the full desktop block set over, you end up with an overloaded card where the user cannot tap the right element and it is not even clear what is being sold.
That is why it is better to plan the mobile design in advance. On the first screen, the card should show only the essentials: name, key features, selected variation, price, stock status, and the action button. Everything secondary is better placed lower or hidden inside expandable blocks.
What else should be checked in the mobile version:
there is no horizontal scrolling;
selectors and buttons are comfortable to tap with a finger;
prices, buttons, and switches do not jump around;
the card does not become too long before the main content;
visual clutter does not make the features hard to read.
What should be checked before release
Before launch, create a checklist. It helps catch bugs before production and avoid surprises on the live project.
What we checked on our projects:
products with long names;
products without an image;
products without variations;
products with several variations;
products that are out of stock;
cards with different numbers of features;
the mobile version on different screen sizes;
the behavior of prices, buttons, and selectors in one catalog row;
the mockup match, if one was created.
This will help catch bugs and unplanned behavior before going live.
Conclusion
To summarize, here is the sequence of actions that will help you with a serious catalog design update:
Create a Figma mockup or at least a visual wireframe.
Understand what technical changes the update requires.
Check the built-in capabilities of CS-Cart and UniTheme2.
Think through the mobile version.
Test cards, variations, states, and theme update compatibility.
This approach helps avoid unnecessary revisions, produces a cleaner result, and ensures predictable behavior on production.