Responsibilities
UX strategy, Product decision-making, UX/UI design, Cross-functional leadership
Leads
Heather Cooper: Design & Product
Garth Brydon: Engineering
William Bergstroem: Product
Responsibilities
UX strategy, Product decision-making, UX/UI design, Cross-functional leadership
Team
Heather Cooper: Design & Product, Garth Brydon: Engineering and Product, William Bergstroem: Product
Taara, Google X, 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.
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.
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.
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.
"The more data, the better. I need to look under the hood and understand the link budget so I can design reliable networks."
"I need the tool to be smart. Show me where to place my links."
"I need to see monthly and hourly predictions. If I am planning a downtown area, show me what the availability is during business hours."
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.
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.
"The more data, the better. I need to look under the hood and understand the link budget so I can design reliable networks."
"I need the tool to be smart. Show me where to place my links."
"I need to see monthly and hourly predictions. If I am planning a downtown area, show me what the availability is during business hours."
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.
"The more data, the better. I need to look under the hood and understand the link budget so I can design reliable networks."
"I need the tool to be smart. Show me where to place my links."
"I need to see monthly and hourly predictions. If I am planning a downtown area, show me what the availability is during business hours."
"The more data, the better. I need to look under the hood and understand the link budget so I can design reliable networks."
"I need the tool to be smart. Show me where to place my links."
"I need to see monthly and hourly predictions. If I am planning a downtown area, show me what the availability is during business hours."
No Existing Playbook in the Market
Making Complex Data Trustworthy
No Existing Playbook in the Market
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.
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.
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.
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.
Mid-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.
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.
"Overall, the experience was positive. The interface was user-friendly and the entire process was straightforward and streamlined."
"I found everything straightforward and easy to understand. I did not have any issues."
"There are a few places I would like additional context, especially to help explain availability confidence."
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,
"Overall, the experience was positive. The interface was user-friendly and the entire process was straightforward and streamlined."
"I found everything straightforward and easy to understand. I did not have any issues."
"There are a few places I would like additional context, especially to help explain availability confidence."
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
"Overall, the experience was positive. The interface was user-friendly and the entire process was straightforward and streamlined."
"I found everything straightforward and easy to understand. I did not have any issues."
"There are a few places I would like additional context, especially to help explain availability confidence."
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.
Responsibilities
UX strategy, Product decision-making, UX/UI design, Cross-functional leadership
Leads
Heather Cooper: Design & Product, Garth Brydon: Engineering, William Bergstroem: Product
No Existing Playbook in the Market
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,
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.
