The most expensive scenario in web development is when the design is already coded, the Bitrix components are connected, and suddenly it turns out that the catalog does not support three-level nesting, the filter works with only one information block, and the cart does not handle multiple units of measurement.
Fixes are expensive, and deadlines slip. We have solved this problem for dozens of clients: prototyping before design identifies risks in advance and saves budget and time. The average savings across projects are significant, and our cases confirm this.
A prototype for 1C-Bitrix differs from a regular UI prototype: it takes into account the specifics of the platform — which scenarios are implemented by standard components (bitrix:catalog, bitrix:breadcrumb) and which require custom development.
Without a prototype, the team spends 30% more time on approval, and rework at the coding stage costs 2–3 times more. Prototyping before design reduces rework costs by 3 times compared to the traditional approach.
Why an interface prototype for 1C-Bitrix?
A typical mistake is to plan for the standard smart filter without checking dependencies between parameters.
In one of our cases (an online store for industrial filters), the client planned bitrix:catalog.smart.filter, but after prototyping it became clear that a dependent selection was needed — the filter type narrows the standard-size values. The standard component cannot do this.
The prototype helped make the decision: either worse UX, or a Vue.js component on top of the Bitrix API. The client consciously chose the second option and saved 2 weeks of rework.
Typical mistakes without a prototype
| Mistake | Consequences | How to prevent |
|---|---|---|
| Catalog section nesting not taken into account | Deadline missed, custom development | Check the infoblock hierarchy on the prototype |
| Filter does not support dependent parameters | Additional 3–5 days of development | Define dependency logic on the prototype |
| Cart does not handle multiple units of measurement | Rework 2–4 days | Prototype the scenario "one product — different units of measurement" |
Example from practice: dependent filter
In an online store project for filters, we identified on the prototype that the standard bitrix:catalog.smart.filter does not support dependent parameters. The solution was to develop a custom Vue.js component with requests to the Bitrix API. This added 5 days to the estimate, but saved 2 weeks at the layout stage.
How does a prototype help avoid rework?
Bitrix is a platform with strong architectural constraints. The complex component bitrix:catalog implements a catalog in a strictly defined way: section hierarchy → element list → detail page.
It is possible to deviate from this logic, but that is custom development with the corresponding cost.
The prototype fixes which interface patterns are implemented by standard Bitrix components and which require custom development. This affects the estimate and timeline. According to our data, prototyping improves estimate accuracy by 25%.
The second aspect is CMS-dependent interface areas. Breadcrumbs are generated by bitrix:breadcrumb. Pagination — bitrix:main.pagenavigation. Feedback form — bitrix:main.feedback or bitrix:form.result.new.
The prototype reflects where these components live in the layout, what data they display, and what their states look like. This saves up to 40% of layout time, since the designer does not draw unrealizable elements.
Why should a prototype be made before design?
A prototype for a standard e-commerce store on Bitrix (7–10 page types, mobile version) takes 10–18 business days. Complex projects with non-standard scenarios (product selector, configurator, personal account with advanced features) take 20–35 days.
We are a company with over 5 years of experience and 50+ projects on Bitrix. Order a prototype — and get a transparent estimate and the guarantee that the design will not contradict the platform architecture.
Contact us for a preliminary assessment of your project — we will analyze the scenarios and suggest the optimal level of detail.
According to IBM research, prototyping reduces the number of changes at the development stage by 30%. Read more about prototyping in dedicated UX resources.
Prototype Detail Levels
| Type | Purpose | When to use |
|---|---|---|
| Wireframe | Schematic arrangement of blocks, page structure, component markup | For any projects — a basis for discussion |
| Interactive prototype | Clickable transitions, simulated states (empty cart, form errors) | Complex scenarios, UX approval with the client |
| Functional prototype (HTML) | Real data from Bitrix, verification of component integration | Projects with non-standard logic (configurators, selectors) |
Prototype development process
- Scenario analysis. For each page type, we define user scenarios. Homepage — 2–3 scenarios, catalog — 5–8: browsing sections, filtering, search, adding to cart, comparison.
- Template inventory. Typical Bitrix set: homepage, catalog section, product detail page, search results, cart, checkout, static page, personal account.
- Component markup. On the wireframe, we directly indicate which Bitrix component provides a given block and what parameters it needs.
- Interface states. Empty state, loading, error, success — for each interactive element.
- Mobile version. A separate prototype for mobile breakpoints: filter (slide-out panel or page?), catalog navigation, checkout form.
What is included in the work
- Wireframes and/or an interactive prototype in Figma
- Component markup with Bitrix parameters specified
- Scenarios for all interface states
- Mobile version
- Annotations for the designer and developer
- Training the client's team to work with the prototype (1 hour)
Get a consultation
Want a transparent estimate without hidden risks? Contact us for a preliminary assessment of your project. We will analyze the scenarios and suggest the optimal level of prototype detail.