CASE STUDY | Product Design & Design Systems

Buying a phone, upgrading internet, cancelling a TV plan — every journey felt like a different company. I helped make them feel like one.

Telia Estonia’s digital product and service flows had grown organically for years. Buying a phone, ordering internet, changing a TV package, or terminating a mobile plan, each flow was designed differently, by different teams, at different times. I led the creation of a unified flow guideline and design system covering the full customer lifecycle across every product and service line.

ROLE

Senior Product Designer

TEAM | AGENCY

Telia Estonia (in-house)

TOOLS

Figma, Miro, Lookback

DURATION

2023 – Present

THE CHALLENGE

One brand, dozens of disconnected flows

Telia Estonia serves thousands of customers across mobile, internet, TV & streaming, cyber security, and e-shop. Plus add-on services like device insurance, trade-in (Vana Uueks), and installment plans. Each of these products and service lines had its own digital experience, not by design, but by accident. Over years of separate teams building separate features, the customer-facing flows had drifted apart in structure, interaction patterns, and visual language.

The problem wasn’t just visual inconsistency. A customer who learned how to buy a phone in the e-shop had to relearn the interface when ordering an internet. Subscribing to a TV & streaming bundle like Stream Trio felt completely different from changing an existing mobile plan, which felt completely different from cancelling. And internally, every new feature required bespoke design work because there was no shared blueprint for how any of these flows should work.

🔴

Every flow designed from scratch

Purchasing a device, ordering a mobile service, signing up for internet, and subscribing to a TV & streaming bundle each had entirely different page structures, navigation patterns, and UI conventions.

🔴

No lifecycle consistency

The experience of ordering a service bore no resemblance to changing or terminating that same service. Customers encountered a different mental model at every stage.

🔴

Compounding design debt

Without reusable patterns, designers rebuilt similar flows from scratch for each service line. Every new feature multiplied the inconsistency instead of reducing it.

🎯

The goal

Create a unified flow guideline covering the entire customer lifecycle — purchase, ordering, changing, and terminating — across all product and service lines. Build a design system that makes consistency the default.

RESEARCH AND DISCOVERY

Two domains, six flow types, one unified system

The scope of this project was unusually broad for a single designer-led initiative. It covered both product purchasing (physical devices) and service lifecycle management (digital subscriptions) — each with distinct user needs, technical constraints, and business rules.

📱

Products Purchasing

Device browsing, comparison & selection on pood.telia.ee
Järelmaks (installment plan) & checkout flow
Vana Uueks trade-in & accessories purchasing

🌐

Service Lifecycle

New service ordering (Mobile, Internet, TV & Streaming)
Plan changes & streaming add-ons (Netflix, HBO Max, Inspira+)
Service termination
Cross-service upgrades (e.g., 5G+, WiFi extenders, MultiSIM)

Why this was complex

Service flows aren't just "ordering flows with different content."

Ordering a new internet connection involves address validation, installation scheduling, and router provisioning. Changing a TV package requires showing the customer their current package versus the upgrade – what channels they’d gain, what streaming services (Netflix, HBO Max, Inspira+) are included, and how the monthly price changes.

Terminating a mobile plan triggers retention offers, contract buyout calculations for leasing devices, and number portability options. The flow guidelines had to account for all of this while maintaining structural consistency.

Mapping the current state across every flow

Before proposing any changes, I conducted a comprehensive audit of every customer flow across all product and service lines. This meant documenting page structures, component usage, interaction patterns, and decision points for purchasing devices, ordering services, modifying subscriptions, and cancelling plans. I also benchmarked against industry-leading design systems such as Bolt, Fluent, Apple HIG, Carbon, and Atlassian to understand best practices for documenting flow guidelines at enterprise scale.

01

The same user action was designed differently everywhere

Selecting a plan was handled differently across the e-shop, the mobile package ordering flow, the internet sign-up, and the TV package configuration.

02

Termination flows had the least design investment

Despite being the highest-emotion touchpoint and the one most likely to generate support calls, cancellation flows received the least design attention.

03

No shared pattern for "current vs. new"

There was no consistent way to show customers what they have now versus what they’re changing to a critical moment in every modification flow, especially when upgrading Telia 1 bundles or switching streaming add-ons.

THE PROCESS

Building the system in four phases

Given the scope, spanning both products and services and covering ordering, changing, and terminating, this had to be built incrementally. Each phase delivered value before moving to the next.

1

Cross-flow audit & taxonomy

Mapped every existing flow across the device e-shop (pood.telia.ee), mobile packages, koduinternet, TV & streaming, and the iseteenindus self-service portal. Created a taxonomy of page types, decision points, and component variants. Identified which patterns were truly unique to each service line versus which were common across all flows and should be standardized.

2

Flow standardization & lifecycle mapping

Defined canonical flow structures for each lifecycle stage: ordering, modifying, and terminating. Documented branching logic, edge cases (e.g., järelmaks buyout calculations, koduinternet installation scheduling, Telia 1 bundle pricing dependencies, retention offers), and how each service line’s unique requirements fit within the shared framework.

3

Component integration & design system

Built reusable Figma components with detailed specs — anatomy breakdowns, state definitions, spacing tokens, and responsive behavior. Key patterns included the plan comparison module, the “current vs. new” change summary, the service configuration wizard, and the termination confirmation flow.

4

Documentation & cross-team rollout

Produced comprehensive documentation: Markdown specs with interaction states, responsive behavior, and usage guidelines for every flow type. Trained designers and developers on the system. Established a governance process for updates as new services launch.

KEY DELIVERABLES

What I shipped

🛒

Product Purchase Flow Guideline

A comprehensive blueprint for the device purchase journey. From browsing and comparison to bundle configuration, checkout, and confirmation. Covers every device category with shared patterns and category-specific variations.

🔁

Service Lifecycle Flow Guidelines

Three interconnected flow blueprints for ordering, changing, and terminating services across connectivity, internet, TV, and mobility. Includes branching logic for service-specific requirements (installation scheduling, retention flows, prorated billing).

🧱

Cross-Flow Component Library

Reusable Figma components designed to work across both product and service flows: plan selectors, comparison modules, configuration wizards, change summaries, and confirmation patterns. Each with full anatomy specs and state definitions.

📖

Documentation & Governance

Markdown-based specs for every pattern and component. Modeled after Atlassian and Carbon, with accessibility guidance, responsive rules, and a decision framework for when to use Selector vs. Toggle vs. Tabs. Includes contribution and review processes for system updates.

Flow guidelines & component system

DESIGN DECISIONS

Three decisions that shaped the system

Every design decision in the final UI traces back to a specific pain point or insight. Here are the five most impactful changes and the reasoning behind them.

1

One structural framework, service-specific content

Rather than designing six separate flows, I created a single structural framework with clearly defined extension points where service-specific requirements slot in. Ordering internet and ordering TV follow the same skeleton; the differences live in the content modules, not the page architecture.

2

Lifecycle-aware design patterns

I created patterns that acknowledge the customer’s emotional state at each stage of the lifecycle. Ordering flows emphasize excitement and possibility. Change flows emphasize clarity and comparison (“here’s what you have, here’s what you’ll get”). Termination flows prioritize respect and transparency over aggressive retention.

3

Termination flow as a design priority, not an afterthought

Finding 02 showed that cancellation flows had the least design investment despite being the highest-emotion touchpoint. I gave the termination flow the same design rigor as the ordering flow: clear steps, honest pricing, and a respectful offboarding experience that leaves the door open for the customer to return.

RESULTS & IMPACT

From fragmented flows to a unified lifecycle system

📐

Consistent experience across the entire lifecycle

Whether a customer is buying a phone, ordering internet, upgrading their TV package, or cancelling a mobile plan — they now encounter the same structural patterns, creating a predictable, learnable experience.

⚡️

Dramatically faster feature delivery

New service flows that once required full bespoke design now start with established patterns and components. When Telia launches a new service line, the flow framework is already there.

🤝

Cross-team alignment on a shared language

Designers, developers, and product managers across all service lines now share a common reference. The flow guidelines serve as the single source of truth for “how things should work.”

📖

A system that scales without any single designer

The documentation and governance process means new team members can understand, use, and contribute to the system independently, which is the ultimate test of design system maturity.

THE REFLECTION

What I learned from building a system at this scale

What worked well

Treating the entire customer lifecycle as one design problem, not separate “ordering” and “cancellation” projects, forced me to see connections that fragmented teams miss. The “current vs. new” comparison pattern, for example, only emerged because I was simultaneously thinking about service changes, upgrades, and downgrades as variations of the same user need. That kind of cross-flow thinking is only possible when one designer owns the full picture.

What I'd do differently

I’d involve developers earlier in the documentation process. Some specs needed revision after handoff because technical constraints in the service backend, especially around real-time pricing calculations for Telia 1 bundles, payment plan installment logic, and address validation for internet provisioning, weren’t fully captured during the design phase. Co-authoring documentation with engineering from the start would have saved rework and produced more implementation-ready specs.

NEXT PROJECT