featured

Clarifying the 5+ roles of a “Front-End Web Developer”

Anyone who has looked for a job in this area understands that there is widespread confusion about who does what when it comes to designing user experiences (UX) and building user interfaces (UI) in a web browser.

For example, the variety of titles seen in job postings is crazy:

  • Senior UX Designer
  • Front-End UX Developer
  • Web Front-End Application Designer
  • UI/UX Engineer
  • Web UI Developer
  • Front-End UX Ninja
  • UX/JavaScript Developer
  • Junior Web Designer
  • Front-End UX Architect
  • Web/UI Designer
  • Senior Front-End Engineer
  • Front-End Unicorn
  • etc…

Looking at them in summary, it’s usually some formulation of:

  • (Sr./Jr.)
  • (Web/Front-End/JavaScript)
  • (UI/UX)
  • (Designer/Developer/Engineer/Architect/Ninja/Unicorn)

This is nuts, people. Who are we looking for, exactly? This may partially explain why there are so many terrible web experiences out there.

It’s especially frustrating for someone with skills in visual and/or experience design who is considering what exactly to learn to land a job in the world of the web.

I’ve spent the last decade of my life “designing” and overseeing the development of web products (working myself mostly as a Rails/JavaScript developer). What I’ve observed, especially recently with the advent of JavaScript-heavy applications, is that during the design and development process, there are at least five distinct jobs that need to get done on the “front-end” alone. These five roles are usually forced upon (or ignorantly tackled by) one or two people.

1. Creative Director

Someone needs to tie the branding and business objectives of the company in to the high-level visual and experience design of the product. This person needs to be a dreamer and influential visionary. If this role is lost at any point in the process, it can lead to team burnout and/or disillusionment with the project.

2. UX Designer

While the high-level creative direction is being set, a member of the team needs to talk to a zillion potential users and get radically specific about the product objectives, content, views, feel, and flow. While it’s best to start prototyping in a web browser ASAP, at this stage it’s smart to get a decent set of wireframes in place. The UX Designer of the project needs to know what can and cannot be done in a web browser from a technical perspective, and be disciplined about listening carefully to users, staying at this level of product development as long as possible while leaving the bulk of visual work to the UI Designer.

3. UI Designer

Here is where the mood boards, color boards, and style tiles get rolled out and iterated with the team to figure out what exactly the UIs will look like. The best visual designers don’t necessarily (in fact, rarely) make the best UX designers, so it’s important to hire someone who can really nail the UIs. This is harder than you think, so set realistic budgets and timelines. (I’m looking at you, hiring manager.)

4. UI Developer

Amazing mockups are useless unless someone can actually bring them alive in web browsers across all devices and screen sizes/resolutions. The best teams move lightning fast through the actual “mockup” stage (making as few as possible) and do most of the prototyping work and subsequent iterations in the web browser itself. The UI Developer, therefore, is responsible mainly for the HTML and CSS. Don’t expect your UI Developer to do any heavy-lifting with JavaScript (yes, read that again, I mean it). This is perhaps the most common mistake when hiring the team and building the product. I’ve learned the hard way (especially when it comes to down-the-road iterations) that it’s better to have your UI Developer be a strong visual and/or experience designer than a back-end developer.

5. JavaScript Developer

A JavaScript (JS) Developer is essentially a back-end developer (in fact, the best ones are indeed proficient with Node.js) who needs to architect the JS tools to efficiently test the UX and manage the flow of data to/from the back-end. At the same time, the browser performance needs to be rock-solid and consistent with what the UX Designer has in mind (slow page rendering is lame). A modern JavaScript Developer should be able to discuss with you the cost/benefit of starting your project on Angular.js versus React/Flux (or something else), and be very comfortable with SVG technologies to encourage your visual/experience designers to think bigger about what can be built.

Bringing These Roles Together

Every company/team thinks about these roles slightly differently, so I’m sure this can be divided in other ways, but the key takeaway is that building great web applications these days requires at least these five roles on the “front-end” alone.

Here at Code Fellows, in addition to our iOS, Rails, and Python tracks, we currently focus on training #4 (i.e. the UI Developer) and #5 (the JavaScript Developer). Along with the rest of the world, we have been on our own journey around what to call our “front-end” tracks. We first called our #4 track the “Unicorn Class” (don’t ask), then UX Engineering, then Front-End UX Design & Development, then finally landing on “Web UI Development” for our 2015 offerings.

Our first front-end track (in Fall of 2013) was a mix of UI, UX, and JavaScript training, and we quickly learned that we needed to split the class up, given that UI Development and JavaScript development students had such fundamentally different learning objectives.

If you are a visual/experience designer with a desire to learn web design, I’d encourage you to start learning how to “cut up” mockups of UIs that you are dreaming up. It’s better to learn how to work with HTML/CSS from that perspective, as working through tutorials alone can get you lost in theory that you’ll forget (and have to look up anyway) when it’s time to put it to practice.

Throughout the evolution of the web development process, we’ve learned that there’s no unicorn. It takes a team to create great products. More on that to come.


This post originally appeared on wclittle.com.

Next PostPrevious Post

About the Author