How I Designed TerraShield's Enterprise CTA to Not Annoy Researchers

Sai Prasanna H — Sun, 12 Apr 2026 15:53:46 +0000

There's a particular kind of UI failure that doesn't show up in error logs: a button that appears on every page when it should only appear on one. Nobody throws an exception. The page renders fine. But every time a field ecologist uploads a photo and sees "Enterprise API Access" plastered across their analysis results, it breaks the context of what they're doing and makes the product feel unfinished.

I'm Sai Prasanna, and I worked on TerraShield's frontend polish the Enterprise API call-to-action placement, the home page layout, and UI consistency across the platform. This is shorter than a story about building the core ML pipeline, but it's about a class of frontend decisions that quietly determine whether a product feels professional or amateur.

What TerraShield Is

TerraShield detects invasive species from citizen-uploaded photos. A field observer uploads a geo-tagged image; we extract EXIF data, pull satellite NDVI readings for that GPS coordinate, recall nearby past sightings from an agent memory layer powered by Hindsight, and run the whole context through Gemini 2.5 Flash for classification. The result is a risk score, species tags, and an ecological summary that gets retained in memory to make the next analysis in that region smarter.

The platform serves four distinct user types: citizen scientists, field researchers and ecologists, government environmental agencies, and NGOs. Each of them has different reasons to be on TerraShield and different actions they'd want to take.

The Enterprise CTA Problem

TerraShield has an Enterprise API tier — TSK- prefixed keys that let government GIS systems and NGO data pipelines pull outbreak data programmatically. It's a real feature. It just doesn't need to be advertised to a citizen scientist who's uploading a photo of a plant they found on a hiking trail.

The original implementation rendered the Enterprise API CTA as a card component across multiple pages: the home page, the analysis results page, and the profile page. The card had a border, a background color, and enough visual weight that it competed with the actual content of every page it appeared on.

My fix was two things: scope the CTA to the home page only, and remove the visual container styling so it blends with the surrounding layout rather than announcing itself as a separate element.

// Before: rendered on every page with card styling
<div class="enterprise-card card-border card-bg">
    <h3>Enterprise API Access</h3>
    <p>Integrate TerraShield data into your systems</p>
    <button>Get API Key</button>
</div>

// After: home page only, no border/bg, seamless blend
<div class="enterprise-cta">
    <h3>Enterprise API Access</h3>
    <p>Integrate TerraShield data into your systems</p>
    <button>Get API Key</button>
</div>

The change is small. The effect on the analysis results page is significant removing the card from there means the risk score, the species identification, and the ecological summary get the full visual attention they deserve. When a researcher is looking at an 8.4/10 risk score for a confirmed Lantana camara outbreak 500m from a protected forest, they don't need a sales prompt.

Why Placement Is a Product Decision

This is something that gets treated as a designer's job but is actually an engineering judgment call: where does a feature live in the navigation hierarchy, and what does its visual weight communicate about its priority?

TerraShield's user roles matter here. The platform is free for citizens, researchers, and NGOs. Enterprise API access is for organizations that need programmatic integration government agencies pulling outbreak data into their GIS workflows, research institutions running bulk analysis. That audience finds the product through the home page, not through the analysis results flow. An ecologist mid-upload is not evaluating API pricing.

Restricting the CTA to the home page respects the context of every other page. It also makes the CTA itself more effective users who see it on the home page are in an exploratory mindset; users who are mid-task and see it are just annoyed.

The Broader Frontend Context

TerraShield's frontend is vanilla JS — no React, no Vue. The UI is built as a collection of page modules in frontend/pages/, each managing its own DOM and state. The home page (home.js) is 73KB of vanilla JS handling the map rendering (Leaflet.js), the agent memory live panel, the upload flow, and several dashboard widgets.

The agent memory live panel on the home page is one of the more interesting UI elements: it polls the /api/agent-memory endpoint and shows real-time stats — total sightings in memory, the most-detected species, and a feed of the five most recent retained memories. It makes the Hindsight-backed memory layer visible to users without them needing to understand the underlying architecture. The numbers change as reports come in. The agent is visibly learning.

The Enterprise CTA sits below this panel on the home page, which is intentional placement — users who've just watched the memory panel and understood that TerraShield accumulates ecological intelligence over time are better positioned to understand why an API integration would be valuable.

What Polishing Frontend Actually Means

"UI polish" is often used dismissively, as if it means tweaking colors. What it actually means is making a series of judgment calls about context, priority, and attention. The blinking logo animation that we removed from the Memory nav — that was a distraction from the content it was labeling. The brain emoji that was also removed — same reason. These aren't aesthetic preferences; they're decisions about what the interface is communicating.

TerraShield processes serious ecological data. When a government inspector opens the platform to assess an outbreak cluster that covers three districts, the interface needs to feel like a tool, not a demo. Every element that draws attention away from the data is a failure of that goal.

Takeaways

Scope features to the pages where they're relevant. A CTA that appears everywhere becomes invisible through repetition and annoying through interruption. One well-placed appearance on the right page outperforms five appearances on the wrong ones.

Visual weight is a signal about priority. Card containers with borders and backgrounds tell users "this is important." Use that signal intentionally. If something isn't more important than the surrounding content, strip the container.

Animations in nav elements are almost always wrong. A nav label that blinks or pulses is competing with the content the user is trying to navigate to. Nav should be quiet. Content should have the energy.

Context determines relevance. The same piece of information (Enterprise API access exists) can be welcome or intrusive depending on what the user is doing when they see it. Frontend decisions are UX decisions are product decisions. They compound.

TerraShield is at github.com/Nitish-k-s/TerraShield. The agent memory layer that powers the live panel on the home page uses Hindsight — worth looking at if you're building systems that need to accumulate and reason over field-collected data.

DEV Community: Sai Prasanna H

How I Designed TerraShield's Enterprise CTA to Not Annoy Researchers

What TerraShield Is

The Enterprise CTA Problem

Why Placement Is a Product Decision

Takeaways