I approach digital design as a connected system—from how an experience is structured in Figma, through production and handoff, to how it is assembled in the CMS and ultimately reaches the customer.
Across multiple initiatives, I took ownership of tangible pieces of this system: production naming, physical release workflows, CMS component testing and governance, reusable Figma structures, and process automation.
These weren't pieces of one formal project. They emerged as I became increasingly involved in how digital creative moves from concept to production.
How can the system make good digital work easier to create, implement, find and repeat?
The enterprise platforms already existed. My contribution was identifying and taking ownership of specific gaps between them, then helping turn ambiguity into something more predictable, repeatable and usable by both Creative and Visual Experience.
A customer sees one cohesive experience. Creative and Visual Experience have to understand everything required to make it function.
A Content Carousel requires independently prepared backgrounds, lockups and carousel children, with different requirements across desktop, mobile and app.
I helped establish what Creative needed to produce, how those assets should be prepared, and how they translated into the component Visual Experience would ultimately assemble.
That meant designing beyond the finished composition. I needed to understand how the design decomposed into production-ready pieces.
Understanding what a component required was only part of the problem. I also needed to understand how it actually behaved once those pieces entered the CMS.
When Engineering released new components into Bloomreach, they could be technically available before their behavior was understood or practical for everyday use.
I built them on test pages, supplied different assets, observed their responsive behavior, identified limitations and helped determine what Creative could responsibly work around—and what genuinely needed Engineering.
Limitations that could be handled safely through asset preparation, visual rules or temporary production workarounds.
Functional or interaction problems that couldn't—or shouldn't—be designed around.
Carousel-child CTAs couldn't initially be disabled or freely recolored. That restricted which backgrounds could safely sit behind them.
Instead of letting that limitation dictate the entire art direction, we adapted how the background asset was constructed so imagery intentionally ended before the fixed CTA area.
Desktop lockups were rendering larger than expected. I tested progressively padded assets until I found a treatment that produced the intended visual scale in the live component.
What looked unusual inside Figma was intentional: the production asset was being designed for the behavior of the system consuming it.
Some temporary approaches supported production for roughly 8–12 months while Engineering worked toward improved component behavior. The goal wasn't to pretend the component was perfect. It was to understand its limitations well enough to use it responsibly.
Testing taught me the rules. The next challenge was making sure every designer didn't have to discover those rules the same way.
As CMS behavior, responsive requirements and production patterns became better understood, I helped translate that knowledge into reusable Creative structures.
The library brought CMS components, page elements, service templates and responsive packages into a reusable Figma environment.
Designers could start with established structures instead of reconstructing production requirements from memory.
Component guidance helped translate CMS capability into Creative decisions: which patterns were appropriate for different content, what assets a package required and how responsive permutations should be approached.
Standardization only works if the structure survives after the designer hits Export. The design still needs an identity downstream.
Production assets move through multiple tools and people after Creative finishes designing them. Inconsistent naming made the relationship between the working file, production asset and eventual implementation harder to follow.
I established and enforced a naming convention that begins inside the Figma file itself, so the production identity of an asset stays recognizable as it moves downstream.
Consistent assets solved one part of traceability. But even a perfectly named asset isn't useful if nobody can find the release it belongs to.
The original process successfully got assets to Visual Experience: Creative exported the work, uploaded it to the DAM, generated production links and shared those links through active project-management tasks.
At the moment of release, that worked. But older links became difficult to retrieve, and Creative increasingly became the retrieval system. Anything outside the current work cycle could become a hunt.
I initiated the push to move permanent release information out of individual project posts. That required buy-in from Creative leadership and Visual Experience because the change affected both sides of the handoff.
The solution evolved collaboratively—from uploaded documents to a live, shared SharePoint structure that could be edited, searched and maintained.
I took ownership of much of the tangible implementation: building the release structure, creating subfolders, establishing document naming, creating early examples and reorganizing the system as partners surfaced real-world concerns.
Simplified public representation of the release architecture.
A connected system requires shared definitions. Work couldn't mean one thing at intake, another thing in Figma, another in the DAM and something different again at release.
Once the workflow became predictable, another question became possible: does a designer actually need to perform every repeatable step manually?
Highly templatized Services work didn't become a good automation candidate simply because it was repetitive.
It became automatable because the system underneath it had matured. The layouts were established. Responsive requirements were known. Inputs were predictable. Component structures were reusable. Production rules had already been solved.
I'm not interested in automating away the parts of design that require thought. I'm interested in recognizing when the thinking has already happened, the rules are stable and repeatedly executing those rules by hand no longer adds value.
These initiatives happened across different projects, systems and partnerships. What connected them was how I approached the problem.
Production naming standards, tangible release-system implementation, CMS component testing, creative workarounds, Figma systems and process automation.
Cross-team release structure, workflow alignment, component governance and practical adoption across Creative and Visual Experience.
Figma, DAM and asset-delivery infrastructure, SharePoint, project-management tooling and Bloomreach were established enterprise systems I learned to work across—not systems I claim to have created.
Partners became substantially more self-sufficient when locating previously released work instead of relying on Creative to retrieve old assets and links.
When an asset genuinely wasn't present in the release record, the gap became visible instead of everyone wondering whether they simply hadn't found it yet.
Designers gained reusable structures that reflected actual production requirements instead of repeatedly rediscovering them.
Once repetitive production became standardized enough, parts of the workflow could be encoded into tools rather than manually rebuilt every time.
Understanding how an experience is assembled in Bloomreach changes how I structure it in Figma.
Understanding how assets move through production changes how I name and organize them while I'm designing.
Understanding what Visual Experience needs changes what I prepare before handoff. And standardizing repeatable work exposes opportunities for automation without removing creative judgment.
That's the space I'm continuing to grow into: where creative judgment, technical understanding and experience systems meet.
