Level Studios (Publicis Groupe)
•
2022 – Present
Brightspeed
Four years building the buy flow, account management, and account app for a 20-state broadband provider — and the three design systems that keep them consistent across web, iOS, and Android.
Embedded in Brightspeed's product team through Level Studios, I was the primary UI designer within a small UI/UX team. I designed the components and screens behind the buy flow, account management, and the mobile app, and built the design-system foundations every one of those flows runs on.
Role
Product Designer — UI & Design Systems
Timeline
2022 – Present
Agency
Level Studios (Publicis Groupe)
Team
UI, UX, Copy, Strategy, Product, and Engineering
Deliverables
3 Systems: Lower Funnel, Upper Funnel, and Mobile App Foundation Buyflow and Account App Component Libraries 34 Sub-Experiences Shipped
Context
What we inherited
Brightspeed launched in 2022 from acquired assets, serving customers across 20 states. It inherited web frameworks from its former companies and almost nothing of its own: no buy flow, no account management, an undefined public site, and no shared rules to build any of them from. The company was already selling service, so every customer-facing experience had to exist quickly.
The first problem wasn't a screen. Nothing could ship at scale until there was a system to ship it from. Over four years, the design team and I built one architecture with three foundations — Lower Funnel (buy flow and account management, web and mobile), Upper Funnel (the public site), and the Mobile App (account app, iOS and Android) — then shipped the two revenue-critical experiences on top of it: the flow that brings customers in and the flow that keeps them.
Both had to handle every customer type differently. A prepaid customer might see a credit check they'd never pass. A DSL-to-fiber migrator could see WiFi upgrades they couldn't buy. That conditional logic — which customer sees which step, in which state — was the design problem the systems had to solve.
Problem One
Two revenue levers, no foundation under them
By the end of 2023 the Lower Funnel groundwork was in place, but the buy flow was converting at 12.5–13% against a 20% business target. Closing that gap meant adding postpaid, and postpaid meant new steps, new risk moments, and a component inventory that didn't exist yet.
Baseline Conversion
Business Target
What the research told us
Before the move, Level's strategy team interviewed customers across age, household type, income, and service preference. The findings located where the flow was most likely to lose people. Deposits drove the most abandonment — sharpest among older customers, lower-income households, and anyone new to postpaid. Tolerance for friction varied by age: younger customers moved through identity verification and conditional offers easily; older customers worried about their data, their credit, and a surprise fee.
The journey told the rest. Prepaid was a seven-step purchase. Postpaid stretched it to eleven: identity verification, a credit check, a possible deposit, and qualification for the $10 AutoPay and Paperless Billing discount. The team aligned on five principles: lead with transparency, show value before qualification, reduce perceived risk, leave no dead end, set expectations early.
Turning principles into a component inventory
For UX, those were flow principles. For me, they were specifications. Four new steps translated into a defined set of components and states the Lower Funnel foundation didn't have:
Passcode input with resend and timeout states
Knowledge-based verification fallback
Processing state that reads as progress, not a stall
Soft-fail and recovery states with a clear next action
Outcome screens placing deposit amount and refund terms where hesitation happens
Discount treatment on the plan card, visible before the customer commits
Consequence modal for the credit-card path: what's forfeited, weighted without adding friction
Eligibility status component with four variants that carries from checkout into account management
Outcome
Here is what we handed off: the full postpaid flow, eleven steps across web and mobile. Select a plan, Customize your package, Value packages, Schedule installation, Checkout, and Order complete, plus the four new steps — identity verification, credit check, deposit, and discount qualification. Every step reached engineering with its states specified: passcode resend and timeout, knowledge-based fallback, processing, soft-fail and recovery, deposit outcome with refund terms, the credit-card consequence modal, and the eligibility status that continues into account management. The set shipped in weeks.
Problem Two
Rebuilding the app around moments, not features
Late 2025, the evidence came from inside the account. Brightspeed's product and support stakeholders brought what customers were saying about the two apps they had to use, the account app and the WiFi app, and the team reviewed analytics, app store feedback, customer archetypes, existing journeys, and business requirements.
What were the pain points?
The reviews told one story: frustration with billing visibility, service status, appointment tracking, and getting into the account at all. Customers open a utility app with a few questions and expect answers in seconds. Is my service working? Is my bill paid? When is my appointment? Do I need to do anything? The existing app made them hunt. It had been designed to mirror the web, and it worked, but it was static and fragmented: two apps with two visual treatments, account and service management barely connected, and critical actions competing with promotions for the same space. A bill, an outage, and a discount carried the same weight on screen.
Our Northstar
The strategy reframed the app around the moments customers need Brightspeed most, prioritizing by urgency, relevance, and journey stage rather than by feature. The mental model the team named plainly: fix what's broken, prevent the next problem, stay informed, then optimize.
For the system, that reframing became requirements:
Add more depth and immersion to app functionalities and experience
One visual language across both apps so they read as one product
A foundation built on variables from the first token, so one definition drives every screen on iOS and Android
How it was built
The app ran on the same cadence as the buy flow, compressed further: week-long cycles, one experience per cycle, launched in priority order. Each cycle opened with alignment across Creative Directors, Product Design Managers, Strategy, Product, and Brightspeed stakeholders on how the redesign would reach customers — which moment shipped first, what the notification tier rules had to enforce, and where the two apps had to converge visually before they could converge structurally. That alignment set the requirements; the foundation carried them.
My method was the same as the buy flow. Atoms first, and here the atoms start from variables, not styles: 136 colors with light and dark modes, 76 type values, 27 sizing values, 13 spacing steps, and 8 radii, each defined once and read by every component in the library. Text stacks, button stacks, fields, tiles, and cards were built on top of those definitions with structured variants and properties, so each state is a configuration, not a one-off. Motion answered the requirement for depth: transitions and micro-interactions were specified in Lottie with defined durations and easing, and loading and confirmation states shipped as Lottie files. Onboarding, billing, service status, and account changes were composed from that set as each cycle came due and prototyped on device, so Product and stakeholders reviewed each experience in context before build, with copy, product, and engineering in the loop from first frame to handoff.
Outcome
Here is what we handed off: one account app in place of two, on iOS and Android. Onboarding, billing, service status, appointment tracking, and account changes, each rebuilt around the moment a customer opens the app for. Engineering received a shared visual language across the former account and WiFi apps, and a variable-driven foundation with light and dark modes so one definition serves both platforms. The MVP shipped in six weeks; each experience after it launched on a weekly cycle.
System
How we worked
The solution wasn't a set of screens; it was how the screens were made. Every part of the buy flow and the account app is built from atoms — text stacks, button stacks, fields, tiles, cards — each carrying its own variants and properties. A component is a configuration, not a drawing. A screen is an assembly, not a composition from scratch.
The smallest part carries the most weight.
Every flow was built first in a foundation file, published through its child library, then composed in its composition file, so a decision made once reaches every screen that uses it. That is what let the team keep pace with one-to-two-week cycles. A new requirement rarely meant new work at the screen level; it meant a new variant at the atom level, and every dependent screen updated on its own.
Reached for. Not worked around.
The three systems now span 16 libraries: 2,160 components and 428 styles, with 261 variables driving the app, across the foundations, their child libraries, and the composition libraries shipped alongside them. In a single week, they take more than 28,000 insertions across the team's composition files — roughly three-quarters of every component in the organization's Figma workspace. On the Mobile App foundation, the fourteen most-used components carry over 96,000 instances and fewer than a dozen detaches; the two utility icon sets alone account for more than 34,000 of those instances with a single detach.
Before handoff, every composition file went through a manual lint pass, checking for detached instances, hard-coded values, and spacing off the scale, so drift was caught in the file, not the build.
Designers configure components; they don't break them.
Components
Styles
Variables
Insertions
Impact
Built once. Every transaction ran through it.
The buy flow, account management, and app are the digital channel Brightspeed's consumer business runs through. The numbers below are that channel's performance over the period the work shipped; the design team's contribution was the interface every one of these transactions passed through.
Buy flow moved from a seven-step prepaid purchase to an eleven-step postpaid flow with full state coverage: every verification, deposit, and eligibility state defined and shipped in weeks.
Sales vs. target, Q1 2025 — on 30% less web traffic
Fiber sales growth year over year, 2026
Value-added services share of sales mix, Q2 2025
Digital attach rate for Home Tech Support vs. all channels (4.5% vs. 2.3%, Feb 2025)
Reflection
What I’d carry forward
Speed taught me the value of thinking carefully before the first frame. When every flow ships in a week, there is no time to fix a bad foundation mid-cycle; the decisions that hold are the ones made early, in conversation with Creative Directors and UX Directors about what each step has to do and what the system has to carry. Those conversations, and a working knowledge of Figma's own capabilities — variants, properties, variables with modes, library publishing — are what let a small team deliver at a pace that shouldn't have been possible on paper.
The same lesson applies to research. A principle like "reduce perceived risk" is only useful once it becomes a specific state on a specific component, built so the next flow inherits it. The work that mattered most on this account wasn't a screen. It was the thinking that made the screen a configuration instead of a drawing.