Blurred lines and job titles
Published on
Job titles seem to come and go, what remains constant is the blurred lines of responsibility. Where does one job end and another begin?
Published on
Job titles seem to come and go, what remains constant is the blurred lines of responsibility. Where does one job end and another begin?
Published on
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.
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.
Since then I’ve been called many things:
The list seems endless.
The website designers I worked with from around 2007 to 2010 are also now working in a range of different profesions. Some are developers, some are designers, one is a creative lead, some are search engine optimisation specialists and some are project managers.
The breadth of this split shows how many job roles were intertwined into in the ‘website designer’ title.
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 then 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 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 prefered 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 entire delivery team.
"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 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 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 therfore understand how things are built. These tweets from Anthony Short and Jared Spool perfectly sum this up.
They value of “knowing code” isn’t just knowing HTML/CSS/JS it’s:
— Anthony Short (@anthonyshort) April 21, 2018
- understanding how browsers/devices work
- knowing how requests are made
- becoming better at designing logical systems
- thinking in components
- etc
It’s all the stuff around code that’s valuable. https://t.co/620w1D1K3t
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.
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.
These are webmentions via the IndieWeb and webmention.io.