Hello and welcome to Front End Center. This is episode eight, The Structural Columns of Front End.

My team has been working on a few parallel projects recently that are all massive in scale. For a team with only a couple dedicated developers, that means that we’re regularly involved in a flurry of very big-picture ideas and small-detail implementation and testing.

Since these projects are also across a couple different technology stacks, I’ve been making a point of taking notes and seeing what universal elements of “front-end” arise across the board. There are plenty of little details and quirky exceptions that make every project uniquely interesting, but there’s a lot to learn about our industry’s constants as well.

A lot of the patterns that have taken shape reflect the Enterprise Design framework that Milan Guenther discusses in his work, Intersection. While Enterprise Design is intended to be wholly encompassing from a technical and business perspective, it is intrinsically tied to front-end work at all scales of projects.

There are three main pillars to this idea, which are identity, architecture, and experience. All three relate to each other in unique ways, but it’s the balance of them together that creates a structurally sound approach.

Identity is the first pillar, and the one most related to design or branding. It’s also very influenced by what sort of project you’re working on. The identity for a product or service might be very tied up in presenting a unified brand to potential consumers. The identity of an internal enterprise website will, instead, be zeroed in on a cohesive understanding and communication between all levels of professionals who use it.

It pays to be very conscious of your identity, and to regularly gauge how others see it. Just because you haven’t implemented a complex and deliberate campaign of branding doesn’t mean your identity is JUST the good work you did. Your project’s identity is built individually in the mind of everyone who interacts with it.

These identities are also not static. They grow and change based on ongoing signals.

A problematic identity freelancers might be familiar with is that of a small business blog. Despite a resounding success in launching a beautiful new website, results are rapidly dwindling a few months in. When you start digging, it’s painfully apparent the owner put up a short, pointless post on the blog they requested be front-and-center for their website, and haven’t touched it since. The identity has shifted from one of prominence and inertia to that of stalled abandonment.

A goal of mine for my current enterprise space provides another light. After years and years of being utterly email-centric, we’re looking into the usefulness of web-based social media in our enterprise. We’re actively engaged with notable business members who can reinforce the new identity of social community format over email chains. If an officer regularly messages and updates teams using new tools, and provides great informational updates with non-email blogs, they’re signaling a shift in identity. Their individual actions shape the collective identity of our project, representing the vast company from the perspective of one employee.

Architecture forms the second pillar. Massively scaled projects face more challenges in architecture, but even the smallest hobby site has decision to make and implement. The default expectation when discussing architecture is planning efficient code, or perhaps understanding the best dev ops methods.

Beyond these, though, you have to think about the architectural structures already in place around your project. What sort of impact will your work have on the current organization of management, and how it interacts with other departments? Are there regulations on the work itself, or on the business that the project will support going forward?

Like actual architecture, mapping and understanding these structures is utterly crucial. A blind spot in architecture may not be fatal, but it’s never a good thing. An architect carefully drafting up plans for a new high-rise would never black out a central load-bearing column and just assume the details will work themselves out. The architecture of a project must be considered fully, from inception through maintenance.

In the same way that a hardware engineer can verify the state of the equipment serving their websites and software, developers and the stakeholders we work for need to be aware of the tools at their disposal. Being able to identify and interact with each part of a project ensures that problems won’t begin building impossible pressure inside some hidden black box tucked away from curious eyes.

Finally, the third pillar is Experience. It’s made up of the actual interactions between an individual and the project. If Identity and Architecture both hold up a project as a whole, then Experience is how a single user understands just their slice of interactions.

A lot of projects are planned and executed based off of initial Experience oriented issues. One huge trend for projects large to small in the last few years has been an astronomical rise in mobile visitors. The Experience for these mobile users is starkly different than someone with a traditional computer monitor, despite representing the exact same efforts of Identity and Architecture.

While Identity is the whole package of a brand or image, Experience can also be broken down by interaction roles. The experience of an end-user can, and should, be functionally different from the experience of an internal employee or a business owner. The context of Experience is a defining feature, setting it apart from the universal idea of Identity. Even shared elements can have different contexts. A website tool a user might leverage once a week could also be used multiple times an hour by many employees. Understanding the Experience of that tool from both perspectives will define whether it’s a failure, partial success, or genuinely useful to people in both capacities.

Because of the intermediary role of front-end technology and design, we find ourselves firmly at the center of these three pillars. Even if great swaths of design and back-end architecture are handled by other team members, we are responsible for putting parts together cohesively.

If you work solo, or within a small team, you might be responsible for all three pillars. Designing an Identity that also lends itself to effective Architecture is a rather multi-disciplined undertaking. That Architecture then has to be implemented, while considering the Experiences of those who will be interacting with your work. Front-end responsibilities often mean blending code and design together to act as the visible layer on top of work most users will never directly see.

Are there any other structural elements to a project that you’ve found to be universal? Have you found that one of these elements is far more important than the others at certain sizes of project work?

Until next week, thanks for listening! This has been Chris Landtiser, and Front End Center.