What "service design" really means
Before I joined the government, I thought that "service design" was mostly related to the realms of customer experience design, user experience design, visual design or interaction design. In other words, the design of things that people use; the "front end".
These were the fields of study that I knew well and in which I felt confident in my abilities. Uday Gajendar refers to this group of tasks as the Tradecraft:
This is the level of craft we often typically associate with design, at the tactical, tangible level of executional details, or final production. Every element precisely and carefully shaped with an exacting attention to the abilities of the tools, potentiality of the material, and needs of the context at hand. This also aligns to the features and functions of a product (or service, app, etc.) in a visceral way — what is seen, felt, and experienced.
As it turns out, service design or at least service design in the context of government has very little to do with these types of "other" design skills. As a user of a service - a citizen or organization - this is the aspect of a service that you see and experience. The simpler, the better. The less mistakes people make and the easier a service is to use and understand, the less errors and problems are caused after the service request is submitted.
It's this "after" - the operational side - of service design that's pushed me and my understanding of what design can represent. Design isn't just reserved for the front-end. Design is also in the discovery, documentation and definition of organizational process; to be able figure out all of the cogs in the machine and optimize as you go.
When we are able to "design" a process rather than just have our service work around a clunky existing one, that's where design thinking can be truly impactful.
After more than 18 months of building the infrastructure for and the production of some public beta services, I've finally started to work on writing the documentation of our standard process for development of transactional services.
In this standard, exactly 1 of almost 60 steps (not including sub-steps) has anything remotely to do with user experience, visual or interaction design. The rest of the steps aspire to outline how a project can conceivably find its way through the twisting, tumultuous waters of existing government policy and procedure. I also describe how to go about designing new or re-designing the various current processes that enable a service.
Discussion around the planning and organization of people, navigating or updating the infrastructure of process and finally communication in any and all ways dominates the content of the standard. Information about technology or the types of design I mention above is extremely far and few between. You know what? I'm okay with that.
As Louise Downe writes, "It’s not complicated, but it is hard".
If you want to survive and prosper in government, you have to be very resilient day-in and day-out, while also maintaining a long-term this will all be worth it view. I know that I have to do the hard work in order to make things better.
I came to the government because I wanted to advance my skills as a designer; I didn't just want to push pixels anymore. If you're a designer who's at the same point in their career, I encourage you to look at government service design jobs. Although challenging, the rewards can be huge both for you and more importantly, for the people who will use what you design.