Is it just me, or are we getting ahead of ourselves with the novelty of automation?

No, this is not a finger-wagging post, nor is it a lecture. This is a collection of tales from the journey and field notes to inform a broader conversation about

1. Process
2. Interdisciplinary alignment
3. Time and phasing and
4. Delivery

While new ideas, techniques, or technologies are one of the reasons many of us are so enamoured with this field, I believe that excellence in fundamentals is how we derive advantages in an ever-changing technological landscape.

TO BEGIN

Let's be honest - none of these ideas magically appear. Paradigms and conceptual frameworks are often inferred or borrowed. To kick off a process review on footer development, I would like to hat tip legendary sushi shokunin (寿司職人) Jiro, who dreams of sushi.

(and since life only hands one so many opportunities for such)

🎤 Thank you, Anthony Bourdain, for the ability to thematically tie in Jiro Ono's sushi mastery into a technical recap of a software system feature.

Global Elements are the rice

Jiro Ono regarded rice as the true foundation of sushi, obsessing over every detail. He would source a specific variety only available to him, cook it under high pressure, and season it to body temperature so it would harmonize perfectly with the fish. This relentless attention reflected his broader philosophy that mastery lies in the repetition of small, uncompromising acts, where the quality of the simplest element determines the quality of the whole.

...and of course Michelin star master makes everyone think of

🎺 do dodo doooo

The Footer

Unglamorous but required utility functionality. Appears on every page. Routes visitors to highly critical areas of any application. Requires a reusable code block housed on every page within an application. The footer, then touches, on all aspects of an applications design.

Global Elements are often overlooked in terms of how many hands need to touch it for it to work

Getting it right requires a unique semblance of shared experience, emotional intelligence, technical fortitude and most importantly, patience.

Client and Business (the focus of any design effort)

• Surfacing the trust signals: locations, hours, contact channels, and accreditations.
• Holding the legal floor: privacy, terms, copyright. The unglamorous compliance band that has to ship before anything else does.
• Naming the next action a visitor should take: Footer CTAs aren't decoration; they're the last chance to convert before someone closes the tab.
• Encoding the territory the business actually serves. The SEO paragraph at the bottom is a quiet, durable asset that outlives most of the campaigns above it.

UX and Design

Translating business vision into visitor-centric paradigms for accessing information, without breaking the Content Management System (CMS)

• Deciding what belongs in the footer at all: Everything that lands here is a vote against the header and the page itself.
• Making it aesthetically pleasing: Every block has constraints the design has to negotiate with, not around.
• Establishing rhythm and hierarchy: help the eye find the brand mark, calls to action, and the legal row in that order, on any viewport.
• Specifying behaviour for devices and breakpoints: desktop, tablet, mobile — because the footer is where layout assumptions silently break.

(now I've been told AI images cheapen one's work, but! I shared an in-house image above, and I secretly do love the next one so...)

Development

Wiring the design to data sources so the footer stays correct without a developer in the loop every time something changes.

• Connecting indexing modules to major categories and pages: A needed balance between aesthetic and functionality.
• Building reusable patterns: Content editors need to be able to move a link, swap a phone number, or update a slogan from the admin without a deploy or developer effort.
• Capturing data from the right source: media library for the brand mark, options groups for locations and socials, taxonomy sync for category nav, block JSON for editor-authored lists.
• Ensuring design and implementation notes: block IDs, render paths, data sources, stable selectors. These will get handed over to QA for regression testing.

Project Management

Keeping the loop between client intent, design, content, and dev tight enough that the footer reaches "done" with minimal rework.

• Ensuring the design reflects the client's wants with minimal effort: translating a wish list into the smallest set of decisions that design and development can actually deliver.
• Using the various link lists and information paradigms to provoke content drafting: most people are more responsive to contribution when information is situated in context
• Sequencing the work so legal copy, location data, and social URLs are ready before the footer is wired up: Content gaps are the most common reason a footer ends up "blocked."
• Holding the line on scope: Every new column, link, or badge is effort for everyone, moving the goal posts on done.

Quality Assurance

Capturing all the notes and nuance from the four roles above so the footer can be tested as a feature, not an afterthought.

• Capturing all layers of notes and nuance: The feature must be actually testable, not just clickable.
• Regression-testing on every release: The footer ships on every page, so a footer regression is a site-wide regression.
• Validating stable data: Verify that data attributes and semantic roles are present, and perform so that end-to-end tests survive the next layout refactor.
• Confirming dynamic regions reflect their data source: The location card pulls from the right options record, the auto-year shortcode is, in fact, the current year.
• Probing the edge cases development couldn't all anticipate: Empty link lists, a missing media asset, a deleted taxonomy term, a viewport sitting right on the breakpoint.

Is this the most important element on a project?

Not really. But that's the whole point. Finding elements like the footer, which factor in:

• business intelligence
• design systems and general prowess
• relay of objectives to technical stakeholders in
• a manner that is scoped and time-boxed such that
• functionality, aesthetic, and objectives can be tested

Is a great way to align entire projects. If thought about from the lens of:

1. Developing strong operational foundations
2. Learning how to communicate/delegate amidst a multidisciplinary and skill-divergent team
3. Using experience to refine efficiency such that
4. The person who is paying you gets what they want

This type of groundwork activity actually allows for the types of decisions to be made like AI usage on a project or compute-based specifics. You have to get started!

A couple of our notes from this footer activity to bring the point home:

Getting everyone together on a common objective showcased friction between development prerequisites and aesthetic objectives. Both entities could produce their work but complications emerged once it was integrated.

None of this was unmanageable, but it's important to note that enacting this on a straightforward feature gave us critical insights that would drive forward the remainder of the project. Here's the real kicker...

The roles of AI and LLM use were more effective for inspection, documentation, and versioning than they were for code injection into existing paradigms on a CMS

We started off using Figma's MCP to test out portability between aesthetic and code. By running these simple tests, we saw that artifcating and corruption were more rampant than simply configuring assets ourselves. This meant that (in our context of this one feature, mind you) these tools were better deployed for inspection.

Once a feature in the footer was ready, we could inspect and catalogue its core attributes using AI.

Instead of slandering the tools, it's simply worth acknowledging that their optimal role within our workflow was vastly different than original expectations. From this experience, early on, on a fairly minor issue we were able to align team and project in a manner that was much more constructive.

• What is the order of operations for developing UI patterns in a block-based builder?
• When is the right time to stop designing and make a formal request to development due to a databasing requirement?
• How do the routes exhibited in the footer become content authoring deliverables later on in the project, and who is responsible for them?
• How do these content generation activities inform broader considerations in applications like information design implementations and the roles of taxonomical hierarchies/categorization?
• How does the cascade of effort in one activity inform the communications strategy, documentation approach, and test planning ethos such that end-to-end testing can be planned for iteratively?

In this case: Jiro Ono was right ⚔️

Focus on essentials, quality, and timing.

It's amazing what can come out of working to perfect the ordinary, as opposed to constantly scanning the horizon. For us, focusing on getting the footer developed properly calibrated our team and client, and gave us deeply useful insights that would govern the remainder of the project.