Public Strategist

Things which caught my eye elsewhere on the web

• Don’t forget who you are working for « We Love Local Government In both cases the assumptions I made, as a fairly IT literate individual was that a) people would share my belief that digital is better and that b) people’s spending habits would reflect this. In fact I was wrong.
• Stumbling and Mumbling: Child benefit, ideology & bias But cognitive biases aren’t something which ignorant citizens have and which wise governments are free of. Policy-makers are also prone to them – either because they are as irrational as everyone else or because they have to pander to an irrational electorate. One of my big complaints against Nudge is that it fails to appreciate this sufficiently, and so panders to the ideological fiction that policy-making is or can be entirely rational and evidence-based.
• “Digital memorials for mass graves” – Jim Kosem at London IA When thinking about designing a digital monument, Jim explained that your main competition was basically big lumps of concrete that tended to last for hundreds of years. That is quite some competition for software, he argued. We really don’t have a good track record of software ageing.
• It’s all about the words | Government Digital Service We will be ‘designing for the common case’. That means we will take information that affects most of our users and putting it up front. If you are an edge case or exception – perhaps affected by something that only affects 100 people in the whole of the UK – then your information will still be there – it just won’t be in the first paragraph.
• Why Facebook doesn’t have or need testers | ZDNet By paying less attention to quality, Facebook has been able to focus on other things, like making the company a fun place to work at that can attract and retain talented engineers. Facebook would probably be less fun if it cared more about quality. Facebook’s product is a website, so it can fix things quickly. It has a process which permits rapid deployment of new code, and rapid rollback of buggy changes. This reduces the cost of recovering from bugs.
• The discipline that dare not speak its name « Martin Howitt’s blog We started strongly and soon had a very elegant programme for exploiting the organisation’s resources to drive higher productivity, better outcomes and lower costs. But no-one was interested. I now believe this wasn’t because people disagreed with it, it was because people didn’t understand it. And I think that has more to do with demographics than anything: there are still a large number of people at or near the tops of big organisations that have a blind spot when it comes to anything new: they can’t cope with big paradigm shifts and clever methods changing the way business is done.
• What is ‘Information Architecture’? | Help | guardian.co.uk In the end, however you try and define it, information architecture boils down to consciously organising the content and flow of a website, based on some principles that can be articulated, that have been derived through evidence gathering.
• Customer Experience v User Experience | disambiguity Given the choice of having a Chief Experience Officer (CXO from a UX background) or a Chief Customer Office (CCO from a marketing/CX background), I’d probably choose the latter – for the more comprehensive, well rounded view of the organisation and all its working parts than the interface obsessed UXer is likely to be. And I’m more confused about where Service Design fits into all of this than ever.
• Leader vs. Loser – GovLoop – Social Network for Government Leaders may have different styles but one thing about them is always the same: They act as if they own the situation, whether they actually do nor not.
• Elegant Code » Agile’s Coming of Age We know good and well that we can’t predict the evolution of a software project beyond a few months in most thriving businesses. Change just happens. Why then do we persist in thinking Big Funding Up Front is any different than Big Design Up Front? Some are making inroads with models of T&M funding, fixed cost, adjustable scope, and other techniques like incremental funding. However, for the most part we remain stuck in annual funding models because business Agility, the real promise of Agile, remains elusive.
• Scroungers – honestlyrealThink of the coastline. Yes, another line. Isn’t it? It’s obvious where it lies. One side land, the other sea. Now look more closely. Still sure about that? Still confident that you can draw, with perfect accuracy, a boundary between the two? One that doesn’t shift faster than you can study it? One in which every crevice, nook, cell and grain can be defined as being on one side or the other. Of course you can’t. The coastline is a great theory, but a poor reality.
• Fixing Twitter (Robert Brook) Interestingly, it Twitter is fixed for me, it might not be great for the money people. And if it’s fixed for them – which seems to be the direction things are going in now – then it might be more completely broken for me.

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

• 24 ways: Extracting the Content The first question is, how are you going to design something to ensure users have the easiest access to the best Content, if you haven’t defined at the beginning what that Content is?
  
• Corporate hubris – and a bit of festive cheer | Flip Chart Fairy Tales Corporations are made up of people. People sometimes do bonkers stuff. Furthermore, large organisations are almost impossible to control. Therefore people continue to do bonkers stuff. Business leaders just have to do their best to minimise the effects of the bonkers stuff and hope that some of it leads to good stuff. And, of course, the business leaders sometimes do bonkers stuff as well.
• Can’t get no satisfaction: Why service companies can’t keep their promises « Dachis Group Collaboratory For example, consider the way that Amazon balances front stage and back stage operations. Amazon’s front stage is its customer-facing website. Amazon can expect that the level of change on the web is likely to remain volatile for some time. Constant innovation in online services will cause customer expectations to evolve accordingly. So it makes sense for Amazon’s web-development approach to be highly adaptive and flexible, with lots of room for creative experiments and innovation.But radical, disruptive innovations on the fulfillment side of Amazon’s business are less likely. It’s reasonable to predict that customers will continue to want fast, efficient delivery; and that warehousing, shipping and logistics, because they involve large investments and existing physical infrastructure (ships, trucks, planes, railroads and so on), won’t change anywhere near as rapidly as online services. So it makes sense for Amazon to focus on reducing variety through standards and controls in its back-stage operations, while maintaining maximum adaptability on its front stage with customers. And indeed, Amazon web developers have a very different work experience than workers in an Amazon distribution center, although the company’s cost-focused, thrifty culture is in evidence throughout.
• Disaster book club: What you need to read to understand the crash of Air France 447 – Boing Boing When there is inherent risk in using a technology, we try to build systems that take into account obvious, single-point failures and prevent them. The more single-point failures we try to prevent through system design, however, the more complex the systems become. Eventually, you have a system where the interactions between different fail-safes can, ironically, cause bigger failures that are harder to predict, and harder to spot as they’re happening. Because of this, we have to make our decisions about technology from the position that we can never, truly, make technology risk-free.
• Design strategy for the changing web :: Blog :: Headshift Accepting that we cannot always predict the next advancement in mobile or tablet technology, we can create solutions tailored to existing technology and devices that remains flexible enough to adapt to innovation ahead.
• Programming should take pride of place in our schools | Technology | The Observer What governments don’t seem to understand is that software is the nearest thing to magic that we’ve yet invented. It’s pure “thought stuff” – which means that it enables ingenious or gifted people to create wonderful things out of thin air.
• Schneier on Security: Walls as Security Theater What a wall satisfies is not so much a material need as a mental one. Walls protect people not from barbarians, but from anxieties and fears,which can often be more terrible than the worst vandals.
• Agile and UX are “an abusive relationship” – James O’Brien at UX People James recommended that UX lie, cheat and steal to cope with being in an agile environment. His examples included lying about what something was called – i.e. a paper prototyping session could be described as a “UX spike”. Or cheating by making sure that test data is specifically designed to stress the UI and reveal flaws that have to be fixed. Or stealing concepts from agile, like using the phrase “UX debt” to describe sub-optimal solutions that have been deployed as “good enough”, but which need to be re-addressed in later iterations.
• Mark Zuckerberg says the email’s end is nigh. LOL | John Naughton | Comment is free | The Observer Organisational addiction to email has long since passed the point of dysfunctionality and now borders on the pathological, with employees sending messages to colleagues in nearby cubicles, people covering their backs by cc-ing everyone else and managers carpet-bombing subordinates with attachments. The real problem, in other words, is not that email is dying but that it’s out of control.
• Public sector innovation must move from Strategy to action « MindBlog The question is not whether innovation is needed, but rather how we will choose to approach the task of innovation. So what key considerations must a public sector innovation strategy include if it is to make a difference?
• Why public services are built around the behaviour of our grandparents | Local government network | Guardian Professional The place to start is by increasing our understanding of how people in 2011 live their lives. It’s fair to say that, at the moment, we have a limited understanding of what our residents do at home – how they access their work, leisure, and recreational activities.In fact, we make a whole host of assumptions and broad generalisations based on historical patterns of understanding. The way we provide leisure services has changed very little from the way councils up and down the country would have provided such services to our grandparents, possibly even our great grandparents, despite the fact that the way we keep fit bears little resemblance to how people behaved in the early 20th century.
• Clear Reporting & Critical Thinking: Why User Experience Needs to Remember its Roots in Psychology You shouldn’t rely on soundbite articles to tell you why other soundbite articles are wrong.
• An Extensive Guide To Web Form Usability – Smashing UX Design A form is a conversation. And like a conversation, it represents two-way communication between two parties, in this case, the user and the organization. In fact, the user has filled out the form in order to initiate communication with the organization.
• Establishing trust in digital services | Government Digital Service But most of all we need to develop identity services around the needs of users – if we don’t then people will not trust or use them. Many people have described this subject as ‘identity management’. That is an organisation centric phrase: a notion that organisations hold data about people and have the responsibility for maintaining it. We have to reset the subject around the user and recognise that in the digital age people assert identity in many different ways and contexts.
• Seth’s Blog: There’s nothing wrong with having a plan Plans are great.But missions are better. Missions survive when plans fail, and plans almost always fail.
• The Social Graph is Neither (Pinboard Blog) You might almost think that the whole scheme had been cooked up by a bunch of hyperintelligent but hopelessly socially naive people, and you would not be wrong. Asking computer nerds to design social software is a little bit like hiring a Mormon bartender. Our industry abounds in people for whom social interaction has always been more of a puzzle to be reverse-engineered than a good time to be had, and the result is these vaguely Martian protocols.
• Knowing and Making: Does Nudge require regulators to be “more rational” than consumers? Somebody who spends their professional life thinking about decision-making and examining the extensive research in this field is likely to be able to help me make decisions that I’ll be happier with.
• Social For Internal Comms – Social Media Workplace | redcatco blog A strong theme through out the day was: Problem first. Technology second. It’s all too easy to say “social technology is the answer. What was the problem?” – be pragmatic, and start with a well defined problem was the wise advice.
• Bryan Clark » Blog Archive » Negotiate with your users A useful dialog would negotiate with your users. Give them actions and power to change their situation. Don’t ask users to acknowledge your troubles and stop the negotiation there. Reconnect! Try Again! Even simple actions can help people correct the situation.
• Piloting new ways of measuring digital success | Government Digital Service Because of the nature of the Jobseeker’s Allowance service, pages are delivered up to the user in a dynamic fashion. This means that there is essentially no concept of ‘a page’ and instead questions are presented to users based on their previous inputs and answers. This is fine from a user perspective but it causes problems when it comes to gathering and interpreting behavioural data.In essence, there is no ‘hook’ within the data for orientation. You cannot assess where people are within the journey or at what stages they drop out because all of the URLs are dynamically generated. Looking for patterns in behaviour is therefore meaningless because each user journey is completely unique.
• Haakon Halvorsen, Kjetil Hansen & Anna Dahlström at EuroIA 2011 Haakon and Kjetil went on to explain what a challenge it was to make banking “fun” visually. For most people, online banking is a necessary evil, not an exciting web destination. To impress the client, though, they showed lots of mock-ups of how the site could be, complete with plenty of polish and drop-shadow. Banking will be fun, the designs shouted.
• Nick Bradbury: Tiny Apps are Hard Regardless of whether I stick with mobile development, the lessons I’ve learned from it are ones I’ll apply to everything I create in the future. Keep it simple, keep it uncluttered, and keep it focused. That’s how you create great apps for any platform.
• If Steve Jobs did government… | Blog As we have argued in our policy making work, this is often the missing link in government – where we assume that policy concepts translate seamlessly into delivery – without putting in the effort to make sure that the policy is deliverable by the people who need to deliver it. That means prototyping, testing and insisting that things work before they are unleashed on a waiting public. It also meant an insistence on excellence with which people who run government feel naturally uncomfortable.
• In The Eye Of The Storm: AlphaBeta.gov … But transactions are where it’s at. We built the government gateway to support both single transactions and joined up transactions (that is, ones that would link more than one department and send each of them the relevant data. The vast bulk of those transactions come from sites other than direct.gov; the vast bulk of direct.gov’s transactions are for Car Tax. That all needs to change. We didn’t ever crack it. It needs cracking – integrated transactions, simple pan-device (and even pan-channel) authentication, pre-population of data that government already knows about you and so on.
• You shape your intranet. Thereafter, it shapes you. « Sharon O’Dea As on the Internet, so in the enterprise. In its infancy, it’s the organisation that shapes the intranet, designing it around the needs of internal users. Or at least, that’s the theory. In truth, organisations get the intranet they deserve, with flaws and compromises and sometimes just bad decisions.But thereafter, it’s the business that has to live with this, and it’s the people within it who have to suffer the consequences. The decisions you make at the design stage will affect the way employees work every single day, for years.
• NESTA – Designing beta public service Though it may seem like semantics, just think about it for a moment: what impact might a ‘beta ethic’ bring to how we currently design and develop public policy solutions and services? How might it help to overcome some of the challenges governments face when trying to innovate, such as an aversion to risk and public criticism? How different the engagement of public citizens and professionals, when a beta version is launched first?

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 rules

The 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:

Will channel shift save money? Yes. How? By making beautiful things says @MTBracken #DigiLeaders

8 December 2011 10:42 am via HootSuiteReplyRetweetFavorite

@helenmilner

helen milner

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.

Pictures by Paul Clarke

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.

The burial of human remains at sea requires a marine licence.

That must be one of the more arresting first lines of any government web page. Its combination of human tragedy and bureaucratic process packs a lot into eleven words.

You won’t find that line, or anything else on the subject, at Directgov. That’s neither surprising nor perhaps unreasonable. Very few bodies are buried at sea – exact numbers are hard to come by, but estimates are in tens a year, a tiny proportion of the half million or so deaths each year in the UK.

The line instead comes from the website of an organisation little known, I suspect, to non-specialists, the Marine Management Organisation, the core purpose of which has little to do with the disposal of corpses. But getting a licence for burial at sea is without doubt a government service directed at individuals, so in principle it should be found where other such services are to be found, which in the not too distant future means the single government domain. I have no imminent expectation of finding it there (and make no criticism that it won’t be). But it is worth asking why that should be and what it tells us about government more generally.

Back in the early days of e-government, there was a target to get all government services online. Increasing the numerator would help achieve the target, but then so would decreasing the denominator. Creating a definitive list of relevant services was the only way of preventing a percentage score from drifting about uncontrollably. Burial at sea was often the example used in the largely pointless debates which ensued. It was a good example, because it brought together two separate issues:  was this a service which anybody was every likely to want to do online; and were there enough of them to justify putting it online at all?

Entirely expectedly, government information and services follow a Zipf distribution, made famous by Chris Anderson in The Long Tail (but applied to websites at least as early as 1997): there is a small number of things which get an enormous amount of attention, and there is an enormous number of things which get a small – sometimes a vanishingly small – amount of attention. Two lessons are often drawn from that: one good and one potentially very bad.

The good one is that there is great value in identifying the things which most people want to do most of the time, and ensure that they can do them easily and efficiently. The potentially bad one is to assume that the rest doesn’t matter and either ignore it or delete it.

In the physical world, it is more or less essential to cut off the distribution.  A good bookshop won’t just rely on best sellers, but equally there will be a limit to the number of titles it can stock which only sell one or two copies a year. Amazon, with warehouse fulfilment, can do much better than that, and it has been estimated that 37% of their revenue in 2008 came from sales of books ranked below 100,000.* It would be supreme folly for Amazon to announce one day that they were rebuilding their web presence and would henceforward only cover the top 100,000 titles.

Government is not Amazon. Web pages are not books. Analogies are flawed. And yet.

The question of how the government’s web presence should be culled and curated is not a new one. It has been around in various forms since the earliest days of e-government, documented perhaps most clearly and consistently by Alan Mather. At least as far back as 2003 (and actually well before then)  he had a strategy which looked uncannily like that of  the single government domain:

• Fewer websites not more. Kill 50 websites for every new domain name.
• Less content not more. Delete five (or fifty, or five hundred) pages for every page you write.
• Solve the top 50 questions that citizens ask … and structure your content around those first. Then do the next 50 and the next. The people who know these questions are the ones that answer the phone in your call centres, the ones that write in to your agency and the ones that visit your offices for help; likewise, they visit accountants, advice bureau, charities and so on.
• Test search engines to see how your site ranks – both from a mindshare side and for individual queries.
• Impose rigorous discipline on use of “words” – plain speak.
• Impose even more rigorous discipline on the structure of the content, including metadata so that it’s easy to read – by people and by search engines.

Or in other words, start at the top of the Zipf distribution, and work systematically along until you stop. Tom Loosemore has a pithier version which means much the same:

'Every superfluous page we create is one more dead end for an angry, frustrated, confused user ' - @GovUK team seeking the irreducible core

6 September 2011 10:26 am via twiccaReplyRetweetFavorite

@tomskitomski

Tom Loosemore

Taken as expressed, it’s hard to disagree with the approach Tom and his team are taking. But a great deal hangs on the word ‘superfluous’. In this context, I think it is being used to mean two quite distinct things, but risks treating them as one. The first is rot, decay and duplication. Too much money is being spent very inefficiently to maintain – or all too often to fail to maintain – information which is poorly organised, hard to find, badly maintained and structured round what organisations do, not what people need. The second is obscure specialisation: there is a vast amount of information which most people don’t want or need and won’t ever want or need, and its existence makes it harder for the important stuff to shine through.

Focusing on an ‘irreducible core’ is a very good way of tackling the first problem, but risks overlooking the second. Whether that is a bad thing is a contingent question which is not inherently an easy one to answer, and which potentially raises some awkward questions about the singularity of the single government domain. There are three basic options:

1. Everything goes into the single pan-government site
2. Popular and important stuff goes into the single pan-government site and the rest goes somewhere else
3. Popular and important stuff goes into the single pan-government site and the rest doesn’t go anywhere

To an extent this is (or can be made to be) a matter of timing – pursuing Alan’s idea of tackling the problem in fifty-question chunks. But even with that approach, sooner or later we get to the question of whether enough is enough. In order to know that, we need to understand two things.  The first is the value to users of the long tail  – government’s version of Amazon’s 37%. If it is high, or to the extent that it is high, the choice is between options 1 and 2. Neither is entirely attractive: option 1 risks compromising the quality and clarity of the much smaller set of key services; option 2 creates a messy boundary and breaks the principle that there is one place to go. If though the value to users of the long tail, or some furthest reach of it, is relatively low, the choice is between options 1 or 2 and 3. And if option 3 is even to be considered for some subset of information that might otherwise have been included, that raises a very big question.

Luckily, GDS is full of exceptionally smart people (and now even fuller) and better still, they have invented the needotron. That’s the right systematic approach – but I will be fascinated to see whether they find a way of creating the right long tail, and of stopping the tail being so unwieldy that it trips up the dog.

*These numbers are hard to make intuitive sense of. Amazon are currently claiming to have ‘over 750,000′ books available for the kindle, which sounds like more than enough for anyone – yet I regularly find that the books I actually want to buy are not among them.