Building BDA's eAuction Experience

In early January, VK and I were added to a WhatsApp group connected to the Bangalore Development Authority (BDA). On January 4, an eAuction poster was shared in it. We pointed out that it was information-dense with no visual hierarchy, hard to scan and difficult to understand. That led to a simple question and a string of efforts on how this information could be made clearer and transparent for citizens.

At Zen Citizen, we often encounter this problem. Public data exists, but it is usually fragmented, dense, and difficult to navigate. When BDA asked if we could help, we readily agreed to explore what could be done.

You can check out the platform here.

Framing the Problem

The issue was not simply one of presentation. Government data is often genuinely hard to use. For this eAuction, information was spread across multiple formats and locations:

• Notices and site lists were published as dense PDFs, important dates were mixed into long walls of text.
• Eligibility criteria, documents, and financial details lived in different places.
• Site information was available in a document, separate from location coordinates.
• Understanding the full process and which site was where required manual cross-referencing between different sources.

While all the required information existed, it was fragmented and not designed to be consumed together. For a citizen, this means additional effort just to build a basic understanding of the auction before even deciding whether to participate.

Our goal was to bring this information together in a way that reduced that effort, without altering the underlying data or diluting legal enforceability.

Collaboration and Process

This work was completed in about twenty days from the first conversation. During this time, we:

• Familiarised ourselves with the auction process and terminology.
• Sought clarity on what information was mandatory versus contextual.
• Coordinated with multiple teams to gather data and documentation.
• Iterated while working with delayed or partial inputs.

Everyone involved in the process recognised the intent behind the work and were open to collaboration. That openness enabled steady progress despite constraints.

Design Goals

We aligned early on a few core objectives:

• Make information easy to scan. Key dates, steps, and requirements should be visible upfront.
• Consolidate information. One place that explains both the auction process and lets user explore available sites.
• Reduce friction. Clear communication can reduce invalid bids, follow-up calls, and grievances.
• Reflect a more transparent, citizen-centric tone. Communication should feel deliberate and respectful of the user.

Working with Government Data

A significant part of the work involved understanding and reconciling data. Some of the challenges included:

• Missing or inconsistent geographic information.
• Differences in numerical values across documents.
• Boundary data available in varying formats but not meant for web use.
• Some information were even distributed across multiple teams and vendors.

Structuring the Information

One of the first decisions was to separate different types of information instead of compressing everything into a single flow. We structured the platform in such a way that:

• Key dates and sections are clearly listed and visually distinct.
• Process and auction related details are separated from Terms and Conditions.
• Legal text is preserved but moved out of the primary scanning path.

Making Sites Explorable Through the Map

A major intervention was introducing a map-based interface to explore auction sites. Instead of having users interpret site numbers and layout names abstractly, the platform allows them to:

• See sites laid out on a map.
• Switch between street and satellite views to better understand access roads, surrounding development, and the physical context of each site.
• Search and filter sites by layout, size, and auction rounds.
• View detailed individual site cards with more information on location, dimensions and pricing.

We also surfaced details that were either missing or difficult to infer earlier, such as:

• Corner vs intermediate sites
• Regular vs odd dimensions
• Site type, directions and area

From a UX perspective, the map helps users build spatial understanding and reduces the effort needed to compare sites.

Design and Technical Considerations

Even though the platform looks straightforward, making it feel simple took a lot of deliberate choices. From an implementation perspective, the focus was on simplicity and robustness. The platform is built as a React app and intentionally kept lightweight: no backend, no complicated services.

Map implementation (street, satellite, and boundaries)

The map is the core of the experience, so I focused on a few things:

• Two base layers: a street map for navigation context and a satellite layer for on-ground context so people can check access roads, nearby development, and the surroundings before shortlisting a site.
• Validation for missing data: The platform is designed to handle gaps gracefully. Sites without usable coordinates still appear in lists, and the interface avoids implying accuracy where it cannot be guaranteed. This was important from a transparency standpoint. Clear communication also means being clear about limitations.
• Boundaries where available: site boundary data came in varying formats and zipped files, which weren’t inherently web-friendly. I parsed this data as GeoJSON and rendered it as an overlay so the map can show boundary outlines to communicate extent or shape.

Styling and layout:

I used Tailwind for the basics (spacing, typography, common components), but didn’t try to force everything into utility classes. For the parts that are genuinely layout-heavy — especially the mobile map experience — custom CSS is used per page/component.

The mobile map UX was mostly CSS. On desktop, showing a list and a map side-by-side is pretty straightforward. however, on mobile, it’s not because you’re always trading off between “I want to see a list of sites” and “I want to see it on a map.”

On mobile, the map and the site list share the same vertical space. Instead of hiding one behind tabs, I implemented a three-state layout: a default split view, a map-expanded view, and a map-collapsed view. Users can move between these states using a drag handle placed between the list and the map, which allows them to shift focus without losing context.

This is mostly done with CSS grid transitions to resize the map container smoothly. However, interactive maps are sensitive to container size changes. When the map resizes, it needs to recalculate its dimensions; otherwise, tiles and markers can render incorrectly.

To make this work reliably, the map’s behaviour is tied closely to the layout changes. When the layout is expanding or collapsing, map animations such as automatic recentering are paused, so the map does not try to animate while its container is changing size. Once the layout transition completes, the map dimensions are recalculated, and normal interactions resume. This prevents visual glitches and ensures that clicking a site — either from the list or directly on the map results in a stable, predictable behaviour.

The code is fully open source.

Why We Took This On

At Zen Citizen, we see communication as part of public infrastructure. When information is unclear, citizens bear the cost — in time, effort, and anxiety.

This project aligned with our broader intent: to demonstrate how thoughtful design and basic technology choices can improve access to public systems without dramatically shifting the underlying rules.

Last-mile impact

This project also reinforced the difference between offering guidance and enabling outcomes. In many public systems, advice and recommendations exist, but the last mile — where information is actually interpreted and used by citizens — often remains unaddressed. Organisations like Zen Citizen operate in that space: translating intent into usable tools and services, and ensuring that guidance is not simply suggested but implemented. Improving public systems requires sustained attention to how people actually encounter and navigate those systems. They do not need to be reinvented.

Clear structure, thoughtful design, and above all, empathy and respect for the user can go a long way in making complex processes more accessible.

What’s Next

Some possible next steps include:

• Hosting the platform directly on the BDA website.
• Extending it into a central reference for all future auctions.
• Improving map layers with clearer layout and division boundaries.
• Exploring assisted guidance or helper features.
• Studying impact such as participation quality and reduction in grievances.