2026
From Taking Briefs to Taking Ownership: Building a Flexible Web Design Process
This project began as a straightforward brief to design self-serve web templates for stakeholders. It has since evolved into a two-year journey (and counting) of turning a shallow brief into solving the right problem and the incremental wins of making a design system actually used.
How the project started
The company was migrating its web pages to a new authoring system built on Adobe AEM, connected to our design library.
The promise was: better design consistency, stronger preview capabilities, quick publishing, and optimised SEO, to name a few.
The brief: Create fixed templates, mould stakeholder behaviour
My brief was clear: design fixed web page templates that marketing and product stakeholders could choose from and use independently.
The reasoning was that many of our pages suffered from being too long and wordy, hurting comprehension and user experience. Rigid templates would act as a natural constraint, nudging stakeholders toward tighter, more considered content.
I had reservations early as I believed a more suitable approach was to have section templates that stakeholders could mix and match into a full page. This would allow us to maintain design standards while allowing various page topics to achieve good content flow.
But I was new to the team at the time and didn't yet have any strong stakeholder context so I deferred and designed the templates as scoped.
I pored through our pages with the highest traffic, analysed content, designed and tested templates against existing content, and came up with guidelines.
We pushed the templates out… but they didn't land. They weren't being adopted.
Stakeholders found they couldn't fulfil content needs amidst evolving campaign and product requirements. Real content kept breaking out of the mould.
The reframe: Shifting from templates to content blocks
This friction to adoption was evidence that we needed to make our templates more flexible with section-level templates — pieces stakeholders could sequence and combine with their actual content in mind.
How the team’s approach shifted:
Influencing stakeholders by shaping content
Our team actively contributes to the web content narrative for key products. This allowed us to actively shape content flow and design, rather than letting our fixed templates be met with resistance.
Using live page references
With a growing repository of live pages fitting our design system, we started pointing stakeholders to these pages instead of using a template menu. This did the work of proving the design can be achieved, along with relevant content use cases.
Maintaining a lightweight usage guide
This guide was originally created to instruct stakeholders how to prepare media assets to go along with their content. Using this opportunity, we baked in guidelines on ideal content length and visual styles as a way to continuously nudge stakeholders to consider best UX practices.
Where it stands
In a recent web hosting migration project, over 40 pages were migrated within three weeks from its previous system — a signal that the web authoring infrastructure, when it works, can move fast. The system now supports pages across multiple brands, with a design library that continues to grow.
Ongoing enhancements: How I’m pushing for a better system
Note: From an operations perspective, we have a dedicated team of web authors who are the ones actually configuring the web pages via Adobe AEM.
Creating better fundamental building blocks
Along with the initial approach to build fixed templates, a lot of the design components built for Adobe AEM aren’t that flexible.
Working closely with our product owner and developer, I initiated conversations around a grid system that fundamentally changes how layouts are structured. Rather than fixed, predefined arrangements, the grid allows any combination of rows and columns — with configurable corner radii, background colours, and text and image alignment.
For designers, this means we can stop saying "that design can't be achieved in the system." For web authors, it means more power — but also a steeper learning curve and a greater need for design literacy. Managing that gap is an active part of the work, not an afterthought.
Designing within Adobe AEM
Often in the process of connecting design components to Adobe AEM, development complexities result in specific outcomes in the design components that don’t match my current knowledge of the component. One shift that quietly changed how I worked: as a designer with access to the UAT environment, I stopped only designing in Figma first and started building directly in the authoring system.
This gave me full control over the design before it ever reached a web author. It also meant my feedback was grounded in how the system actually behaved and not how I imagined it might.
The work isn't finished: the grid system is in active development and authoring workflow improvements are ongoing.
The balance between flexibility and guardrails is something we manage continuously, not something we've solved.
But the system is being used and we’re pushing for it to be better.
What I'd do differently
If I were starting this over, I'd treat it like a research exercise before a design exercise.
Knowing who the actual users of the ecosystem are — web authors, business stakeholders, designers — I'd ask what does success look like for each of them and what metrics would tell us the system is working. I'd work to collect evidence against the assumptions.
I'd also advocate earlier on my approach. Being new to a team is real, and working within inherited constraints is sometimes the right call. But now with more experience, I'd have explored other ways to show the value in my solution.
The most useful thing I could have done earlier was make my reasoning more visible, document my reservations, and run a small test rather than waiting for a full-scale outcome to pivot on the approach.