When your Bitrix project has a team of 5+ developers and a catalog of tens of thousands of products, the interface starts to look like a patchwork quilt: buttons in different templates look different, modals are implemented in three ways, and notifications in four?
Each new component is written from scratch because there is no common standard. We have accumulated experience solving this problem in dozens of projects — and we know that a UI-kit on Vue.js with a unified API and documentation eliminates the chaos.
Turnkey UI-kit development reduces the time to create new features, improves interface consistency, and simplifies onboarding of new developers. Below is how we design and develop a UI-kit on Vue.js for 1C-Bitrix projects, including a real case and work stages.
What is a UI-kit and why is it needed in a Bitrix project
A UI-kit is a library of reusable Vue components with a unified visual language. It includes basic elements: buttons, input fields, modals, notifications, icons, typography. Each component encapsulates markup, styles, and behavior. In the context of 1C-Bitrix this is especially important because each component template may be written by different developers, and without a UI-kit consistency is lost.
Library architecture
Structure of a typical UI-kit:
/local/js/ui-kit/
├── src/
│ ├── components/
│ │ ├── UiButton.vue
│ │ ├── UiInput.vue
│ │ ├── UiModal.vue
│ │ ├── UiToast.vue
│ │ └── ...
│ ├── composables/
│ │ ├── useModal.js
│ │ └── useToast.js
│ ├── tokens/
│ │ └── design-tokens.css
│ └── index.js
├── dist/
└── vite.config.js
The library is built via Vite in UMD format:
// vite.config.js
export default {
build: {
lib: {
entry: './src/index.js',
name: 'BitrixUIKit',
formats: ['umd'],
fileName: 'ui-kit',
},
rollupOptions: {
external: ['vue'],
output: { globals: { vue: 'Vue' } }
}
}
}
Design tokens and CSS custom properties
All colors, spacing, radii, and shadows are stored as CSS custom properties. Components use tokens rather than hardcoded values. This allows theme changes without modifying the components:
:root {
--color-primary: #2563eb;
--color-primary-hover: #1d4ed8;
--radius-button: 6px;
--shadow-modal: 0 20px 60px rgba(0,0,0,.2);
}
Typical component set for e-commerce:
| Component |
Purpose |
Key props |
| UiButton |
Button with variants |
variant, size, loading |
| UiModal |
Modal window |
title, size, close-on-esc |
| UiToast |
Notifications |
type, duration, message |
| UiSelect |
Custom select |
options, multiple, searchable |
| UiProductCard |
Product card |
productId, image, price |
| UiPagination |
Pagination |
current, total, onChange |
What stages does UI-kit development include?
Here is a step-by-step guide for integrating a UI-kit into a project:
- Conduct a UI audit — inventory all elements, identify duplicates.
- Design the design system — fix tokens, component composition, variants, and states.
- Develop components in Vue 3 with Composition API, typed props, encapsulated logic.
- Set up build via Vite in UMD format with Vue as an external dependency.
- Integrate the library into the Bitrix template using
AddHeadScript and mount at the required points.
Integration with the template:
use Bitrix\Main\Page\Asset;
$asset = Asset::getInstance();
$asset->addJs('/local/js/ui-kit/dist/ui-kit.umd.js');
$asset->addCss('/local/js/ui-kit/dist/ui-kit.css');
As the Vue.js documentation says, components are reusable instances, and a UI-kit implements this principle in practice.
Why invest in a UI-kit?
A UI-kit solves three key problems. First, development speed: a new template is assembled from ready-made components instead of being written from scratch. Second, consistency: the user sees the same buttons and forms throughout the site, which builds trust. Third, easy onboarding: a new developer gets familiar with the component library in a couple of days instead of figuring out 12 button variants. Our experience shows that after implementing a UI-kit, the time to create new functionality is reduced by 30–50%, and the number of interface-related bugs drops to near zero. The library is accompanied by documentation (at least a README, in large projects — Storybook) and is kept up-to-date. Thanks to component reuse, the cost of developing a new functional block is halved.
Case: UI-kit for a large online store from our practice
Client — a home appliance retailer with a catalog of 25,000 SKUs. Team: 4 frontend developers. Problem: over time, the site was developed by different teams, CSS accumulated 8 button variants, 3 modal implementations (jQuery, Bootstrap, custom), and 2 notification variants.
First stage — audit: collected all unique UI elements from the entire site. Got 47 element types that needed unification. Second stage — design: together with the designer, we fixed the design system (tokens, 24 components, their variants and states). Third stage — development: wrote the library in Vue 3 with Composition API, included UiButton, UiInput, UiModal, UiToast, UiPagination, UiDropdown, UiLoader, and others. Fourth stage — migration: replaced old implementations with kit components, starting with new templates and the messiest old ones.
Result: development speed doubled, design review time shrank from 2 hours to 30 minutes, all new features immediately fit into a unified design system. Implementation time — 6 weeks. Vue.js components are developed 2 times faster than jQuery analogs — the speed difference is especially noticeable on complex custom elements.
How we work: process and timeline
| Stage |
Duration |
Result |
| UI audit |
1 week |
Inventory of elements, report |
| Designing |
1–2 weeks |
Design tokens, component specification |
| Development |
2–4 weeks |
Component library, build |
| Documentation |
1 week |
Storybook / README, examples |
| Testing & migration |
1–2 weeks |
Replace old implementations, regression |
| Support |
Ongoing |
Library evolution, fixes |
Full cycle for a basic UI-kit (15–20 components) — 6–10 weeks. For a large project with 30–50 components and Storybook — 8–14 weeks.
Guarantees and experience
We have been developing on 1C-Bitrix and Vue.js for over 10 years. Certified specialists, dozens of successful UI-kit implementations for retail, services, and corporate portals. We provide a 6-month warranty on components. Order a UI-kit development for your project — get a consultation on timeline and cost. Contact us for an assessment of your project — we will prepare a proposal for a turnkey UI-kit.
Useful resource: Vue.js.
Why does UX/UI for Bitrix require a special approach?
The first thing we do upon receiving a layout from a "pure" designer is check how it fits bitrix:catalog.section and bitrix:catalog.element. In half the cases, a non-standard filter means rewriting bitrix:catalog.smart.filter from scratch — not 2 hours, but a week. That's why we design the interface directly for Bitrix's component architecture, not adapt afterward.
Redesign on Bitrix often hits the same issue: data comes from 1C via CommerceML, but the designer doesn't account for it. We incorporate the real infoblock structure — properties, price types (BASE, RETAIL), warehouse balances — into layouts. This way, the product card doesn't break when 15 characteristics and 4 prices appear. This reduces approval iterations by 30% and saves the client budget significantly — typical savings range from $5,000 to $12,000 compared to a redesign that requires later rework.
Here's what we consider at the design stage:
- Component grid — the interface is built from real Bitrix components:
bitrix:catalog, sale.basket.basket, sale.order.ajax, system.auth.form. The designer knows what data each component outputs and what parameters it accepts. This avoids refinements during layout.
- Visual editor — content managers edit content through the admin panel. Block structure, flexible sections, manageable banners — all thought out before Figma.
- Data from 1C — products, price types, and balances come via CommerceML. The product card accounts for real data volume: 15 characteristics, 4 price types, balances across 3 warehouses — not the ideal three lines from the layout.
- Semantic markup — H1–H6 hierarchy, Product/Offer microdata, alt texts. Incorporated at the design stage because "fixing SEO later" means redoing templates.
| Problem |
Consequences |
Our solution |
| Unaccounted infoblock properties |
Product card breaks when loading 15 characteristics |
Design template with automatic property grouping |
| No mobile version |
Loss of 60% mobile traffic |
Mobile-first with responsive grid |
Custom filter without smart.filter support |
Rewriting the component in 2 weeks |
Include bitrix:catalog.smart.filter in prototype |
How does a clickable prototype prevent development waste?
Before opening Figma — we dig into data. We create personas and scenarios based on Yandex.Metrica (Webvisor, heatmaps), GA4, and user interviews. Not abstract "male 25-45", but specific: "a purchaser who places an order by article numbers from Excel in 10 minutes." This allows more accurate prototyping.
During redesigns, we conduct a UX audit of the current site: conversion funnels, session recordings, drop-off points. On one project, we found that 40% of users abandoned the cart at the delivery selection step — because sale.order.ajax rendered 12 delivery services without grouping. We redesigned it, and conversion increased by 18% (resulting in additional monthly revenue of $15,000–$25,000). Competitive analysis is structural: catalog navigation, number of steps to checkout, filter performance on mobile. Contact us for a UX audit to identify your site's drop-off points.
Prototypes test logic before spending budget on visuals:
- Wireframes — schematics of key pages: home, catalog (
catalog.section), product card (catalog.element), cart (sale.basket.basket), checkout (sale.order.ajax), personal account. Information is prioritised.
- Clickable prototypes — Figma with transitions, modals, filter functionality. The client "touches" the site before development starts, catching navigation issues 4x cheaper than fixing coded templates.
- User tests — moderated sessions with target audience representatives. Cheaper to catch navigation issues here than after coding 40 component templates.
Step-by-step UX/UI design process for Bitrix
-
Design analytics — collect data from Metrica, interviews, audit current interface. Identify drop-off points (if conversion drops at delivery selection, we see it in the funnel).
-
Prototyping — wireframes + clickable prototype. Test scenarios: product search, add to cart, checkout. Iterate until approval.
-
Design system creation — typography, colors, UI components, modular grid. All tied to Bitrix component model.
-
Key page design — mockups for all breakpoints (320–2560px). Account for real data: infoblock properties, price types, balances.
-
Handoff to development — Figma with Dev Mode, export SVG/WebP/AVIF, component documentation. Help developers adapt templates to new design.
How does the design system accelerate Bitrix development?
For each project, we build a scalable system — a shared vocabulary for designers and frontend developers.
- Typography — font pairs optimised for Cyrillic and web rendering. Size scale, line height, heading hierarchy.
- Colors — primary, accent, states (hover, active, disabled, error). Contrast at least WCAG 2.1 AA minimum.
- Modular grid — fixed spacing, consistency from 320px to 2560px.
- UI components — buttons, forms, cards, tables, notifications, icons. Each with state variations and responsive versions.
- Documentation — usage rules so new designers don't "invent" styles. Without it, after six months the project has 4 shades of gray and 3 variants of the "Buy" button.
Result: interface development is 2–3 times faster because the developer gets ready-made classes and spacing instead of guessing from the layout. On one project, after implementing the design system, the time to code a new catalog page dropped from 5 days to 1.5. Get a turnkey design: from wireframes to developer handoff.
Why mobile-first?
We design the mobile version first, then expand. Touch-friendly — minimum 44x44px for interactive elements, sufficient spacing. Swipe for gallery, pull-to-refresh for catalog. Forms use inputmode="numeric" for phone, type="email" for email, input masks via IMask, autocomplete via DaData. Responsive images via <picture> and srcset — art direction for banners: on mobile we don't shrink, we show a different crop. This approach captures 60% of mobile traffic that would otherwise be lost.
How we work in Figma?
- File structure — pages: research, wireframes, UI kit, mockups by breakpoints, animations.
- Auto Layout — components on Flexbox logic, correctly stretch when content changes. The developer sees the same model as in CSS.
- Variables and Variants — variables for colors and spacing, components with state variants. Theme switching — toggle one collection.
- Dev Mode — precise values, export SVG/WebP/AVIF, CSS inspection. No pixel guessing.
What's included in the deliverables?
You receive:
- Figma file with design system and mockups of all pages (including mobile and tablet versions)
- Interactive prototype for approval and testing
- Component documentation (styles, spacing, behaviors)
- Access to files and final exports in SVG/WebP/AVIF
- Recommendations for adapting Bitrix templates to the new design
- Post-release support (up to 2 weeks) — help developers understand the layouts
We are certified 1C-Bitrix partners with 15+ years of experience. We guarantee the design will be implementable on your platform version. We have worked with over 50 online stores and corporate portals — from landing pages to marketplaces.
Usability testing and conversion optimization
How do we measure design effectiveness?
- Moderated tests — real users perform tasks: find a product, add to cart, checkout. We record where they stumble.
- A/B tests — two variants on live traffic. Conversion wins, not the art director's opinion.
- Heuristic audit — Nielsen Norman Group principles: visibility of status, match with expectations, consistency, error prevention.
- Accessibility — contrast, keyboard navigation, alt texts, aria labels. Not optional, but a requirement.
Detailed case study: delivery redesign
On one project, 40% of users abandoned the cart at the delivery selection step — because `sale.order.ajax` rendered 12 delivery services without grouping. We redesigned the interface: grouped by tariffs, added delivery time hints. Conversion increased by 18%, and average order value by 12% — translating to an additional $20,000 in monthly revenue.
Order a usability test for your current interface to boost conversion.
Conversion-focused design
- Visual hierarchy — CTAs, prices, promotions highlighted through size, color, contrast. The eye goes where the business needs — verified via eye-tracking or heatmaps.
- Minimal friction — reduce steps to target action. On one project, we removed mandatory registration at checkout — conversion to order increased by 18%.
- Social proof — ratings, reviews, cases, partner logos. Integrated into the design, not tacked at the bottom.
- Micro-animations — product flies into cart, form confirms submission. Direct attention and reduce anxiety.
A site designed with our system typically loads 2x faster than one retrofitted with standard Bitrix templates after optimization, and conversion rates improve by 1.5x–3x depending on the vertical.
Timeline and results
| Project type |
Design timeline |
Result |
| Landing page |
3–5 days |
Mockups + UI kit |
| Corporate site |
2–4 weeks |
Design system + mockups for 10–20 pages |
| Online store |
3–5 weeks |
Design system + mockups for 20–40 pages |
| Portal / marketplace |
4–8 weeks |
Design system + mockups for 30–60 pages |
How to get started?
We evaluate your project within 1 business day. Contact us for a free consultation and project evaluation. Order a full-cycle UX/UI design for your Bitrix site — from research to final mockups. Call us to start your project today.