Rethinking how the world's largest CDN customers configure their delivery, from the ground up.
This product is currently unreleased. The screenshots shown here are selected details shared with permission. I'm happy to walk through the complete design, prototype, and process in conversation.
Property Manager (being redesigned as Delivery Manager) is the core of Akamai's delivery platform. It's where customers configure how their traffic is served through the Akamai edge network, and it serves as the backbone that most other Akamai products connect into. Security, media delivery, performance optimization. All of it hooks back into a delivery configuration.
The user base is extraordinarily broad. On one end, a small business setting up a website. On the other, billion dollar corporations pushing terabytes of data, some of whom hire people whose entire job is to be an expert in Akamai. Internal professional services teams also manage configurations on behalf of massive clients. The range of technical ability across that user base is enormous.
The product had been built by dozens of teams over more than a decade, none with a holistic view of the experience. It was powerful, and nobody else could do what it did, so that power carried it for a long time. But it was a monolith. Overstuffed. Disjointed. Unopinionated. An everything tool built on an everything architecture. Almost no single person, even internally, knew how to use all of it.
Over time, the competitive landscape shifted. Newer platforms were gaining ground, and the gap between what we offered technically and what we offered experientially was becoming harder to justify. The project was greenlit as a ground-up redesign.
I led the UX design for this project from its earliest stages. It was a large, cross-functional effort that touched product, engineering, architecture, and UX simultaneously, and I was the primary point of continuity across all of it on the design side. Researchers, tech writers, and junior designers contributed throughout, with the team composition shifting as the project moved through phases, but the design direction and major decisions ran through me.
Day to day, my work split between hands-on design and cross-functional coordination. A significant amount of my time went into working through concepts with product and engineering, demoing progress to stakeholders, and presenting to large customers who needed to see that the experience they'd been asking for was actively being built. I built the prototype using an AI-assisted development tool, which made it possible to put a working, interactive version of the design in front of people early and often.
This was not just a UI redesign. The work included a new object model, a rebuilt API, and a new Terraform provider. My design decisions at the interface level were inseparable from structural decisions about how the product worked underneath.
The redesign was guided by a set of core principles that emerged from research, deep knowledge of the product, and years of watching where customers struggled.
Development has changed, and the tool needed to change with it. Rather than inventing a new interaction paradigm, we modeled the core workflow after Git. Branching, versioning, and deployment concepts that developers already understand. This made the product more intuitive, but it also allowed it to align with how modern development teams already work, opening the door to automation and CI/CD integration.
The old design was a monolith. Want to turn on caching? You had to build a complex rule inside the everything-interface, then push the entire configuration. Want to update some hostnames? Same thing, push the whole config. Slow and risky. We broke the object model apart so that individual pieces could be versioned, permissioned, and activated independently. Hostnames, rule sets, and settings became portable objects. You want to let someone manage image caching without giving them the keys to the entire configuration? Now you can.
The challenge was that portability adds complexity. Where once you versioned, activated, and permissioned a single object, now there are many. So the design had to be contextual. When the system can offer to do something for you, even if that's not the screen you're on, it should. When related actions can be bundled together, bundle them. Reduce the cost of the flexibility we were adding.
The old product had onboarding wizards and specialized setup flows. They walked new users through initial configuration step by step. The problem was, when those users needed to edit something or do it again later, they had no idea how. The wizard had done it for them. They never learned the actual interface. Our approach was to onboard users in the same place they'll work every day. Teach while you help. Don't build a separate experience that becomes a crutch.
The software is genuinely complex. Akamai knows it better than anyone. So the product should offer that expertise instead of just handing users the toolbox. This showed up across the entire experience: curated libraries of generated rule configurations, recommended settings, contextual tutorialization, an action item panel suggesting what to do next. It's not a single feature. It's a philosophy. Don't just give them the controls. Help them build.
Customers don't care about Akamai's internal structure, team organization, or proprietary terminology. The experience shouldn't be shaped by how things are built behind the scenes. We shifted to common language, developer language, human language. Organized features by how customers think about their work, not by which business unit owns the code.
Just because turning on caching requires creating a rule, adding match criteria, adding a caching behavior, and setting its value behind the scenes doesn't mean the customer should have to do all of that. We built a settings panel. It's not a revolutionary concept, and that's exactly the point. Behind the scenes it generates full rule configurations. On the surface, it's a toggle. Familiar, intuitive, and fast.
These are six of the principles that shaped the redesign, but they're a fraction of the full picture. The project spans dozens of workflows across the entire platform, touching everything from a complex rule tree builder and permissions models to multi-environment orchestration, API documentation, error handling, integration across dozens of other Akamai products, and migration paths for existing customers. Each of those areas involved its own set of design challenges and decisions. What's shown here is a curated view of the thinking.
The redesign is currently in preparation for its first beta release in mid-2026, with full general availability targeted for early 2027. Design work on the second phase of the beta is underway in parallel.
While the product hasn't yet reached live customers at scale, the response throughout the design process has been strong. In road show presentations to large enterprise customers, the reaction has been consistently and genuinely positive. Internally, it's been met with the kind of enthusiasm that's rare for a project of this scope and duration. The design work is ongoing, and I expect to have more concrete data to share as the beta progresses.