Building a Shared Contact System for Cian

Summary

What appeared to be a small contact block was actually a fragmented system maintained by several teams. I initiated and led a design-system pilot that consolidated these legacy implementations into one controllable and scalable contact system.

The system included three Contact Card variants named after their placement in the product: Snippet, Sidebar, and Inline. They used the same content model and interaction patterns while adapting their composition to different contexts and screen sizes.

The web components were released to production. I also prepared mobile app adaptations, but their later implementation status is unknown.

My role: I initiated the project, mapped ownership across teams, gathered requirements, facilitated the working group, and designed and documented the system through its web release.

Cross-team initiative · Working group: 3 → 15 people · Web production release · 3 Contact Card variants

Scale and constraints

• Around 4–5 different snippet implementations and approximately 2 sidebar variants had accumulated across the product.
• The working group grew from 3 to 15 participants across product, design, and engineering.
• The web system had to work across several responsive contexts.
• Monetization requirements were introduced while the system was already being designed.
• Existing differences reflected a mixture of valid business rules and almost 20 years of legacy.

Finding the system inside the interface

I collected contact-information patterns from across the product in a separate Figma file and grouped their differences by placement, content, behavior, and seller type.

The project was deliberately used as a design-system pilot. Its purpose was not only to redesign a small interface element, but also to demonstrate how much hidden complexity could exist inside a seemingly simple piece of contact information.

Defining the content model

Rather than standardizing the existing layouts directly, I first identified the information shared by their different implementations. Together with product owners, we separated active business requirements from legacy behavior.

3 primary placements · Listing snippet, property-page sidebar, and inline content
6 seller categories · Owner, realtor, real estate agency, developer, management company, and official representative
6 shared content groups · Identity, role, verification, loyalty, additional details, and actions

Three variants, one content model

The content model was assembled from smaller reusable components. This allowed the system to keep the same information and behavior while changing its composition for different contexts.

I initially explored one fully adaptive component. As the number of valid combinations grew, I split it into three placement-based variants built on the same underlying model.

Instead of separating larger “cards” from smaller “bars”, I named all variants by their placement:

• Snippet Contact Card — compact contact information inside a property-listing snippet.
• Sidebar Contact Card — a persistent contact area in the property-page sidebar.
• Inline Contact Card — an expanded contact block inside the main content flow.

Individual elements can appear or disappear depending on the context and available data, but every variant uses the same underlying model.

Making seller roles clear

Users could not always tell whether a listing represented an owner, realtor, real estate agency, developer, management company, or official representative.

I introduced an overline label to make the seller role immediately visible without competing with the seller name. Avatar shapes and role-specific placeholder icons reinforced the distinction.

Round avatars represent personal accounts. Square avatars represent organizations. The placeholder icon changes depending on the account type.

Snippet Contact Card

This compact variant appears inside property-listing snippets. It keeps seller identity and primary actions clear without competing with the property preview, replacing around 4–5 different legacy implementations.

Sidebar Contact Card

This variant remains visible while the user explores the property page. It supports more seller information and actions than the Snippet variant.

I used a contact section from an existing real estate agent page that I had previously designed as a starting point. The pattern was revised to fit the shared content model and replace approximately two legacy sidebar versions.

Inline Contact Card

This variant appears inside the main content flow, where there is more space for seller information and stronger visual emphasis.

Supporting monetization

During the project, the monetization team introduced profile tiers internally referred to as Bronze, Silver, and VIP. The same tier model applied across all three Contact Card variants rather than creating separate component families.

• Bronze showed the seller role and name.
• Silver added trust-building metadata such as experience, founding date, time on Cian, and the number of active listings.
• VIP retained the same information and added contact actions.
• Only VIP received distinct visual treatment through a colored background behind the avatar and a centered composition.

The metadata area initially contained two or three fields but was structured to support additional trust-building information later.

Early concepts relied mainly on decorative differences between tiers. I proposed using information depth as the primary value differentiator and reserving strong visual treatment for VIP.

Responsive behavior

The information hierarchy and interaction patterns remained consistent across web breakpoints, while the composition adapted to the available space.

Collaboration and rollout

I started the project with a small group that helped research the problem and discuss the initial idea. As the hidden scope became clearer, we invited potential product owners, other feature owners, the monetization team, and developers.

This is how the working group grew from 3 to 15 participants. The hardest part was not designing the cards, but finding ownership, aligning changing requirements, and keeping the system coherent as the group expanded.

The first implementation was led by the team responsible for the vertical serving realtors and real estate agencies. This team also introduced the monetization requirements.

I documented the anatomy, content rules, variant matrix, responsive behavior, platform differences, and usage examples before the web system was released. I then presented the pilot internally as an example of how design-system work could expose and reduce hidden product complexity.

Before and after

The new Snippet Contact Card replaced several disconnected implementations with one shared structure.

The Sidebar Contact Card brought the same model into the property page while preserving the needs of that placement.

expand_moreAdditional component variants and design stages

Snippet configurations

Snippet design evolution

Existing agent-page pattern used as a starting point

Sidebar configurations

Sidebar design evolution

Compact layout evolution

This compact variant was initially called Contact Bar. It was later treated as another Contact Card placement rather than a separate component type.

One shared contact system

• 4–5 snippet implementations and approximately 2 sidebar variants → one shared model
• Scattered scenarios → three controlled, context-specific variants
• Unstructured contact information → six shared content groups
• Separate monetization requirements → one extensible tier architecture

The web system was released to production. Its structure remains in use today, although individual details have evolved, including the addition of new badges.

Live examples

• Snippet Contact Cards in secondary-market listings
• Standard Sidebar Contact Card
• VIP Sidebar and Inline Contact Cards