Systems & Platform Design
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 and disjointed, with no opinion about how anything should be done. 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 on the design side throughout. Researchers, tech writers, and junior designers contributed across phases as the team composition shifted, and I held the design vision and drove the major decisions from start to finish.
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 first thing we redesigned wasn't the interface, but the object model underneath it.
The existing product was built around a single monolithic object called a property. A property contained everything: rules, hostnames, origin servers, variables. All of it bundled together, versioned together, deployed together. If you wanted to change one rule, you pushed the entire configuration. If you wanted to give someone access to manage hostnames, they got access to everything. If you wanted to reuse a piece of configuration somewhere else, you rebuilt it from scratch.
That architecture drove almost every usability problem in the product, and it had nothing to do with visuals or interaction patterns.
The object model, before and after
We broke it apart. The new model is built around workspaces, which contain typed environments: production, testing, and development. Environments function like branches in Git. You clone production, make changes in development, promote through testing, and merge back. Each environment is independently versioned, deployed, and access-controlled.
The pieces that were previously locked inside a single configuration were pulled out and made into independent, shareable objects. Hostnames were grouped into sets at the workspace level with shared defaults, connected to environments through configurable routes. Origins were elevated to the account level, since they're commonly shared across products. Rules were wrapped in a new object called rule sets, versionable and permissionable on their own, enabling fine-grained control over who can change what. Rule sets can be shared across an entire account, and we introduced platform-level rule sets that Akamai maintains on behalf of customers.
Every one of these structural decisions had direct UX consequences. Decomposing the monolith gave us granular permissions, but it also meant more objects to manage, so the interface had to stay contextual and connected. The Git-modeled environment system gave developers a familiar mental model, but it also meant the UI needed to surface deployment state, version history, and merge flows clearly. Shareable rule sets unlocked reuse, but they also introduced questions about ownership and override behavior that the interface had to answer without documentation.
The APIs were crafted after the object model and the interaction design, not before. I was consulted throughout on how the experience should work, and those conversations directly shaped what the APIs exposed and how they were structured.
How changes move through the system
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 something new, 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. It was 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.
Nobody uses the full product. Not even most people inside Akamai. So the product should offer what Akamai knows 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. The goal was to help them build, not just hand them the tools.
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 the language developers actually use and organized features around how customers think about their work, not around which business unit owns the code.
Just because something like turning on caching requires creating a rule set, adding 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, which isn't a revolutionary concept, but that's exactly the point. Behind the scenes it generates full rule configurations, but on the surface it's just toggles, dropdowns, and simple components.
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.
One piece of the redesign has already shipped into the existing product: a reworked activation experience. We changed the progress bar to resolve at footprint activation, the moment a customer's configuration is actually serving live traffic, rather than tracking the full network rollout. We also replaced the generic ten-minute estimate with ETAs that reflect actual platform timing. Two changes to messaging, no changes to the underlying infrastructure. Users who felt activation took over ten minutes dropped from 49% to 29%. Positive sentiment on activation speed grew from 54% to 65%. The change didn't make the system faster. It made the system honest about what was happening and when, and users responded to that.
In road show presentations to 20 large enterprise accounts, the response to the full redesign was equally clear. Customer satisfaction shifted from 35% positive to 88% positive. Negative sentiment dropped from 41% to zero. When asked which aspects of the new experience mattered most, the structural changes ranked highest: object modularity, rapid development and testing, and improved activation times. That ordering validated the core premise of the project. The most impactful thing we redesigned wasn't just the interface. It was the system underneath it.