Opportunities lost – AlphaGov

AlphaGov Homepage

I’m sure that many of you will have heard about the very worthy Alpha.gov.uk project, the first prototype of which was released earlier this month.

If you’re a user experience practitioner, this should particularly interesting to you.

By way of a quick background, the AlphaGov project was formed in response to findings from a report by Martha Lane Fox, Revolution not Evolution into Government online services and opportunities to improve. (As a tangent, I’d love to see her in a cagefight with Lou ‘The redesign must die‘ Rosenfeld)

In this report she recommended the introduction of

“a service culture, putting the needs of citizens ahead of those of departments”

The AlphaGov project responded, setting out two overarching objectives:

  1. To test, in public, a prototype of a new, single UK Government website.
  2. To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.

See. It doesn’t get more UX-interesting than that right? It reminds me quite a bit of the D7UX project I worked on with Mark Boulton and the Drupal community, so I’ve been following it’s progress with a keen interest.

Now, go have a play with the prototype and see what you think. I’m actually not going to comment on the UX of the prototype today, partly because it’s actually quite difficult to do so. I’ll get to that later.

What I want to talk about today is the responsibility that playing out a project like this in public brings with it and how, in my opinion, AlphaGov have let down both the UX and Inclusive Design/Accessibility professional communities.

What you do, not what you say

Let me start by saying that I have a lot of admiration for the the ambition of this project. There is a lot that is good about it. There are also a lot of smart and talented people on the team.

The first thing that strikes me as strange is that on a project that claims to have an obsession with meeting user needs, the team contains a visual designer and a content strategist, a general strategist and multiple search analysists but NOT a user experience lead.

That’s right. We have an obsession with meeting user needs but not so much that we’ll actually hire someone who has extensive experience in actually making that happen.

Now, the project was fortunate in that it had Richard Pope, who I first met when he was a very UX-savvy developer at Moo and who  played the Product Lead role on AlphaGov. As far as UX resources go, you could do a lot worse.

The team also recruited Paul Annett later into the project. Paul also has some UX experience but, as I understand it, his role was primarily as visual designer, making the interface a nicer place to be.

Without commenting on the interface itself, the lack of a rigorous approach to user experience is very evident in the way that the team talk about the work that they have done and their ‘design rules‘.

In a recent blog post about their agile methodology Project Manager Jamie Arnold describes exactly what this ‘obsession with user need’ entailed:

We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha’s report.

We ended those two weeks with a list of prioritised user needs (based around search analytics from Directgov, Hitwise and departments),

We roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom.

Crucially also there was a fair amount of @tomskitomski and @memespring‘s product experience. All this was more than good enough to get on with twelve weekly development sprints.

More than good enough, eh? For many projects this would have been more than they ever had to work with.

But this is not just any project. This is a groundbreaking, whole of government initiative that claims to take a User Centred approach and be obsessed with knowing and supporting the end user need.

I think a project like that needs to demonstrate User Centred-ness a little more rigorously. For example.

Who is the audience?

At no point that I saw did the AlphaGov team ever apparently think deeply about what kind of an end user they were going to prioritise. They talk about ‘thinking about who our users were’ and having a ‘user-base of all the entire adult population of a country’.

As User Experience practitioners we know that although you might want the whole country to use whatever you’re designing, you need to put a ring around the kind of users you MOST want to support.

As designers we always privilege some behavioural attributes over others, even if we don’t articulate it. By not thoughtfully articulating this, you risk either an incoherent approach to the experience design or resort to self-referential design (designing for your own behaviour – something that is incredibly difficult to overcome).

You can’t take a User Centred approach to design when your user is ‘Everyone’. You need to define who your users are. You must clearly identify the behavioural characteristics that you most want to support and focus on designing to best support these.

There are many valid design approaches that do not require such a clearly articulated definition of the end user, but these are NOT user centred approaches. Thinking generally about ‘users’ while we design is not doing user centred design. I think it’s pretty irresponsible to suggest that it is.

AlphaGov sends a message that you can say you’re doing User Centred Design but you don’t have to show any evidence of a UCD process – audience definition, research, user involvement, design principles that actually track to specific behaviour attributes.

For example, it would have been great to see some personas developed and shared for this project – even hypothetical ones that drew on the data/insight available to the team. As well as helping the team avoid the problem of the ‘elastic user’ (particularly problematic when you do think your target audience is everyone), it would also help us be better able to evaluate what is good and bad about the prototype. It would also have demonstrated that the team was actually practicing User Centred Design.

(Elastic user, for those not familiar with the term, was coined by Alan Cooper to describe the way that while making product decisions different stakeholders may define the ‘user’ according to their convenience, often resulting in self-referential rather than user-centred design. More here).

This leads us to one of the complexities of the AlphaGov audience which is that, in reality, rather then being obsessively user-centred, the project had two competing audiences. The largely undefined end user and, often more importantly, the stakeholders who would ultimately decide the fate of the project – public servants. These two audiences have VERY different motivations and goals for this project, and the impact of the latter on design decision making was never clearer than when the accessibility topic came up.

On Accessibility and a conflict of interest

Again, from what I know, there was no formal expert accessibility (or inclusive design as I prefer to call it) consultancy on the project team. This is not to say that the team didn’t have quite a bit of knowledge about the mechanics of accessibility (the impact of technical decisions on whether something could be certified ‘accessible’).

The team sets out a really thoughtful understanding of what it takes to make a service properly accessible:

Accessibility should start with research and consideration, not with box-ticking or sprinkling a few standard accessibility features – especially in a government context where a user journey regularly extends into the real world (Booking a driving test? You’ll probably want to know the facilities at the test-centre).

Ultimately, the AlphaGov prototype doesn’t make any significant attempt at achieving accessibility (particularly making a site that works fine even with JavaScript is switched off) apparently due to the short timeframes and ability to ‘retrofit’ accessibility later (hrm).

Actually, what I picked up from discussions about this on Twitter and elsewhere was that actually, it was the other target audience – the stakeholders – who most influenced this decision. If they put the focus on accessibility, they’d have to take away some of the ‘shiny’ – AlphaGov would end up feeling like Just Another Government Website. Rightly or wrongly, the shiny would help excite the public servants to approve and fund a beta version of the prototype.

Perhaps it was a noble sacrifice… who knows. Point is, it’s far from transparent.

The message that the world takes away from this exchange is that accessibility, even when your audience ‘entire adult population of a country’ is optional. And that accessibility can be ‘done later’ not, as they had first set out, built into design considerations from the outset.

These are really bad messages to be sending and, given how publicly visible and lauded this project is, sets the work of many amazing inclusive design specialists back considerably.

It’s hard enough to sell in good accessibility work already. AlphaGov just made it harder.

Activity Based Design and Search Analytics

OK. So I will talk briefly about the prototype… but mostly to discuss how the data you have access to can significantly shape your design.

The team have published very little information on the data that has guided their design decision making for this project but we do know that search activity has influenced it heavily. A team of sixteen people included no UX lead (sorry, did I mention that already?) but two people doing search analysis.

In the design rationale blog post, Richard Pope implies that search logs strongly influenced the design and information architecture strategy for the prototype.

we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make

Based on what we learned from looking at search-logs, we knew that there was a relatively small subset of tasks that require the majority of people need to interact with government online. So we should do less and focus on tasks.

Since for the vast majority of people their web journeys (finding out the date of the next bank-holiday, or reporting a lost passport) start with a search engine rather than a direct visit we should think of Google as the homepage and we should also feed Google, Bing and other search engines nice friendly urls.

If someone is just landing at a page on your site then it’s helpful to start thinking of every visit being a new user, assuming they have no prior knowledge of the structure or content website they have landed at.

It is really difficult to evaluate this prototype from a user experience perspective, given the competing target audiences. The best you can do is try to recall the last few times you interacted with a government website and try to reenact that here. Every time I do that I come away with a lingering feeling of disengagement. There’s something that search logs probably don’t really show which is that this is MY government. For better or worse, I have a long term and multifaceted relationship with this government and yet, every time I encounter this site it (by design) makes me feel as though this is my first visit. I find that really unsatisfying and kind of perturbing.

Now, this is not a professional design critique, this is a qualitative research data point of one. But it’s not something that you’ll ever pick up from search stats and analytics. I could bore you further with how I find the promise of localisation with this infinite noob status even more perplexing, but you’d have to spend time with me to understand it. And then spend some time with a bunch of other people to see if this is a common theme or just me being an edgecase.

And people will never post this kind of feedback on GetSatisfaction. (Most people can’t really articulate this kind of weird feeling and wouldn’t think that it was important enough to comment on compared to, say, a bug. You need a good facilitator to extract this kind of data).

To do really good user experience design you need a mix of data points. If you privilege one set of data, you’ll see that in your design. I think we’ve got some of that going on with AlphaGov.

Quantitative data is fantastic. I’d love to see more of what the team had to work with and how they applied it in their design process. But it’s just one kind of input. Qualitative research helps you better understand your end users and thereby to design better for them.

People who do User Centred Design do Qualitative Research.

User Experience is a Time Soak/Non-Agile

Which leads me to the final problematic sub-text that I felt emanating from the AlphaGov team which was essentially that ‘we’re as user centred/accessible as we can be given that we only have 10 weeks to build this thing’. This perpetuates the myth that User Experience can be a time soak, that it slows you down, that it doesn’t really have a place in an Agile methodology.

This is where having an experience UX practitioner on the team from early on could have been helpful.

It is certainly true that historically, Agile and UX have had a fairly vexed relationship but these days many practitioners are experienced and adept at including both user research and ux design into the most demanding agile iterations. We have a toolkit of lightweight qualitative research approaches that work beautifully in this kind of fast paced and responsive environment. UX does not have to be a laggard either at the outset or in the throes of an agile project.

The ten week project timeframe is absolutely no reason to not include real practice of user experience in the process. You may need to find someone who has experience working this way (not all UXers find this kind of project much fun), and you may need to be creative in the way you structure the work, but you should definitely be doing it. Particularly if you’re setting an example of how projects should be done, as the AlphaGov team certainly was.

In conclusion

I want to repeat again, this is a very worthy project and many of their design principles are, I think, sound. For many commercial projects, the methodology that they’ve applied and shared is absolutely appropriate. But the bar is set higher here.

By doing this project in public, by making such a big deal of putting the end user needs and their importance to the project, the AlphaGov team have set themselves up as rolemodels. They’re sending messages about the the way things should be done. They’ve made quite a rod for their back.

If I was just a member of the community, I’d probably be nothing short of delighted with what they’ve achieved. Unfortunately, as a User Experience practitioner, I feel kind of glum. This project has talked the talk of caring about the end user, of placing their needs at the centre of the project and above the needs and desires of government, but at every step, they’ve done little to set a good example for how others should actually do this.

I hope AlphaGov does move forward into BetaGov.

But I hope, if they do, they take a moment to think about what the public performance of AlphaGov and then BetaGov means for their professional community.

Either stop calling the project User Centred, or hire someone to really focus on user experience and do more to share how they’ve integrated real user insight into their design strategy and implementation.

There’s a big opportunity to set a good example to a big audience here. Let’s take advantage of that opportunity and show the UK Government, digital industry, hell, the whole world what projects really look like when they’re user centred, – that they don’t have to be cumbersome, expensive and slow.

Imagine that, a properly user centred government website that was agile, and shiny and amazing. Now, that’s something to get excited about.

Drupal contributor sentiment survey

As you may know, I’m working with the Drupal community on a (voluntary) Social Architecture Project called the Prairie Initiative.

We’re looking to tune up Drupal’s collaboration tools so that it’s an easier, more efficient and more collaborative place for all the different disciplines that Drupal needs to be great.

If you’ve got any experience attempting to, considering or actually contributing to Drupal, I’d really appreciate if you’d come take our sentiment survey. We’re taking a benchmark now and will check back every quarter to see if and how any changes we make impact this and some other metrics.

Much appreciated.

UX Survey – what we care about when we’re taking a new job

I’m taking a couple of surveys to explore our priorities and experiences hiring and being hired as UXers.

If you’re a UXer: Come tell me what you think about when you think about taking a new job.

If you hire UXers:  Here’s a survey for you

This came out of an interesting exchange on Twitter the other day with a colleague who posted a Tweet about job opportunities at his company and promoting the opportunity to work on big brands if you worked with him.

He also has an awesome team working with him. I suggested to him perhaps he should be promoting that as well or instead.

I got to wondering (again) how how other people saw the world – what was important to UXers when they were thinking about a new job and what the process was like for finding, interviewing and taking a new job.

Being a good UXer, it was only logical to take the next step and do some research.

I’ll collate the results and share them back in a few weeks.

Thanks!

Designing for illiteracy – a mass market accessibility challenge

I was in Chicago the other week and out with a friend who has multiple, severe dietary allergies. She can’t eat dairy, eggs, wheat, and a bunch of other stuff. Eating out is a bit of a pain for her but, if she doesn’t get it right, a whole lot more pain later.

We were in one of those posh grocery stores with its own little cafe and, after much deliberation, decided what to eat. The girl who was taking our order had a desk that was positioned in a way that made it easy for me to look over her shoulder at the interface she was using to take the order.

Taking a standard order was pretty easy – you just pressed the button that said ‘thai chicken salad’. Simple.

Then it came time to take my friend’s order. First she had to press the button that said ‘thai chicken salad’ and then my friend asked that she make a special note for the chef about her allergies. To do this, the girl had to press the notes button and then type the special request in. No assistance from the UI whatsoever. And that’s when the trouble struck. Spelling.

Without wanting to ridicule her – she failed to spell ‘dairy’ even to the point that you might guess what she intended. There was no way she was ever going to accurately convey my friends requirements to the chef. I watched, quietly, as she tried and failed to type the instructions and eventually sent the following note through to the chef:

‘eg’

Here’s the thing. Our order taker is far from an edge case. Jonathan Kozol has written extensively about illiteracy in the US (and there are similar problems in many parts of the world). He says:

Twenty-five million American adults cannot read the poison warnings on a can of pesticide, a letter from their child’s teacher, or the front page of a daily paper. An additional 35 million read only at a level which is less than equal to the full survival needs of our society.

Together, these 60 million people represent more than one third of the entire adult population.

The largest numbers of illiterate adults are white, native-born Americans. In proportion to population, however, the figures are higher for blacks and Hispanics than for whites. Sixteen percent of white adults, 44 percent of blacks, and 56 percent of Hispanic citizens are functional or marginal illiterates. Figures for the younger generation of black adults are increasing. Forty-seven percent of all black seventeen-year olds are functionally illiterate. That figure is expected to climb to 50 percent by 1990.

Fifteen percent of recent graduates of urban high schools read at less than sixth grade level. One million teenage children between t velve and seventeen percent cannot read above the third grade level. Eighty-five percent of juveniles who come before the courts are functionally illiterate. Half the heads of households classified below the poverty line by federal standards cannot read an eighth grade book. Over one third of mothers who receive support from welfare are functionally illiterate. Of 8 million unemployed adults, 4 to 6 million lack the skills to be retrained for hi-tech jobs. (more here)

This is a big problem. This is not an edge case. And, before you say it, the answer is not icons. (The number of times people have told me that the solution to designing for an illiterate audience is icons. Now make me an icon for ‘vegan’).

I don’t have the solution, but I do have a couple of guiding thoughts.

  • People are better at recognising words than they are at making them from scratch. My 3yr old can recognise words in books that he is familiar with but he can’t read (no matter what he tells you). This is true for all of us. Recognition is far easier than recall. Think about foreign languages – most of us can read a lot more than we can speak, right?
  • Think about mission critical tasks. Things that, if not done right, could hurt people or have significant negative impact on people or business. Don’t give people a blank box to fill in when you’re designing these tasks. Give options (in words, not icons). Let people recognise and select, don’t make them remember how to spell stuff.

Jan Chipchase has done a lot of design research work with Nokia in the area of device design for illiterate end users and supports the view that making the interface easy to ‘learn’ (which largely means ‘remember’ for people who are less literate), is the best approach – better than icons or audio menus or all other apparently obvious solutions.

This presentation is worth a flip through if you’re interested in his experience and outcomes.

 

None of this is new, granted. But it’s not something I hear us talking about anywhere near enough. Watching that poor girl struggle with that interface and because of the poor design put my friend’s health at risk was a real wake up call and reminder to me of how wide-spread and significant this issue is.

I’m resolving to be more aware of this in the future and I hope you will to.

(And, if you’re in the UK, consider signing the Save Bookstart petition – this invaluable service puts books into the hands of young children – having books in the house in childhood is a key indicator of later literacy).

Page 5 of 155« First...«34567»102030...Last »
smålån