Context
Taara, Google X, builds free-space optical communication links that beam internet connectivity using light. Those links involve physical hardware that users need install and deploy in the field, so getting the connectivity live is a journey.
For roughly eight years, Taara was mostly R&D; product and design are recent functions. As it shifted from proving the technology to commercializing it, the deployment experience customers actually touched had never been designed, it had accumulated, with compounding friction at every step.
The result was a gap between links sold and links live , and in that gap, Taara wasn't delivering its real value to the user. Connectivity that had already been paid for sat waiting in inventory. Closing that gap became the business's clearest goal: shorten the lifecycle from links purchased to links live. As the founding UX designer, my responsibility was to design the solution.
The Cost of Friction
The cost of all this friction shows up as time, and time is the metric that matters: a link sitting in inventory is connectivity, and revenue, waiting. Deployment is a field operation with real cost. A site that looks ready but isn't means an installer climbs a tower twice. A stalled link means a customer's network commitment slips. Every manual handoff adds a place for the process to fail silently and a place for days to leak, and the support burden scales with each one. Getting "ready to deploy" right the first time is the difference between a clean go-live and a repeat truck roll.
And for Taara, the cost compounds past a single deployment: a customer who never reaches full value is a customer who doesn't come back. No value delivered, no repeat business.
Problem Statement
Customers deploying Taara hardware need a single, guided place to onboard their team, complete training, prepare their sites, and bring links live, so they can get their network up and delivering connectivity faster, shrinking the time from links purchased to links live.
Core Challenges
Customers juggled roughly six separate logins across disparate tools, each with its own sign-up and its own experience, and not one of them worked cleanly end to end.
The workflow ran on email, WhatsApp, and text. It was manual, unsystematic, and fragile.
The resource portals stored content but didn't guide anyone through it. Steps weren't tracked, there was no system memory of progress, and users didn't know where to go next.
Personas
After considerable research and clearly defining jobs to be done, I identified two primary users for Taara Base. here are two primary users for Taara Base.
Admin/Operators set up the organization, manage the team, assign training, and oversee deployments across all their links.
Installer, the field engineers complete training, prepare sites, and deploy in the field.
Information Architecture
The priority was to create a home base, a single login that opens into everything needed for a successful deployment. The Dashboard serves as the landing page: a place to launch every Taara product and see, at a high level, "what needs my attention." I used Learn as the large bucket for understanding the what and how of deployment, both training and all resources live under it. And Team Management is where admins add users and assign training. One entry point, organized around the work rather than the scattered tools it replaced.
Adaptive Design
For mobile, rather than lean into responsive design, I opted for adaptive because the use cases and workflows are genuinely different. Mobile primarily supports installers out in the field, so I omitted the Dashboard entirely and instead prioritized the two things that matter on site: the training and resources needed for deployment, and the site readiness workflow. It's not a shrunken version of the desktop app, it's a focused tool for the person on the tower.
Low Fidelity
I started low-fi to keep the focus on hierarchy and jobs to be done, structure and intent first.
Embedded in Engineering
Rather than the traditional design and then handoff, I worked in embedded with engineering, participating in the team's day-to-day. I took part in backlog previews and refinement, sprint prioritization, daily standups, and sprint reviews, so design decisions were made with engineering constraints in the room instead of discovered afterward. That closeness kept development and iteration fast.
I also contributed directly to the codebase, picking up frontend tickets. And I stayed in the loop through delivery: I participated in the release cycles, ran smoke tests, and wrote the release notes, so I shared ownership, not just in design, but in the full design, build, test, ship, iterate process.
AI Workflows
I contributed directly to the codebase on frontend tickets, and used Claude Code and other tools to support work with: specs, design-vs-build reconciliation, copy, mockups, and research synthesis that turned journey notes, data, and interviews into clear patterns. It also produced the working prototype.
I also built AI agents to run usability testing ahead of human sessions. They caught the obvious friction, unclear labels, dead ends, missing affordances, so human testing could go straight to the harder, judgment-based questions instead of the basics.
High-fidelity
I designed the high-fidelity screens in Figma, the single source of truth for the engineering team, on a newly established Taara Design System, ensuring consistency and keeping design and build aligned.
Usability Testing
Once the prototype was complete, I launched usability testing. I began with an AI agent for AI usability testing, to find the obvious issues. Following AI usability testing, I launched traditional usability testing with human testers.
Every tester completed every task, and nearly all task-ease ratings came back "Easy" or "Very Easy." No one reported getting lost.
The friction was minor and specific — exactly what a first pass should catch:
Mark-complete affordance (Site Readiness). One tester didn't notice the "mark complete" control (top-right) until after finishing the checklist. Reposition and emphasize the action.
Add-site entry point. Another expected to add a site directly from the Sites page rather than through "Manage." Add a direct entry point.
Base was as much an organizational challenge as a product one. Taara had spent roughly eight years as an R&D organization, but product and design were brand-new: no research practice, no journey thinking, no source of truth, no design system. Part of the work was establishing how design even happens here.
That took advocacy. In an org with deep engineering roots and a large hardware team, the instinct is to lead with what the technology can do, so I spent many conversations, with leadership and across teams, making the case that a link isn't valuable until a customer can deploy it, and the deployment experience deserved the same rigor as the hardware.
Base replaces six logins and a web of email with one guided platform, a stepper that walks customers from team setup to first link live, Site Readiness that makes "ready to deploy" a tracked checklist, and training, support, and tools in one place. It closes the gap between links sold and links live.
