Aphorism 61
Two elements of successful leadership: a willingness to be wrong and an eagerness to admit it.
Seth Godin
(via Tim Harford)
Two elements of successful leadership: a willingness to be wrong and an eagerness to admit it.
Seth Godin
(via Tim Harford)
Things which caught my eye elsewhere on the web
Translation is an extraordinary process. It is holding on to the essence of a thing while stripping away everything which expresses that essence and replacing it with a different language or a different form. Having pulled off this remarkable feat, the fate of the translator is then to be ignored: the integrity of the original is maintained and rightly belongs to the original author, the better the translation, the tighter that integrity and the less it is apparent that the new version is a translation at all.
Georges Perec is famous for writing a novel in French entirely without the letter e – a formidable technical achievement. But in some ways the more astonishing achievement came when Gilbert Adair translated it into English – also without the letter e, preserving a connection with the original at a level of detail which most translators don’t even have to think about, let alone strive to match.
This being a blog about public strategy, bravura literary translation is not really what this is about. But thinking about Perec and Adair, following the latter’s recent death, made me reflect that the job of a public strategist is also about translation (though that’s not all that it is about). The job is to take vision, intention and legislation, often expressed in relatively abstract terms, and create from them the wherewithal to deliver practical and effective implementation.
As with literary translation, original authors may not be fluent in – indeed may not have any knowledge of – the target language for the translation. They thus may have no way of directly assuring themselves of the integrity of a translation. But that does not invalidate the translation, or make it any less necessary for monoglot readers of the translated language. So it is with the serial translation of vision into strategy, policy and legislation, of policy into delivery approach, of delivery approach into project objectives, of project objectives into IT specification, and so on down several forking sequences. At each stage there are unavoidably and necessarily small distortions. Done well, the translation errors are not cumulative. Done anything less than well, any final attempt to return to the original language, or to infer the original policy intent from the daily pattern of service delivery, is doomed by the triumph of noise over signal.
At the end of it all, there is a risk that what gets delivered is not the original intention, but the third level mistranslation of that intention. As a result, a project may be triumphantly completed to conclusion without anybody quite having noticed that though a problem might well have been solved (and even solved well), it has slid into being a different problem from the one originally posed.
As translations are rarely remarked, translators are rarely celebrated. To miss their contribution is to miss something rather important.
This is a story of joined up government. This is a story of not very joined up government.
It is quite a long story: there are well over a thousand words here, describing a bit of activity which took no more than a few minutes to do. There are no heroes in this story, but no villains either. And since there is a lot of quite tedious detail in what follows, it’s probably worth starting with the conclusion.
I wanted to find what I thought would be a simple piece of local information. As with many apparently simple questions, it turned out to be remarkably hard to answer. That’s partly because managing information and keeping it up to date across the three bits of government which I came across in the attempt is hard. But it’s also because of a set of minor usability glitches and inconsistencies, none of them individually catastrophic, but cumulatively making the experience harder than it needed to be. It is also an unexpected reinforcement of the argument I made a few weeks ago that you can’t tell how well a service or site might meet your needs by looking at it. You can only tell by having needs and trying to meet them. My conclusion is that this is always harder than it looks. And that there is always something to be gained from being obsessive about the detail.
And so to the story.
My mother in law is less mobile than she used to be. She has recently got a blue badge, allowing her to park her car much closer to places she is trying to get to. Actually she doesn’t have a car, it is many years since she gave up driving. But the blue badge can be used in other people’s cars, so long as they are taking her somewhere she wants to go. My cousin is visiting from the States for Christmas. She wants to take my mother in law out to lunch. So is there convenient disabled parking sufficiently close to the intended restaurant?
My mother in law lives in Shrewsbury, which comes under Shropshire unitary authority. That’s an immediately encouraging start, because the Shropshire website is a thing of beauty, with clear minimalist design and simple straightforward navigation (and a project team who show their passion in making it so). What I want is a map of disabled parking bays in central Shrewsbury, so ‘Maps’ seems like a good place to start. The map tool is very well done. You can drill down practically to the level of individual paving stones, and select from no fewer than 43 overlays, ranging from the precautionary salt network to mobile library stops. Sadly, though, disabled parking isn’t on the list of 43, so I need to look elsewhere.
It’s not hard to find the relevant page – though it’s primarily about applying for a blue badge, with using it seeming to be a bit of an afterthought well below the fold. ‘Where can I park if I have a Blue Badge?’ is a promising heading, but sadly tells me only about kinds of places, not actual places. But there is a promised link to ‘Parking Benefits’ which might do the trick.
At this stage the link is only promised because Shropshire seems to have a consistent policy of not putting links in the body text, but adding them in a separate box at the end of each page. That creates two significant problems.
First, there is an impact on usability. The actual links are invisible without scrolling down, creating a sense of uncertainty which, as we will see, turns out to be entirely justified. More importantly, it breaks a fundamental part of how the web works. If there is anything more fundamental to the concept of a web page than hyperlinks, I don’t know what it is. And even if you don’t accept that in principle, there is Jakob Nielsen’s law of internet user experience to consider:
Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
I wanted to click on the phrase ‘Parking Benefits’, not to have to scroll down, find the phrase in a links section and click on it there. That leads to the second problem, because as it turns out the promised link is not there to be found, a mistake I suspect it is much easier to make if the link gets separated from the text which introduces it – there is no way of looking quickly at the list of links on the page and detecting that one is missing.
As an alternative, I followed a link which did exist to ‘The Blue Badge scheme: rights and responsibilities in England’. That turned out to be a pdf version of a booklet produced by the Department for Transport.
I thought it was rather good. It told me everything one might want to know about how the scheme works, other than the answer to that elusive question of where disabled parking bays are to be found. But buried deep in the booklet, on a page dedicated to the curious fact that four London boroughs have declared UDI from the scheme, was the line I was looking for:
You can find the location of parking bays in London and elsewhere at http://www.bluebadge.direct.gov.uk
My sense of triumph was short lived. The result of following the link was not what might be hoped for. Without even the dignity of a 404, that subdomain is stone cold dead:
This page is generated by Parallels Plesk Panel, the leading hosting automation software. You see this page because there is no Web site at this address.
There was something not quite right about that, beyond the obvious fact of the broken link. I had assumed that the Shropshire site was linking to DfT to provide the booklet, but it turns out it has hosted its own copy. But the version they have is from 2007, now superseded by a new edition dated 2011, which has neither the link, nor any promise of the elusive map. Linkrot is a pernicious business, and not generally the fault of the linker. I don’t know how Shropshire checks the validity of its links, but whatever method they use, I am not surprised that it fails to pick up non-clickable URLs buried in pdfs (and that fact is perhaps another argument against using pdfs for mainstream content). But since the booklet as a whole has been replaced, perhaps it should be taken as an instance of the more general principle that it is better to point to information which may change at times and in ways you don’t control. There is no excuse though for Directgov closing a previously publicised sub-domain without leaving so much as a redirection to where the current content is to be found.
I was also struck that the 2011 version on Directgov is much inferior as a web page than the old 2007 version on the Shropshire site. Shropshire has one page to a screen, giving proportions which are about right, so filling the screen with clear content. Directgov has a double page to a screen view, completely out of proportion to any screen I have ever seen.
To complete the oddity of it all, the new version also has a link to where copies can be downloaded from. Except that it is a DfT link, not a Directgov link, despite the content being very clearly addressed to a citizen audience. And except that although the link has been made clickable, it runs over two lines, and only the first line is used, so taking anybody who tries to use to the DfT home page rather than the topic page. And while I am being pernickety, the DfT page which is, I assume, the canonical source describes the booklet as published on 23 March 2010, despite linking to the May 2011 version.
But back to Directgov, where it turns out that despite the demise of the sub-site, there is a blue badge page. It even gave me the extremely useful (but all too rarely provided) information that the thing I was looking for (even if I didn’t know that that was what I was looking for) doesn’t exist. Better still, it says it can tell me where to look instead.
If you live in England, see the link ‘Locate parking bays for registered disabled drivers’ to find Blue Badge parking bays
This is information held at local authority level, so it needs to know the area I am interested in and two screens later it successfully finds the right link – to the general blue badge page on the Shropshire site which I had been on half a dozen steps earlier. Beyond the general frustration of being sent round in a circle, it is also important to spot that this came of answering a question different from the one asked. The Directgov offer was to take me to a page where I could locate parking bays. But it didn’t – and couldn’t – deliver on that offer because it has no control over whether local authorities provide it. Perhaps other local authorities do, but that doesn’t help me with knowing where one might park in Shrewsbury.
My cousin decided they would take a taxi to the restaurant.
Things which caught my eye elsewhere on the web
Some would say the answer is obvious.
But it’s always worth remembering that processes seemingly designed to frustrate the customer are not limited by sector or organisation. Here’s a tale of convoluted customer service with rather a surprising punchline. Though here is another, more seasonal, story which shows another approach altogether.
You can’t institutionalize innovation. If you could, everyone would do it.
Carl Bass, quoted by Brian Bergstein

The skill of a pilot is in bringing vertical speed to zero just at the landing point.
The skill of a bell ringer is in bringing rotational speed to zero just at the balance point.
The skill of managing change is in making the rate of change as close to zero as possible at the point of change.
Successful pilots, bell ringers and change managers do this apparently effortlessly by preparing their trajectory well ahead of time and being continually alert to changes in the environment which might require a correction – but those corrections will tend to be small in relation to the goal.
Unsuccessful pilots and bell ringers crash.
Picture by RTPeat licensed under creative commons
I went to two events yesterday.
The first was the launch of the Government Digital Service, or rather a housewarming party for their shiny new offices. In fine agile tradition, they put on a slick show and tell with short sharp presentations about their work and achievements topped and tailed by Francis Maude, Mike Bracken (who has blogged his account of the day), Martha Lane Fox (likewise) and Ian Watmore. There was an enthusiastic crowd of supporters twittering furiously and other blog posts are starting to appear [added 10/12 - and GDS has now posted the presentation material and links to press coverage] . The dress code was smart casual, with a lot more emphasis on the casual than the smart. There was a buzz, a sense of creativity and spontaneity, of energy and talent unleashed, of an approach which felt a million miles away from both the stereotype and the reality of government projects.

Frustratingly, I had to leave early to get to the second event.
That was a much more sombre affair, closed and closed in, in an anonymous Treasury meeting room. The programme I work on was being reviewed, to check that we are managing effectively and are on track to deliver. There was little that was casual, in dress or anything else. There were plans, business cases, critical paths, migration strategies, decommissioning strategies, privacy impact assessments and a pile of other stuff besides. There was pointed questioning on risks, affordability and resilience. I make no complaint about that. We are spending public money – rather a lot of public money – and we should be challenged and tested on whether the spending is wise and the results assured. The track record of large government projects is not so great that there is room for complacency. But it felt a very long way from the world of GDS.
That matters, because actually the two are very closely linked. They represent, in effect, different ways of thinking about the same problem, and have roots in some of the same people and ideas. And in recognising that, I suddenly realised that I had rediscovered a thought I had first had at a seminar I went to almost four years ago, where both approaches were represented, each largely talking past the other. Tom Steinberg, who spoke at the point of inflection between the two, memorably started by saying that he completely disagreed with everything which had been said in the first half, and that the solution to the problem of big blundering IT projects was to have small fleet of foot projects, not to find a cure for blundering. I reflected on the apparent tension then as I reflected today:
And then the penny dropped. The apparent gulf between the two parts of the seminar is itself the challenge.
We need to apply two different sets of disciplines (in both senses), in two separate domains:
An approach to the customer experience – both offline and online elements – which is flexible and responsive and which maximises its exposure to customer intelligence in order to do that An approach to the supporting processes which is robust, consistent and correctly applies the full set of rulesThe collective culture and skills of government are much more geared to the second than the first – and the risk is not just that we don’t do the first as well, but also that we can all too easily fail to spot the need to do it all. The first is where there is the greatest need for change, flexibility and responsiveness – and where tools and approaches are available to deliver that responsiveness. The second requires the hard grind of implementing big robust systems which do the transactional heavy lifting as invisibly as possible.
Of course the distinction isn’t an absolute one, and of course each domain needs to incorporate the key strengths of the other. But if we confuse them, we are at risk of getting the worst of both worlds.
My view has changed in the four years since then. I no longer think they are two different domains, they are aspects of what should be intrinsic in any approach (though scale and purpose will drive balance and relative importance). But perhaps there is a risk that big projects are still too much trying to learn the lessons of the last decade and too little trying to anticipate the needs of the next. It is no longer enough for systems to work (though they do, of course, absolutely have to work); they must work well, and work well specifically for the people who will use them. Or, as Helen Milner reported Mike Bracken as saying at another event yesterday:
That makes a lot of sense to me, though only if it is understood that in this context function is an integral part of beauty (as Brian Hoadley rightly challenged).
Conversely though, it is not enough to make beautiful things, though, perhaps less obviously but no less necessarily, they do need to be beautfiul. It is essential that they work and work well too.
Looked at one way, the core mission of GDS (and not just GDS) is to make beautiful things which work well. That means some of the values so apparent in the GDS event need to be more obvious in many other aspects of the work of government. We will have made great progress when discussions about projects in anonymous Treasury meeting rooms are more like the world of GDS. But as increasingly function begins to underpin beauty, it may also mean that the palest shadow of the Treasury meeting room also needs to fall across the sunny loft which is GDS.

One of the key tests of the success of GDS will be that when their turn comes to give an account of themselves in that room in Treasury, their approach is recognised and valued – and the work of every other project is being tested against it. And another key test may be that that room will be a bit less anonymous, with its own wall of post-its and whiteboards.
We can never be a normal user of our own services. We can temper that by being self-conscious in reflecting on our experiences as users of other people’s. But even that tacitly assumes that we are like normal users, other than in our expertise as providers of a particular service.
But that assumption may be badly wrong if in fact we are unlike typical users in ways which introduce the risk of systematic skews in our perceptions. And it’s a safe starting point to assert that if you are reading this, you are sufficiently abnormal that you should worry about that distortion (and if follows that I am so much more abnormal for writing it that I am almost certainly beyond hope).
The first step is to recognise that you can only have a personal appreciaton of the usability of a service by using the service.
I spent a great day on Friday visiting a local authority and talking about ways in which local and central government could work more closely together around service delivery, particularly for people we know will have to deal with both (or several) of us. They took me round their one stop shop, and showed me their plans for a newer and shinier one. It was truly impressive stuff. But there was a small voice in my head reminding me of my own experience a few weeks ago at a one stop shop as a resident in my own local authority which, as I reflected then, wasn’t bad, but wasn’t great either. It’s not that the voice was telling me it might not be as good as it looked. It was telling me that I would never be able to tell by looking.
In the early days of the web, the DTI (I am pretty sure it was) won an award for having the best government website. I understood why: it has a level of visual and structural clarity which was well ahead of the standard of the competition. Asked which government site deserved the prize, I would have awarded it to them too. Looked at without any specific purpose in mind, it was superb. But as I discovered when I had to look for something I knew was in there somewhere, it was much less good at meeting actual needs.
Even those who might be supposed to have an experience sufficiently close to the end user to have a reliable understanding of their experience can’t be assumed actually to do so. I wrote a few months ago about the difference between bus drivers and bus conductors which is one illustration of that point, but there are many more to be found wherever you look for them.
The second step is to recognise that whatever your experience as a user, you should not assume that your reactions are normal.
Designers and builders of services tend to assume that we are just like the people who will use those services, except that we have some specialist inside knowledge which gives us a slightly altered perspective. Having acknowledged that, we may – we should – go on to recognise that there are needs some users of the service may have which we don’t share. So we will think about accessibility and plainness of English (to say nothing of plainness of Welsh). But still we are tacitly assuming that while people may be at different points along a spectrum, there is only one spectrum.
I was helped to recognise the danger of that assumption a few years ago by hearing an account of a small qualitative research study into channel preferences, particularly the relative attractiveness of doing things online and by phone. It turned out that what everybody wanted was to be sure that the information they had provided had been correctly recorded and confident that action would be taken as a result. No surprise in that, that’s pretty much what I want too. For me, the conclusion is obvious: given that objective, an online transaction is clearly to be preferred. I can be completely clear about what data is being captured, avoid having to say, ‘no, that’s B for Bertie’ in increasingly exasperated tones and can be pretty sure that whatever system the organisation concerned has for doing whatever needs to be done next, it knows it has that thing to do. But for a lot of people, it turned out, the answer is equally obvious, and is precisely the opposite. Talking to a person gives you the confidence that the organisation has asked the questions it needs to ask, and as a result knows what it needs to know. Critically, it is felt to mean that responsibility for accuracy and completeness has been accepted by the organisation, whereas self-service data entry leaves an unwanted sense of responsibility somehow sticking to the user. And a human having accepted that the transaction is complete is more reassuring than any form of electronic confirmation.
Bruce Tognazzini has just published an essay on the apparently esoteric topic of whether the navigation of an iphone contacts list is better done by scrolling or searching. If that’s an important issue for you, it’s worth reading. If it isn’t (as it isn’t for me, since I don’t have an iphone), it’s worth reading anyway, as the core of his argument is much more general. It is in essence that some patterns of thinking are over-represented among those who design and build services, with a real risk that services so designed are optimised for people who think like them, not for a potentially much larger group whose mental model and heuristic preferences may be very different.
For all our bluster about how special we in high tech are, we really tend to think of ourselves as average—average intelligence, average likes and dislikes, average knowledge. We are none of the above. In fact, only one person in the entire world is average, and we don’t know who that person is.
Engineers (including programmers), he argues- are typically much more logical, much more abstract and better at rote memory than the rest of us. Unconstrained, that can have interesting results. Tognazzini takes as an example Steve Wozniak, one of the brains behind the Apple II:
[He] later developed the CL 9, the first programmable universal remote control. It featured the keys 0 through F, labelled with the standard Hexadecimal notation so familiar to everyone born with 16 fingers. It enabled you to capture and command 256 different codes spread across 16 invisible “pages.” You just had to memorize the page and position of all 256 of those codes and you could control everything! Woz and about three other people were able to make excellent use of the resulting product. Engineering, even genius engineering (and Woz was and is second to none), must be balanced with equally talented design.
So we need designers too. But that (shades of Officer Krupke) isn’t the whole answer either:
Graphic designers, left unchecked and unschooled, are likely to aim for maximum visual simplicity at the expense of both learnability and usability. Such interfaces require users to discover new capabilities by clicking around and seeing what happens. Users don’t do that. In the most extreme cases, functionality desperately needed by the majority of users may actually be removed from products in the effort to generate visual simplicity.
So it turns out that we also needs human-computer interface (HCI) experts, of which, of course, Tognazzini happens to be one.
The three professions, working together, with a healthy tension among them, produce good software and good products. That balance of power is critical to success.
But even that, of course, is not enough: we still haven’t got to the people who will actually use this service yet. So it doesn’t really matter whether you agree that a constructive tension between the three disciplines Tognazzini discusses is the optimal approach, the question is still whether the people who end up designing and building services are systematically dissimilar to the people who end up using them.
That’s not an argument that those professional disciplines are wrong or irrelevant: on the contrary, they are essential. Nor is it an argument about superiority: this is not a demand to dissolve the people and elect another. It is instead a recognition of the need to correct for skewed representation of different mental models. It is an argument that what seems most obvious may be most dangerous, because it may not be at all obvious to others.
So it’s not just that we aren’t the users, but that we may be too unlike them to understand the gap.
Small footnote: I know that ‘user’ is a controversial and imperfect word, but in the context of what is being discussed here it isn’t easy to find another one. I have argued elsewhere that ‘customer’ is generally the least worst word, but then and now I am not persuaded that it is a particularly productive debate.