UI Prototype Development for 1C-Bitrix Websites

UI Prototype Development for 1C-Bitrix Websites

One of the most expensive scenarios in web development is when the design has been composed, Bitrix components have been wired up, and then it turns out: the catalog does not account for three-level section nesting, the filter only works with a single infoblock, and the cart does not support "one product — multiple units of measure" logic. Reworking it is expensive. A prototype before the design stage is cheap.

Prototyping for 1C-Bitrix differs from standard UI prototyping: you need to understand not only the user scenario but also how a specific platform component implements that scenario.

Why Prototyping Matters Specifically for Bitrix Projects

Bitrix is a platform with strong architectural constraints. The bitrix:catalog composite component implements the catalog in a strictly defined way: section hierarchy → item list → detail page. Deviating from this logic is possible, but it constitutes custom development with a corresponding cost.

A prototype makes it possible to establish: which interface patterns are implemented by standard Bitrix components and which will require custom development. This directly affects the estimate.

The second aspect: CMS-dependent interface zones. Breadcrumbs are generated by bitrix:breadcrumb. Pagination — bitrix:main.pagenavigation. A feedback form — bitrix:main.feedback or bitrix:form.result.new. The prototype must reflect where these components live in the layout, what data they display, and what their states look like.

Levels of Prototype Fidelity

Wireframe. A schematic layout of blocks without visual design. The goal is to fix the page structure and navigation. For Bitrix projects it is important here to mark out component zones: "here will be bitrix:catalog.section with the following parameters…"

Interactive prototype. Clickable transitions between pages, simulated states (empty cart / cart with items, filter state, form errors). Tools: Figma with interactive components, Axure for complex state logic.

Functional prototype. An HTML template with real data from Bitrix but without final design. Used rarely — on complex projects where it is important to verify component interaction before design begins.

Prototype Development Process

Use-case analysis. For each page type we record user scenarios. Home page — 2–3 scenarios. Catalog — 5–8 scenarios: browsing sections, filtering, searching, adding to cart, comparing. Personal account — order history, updating details, repeat order.

Page template inventory. The typical set for Bitrix: home page, catalog section, product card, search results, cart, checkout, static page (about us, contacts), personal account. Each template is a separate prototype.

Component annotation. On the wireframe we directly indicate which Bitrix component provides the given block and what parameters it needs. This is not documentation — it is a boundary of responsibility: "here is what the platform provides out of the box, here is what needs to be customized."

Interface states. For each interactive element we prototype states: empty state (no products in section), loading (skeleton screens), error (form with validation), success. Standard Bitrix components have templates for the "no results" state — this must be accounted for in the prototype.

Mobile version. A separate set of prototypes for mobile breakpoints. Special attention: the filter on mobile (sliding panel or separate page?), catalog navigation, checkout form.

Case Study: Prototype for an Industrial Filters Online Store

Client — a manufacturer of filtration equipment. Catalog: 3,000 SKUs, complex technical specifications (pressure, temperature, material, size), parameter-based selection — the core function of the website.

Before prototyping, the team assumed: "We'll use a standard catalog with Bitrix's smart filter." After analysis it turned out: the parameter-based selection logic requires dependent filters (choosing a filter type narrows the available size values) — the standard bitrix:catalog.smart.filter does not support dependent filters out of the box.

The prototype established two options:

1. Standard filter without dependencies — cheaper, but worse UX.
2. Custom parameter-selection component in Vue.js on top of the Bitrix API — more expensive, but solves the problem.

The client chose the second option — and did so consciously, because they saw the difference in the prototype before design started, not after project delivery.

The prototype also revealed: the "Certificates and Documentation" page requires a dedicated infoblock with file types and product filtering — this is not covered by standard document components.

Tools and Formats

Figma is the standard for wireframes and interactive prototypes. It supports collaboration, commenting, and versioning. The result is handed to the designer as the foundation for visual design.

For documenting the component composition of pages — a table or a dedicated annotation layer in Figma: component → parameters → customization.

Timeline

Prototype for a standard Bitrix online store (7–10 page types, mobile version) — 10–18 business days. Complex projects with non-standard scenarios (configurator, comparison tool, personal account with extended functionality) — 20–35 days.