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.
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.
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.
“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.
They value of "knowing code" isn't just knowing HTML/CSS/JS it's: – 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.
Originally published at cathydutton.co.uk