Accidental designer

Despite my advertising myself as a front-end developer, writing a lot of HTML and JS, I find my most productive days taken up considering and designing digital products and services, ideally with data and evidence.

I enjoy it a lot, but it as left me with a bit of a “am I a developer or designer?” identity crisis.

Colleagues suggest I’m in denial about being a designer – mostly because I’m not a visual designer; I don’t do pictures and graphics and I don’t wield photoshop as my tool of choice – I work in-browser. They also suggest that if I don’t start labelling myself better, I won’t be able to continue finding work doing the sorts of things I enjoy, which it turns out are mostly around supporting and, sadly, defending the user.

If I’m honest, I think I have actually just always had a bit of a problem with designers.

I unfairly (despite being very much into, and doing, art throughout my life) considered “design” to be a soft subject – engineering being the one with the greater level of difficulty. Wrong assumption, I realise, but easily encouraged during my time with computer scientists during my degree years where the concept of service design for the human-being end of software was treated as a “nice extra” and usually quite glossed over.

Along with the engineering bias, the industry as I entered it wasn’t exactly doing much for changing those wrong assumptions. When I started out, I had, as many people did in the early 00s until relatively recently, a lot of up-hill conversations and experiences with designers who were traditionally working in print and had somehow found themselves on the web, and they were doing a pretty crappy job of it.

They didn’t get it.

Those of us building websites then, early adopters of proper web-standards and sites that worked for lots of different kinds of users, tried desperately to make them understand that this isn’t print and it is a flexible, changing, growing, responsive, versatile, medium. They didn’t get it. We fell out. I had some fairly horrible run-ins with the then design director in my first job as a junior developer… Every day I am glad my current one can take me calling him an idiot and see it as a positive (not snark, genuine <3).

So, all that had left me with a fairly bitter taste. I very much knew that in my career, I not only wanted to distance myself from people who didn’t get it, but also myself from being anywhere near them in terms of the work I did, which is pretty much why I have always very clearly said “I do the code, I don’t do the design”. I’m not one of them. As if there should ever really have been a them and us.

It has meant I have had to push back into the “design” aspects of organisations I work for, because I hadn’t aligned myself from the start as part of the design team, where most of the user-orientated decisions tend to get made (which, I do think, is a mistake on most organisations part… designing for your users should be a concern from everybody on your team, no matter their role).

I think all developers should be more engaged with the overall site experience, but I realise that specialisms exist and some of us want to be nearer to that area than others. I’m one of those people who wants to make design decisions as well as code them up where I can. I want to have my cake and eat it too.

In hindsight, the problem was never really the art director when I was a junior. It wasn’t the designers that didn’t want to include me in decisions because I was a developer. It was the organisation, like many others at the time, as a whole not getting it. It’s part of the reason why it’s been great to work with other people over the years that have got it, allowing me to do the things I like and change early biases, and most recently at the Government Digital Service where I honestly believe they get it better than anyone I’ve ever worked for before. And that’s not just down to the amazing people they’ve hired – they get it at a basic level in the ethos of the department. My current contract may say “software engineer” but I am in the design team and like it very much.

I don’t really want a label. I hate labels. I loathe the term “user experience designer”, because I still believe that “user experience” is just a fundamental to what you’re doing, and shouldn’t need stating. There is nothing but user experience design if you’re building products for people.

I have a sneaking suspicion that’s what I am though and probably have always been, in the wide world of jobs people are already doing. User experience service product developer maker dogsbody thing. I am a designer who writes code, who will defend better user experiences and probably be able to tell you how to get them. But I still won’t do the pictures. Deal?

6 thoughts on “Accidental designer

  1. Great post Francis. I feel the same way about being a front-end turned ExpressionEngine developer who also does the wireframing (and a lot else besides). Does this mean I can call myself an information architect? Am I a user experience designer? I’ve always thought that was what other people did but when I attended UX London this year one thing I learned was that we all have the same concerns.

    Leisa Reichelt wrote about the “UX developer” earlier this year on her blog (What is a UX Developer and are they really a thing?). My reaction, like you’re saying too, is really that all front-end developers should have the users in mind, but as there is more competition for work, perhaps using this title is a way to set yourself apart and attract the kind of employers/contracts/projects where your input will be valued.

  2. Good post. It’s unfair of me, but I do sometimes feel that getting visual designers to do user interface design is sort of like asking kids to paint a nice mural on the new ship you’re going to launch and then OH BY THE WAY let’s get them to build the engine as well. :)

    I’m a programmer, obviously. In a previous job I had the title ‘software designer’, which I liked. (Some people might read ‘software design’ as referring only to the internal architecture, but in that job, that wasn’t the case.) I think developers are in a good position with regard to design. Developers (or in large projects, senior developers) are experienced in turning requirements into something that doesn’t just work, but works well, and interface design fits a lot better as a part of that than it fits with visual design. Visual design does have problem-solving (how do you fit that text in, how do you lead the eye in the right sequence) but it’s all a lot fluffier than the sequences of precise steps that are involved in user interface development

    But:

    1) It depends on the individual. Just as I feel visual designers often don’t really have a great aptitude for UI design (although this is in my experience getting better, probably as they start to care about it more), the same can be true of developers. Some developers will naturally (if left alone) do something that’s OK from a UI design perspective, some will naturally do something that’s horrible.

    2) There is a bit of a problem in the turkeys/Christmas category if the same person is doing the software and UI design, as there could be a tendency to adopt the easier-to-develop option. You actually need a balance: easier-to-develop is important because there is always more work to do than time available, so it means you can get more done, but you also need a ‘good enough’ user interface (where ‘good enough’ depends on whether it’s only going to be used by employees who will get familiar with it even if it’s not as obvious as it could be, or the general public, etc). For this reason it can be useful to have visual designers do, or be highly involved in, UI design in order that the developer can argue with them and come up with a compromise explicitly (rather than the developer just deciding one arbitrarily).

  3. I’ve been struggling with a similar dilemma. Not coming from either a visual design or particularly heavy programming background, but finding myself somehow in the mix.

    Of course, ultimately it depends on the person – there’s designers *and* developers who do ‘the other side’ down, and there’s others who acknowledge the stuff they can’t do, and the importance of the other skills. I’d like to think I’m in the latter camp, but it can be tough in environments where you’re expected to be one or the other.

    More thoughts here: http://www.r4isstatic.com/247 (on how I think the ‘web’ bit is often forgotten – designing webs is a skill, too)

  4. I just call myself web developer. It’s not very precise which for me is the point since what I do doesn’t fit neatly into one category.

    The other reason why I prefer a somewhat vague title is that concreteness invites forming stronger opinion about my role than merited and can avoid a chat of what I actually do.

    In practice, if I need to be short, I explain my work as everything except visual design.

  5. First of all, you made the frontpage of Hacker News — was odd seeing you there Phae :D

    This is something I struggled with for a while in my professional life, until I decided to explicitly specialise as a front-end developer. So I’ve done that for a while, but now I find that in my job (a small Agile team with 3 back-end devs, myself on front-end, and a ux/designer guy) I’m needing to generalise a little. So I often find myself learning a bit of Python here, and having an opinion with regard to ux/design decision there.

    One advantage to being a front-end developer doing ux/design work is that you’ve got a working knowledge of the feasibility of doing things with the technology available, which helps…

    With regards to personal projects though, as is the nature of them, I’ll happily be the designer, will happily read up on UX and apply my working knowledge, and I’ll even do some back-end work.

Comments are closed.