A Response to Brad Frost's "Frontend Design" Article

February 21, 2016

This past week I was thrilled to stumble across the alliteration filled article by Brad Frost called simply "Frontend Design". Actually, I didn't stumble across it at all, as it was showing up in just about every feed I followed around the interwebs. It had been tweeted, retweeted, quoted then tweeted, screen captured, uploaded and tweeted so many times that I had a feeling Brad had struck a particular nerve in the community. So I sat down to read it, curious to see see just what pain, joy, or fear receptor he might have hit.

A response too big for the comments section

Before we had comment sections, before social media, before Medium entries were cross posted to LinkedIn, Facebook instant articles and 3 different publications, the web only provided a single method for writing a response to someone's blog. That method was to write a blog article of their own!

Who's blog is it anyway

The point of these blog responses wasn't just say "Great job, you rock!" or simply summarize the original article. The response would follow the great improvisational tenets known as "yes and...", acknowledging the work that has already been done and then expanding upon it. If you weren't adding value to original post then all you were saying was "yes!".

So here is my "and..."

What is a Frontend Designer, and am I one?

Interestingly enough, the first thing about the article that struck me was the title, which seems fitting as it is the first thing one reads. I don't often use the term "Frontend Designer" to define myself, but the more I thought about it the more it made sense to use that term.

Do I need to be Visual to be a Designer?

I have never had much of a knack for visual design. I've tried my hand at web design a few times, and while I succeeded (in that I got paid for my work) I never much enjoyed it or felt compelled to do it again.

Writing code on the other hand is something I always felt comfortable doing. I believe I found comfort in the rules, best practices and practicality of code. "Does the code work?" Yes! "Then you have succeeded"!

But just because I was never a fan of doing visual design, doesn't mean that the work I do should not be considered design. Design can mean many things!

Why do we think Design is always visual?

Speaking about the term "design" with a friend outside of the web development industry, I was quickly reminded that we have created a unnecessarily strong association between the terms "design" and "visual design". We view them as essentially the same thing. But outside of web development, my friend reminds me, "design solves problems, no more, no less". So why do we treat the term differently?

Our printed history

My only conclusion is that our interpretation of the term "design" comes from our predominantly print background. Many web departments (and developers) are direct descendants of print design. Media companies who wanted to dive into the "new media age", tasked their staff of designers to hop into photoshop (or even inDesign) and come up with a flattened image to hand off to the new development team they hired so that they could make one of those new fangled website.

Now see what I did there? I said "staff of designers", and you didn't think to ask "what kind of designers?". A media company that has a designer on staff is going to be a visual designer. That has always been our assumption. But it's about time we assert our independence from out print heritage, and fight for the right to define our own industry. We are all designers solving problems through creative use of our talents, skills and expertise.

s/Visual/Frontend

We believe that a Frontend Designer's creative effort is not measured by the visual appearance of our end product, but by the processes we employ in producing said product.

• How do we tackle accessibility problems?
• How have we addressed performance issues?
• How is our code organized?
• How reusable are the pieces that we have created?

For every second we spend completing a development task, we spend an equal amount of time designing solutions for the unique problems we face in our profession.

Sure, I don't have any problem calling ourselves Frontend Developers instead, but we do ourselves a disservice to ignore the fact that we are all designers in our own way.

The many faces of Frontend Design

The second interesting tidbit from this article is the recognition that, though we might all fall under the umbrella of Frontend Design (or Frontend Development if you prefer), the job titles used to describe our positions couldn't be more diverse.

Brad points out that regardless of which of the following titles you might hold, we all live in " a sort of purgatory between worlds".

• UI Developer
• Client Side Developer
• UI Engineer
• Design Engineer
• Designer/Developer
• Prototyper
• Frontend Architect

If Dante were a developer, he'd be a Frontend Designer

He goes on to describe the limbo in which many of us find ourselves. A world where we as Frontend Designers:

1. Need to be skilled in UX, yet we are not UX developers
2. Need to have an eye for design, yet we are not visual designers
3. Need to have a mastery with JavaScript, yet we are not JavaScript Developers
4. Need to understand the role of our server side code and infrastructure, yet we are neither backend developers or sysops engineers.

That's just how Frontend is, right?

You might look at that crazy list of requirements and not bat an eyelash. "That's just how frontend develoment is". As the bridge between backend services, front end aesthetics, and content architecture, it just seems natural that we are capable of wearing this many hats.

Brad goes on and talks about how unlike Frontend Design...

...there is often a massive divide between designers and developers (or “marketing” and “IT”, or “creative” and “engineering”, or some other divisive labels)

Taking up the torch

Therefore, I wholeheartedly join brad in embracing the ambiguity of our role. I revel in the fact that we, as Frontend Designers, are not just allowed, but encouraged to reach as far up and down the stack as we desire.

It was in the spirit of reaching up and down the stack, and trying to find a banner under which to organize the many things we do within a project, that I decided to champion the Frontend Architect discipline.

Raising a Banner for Frontend Architeture

Frontend Architecture is a discipline that resonates firmly with this entire article, and is summed up in one of the article's key phrases:

[I]t’s crucial to treat frontend development as a core part of the design process.

But I would argue that it is not just the design process that Frontend Architecture should permeate, but the entire project engagement. It is incredibly important to represent the needs and concerns of the frontend from the writing of our proposals, to the staffing of the project, to the planning of the work, to the writing of every story.

When frontend is treated like a first cl.gatsby-resp-image-image { width: 100%; height: 100%; margin: 0; vertical-align: middle; position: absolute; top: 0; left: 0; }ass citizen next to infrastructure, platform development, content strategy, and design, your project doesn't just launch successfully, it continues to be a success throughout its entire lifetime.

Conclusion

So, whether you consider yourself a Frontend Designer, a Frontend Developer, or a Frontend Architect, remember that you play a vital role in bridging the gap between visual design and development. While we have been tasked with being the advocate for the end user, don't forget that we also champion the causes of the Designers and Developers as well.

Our project succeeds when the visual design of the site inspires and delights, while at the same time the design system is able to scale effortlessly without placing a burden on development or infrastructure.

Want to learn more about Frontend Architecture?

If you want to learn about the four pillars of Frontend Architecture and hear the story that lead me to champion this new discipline, pick up my book from O'Reilly Press called "Frontend Architecture for Design Systems". It has been my passion for the past two years, and I'm always excited to see that passion shared in others.