Blurred lines and job titles

The great divide and Should designers code? two ongoing debates that seem to split the design and front end developer communities straight down the middle.

In front end development it’s a split between traditional front end languages like HTML and CSS and a move towards more complex JS libraries and frameworks.

The design debate crosses role definitions, designers should definitely understand the medium they design for, but does this mean they should also build their designs or just work side by side with front end developers?

They both seem to boil down to responsibility and where one job ends and another begins.

Over the past 12 years, I’ve moved from designer to front end developer and back, experiencing the pros and cons of each and getting caught up in both debates.

In truth I’ve never felt 100% comfortable doing either of these roles in isolation, one without the other has always seemed strange and slightly disjointed.

Website Designer

After leaving university with a degree in product design I built my first webpage in 2007, spending an afternoon with a very patient teacher who single-handedly managed the company website. We used Notepad to write HTML and CSS, which was then deployed using an FTP client.

At the time my job title was ‘website designer” (I’m still a little upset I was never a webmaster) this role covered all aspects of designing, building and maintaining the website, starting out in a role like this is potentially why I’ve never liked letting go of either design or development.

This, however, was a much simpler time, and I’m grateful that I learned to write HTML and CSS when I did, today’s framework heavy seemingly JavaScript led world is a much more intimidating prospect for beginners.

Rachel Andrew talks about this in her post HTML, CSS, and our vanishing industry entry points.

the entry point more recently for non-traditionally educated people has been the bootcamps. They are typically teaching a framework-heavy style of development which gets students as quickly as possible up to speed with the technologies most likely to get them a job. However, I see from the questions I get from those who have been through that type of training, the basics are often glossed over at best.

Rachel Andrew, HTML, CSS, and our vanishing industry entry points

Since then I’ve been called many things:

  • UI developer
  • UX developer
  • experience designer
  • software engineer
  • front end developer
  • UX engineer
  • service designer
  • user-centered designer

The list seems endless.

The website designers I worked with from around 2007 to 2010 are also now working in a range of different professions. Some are developers, some are designers, one is a creative lead, some are search engine optimization specialists and some are project managers.

The breadth of this split shows how many job roles were intertwined into the ‘website designer’ title.

Front End Developer

As it became increasingly difficult to remain proficient in all areas of website design I began to focus more on HTML and CSS, and as a result kind of drifted into a front end developer role.

I started to learn jQuery and then JavaScript as well as build tools like Grunt then Gulp and version control like SVN than Git. For a time I really enjoyed this and was able to pick up new things pretty quickly, but the new things just kept coming.

I can write basic JavaScript but I am completely out of my depth when it comes to things like React or Angular. And it wasn’t just JavaScript I also found myself being expected to know how to write MySQL Queries, a little PHP here and there and numerous templating languages like Handlebars and Mustache.

At some point, my title became a software engineer, which was never something I was particularly comfortable with, It felt like I was moving further and further away from my starting point as a designer.

What I really wanted to do was design in code and to be responsible for designing the way people interact with a website. In my opinion, this isn’t possible in image software alone, or at least not efficiently. Using HTML and CSS you can take control of the whole experience including accessibility and performance across all resolutions and devices.

I’m a huge fan of the ‘front end designer’ title described in the post frontend design by Brad Frost.

What I didn’t want was to have designs thrown over a fence for me to thoughtlessly build.


Unfortunately, I’m yet to see a huge amount of opportunities for front end designers so around 4 years ago I moved away from development roles and back into the design world where I started.

So far the most frustrating thing about being a designer has been dealing with the assumption that design is about aesthetics. In some areas, it might well be, but for digital products designing how things work is the primary objective.


At times I’ve been labeled a UI designer, others a UX designer and sometimes both. Both roles have similar expectations to parts of my original web designer job, however, the fence was still in place keeping design and build in separate job descriptions.

Of the two UX is my preferred option as it hints more at how something works over how something looks. However taking responsibility for a user’s entire experience should never be the job of just one person, it should be in the minds of the entire delivery team.

Interaction design

“UX is everyone’s job” is a phrase I first heard when I starting working for a government department as an interaction designer. This is the closest I’ve found to date to that front end designer title and gets me back to where I started with the design and front end responsibility.

It’s also about more than just the digital interface, it includes the whole service or experience, including offline sections or follow up a correspondence with the user. Looking at an entire experience like this takes me back to my Product design training, replacing physical objects with services.

Interaction design is definitely my happy place and allows me to work on high-level user journeys as well as detailed interactions and coded components.

For me, if you design for the web, you should understand the web and therefore understand how things are built. These tweets from Anthony Short and Jared Spool perfectly sum this up.

Working as an interaction designer allows me to keep working on my skills in both design and code, and also allows for accessibility to be part of the design process, not just added in at the end.

Blurred lines

The blurred lines and fuzzy edges still exist.

It can sometimes be hard to separate interaction design from the digital thing that people are interacting with, even though the service itself is often much larger than that.

Design roles seem to be changing from UI/UX to interaction/service to incorporate this design of an end to end user journey. These two roles overlap in many ways as well as having their respective skill sets.

Originally published at

Blurred lines and job titles was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.