Taara Link Planner

Taara Link Planner

Taara Link Planner

Company

Taara

Responsibilities

UX strategy, Product decision-making, UX/UI design, Cross-functional leadership

Leads

Heather Cooper: Design & Product

Garth Brydon: Engineering

William Bergstroem: Product

Timeline

4 Months

Company

Taara

Responsibilities

UX strategy, Product decision-making, UX/UI design, Cross-functional leadership

Timeline

4 Months

Team

Heather Cooper: Design & Product, Garth Brydon: Engineering and Product, William Bergstroem: Product

Context

Context

Context

Taara, a Google moonshot organization, builds free-space optical communication links that beam internet connectivity using light. When traditional fiber can't reach, for example across rivers, through dense cities, or remote areas, Taara's Lightbridge closes the gap, But, before deploying, operators need to know if a link will actually work. It needs clear line of sight and high reliability, which is dependent on visibility. Taara Link Planner is the web-based tool to answer the question, using historical weather data, terrain analysis, and line-of-sight modeling to predict availability before anyone climbs a tower.

Discovery

Discovery

Discovery

Early discovery included:


• Researching wireless optical communication, how light-based connectivity is different from RF.


• Time with modeling team to better understand how they generate predictions.


• Interviewing network engineers and planners to understand how they assess link feasibility and link budgets.


• Conducting site visits with field installers to observe physical site surveys and deployments.

Core Challenges

No Existing Playbook in the Market

Making Complex Data Trustworthy

Weather Data

Gaps

Core Challenges

No Existing Playbook in the Market

Complex Data

Weather Data Gaps

Wireless optical communication is a newer technology. Network engineers' mental model aligned to RF planning. So, the tool needed to also help users understand a whole new way to plan. Not only did we need to meet their needs, we had to help them understand what it is they need.

Availability predictions include a lot of data, which is complex. One challenge up front was how to clearly share this data in a way that was digestible.

Availability for wireless optical communication depends on visibility, which is directly tied to weather. However, historical weather data is not readily available for all parts of the world.

High-stakes

High-stakes

High-stakes

Telecommunications providers operate under strict service-level agreements that define the availability they must deliver to customers. Even brief periods of downtime can result in financial penalties, service disruptions, and loss of customer trust. Network planners are responsible for designing networks that meet availability targets, often 99.99% or higher, while balancing cost, geography, weather conditions, and infrastructure constraints. A poor planning decision can impact network reliability and ultimately put both customer commitments and business relationships at risk.

Problem Statement

Problem Statement

Problem Statement

Network engineers and planners need a way to evaluate the feasibility and predicted performance of free-space optical links before deployment, so that they can make confident infrastructure decisions and build networks that reliably deliver connectiity.

Users

Users

Users

Network engineers/planners emerged as the primary user early in discovery. These are the people evaluating whether a link will work, and if it supports their network, before anything gets deployed. They will run feasibility checks, compare candidate locations, and build a case for their stakeholders. They're technical and risk-adverse.

Information Architecture

Information Architecture

Information Architecture

We identified the primary workflow involved the network map, where users could place links, open a details container and review line of sight and availability predictions. to provide a progressive disclosure experience, drilling into building and terrain or availability analysis would provide additional data and opportunities to evaluate data details. Users also expressed the need for bulk analysis, a way to upload as many as 10,000 links at once and have the tool assess for clear line of sight and availability. Learning how engineers plan their links and organize projects, we understood the need for links management.

From Model to Interface

From Model to Interface

Taara's availability predictions are powered by a weather-dependent model, rain, fog wind and turbulence all affect whether a free-space optical link will perform. The model relies on historical weather data from weather stations nearby the link. But, station proximity, sensor quality, and data completeness vary by region. When no station is close enough, the model finds a "twin" as a proxy.

These constraints shaped the design work, and made it both challenging and interesting. Users need to decide whether a location is a good candidate for a link. Bad performance means risking their position, as well as the company's. The model creates predictions, based much on weather. Accuracy is crucial, but weather is still unreliable. The tool needs to build trust and set expectations.

User Interviews

User Interviews

Spending time with users helped us understand the complexities and nuances of the work. Nothing was binary, good or bad, rather it was about design and tradeoffs.

Low-fidelity

High-fidelity

While exploring low-fidelity and mid-fidelity designs, some of the core design principles included the following: align to current map mental models, progressive disclosure, flexibility in input, and reinforcing the connection between availability and weather

To create a high-fidelity prototype that could be tested with users, every interaction had to be fully built out, from placing terminals in the map to drilling into availability analysis, weather data, and building obstructions. Figma has limitations in fully complex interactions. I needed to rely on Claude Code to create a fully functioning prototype that could be flexible for usability testing.

Low-fidelity

While exploring low-fidelity and mid-fidelity designs, some of the core design principles I was aiming for included the following: align to current map mental models, progressive disclosure, flexibility in input, and reinforcing the connection between availability and weather

Product Management

Up until the General Access release of Taara Link Planner, there was no dedicated Product Manager. I shared the responsibilities with the lead engineer on the project, owning feature prioritization, requirements definition, stakeholder alignment, and roadmap planning. This experience allowed me the opportunity for larger sense of ownership and direction, beyond product design.

High-fidelity

To create a high-fidelity prototype that could be tested with users, every interaction had to be fully built out, from placing terminals in the map to drilling into availability analysis, weather data, and building obstructions. Figma has limitations in fully complex interactions. I needed to rely on Claude Code to create a fully functioning prototype that could be flexible for usability testing.

Usability Testing

Usability Testing

Once the prototype was complete, we launched usability testing. Results were positive with most users finding the platform intuitive and user-friendly. Learnings included the need for additional context, especially with the use of tool tips, to help guide decision making.

Weather Twin & UAT

Weather Twin & UAT

The most challenging problem for Taara Link Planner is how to solve the experience for when the tool does not have accurate weather data for the location of the link. It happens fairly frequently outside the US, and Taara has customers all over the globe. When there is not a vetted weather station, or the station is more than 200km from the link location, the model selects a weather twin. Using an LLM, the tool finds a city with identical climate and creates an availability prediction based on this twin location.

The weather twin feature created internal debates with stakeholders. Fears of customers being confused, not understanding the weather twin experience, or not trusted it became a blocker for the GA release.

To help the stakeholders gain trust in the design and in the tool, we engaged in extensive UAT with network engineers and planners. Fortunately, UAT was successful. On the scale of 1-5 for how likely are you to use this tool to design your network, 1 being not likely and 5 being extremely likely, the average score was a 4.9. The stakeholders gained confidence in the tool and GA happened on time,

Transparency Debate

Transparency Debate

Internal stakeholders wanted to keep weather twin invisible , let the model do its work under the hood and just show the user a prediction. We pushed back. User interviews were clear: planners wanted to see where the data came from so they could make informed decisions. They needed the ability to disagree with the tool.

If a planner in São Paulo sees their prediction is based on weather data from El Paso, Texas, they should be able to question that. Hiding it would mean asking users to trust a number they couldn't interrogate , the opposite of what a decision-making tool should do.

A/B Test at Launch

We ran a feature flag test with two experiences:

  • Group A saw the full weather twin experience, the matched city name, the underlying data, and a comparison with the reference city near their link. This is the version users preferred.

  • Group B saw weather twin as a generic label with no city name or comparison data

Internal stakeholders wanted to keep weather twin invisible , let the model do its work under the hood and just show the user a prediction. We pushed back. User interviews were clear: planners wanted to see where the data came from so they could make informed decisions. They needed the ability to disagree with the tool.

If a planner in São Paulo sees their prediction is based on weather data from El Paso, Texas, they should be able to question that. Hiding it would mean asking users to trust a number they couldn't interrogate , the opposite of what a decision-making tool should do.

A/B Test at Launch

We ran a feature flag test with two experiences:

  • Group A saw the full weather twin experience, the matched city name, the underlying data, and a comparison with the reference city near their link. This is the version users preferred.

  • Group B saw weather twin as a generic label with no city name or comparison data

Hemisphere Problem

Hemisphere Problem

An early version of the model returned weather twins exclusively from US cities because US weather stations had the most reliable historical data. This created a critical issue: availability predictions are shown monthly, and seasons are inverted across hemispheres. A link in the southern hemisphere matched to a US city would show high availability in January (US summer conditions) when it should have been showing winter.

The modeling team updated the algorithm to match weather twins within the same hemisphere as the link location.

An early version of the model returned weather twins exclusively from US cities because US weather stations had the most reliable historical data. This created a critical issue: availability predictions are shown monthly, and seasons are inverted across hemispheres. A link in the southern hemisphere matched to a US city would show high availability in January (US summer conditions) when it should have been showing winter.

The modeling team updated the algorithm to match weather twins within the same hemisphere as the link location.

Company

Taara

Responsibilities

UX strategy, Product decision-making, UX/UI design, Cross-functional leadership

Leads

Heather Cooper: Design & Product, Garth Brydon: Engineering, William Bergstroem: Product

Timeline

4 Months

No Existing Playbook in the Market

Complex Data

Weather Data Gaps

Core Challenges

Wireless optical communication is a newer technology. Network engineers' mental model aligned to RF planning. So, the tool needed to also help users understand a whole new way to plan. Not only did we need to meet their needs, we had to help them understand what it is they need.

Availability predictions include a lot of data, which is complex. One challenge up front was how to clearly share this data in a way that was digestible.

Availability for wireless optical communication depends on visibility, which is directly tied to weather. However, historical weather data is not readily available for all parts of the world.

From Model to Interface

Taara's availability predictions are powered by a weather-dependent model, rain, fog wind and turbulence all affect whether a free-space optical link will perform. The model relies on historical weather data from weather stations nearby the link. But, station proximity, sensor quality, and data completeness vary by region. When no station is close enough, the model finds a "twin" as a proxy.

These constraints shaped the design work, and made it both challenging and interesting. Users need to decide whether a location is a good candidate for a link. Bad performance means risking their position, as well as the company's. The model creates predictions, based much on weather. Accuracy is crucial, but weather is still unreliable. The tool needs to build trust and set expectations.

Product Management

Up until the General Access release of Taara Link Planner, there was no dedicated Product Manager. I shared the responsibilities with the lead engineer on the project, owning feature prioritization, requirements definition, stakeholder alignment, and roadmap planning.

High-fidelity

To create a high-fidelity prototype that could be tested with users, every interaction had to be fully built out, from placing terminals in the map to drilling into availability analysis, weather data, and building obstructions. Figma has limitations in fully complex interactions. I needed to rely on Claude Code to create a fully functioning prototype that could be flexible for usability testing.

Weather Twin & UAT

The most challenging problem for Taara Link Planner is how to solve the experience for when the tool does not have accurate weather data for the location of the link. It happens fairly frequently outside the US, and Taara has customers all over the globe. When there is not a vetted weather station, or the station is more than 200km from the link location, the model selects a weather twin. Using an LLM, the tool finds a city with identical climate and creates an availability prediction based on this twin location.

The weather twin feature created internal debates with stakeholders. Fears of customers being confused, not understanding the weather twin experience, or not trusted it became a blocker for the GA release.

To help the stakeholders gain trust in the design and in the tool, we engaged in extensive UAT with network engineers and planners. Fortunately, UAT was successful. On the scale of 1-5 for how likely are you to use this tool to design your network, 1 being not likely and 5 being extremely likely, the average score was a 4.9. The stakeholders gained confidence in the tool and GA happened on time,

Weather Twin & UAT

Weather Twin & UAT

The most challenging problem for Taara Link Planner is how to solve the experience for when the tool does not have accurate weather data for the location of the link. It happens fairly frequently outside the US, and Taara has customers all over the globe. When there is not a vetted weather station, or the station is more than 200km from the link location, the model selects a weather twin. Using an LLM, the tool finds a city with identical climate and creates an availability prediction based on this twin location.

The weather twin feature created internal debates with stakeholders. Fears of customers being confused, not understanding the weather twin experience, or not trusted it became a blocker for the GA release.

To help the stakeholders gain trust in the design and in the tool, we engaged in extensive UAT with network engineers and planners. Fortunately, UAT was successful. On the scale of 1-5 for how likely are you to use this tool to design your network, 1 being not likely and 5 being extremely likely, the average score was a 4.9. The stakeholders gained confidence in the tool and GA happened on time,

Hemisphere Problem

An early version of the model returned weather twins exclusively from US cities because US weather stations had the most reliable historical data. This created a critical issue: availability predictions are shown monthly, and seasons are inverted across hemispheres. A link in the southern hemisphere matched to a US city would show high availability in January (US summer conditions) when it should have been showing winter.

The modeling team updated the algorithm to match weather twins within the same hemisphere as the link location.

An early version of the model returned weather twins exclusively from US cities because US weather stations had the most reliable historical data. This created a critical issue: availability predictions are shown monthly, and seasons are inverted across hemispheres. A link in the southern hemisphere matched to a US city would show high availability in January (US summer conditions) when it should have been showing winter.

The modeling team updated the algorithm to match weather twins within the same hemisphere as the link location.

Solution

Solution

Link Planner is a self-serve planning tool that lets network engineers evaluate link feasibility. Users place terminals on a map, run availability analysis powered by weather and terrain data, and get a clear picture of whether a link will perform at a given location and range. For data-sparse regions, weather twins provide predictions where local stations don't exist. Bulk analysis lets planners evaluate entire networks at once instead of one link at a time. Every prediction surfaces the data behind it, where it came from, how complete it is, and how confident the user should be, so planners can make successful deployment decisions.

The Hemisphere Problem

The Hemisphere Problem

An early version of the model returned weather twins exclusively from US cities because US weather stations had the most reliable historical data. This created a critical issue: availability predictions are shown monthly, and seasons are inverted across hemispheres. A link in the southern hemisphere matched to a US city would show high availability in January (US summer conditions) when it should have been showing winter.

The modeling team updated the algorithm to match weather twins within the same hemisphere as the link location.

An early version of the model returned weather twins exclusively from US cities because US weather stations had the most reliable historical data. This created a critical issue: availability predictions are shown monthly, and seasons are inverted across hemispheres. A link in the southern hemisphere matched to a US city would show high availability in January (US summer conditions) when it should have been showing winter.

The modeling team updated the algorithm to match weather twins within the same hemisphere as the link location.