UX/UI Design Development for a 1C-Bitrix Website
A familiar scenario: a site has been running on 1C-Bitrix for three years, conversion is dropping, and analytics shows users leaving the catalog on the third click. The designer who built the site originally worked "to a marketing brief" with no knowledge of Bitrix component structure or template rendering. The result: beautiful Figma mockups that cannot be implemented without rewriting half of the bitrix:catalog.section template.
UX/UI for Bitrix is not just design. It is design that accounts for how the platform renders data, where components live, how navigation is built through CIBlock, and what constraints the visual editor imposes.
UX/UI Design Development for a 1C-Bitrix Website
Work begins with an audit of the current state, not with Figma. Before designing, it is essential to understand: which components are in use, how the site template is structured, whether there are custom modules, which pages are generated dynamically through CBitrixComponent, and which are static.
Audit and Technical Specification
At this stage we analyze:
-
Template structure: directories
/bitrix/templates/, component overrides in/local/templates/ -
Components in use:
bitrix:menu,bitrix:catalog,bitrix:news,bitrix:form.result.new— each has its own markup constraints - User entry points: data from Yandex.Metrica or Google Analytics, click maps, session recordings
-
Technical constraints: PHP version, component cache (
managed_cache), CDN
The audit results in a technical specification with wireframes — not pixel-perfect mockups, but interaction diagrams. Wireframes are approved before visual design begins.
Designing User Scenarios
For an online store on Bitrix, the key scenarios are: catalog → product page → cart → checkout. The bitrix:sale.basket.basket component has a rigid template structure — you cannot simply "move the button to the left" without editing template.php. This must be taken into account during design.
For a corporate site, the focus shifts to info block structure: how a user finds the right section, how search works via bitrix:search.title and bitrix:search.page.
We design separately:
- Desktop scenarios: full navigation, hover states, complex filters
- Mobile scenarios: taps, swipes, content prioritization for narrow screens
- Component states: empty cart, out-of-stock product, form error, data loading
Visual Design and Design System
Mockups are developed in Figma using a component-based approach. Every UI element — button, product card, pagination, breadcrumbs — is described as a component with state variants (default, hover, active, disabled, error).
For Bitrix, it is especially important to work through:
-
Component templates: a separate mockup for each significant component —
bitrix:catalog.element,bitrix:catalog.section,bitrix:news.list,bitrix:news.detail -
Admin context: if editors use edit mode (the admin toolbar), the design must not break with
show_admin_panelenabled - Responsive states: at minimum three breakpoints — 1280px, 768px, 375px
The design system is documented in Figma as a library: colors, typography, spacing, shadows, icons. This reduces markup time and makes maintenance predictable.
Case Study: Catalog Redesign for a Manufacturing Company
The company produces industrial equipment; the site runs on Bitrix "Business". Problem: managers reported that clients could not find the right product variant — they landed on the product page, could not understand the characteristic selection, and called the sales department.
What was done:
- Analyzed the funnel via session recordings — 73% of users did not reach the "Add to Cart" button on the product page
- Studied the info block structure: products had 12 characteristic properties, but the
bitrix:catalog.elementcomponent displayed them as a simple list - Designed a new product page UX: characteristics grouped into tabs, variants selected through an interactive configurator
- Developed mockups taking into account that data comes from
CIBlockElement::GetProperty()— the configurator is built dynamically from property values - Designed the mobile version separately: the configurator collapses into an accordion, key characteristics are placed above the fold
After implementation, time on the product page increased and the number of "help me choose" calls decreased — customers began completing checkout independently.
Handoff to Development
The finished design is delivered with full documentation:
- Figma file with Auto Layout configured, named layers, and components
- Specifications for each component: spacing, dimensions, behavior across states
- Animations and transitions: described as Figma Prototypes or written descriptions for the developer
- List of Bitrix components affected by the redesign, with the specific files to be edited
Timeline and Phases
| Phase | Small site (up to 20 pages) | Medium site (20–80 pages) | Large project (80+ pages) |
|---|---|---|---|
| Audit + specification + wireframes | 3–5 days | 1–2 weeks | 2–4 weeks |
| Visual design | 1–2 weeks | 3–5 weeks | 6–12 weeks |
| Design system | — | 1 week | 2–3 weeks |
| Review and revisions | 3–7 days | 1–2 weeks | 2–4 weeks |
Timelines depend on the number of unique templates, component complexity, and the client's review turnaround. Revision iterations are built into the estimate.
What Affects the Cost
Designing "a landing page on Bitrix" and designing "an online store with a 5,000-item catalog" are fundamentally different in scope. Cost drivers:
- Number of unique pages and component states
- Whether a design system is needed (for future scalability)
- Depth of prototyping — mockups only, or an interactive prototype
- Mobile requirements: responsive adaptation or a separate mobile design
- Number of revision rounds that fall outside the agreed specification