Building for everyone

The case for specialist user centred Front-end Developers within Government and beyond.

Recently the Government Digital Service published it’s work on the Digital, data and technology career framework (DDaT), which is a common set of roles, skills and career paths, that every government department can use.

In summary it aims to bring consistency to the multitude of technical roles that exist in the public sector. Many of these roles have a number of different titles, but in reality, the scope and skills are the same.

I applaud this effort, however the beta version of the framework does not recognise what I believe is a specialist role of ‘Front-end Developer’, instead it has a catch-all role of ‘Software Developer’

So this is my feedback and the case for ‘Front-end Developer’ to be recognised as a specialist role and to be part of the user centred design ‘cluster’ of the framework, alongside roles like ‘Content designer’, ‘Technical writer’, and so on.

UPDATE: Frontend Developer is a specialist DDaT role now! Well done to all who made it possible.

Why? Some soul searching

The first question I asked myself when reading the DDaT Framework is how did this get missed? or did it, was it a conscious choice not to split this out as a specialty? if so, why?

Before I went knocking on doors, it lead me to question my own perspective for the reason why this didn’t feel right.

Is it my background?

I come from a digital agency and commercial media production background, where those businesses need specialist front-end developers to achieve high fidelity designs that create immersive customer/audience experiences.

One of the last things I worked on prior to joining government was the relaunch of lexus.eu with my last project being to create a Virtual video tour of the new model Lexus RX.

If you asked a ‘full stack’ software developer in my previous places of work to do that, to stop writing ASP.NET and start working with the HTML5 media element api, they would point to a front-end developer and say that they are better placed to do that work, do it well, on budget and within a given timescale.

Of course I’m not saying that a full stack developer isn’t capable of doing that type of front-end development but it’s a level of mastery that takes deep knowledge and experience which is maintained over time. It’s not something you can effectively ‘dip into’ as and when the need arises.

Are my expectations for the practice of Front-end development within government too high?

Browsers bugs, quirks, accessibility, debugging tools, client-side performance, a multitude of devices and assistive technologies are hard issues to keep up with, a person with broad but not very deep working knowledge of front-end development would struggle in my previous world but is that the level required in the public sector?

I think that depends on what we want to to achieve and where in the process the Front-end Developer is placed, we might not be building highly interactive or immerse user experiences like Lexus but upon reflection my expectations for ‘front-end’ are not too high and I believe our challenges are far greater.

This is for everyone

When I thought about it more, I arrived at why I joined DWP in the first place. I joined because if there is one place I should be able to truly do what’s right for the user then surely it’s when I’m developing for public services.

In the commercial world, users are often divided into target markets or demographics. Limited time and resources mean it doesn’t make business sense to cater for people that are unlikely to want your products or to use your services.

As a front-end developer this often lead to difficult conversations about the degree to which something could or should be accessible or which browsers and platforms did we ‘care about’.

Progressive enhancement to some people (thankfully becoming less over time) became synonymous with being ‘boring’ , ‘safe’ and even ‘avoiding work’.

However in government our users often don’t have a choice about interacting with us but more importantly those people can be anybody, from any walk of life. They can be people on old computers, new computers, phones, disabled people with Macs, Linux machines, games consoles, in public libraries, even Fridges! You get the point, the list is endless.

So in government we should never write-off a proportion of our users as not warranting consideration. This in my opinion instantly deepens the level of knowledge and experience required for a front-end developer in government.

Software Pioneering to Front-end Town Planning

I realise that the DDaT framework is not asserting there is no such thing as a ‘front-end developer’ specialism and I work in a section of DWP lead by Ben Holliday, which very much recognises front-end specialists.

In 2016 the lead developers at GDS blogged their approach to frontend and backend development, making some great points but I feel their primary concern was to ensure departments can be ‘agile’ which leads me to Simon Wardley’s excellent notion of Pioneers, Settlers and Town Planners (#1, #2).

Simon’s model is a powerful tool for helping individuals find their purpose and working agile means you need those ‘pioneers’ who have broad skills and are good at exploring, good at implementing the organisational needs to make things work together.

But that’s an entirely different (but equally valuable) mindset to that of what I see as a user centred ‘front-end developer’, who are more of settler and town planner.

I think given how important a skill front-end development is to the delivery of services, I’m concerned that the front-end ‘town planner’ will, in practice, not get the chance to exist.

People with that deep practical experience will lose their opportunity for continued mastery as a practitioner, they will be swept along because, as the GDS post says, they want the ability to ‘re-assign developers to different projects as the need arises’.

It’s not just about the level of quality and accessibility we want to deliver to our users. It’s about fostering a community that can implement those things in a way that they become consistent best practice across government and hopefully influence the wider web development community.

We talk about user needs but we must not forget that other developers and designers within government are users and have needs too. User centred Front-end developers can write code that makes it quicker and easier for full-stack or back-end developers to reuse design or interaction patterns, which makes it faster and easier to create accessible services of a consistent standard.

I’d like to see government taking the lead on things that the private sector simply doesn’t have the motivation or resource to invest in.

We should be propagating best practice not just in what we deliver but in how we deliver it.

After all, specialist front-end developers are the people that ultimately build the result of the other user centred designer’s hard work. Front-end developers create the interfaces our citizens (and civil servants) use, read and click through.

Across the pond

Lastly it’s worth looking at what others are doing, the best comparison I can see is the US Digital Service and their counterpart 18F.

Modelled on GDS (the UK’s Government Digital Service). 18F is an office within the US Government’s General Services Administration (GSA) that collaborates with other agencies to fix technical problems, build products, and improve how government serves the public through technology.

18F is promoting team best practices across speciality areas they call ‘guilds’. These guilds support their members in whatever way deemed most appropriate by those members themselves.

So not only do 18F recognise Front-end Developers as specialists, under what they call the ‘Front-end guild’, they have began fostering sub-specialities of ‘Front-end Designer’ and ‘Front-end Developer’.

Their list of guild outcomes and metrics are great and example of what we in the UK government need to be doing, which is why we should recognise ‘front-end development’ as specialist role and community.

Thank you for reading. I deliberately didn’t include a ‘TL;DR’.