[Part 1 of my series on language and service design]
When I delivered my first corporate website in the languages of Welsh and English fifteen years ago, I was happy about the fact that it was genuinely language agnostic. The first page you got to was a custom side by side screen with dual permanent navigation and a list of the most recently updated content in each language. Selecting content in one language stored a cookie that recorded a preference and allowed the home page to be defaulted to the language preference. (Yes, there was an option to reverse the setting; yes, you could still switch language at any point; and, yes, the home page in whichever language would still tell you about updates to content in the other language.)
I thought this was a nice bit of design right up until the point where someone skewered my vanity by calling it a “functional splash page”, which was – as far as I was concerned – the digital equivalent of calling a rose a skunk cabbage.
None of this matters any more – and my inner digital nerd wants to point out that it wouldn’t work responsively, in any case. Why? Because fifteen years ago, it wasn’t an unreasonable assumption to make that someone coming to your website would start at the homepage. For public sector sites, that stopped being the case a long time ago. I don’t think I’ve seen a public sector site in the last six or seven years where more than a quarter of users have seen the home page.
The reason for this is simple: most users land straight into a page courtesy of Google (other search engines are available etc.) Full disclosure: if you’ve ever seen me smiling in the middle of a heated board discussion about some promo box on the homepage for the latest internal enthusiasm, it’s precisely because I know that almost no-one is going to see it anyway.
This means that a user journey starts somewhere that is not on your website or service. And this also means that language switching options on your website – no matter how beautifully designed – matter far less than what happens before the user gets to your website or service, because it’s there that the journey starts and there that the language choice will take place. There is no language agnostic design possible within the walled garden of your website or service.
What work has been done on search and language? I’m aware of work on language use on social media channels, which almost starts to cover some relevant ground, but user research on language in user journeys from Google to content/service and e.g. what happens when you enter search terms in a mix of languages is something I’ve not seen.
This gets worse. Search is increasingly the domain of machine-driven learning techniques, which use metadata and other techniques to derive relevancy and answer questions. Those processes and the metadata that drive them are often in English. How many content management systems that allow bilingual content also record metadata bilingually? What happens with schema.org and multi-lingual content? How much does language affect URLs with locale codes?
The little I can find on this topic creates as many questions as answers. It also appears to suggest that pagerank rules supreme and that linking to stronger performing pages matters more than linking to pages in the same language. This is Google’s advice for developers (my emphasis):
If it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages; Google will still process the ones that point to each other. However, it is important to link newly expanded language pages bidirectionally to the originating/dominant language(s). For example, if your site was originally created in French with URLs on .fr, it’s more important to bidirectionally link newer Mexican (.mx) and Spanish (.es) pages to your strong .fr presence, rather than to bidirectionally link your new Spanish language variant pages (.mx and .es) to each other.”
In service design, my experience is that it’s almost always the bit on the left of the blueprint that is the problem: how does the user find or discover your service in the first place?
Judging purely on the basis of the number of times I’ve heard “but there’s a language/flag option on the top of the page” I’m not sure that we’ve updated our ideas of interface design around languages. If most users start somewhere that is not our (beautifully architected and designed) home-page or permanent navigation, then how do we make sure they find the service or content that we’re aiming at them? If we think about language in this area, then maybe we should stick our language switchers on the shelf for a bit, and spend some time re-search-ing search.
Header image by Stock Catalog CC-BY-2.0
Recent Comments