6. User research is not language agnostic

[Part 6 of my series on language and service design]

I had done some guerrilla testing before I joined government but the first time I set up a formal programme of user testing on a new website it ended up being late on in the process on the first government project I’d been involved in. At the time I naively thought that any user testing was worthwhile and you could use any insight that couldn’t be acted on straight away to feed into the live running of the site. That was a mistake. What I ended up doing was telling a board of directors that their expensive and long running project – which they fully expected to be launched and then stay the same for a while – wasn’t very good. In Australia they call this kind of thing a CLD, or a “career limiting decision”. Needless to say, the website launched anyway, it wasn’t any good, and no-one thanked me for pointing that out. 

When I finished the discovery and the procurement process for the Alpha and Beta phases of my last government project as a Civil Servant earlier this year, I had made sure that user research was an integral part of the process from the beginning. I also succeeded in procuring a team that included the ability to carry out user research in both the languages of Welsh and English. Not only was user research part of the process from the beginning, but user research that included all of the language contexts in which the service would be used was part of the process from the beginning. 

The journey between the two pieces of work took slightly over a decade and encompassed not only learning and changes in my approach but a paradigm shift in the way that government, and other sectors, design and manage services. Ten years ago, the dominant model was one where all of the user interface design was done up front, often in Photoshop, before being signed off, cut up and sent off to developers to create a version that – if you squinted at a low-res version from twenty yards – looked slightly similar. Design, content, structure was all pre-determined, and then either abandoned for years or the subject of endless shanty town like extensions in the digital equivalent of corrugated iron. I used to shout at boards that a website was for life, not just for Christmas, and they’d stare at me like I was a lunatic. 

Providing the service in a different language simply meant that you added on a couple of months for taking a finalised English language version, copying it, and then adding the different language on top of it. This usually then got abandoned even more quickly than the English language version. (I once raised a question about the Welsh language website for the organisation I worked for referencing the wrong Prime Minister by a number of years, only to be told that the site didn’t exist. When I provided a URL, it took them a number of weeks to track down the server that was hosting the content, which was then immediately deleted.)  

Fast-forward to now, when an iterative, user-centered approach to service design means that change is no longer constrained to a launch ceremony once every five years but actually happens continuously. Let’s be honest: genuinely iterative, user-centered service creation is messy. Mud-in-your-hair and these-shoes-will-never-smell-the-same-again messy. You do some research, you try something, it does something you didn’t expect, you try again, you take three steps forward, you take a step backwards, you take a short-cut that becomes a cul-de-sac, you try something for “assisted digital” users and it makes things better for everyone, you learn, you change, the interim solution turns out to be better than the permanent one, you get frustrated, you find a user who describes what’s happening in coruscating terms and you run back to the team session feeling like you’ve seen the light, you find a legal problem, you discover a pattern in the analytics that shows users are doing something weird… and then someone in a suit comes and asks you to put timescales on every delivery for the next 18 months. But somehow, it seems that we’re still applying the same approach to multilingual delivery that we applied ten years ago: we do all of the work, create a translated version, then hope that nobody changes anything, and – if they do – pretend that it wasn’t an important change so that we don’t have to change the translated version. (There is a plethora of well meaning approaches all predicated on creation of the service in language x first.)  

If, as I tried to suggest in the last post, service design is not agnostic of language, then that has some significant impacts on the way in which we approach the design of multilingual services. It means that you cannot design up front once, and then – once the design looks stable enough – translate it. It means that you need a different service blueprint for each language. It means that you have to build language in from the beginning, and not tack in on afterwards. It means that if the service is created and iterated by a multidisciplinary team, then that multidisciplinary team needs to include the people involved in the design of the service in all of the languages that it will be delivered to users, from the beginning. It means that if you run user research sessions, or multivariate tests, or create prototypes, you need to do it in all of the languages in which the service will be delivered to users. It means that if you make changes to the service, it needs to happen in all of the languages in which the service will be delivered to the users. It means that if you provide some routes for users who may experience problems accessing the service, you need to do this in all of the languages in which the service will be delivered to users. [1] 

And there will be many people who say that this is needlessly complicated, needlessly expensive, and why bother?, and these will be people who haven’t seen how the principal cost is making sure that you can provide a multidisciplinary team that can own and iterate a service. Language is often used as part of the excuse that services are too complex to be changed. If we are genuinely engaged in the business of funding teams not projects to manage iterative, user-centered services then this is not a valid excuse. 

I will add one postscript, which is that almost all organisations that I’ve worked for and that undertake user research keep a mailing list of people who have volunteered to be contacted with requests for being involved in user research, whether this is filling out a questionnaire or trying a prototype online, or being invited to an online or in person session with a researcher. If I’m correct in positing that user research done in multiple languages is a rarity, then the one thing that would help change this would be easy access for organisations delivering Welsh language services to a list of users willing to be contacted with requests to be involved in user research with Welsh language services. A single cross-Wales list could be easily generated in exactly the same way as existing lists are, by adding the opportunity for people to volunteer for it to existing websites, and on and offline channels when they contact public sector organisations. 

Header image – User Research Periscope by GDS Team, CC BY 2.0

[1] Is equality of treatment for users in multiple languages always the same as uniformity of treatment? This stops being an interesting discussion the moment that you can provide evidence for the way that the service meets user needs in any of the languages that it is delivered in.

Leave a Reply:

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.