Last week we asked what improvements you’d like to see on TheyWorkForYou. Thanks so much for all the comments on that post (do keep them coming). They’ve all been carefully documented on our development list.
Our standard way of working on a project like this is in ‘sprints’ – short periods of activity after which we can spend some time reflecting on what went well, and what could have gone better.
This system is great for ensuring that we don’t get involved in a large piece of work, only to realise that it doesn’t do what was intended, or hasn’t had the desired effect. So, for example, if we’ve added a new feature, we might be asking ourselves, ‘Is anyone using it?’, ‘Have there been any bug reports?’, and ‘Has it fulfilled our original aim?’. We’re striving to be as analytical and methodical as possible about these assessments, so part of the process has also been figuring out which types of metrics to collect, and how.
That said, what have we already done?
It’s easier to find a specific representative
Where previously our pages listing all MPs, all MSPs and all MLAs just contained one very long list of names that you had to search or scroll through, there’s now an A-Z navigation at the top. We also added the ability to find your own MP from this page.
Why? This is an example of a small usability tweak which should make a difference to a large number of people – not everyone knows how to search a web page with Ctrl+F. It’s also a fix that’s been on our to-do list for two years!
The addition of the ‘find your MP’ box helps to serve one of our core aims: to make democracy easy to understand for the uninitiated.
We’ve added ‘like’ and ‘follow’ buttons
We thought you might not notice these discreet additions to our page footers – but we’ve certainly seen an upturn on the rate at which people are ‘liking’ our Facebook page. Whereas Twitter – not so much. Maybe TheyWorkForYou users are just more Facebook-inclined?
Why? In part, this addition is for our own benefit – we welcome the opportunity that social media gives our users to spread the word. As a small organisation with no advertising budget, this kind of grass roots promotion is invaluable. Then, we are hoping that it will help us to understand our users. Clicking that ‘like’ button can be seen as a form of positive affirmation and enagement that it’s very hard to quantify by other means.
We are still considering the addition of buttons which would allow you to share specific debates with your social circles.
We have noted the comments on our last post which made it clear that some of our users do not welcome integration with social media. That’s fine – we’ll never do anything that excludes you from the core activities of the site, whether you use Facebook and Twitter or not – our intention is simply to provide the functionality for those who want it.
Those comments have been a useful reminder to us that we should continue to consult our users, because we can’t always predict what you might object to!
You can change your email address
If you have an account, now you can change your email address yourself.
Why? This was identified as a common request that often puzzled users, and took up support time on our side.
MPs’ pages will look better
You can’t see these yet, because they’re still in progress. Due to some quirks of the code in which the site was originally built, the new design for the MPs’ pages has taken longer to implement than we’d anticipated. But we’re getting there.
Why? MPs’ pages contain an awful lot of information, from voting history to recent appearances, and more. The redesign will help us present all this information more clearly, making the page just as easy to read on a mobile device as it is on a desktop, and simply bringing the (frankly, dated) pages a more current look.
Bullets are bullets
This is almost ridiculous, but we think it was worth attending to. In recent user tests, we noticed some confusion, caused by the fact that our bullet points were in the form of small squares – they were frequently mistaken for check boxes.
Why? Just to rid the world of that one small piece of frustration that occurs when you try to tick a box that is not, in fact, a checkbox.
As I say, we are still actively collecting and working on your feedback, so please do keep it coming. Comment below this post, or drop us a line on firstname.lastname@example.org. I’ll be reporting back after our next sprint.
Photo by William Warby (CC)
Put yourself, for a moment, into the shoes of a manager in a big public sector organisation, in almost any country in the richer parts of the world (well, except Norway, maybe). Times are tough. Budgets are shrinking. And yet some annoying nerd from the corporate web team keeps nagging you about the fact that the organisation’s website and social media usage are not up to scratch.
You sigh. How can they not get it? Last year you had to serve a million people with £x, and this year you’ve got to serve 1.1 million with £x minus a lot. You’re desperately trying to think of ways to avoid serving extra people with services that you already can’t afford. You’re tightening eligibility, closing branches, laying people off, shortening hours.
And yet this annoying ‘webmaster’ person keeps saying how important it is to make your site easier to use. Don’t they understand that ideally the site would be virtually impossible to use? Don’t they know that most big IT projects turn into massive black-holes for money anyway? And how can they not see the obvious truth, which is that we should leave the stupid website well alone until the good times return?
Seductive logic but the wrong conclusion
This seems like a pretty open-and-shut argument. If you want to spend less, why on earth make it easier for people to ask you for more services?
But as seductive as this argument is, it’s also wrong. Here’s why.
1. Using bad design to limit demand is a way of guaranteeing that you spend more of your money on the people who need it least. Skilled computer users can get past all the hurdles and pain points created by bad digital services. Those people also tend to be the richest and best educated people in society. So bad digital service design is a filter that almost guarantees that you’ll be serving the people who need your services least. And you still want next year’s budget renewed, do you?
2. It creates unnecessary costs that will keep rising as times get tougher. If you can’t effectively use digital channels to explain what you do and don’t offer people, then those people aren’t all going to vanish. In fact most of them will persist. And once they find it impossible to use your digital channels, they’re going to phone up, then send you letters and emails, then visit your offices and perhaps even complete entire application forms that you’ll have to process and reject. That’s all a lot more expensive than a simple, well written, easy to find page that says what services are and are not offered, and to whom.
3. You’re missing a fantastic chance to generate empathy from the public. Public servants often complain that the public doesn’t understand the constraints and compromises that have to be made when delivering public services. But what better time and place to explain about limited budgets and hard choices than when someone is trying to access a service that cannot be provided? High quality digital services are a fantastic platform to explain these dilemmas. I would love to see councils using comments on FixMyStreet and FixMyTransport reports to say – in public – that ‘we can’t afford to fix this’. From that clear, accessible confession, we could all benefit from a wider public debate about why services are being limited.
4. Bad design makes people think you’re lazy and incompetent, not that you are making hard, difficult choices with limited budgets. When I try to buy a book on Amazon and it’s out of stock, it doesn’t just crash, or give me false information, or become unusable. Instead it says sorry and I say ‘oh well’ and move on. If Amazon lied to me about the stock, or became impossible to use, I’d think it was run by a bunch of incompetents. It would not cross my mind for a nanosecond that this was a bold, difficult choice made by people managing tough problems.
Tom Steinberg is the director of mySociety, and a consultant at mySociety ltd, our subsidiary that aims to help our clients serve the public with brilliantly simple online tools.
Photo by Alan Levine (CC)
Simple things are the most easily overlooked. Two examples: a magician taking a wand out of his pocket (see? so simple that maybe you’ve never thought about why it wasn’t on the table at the start), or the home page on www.fixmystreet.com.
The first thing FixMyStreet asks for is a location. That’s so simple most people don’t think about it; but it doesn’t need to be that way. In fact, a lot of services like this would begin with a login form (“who are you?”) or a problem form (“what’s the problem you want to report?”). Well, we do it this way because we’ve learned from years of experience, experiment and, yes, mistakes.
We start off by giving you, the user, an easy problem (“where are you?”) that doesn’t offer any barrier to entry. Obviously, we’re very generous as to how you can describe that location (although that’s a different topic for another blog post). The point is we’re not asking for accuracy, since as soon as we have the location we will show you a map, on which you can almost literally pinpoint the position of your problem (for example, a pothole). Pretty much everyone can get through that first stage — and this is important if we want people to use the service.
How important? Well, we know that when building a site like FixMyStreet, it’s easy to forget that nobody in the world really needs to report a pothole. They want to, certainly, but they don’t need to. If we make it hard for them, if we make it annoying, or difficult, or intrusive, then they’ll simply give up. Not only does that pothole not get reported, but those users probably won’t bother to try to use FixMyStreet ever again.
So, before you know it, by keeping it simple at the start, we’ve got your journey under way — you’re “in”, the site’s already helping you. It’s showing you a map (a pretty map, actually) of where your problem is. Of course we’ve made it as easy as possible for you to use that map. You see other problems, already reported so maybe you’ll notice that your pothole is already there and we won’t have wasted any of your time making you tell us about it. Meanwhile, behind the scenes, we now know which jurisdictions are responsible for the specific area, so the drop-down menu of categories you’re about to be invited to pick from will already be relevant for the council departments (for example) that your report will be going to.
And note that we still haven’t asked you who you are. We do need to know — we send your name and contact details to the council as part of your report — but you didn’t come to FixMyStreet to tell us who you are, you came first and foremost to report the problem. So we focus on the reporting, and when that is all done then, finally, we can do the identity checks.
Of course there’s a lot more to it than this, and it’s not just civic sites like ours that use such techniques (most modern e-commerce sites have realised the value of making it very easy to take your order before any other processing; many governmental websites have not). But we wanted to show you that if you want to build sites that people use, you should be as clever as a magician, and the secret to that is often keeping it simple — deceptively simple — on the outside.
When we built FixMyStreet in 2006, our primary focus was to create a tool for citizens. We wanted to make it easy, quick, and effective to report street problems, even if the user had no prior knowledge of where their reports should go. And while the tool obviously had to work for the councils who were receiving reports, it never crossed our minds to research, or try to key into, prevailing council strategies.
But over the last few years, and to the benefit of both sides, council strategy has become strongly aligned with several of the qualities that FixMyStreet was founded on. The development of our specialised software, FixMyStreet for Councils, cemented that further, based, as it is, on consultation with local authorities.
If your current strategy focuses on any or all of the following points, then FixMyStreet is extremely well-positioned to help you.
UK local authorities are fully aware of the channel shift theory by now: put reporting online, make it self-service, and see efficiency rise while costs fall.
It sounds simple, but it hinges on one important factor – you have to get the reporting interface right. Otherwise, all those hassle-free online transactions turn into irate residents on the phone, seeking help.
On first impressions, many assume that FixMyStreet is just a public platform for grumbling – so it can be quite a surprise to discover that it often has the opposite effect. By allowing everyone to see what the problems are in their own community, it provides a platform for engagement, debate – and, sometimes, solutions.
FixMyStreet is a superb tool for councils who are looking for ways to encourage residents to take a stake in their own communities.
Any council web team worth its salt will be anxious to maximise usability across the website. FixMyStreet was designed with the user at its heart: from minimising the number of clicks it takes to make a report, to making sure that every step is as easy and comprehensible as possible.
Modern society is demanding transparency across a vast array of organisations, not least government. By putting a record of every report online, FixMyStreet helps you fulfil those demands. And there are side benefits, too.
First, FixMyStreet brings previously ‘hidden’ work into the open, allowing your residents to understand the degree and quantity of work you do on their behalf.
And second, having reports online allows citizens to see at a glance whether their problem has already been reported, thus cutting down on duplicates – and saving you time.
FixMyStreet is efficient when used on a desktop; it also works very easily on mobile devices, meaning that your residents help you crowd-source information. You’re effectively multiplying your inspection capabilities by a factor of hundreds, and your residents become your ‘eyes and ears on the ground’, as one of our client councils has said.
Find out more
Drop us a line now and we’ll get right back to you.
Image credit: Dennis Skley (cc)
The Open Democracy Advice Centre (ODAC) in South Africa will be using mySociety’s Alaveteli software in their latest project – and, with a bit of match-making from mySociety, the preparation period has been rigorous.
Alaveteli is our open source Freedom of Information platform. It underlies our own UK-based WhatDoTheyKnow, and right-to-know sites around the world. Alaveteli sites make it easy for citizens to ask questions of those bodies who operate under Freedom of Information law and, significantly, they automatically publish all responses.
Before any coding or implementation began, we got ODAC together with the “Governance Collaboratory”, an initiative from the d.school in Stanford University that seeks to apply the “design thinking” approach to projects that intend to make government more open, more effective, and more accountable. We’ve observed quite a few Alaveteli installs, but while we’re always on hand to offer support and answer development queries, we’ve never prepared the ground quite like this.
Gabriella Razzano of ODAC welcomed Jeremy Weinstein and Jenny Stefanotti, both from the d.school, to Cape Town for an intensive few days of assessing how the design thinking approach could shape the project. Two staff from mySociety also went along — Paul (our Head of International Projects) and Dave (one of our developers) — because we’re keen to understand how the d.school’s approach might improve the way we go about building our new projects.
Now, at mySociety we already know a thing or two about building civic systems that engage with the public, because we have considerable experience in the field. We are expert at combining user experience and current tech to create simple, usable interfaces. We conduct usability tests, we apply A/B testing, and we think hard about what our analytics tell us. But actually much of this is reactive, iterative design: it’s being applied after the core product has already been built.
Design thinking challenges this approach by suggesting that the user on which initial designs are often based is purely imaginary. As a result, the site inevitably includes the assumptions and prejudices of its creators. This won’t necessarily lead to a bad design — especially if the creators are benign and experienced — but it must fail, by definition, to account for the unexpected things that may motivate or concern actual users. The design thinking process attempts to change this by approaching the initial problem in a prescribed way and following a process that isolates genuine, existing requirements. This includes, in design thinking terms, processing the initial interviews into empathy maps from which requirements emerge, and which themselves become features that are rapidly prototyped in isolation from other parts of the system.
This is uncomfortable for those of us used to building loose iterations from the bottom up and refining them later. It means introducing empathy and rapid, offline prototyping much earlier in the process than we’d normally expect. Certainly in the commercial world it’s common for a company to prototype against their target consumers early on. But for civic projects such as mySociety’s, it’s often much harder to identify who the users will be, for the impressive yet overwhelming reason that often we are building our platforms for everybody. This can lead to generalisations which may miss specific issues that could make a huge difference to some users.
The d.school advocates a “learning by doing” way of teaching, so the days we spent in Cape Town were a busy mix of practice as well as theory. We interviewed people who had a variety of reasons to want to make Freedom of Information requests, including an activist who’s already used South Africa’s Freedom of Information legislation to make requests regarding housing projects, the head of a rape crisis centre, and law students who may well become a nation’s most empowered activists. From these interviews we isolated specific needs, which at this stage were nearly all unconnected to any digital or web requirement. Jeremy and Jenny then led us through the process of rapid, analogue prototyping intended to address those needs.
Inevitably we could only scratch the surface in the few days we had available, but we hope ODAC will be able to apply the process to the development of their project, just as we aim to use it to benefit the work on ours.
Image credit: Procavia capensis (Rock-dwelling Hyrax or Dassie) by Arthur Chapman, released under CC BY-NC-SA on Flickr.
They tell visitors that dassies such as these live atop Table Mountain. We went up there and saw none. Similarly, Freedom of Information requests exist in South Africa under the Promotion of Access to Information Act 2000 (PAIA), but most people have never seen one — fewer than 200 PAIA requests were made nationally in 2012. This tenuous comparison allows us to illustrate the blog post with a cute picture of fuzzy mammals.
We use Google analytics to understand how people use, and find, our sites. This blog post is a summary of one deceptively simple way we use this information to get more people to use TheyWorkForYou, our UK parliamentary tracking website.
One technical term: landing pages are the pages on a website that a user first arrives on from a particular link or search result. In this case, we created explicit landing pages. That is, we made these pages solely to be the target of search results. They serve no other purpose in the structure of the site; they are like super-focussed homepages. If you’ve read the blog post about minimising clicks on the homepage you’ll see that this is a clear example of that principal in action.
We added two specific landing pages to TheyWorkForYou — here’s one of them: http://www.theyworkforyou.com/parliament/
This page exists for a simple reason: we know that someone who uses the word “parliament” when searching on Google is probably looking for something that TheyWorkForYou can help with. By creating the “parliament” landing page, we are able to offer a page that is more likely to serve them. Incidentally, we try to make sure that searches lead to the landing page by using Google Adwords, and encouraging the Google bots to associate the page with the keywords, and other things too — but those are not the details this tip is about. Instead, look what we’ve put on that page. You’ll see it includes a set of useful explanations about parliament (it’s very common for people not to know how their parliament works), as well as a search box.
That search box is the same one that appears on every other page on the website, in the top right-hand corner.
But on this landing page, we’ve changed the prominence of the search box by putting it right in front of your eyes. And we added the caption: “Search for any word or phrase – see if it’s been mentioned in Parliament”.
Yes, there’s no technical magic here. No special code. It’s our regular search box. The difference is that on this page we know the user is thinking about parliament, and that search box does indeed search extensive records of what’s been happening in parliament. If we didn’t do this, we could leave the user to figure it out for themselves. They might of course… or they might give up. As you’ll have noticed if you’ve read the previous design tips, we don’t want users to give up, ever.
We did it again for “Hansard”. What’s Hansard? It’s the name of the transcript of all UK parliamentary debates, published by Parliament itself. Someone who knows about Hansard might be searching for it (on Google, say) and not realise that TheyWorkForYou has the entire transcript available for search. So we added another landing page. Again, it’s the same search that’s on all the other TheyWorkForYou pages, but now — for a user who’s already identified as someone who knows that Hansard exists — it’s clear that the search will do what they expect.
When a user on FixMyTransport tells us about a journey they’ve had, we ask them if it was on a bus, train, underground, or ferry. This is a simple question, but of course our lead developer Louise thought carefully about how to ask it.
As programmers, we sometimes approach collecting data from the user just like filling in a form — a paper form. So, we could ask the bus/train/ferry question by using a list to select from (in HTML, that’s a
selecttag) — perhaps spread out, or as a drop-down list — or maybe as a set of radio buttons. But in this case we have deliberately broken away from idea of the form.
Instead, FixMyTransport uses four big buttons. They look like this:
Effectively, this means we have a whole webpage devoted to one single question. That’s perhaps not what you’d expect if you’re building an online form. Often it seems easier not to break a task across several pages. But here we have a single page with a single question on it.
There are some important things to note about this page:
- the four buttons are big and colourful and beautiful (we can thank Supercool for this, who did the design work on the initial FixMyTransport site)
- it’s a very easy question, even though the answer is critical (because it affects the kind of data we need to ask next)
- it’s a reasonable question — the user isn’t surprised or confused to be asked it
This page has been very successful. We know this because we study our web analytics (that is, how people use our sites) as well as running usability testing. It’s true to say nobody gets stuck on this page, nobody drops out, and in fact most people don’t even think about it (that’s the “reasonable” thing, above).
After the latest session of FixMyTransport usability testing, run by our developer Mark, we had a discussion with other team members. We agreed this was one of our favourite FixMyTransport pages. It’s pretty, it does the job, it moves the user forward (see the earlier blog post about “why the FixMyStreet homepage asks one easy question”)… and best of all it shows that some of us were wrong to be cautious about introducing another step into the problem-reporting process.
Incidentally, Mark recommends the book Rocket Surgery Made Easy if you’re interested in running your own usability tests.
In summary, sometimes a super-simple choice is strong enough to be presented as a single webpage all by itself. Don’t fall into the trap of thinking web forms should be like paper forms.
When you report a problem on FixMyStreet.com, the site displays a map for you to click on to indicate its exact location. Of course, you can zoom in and out of that map, but when it is first displayed, FixMyStreet needs to use an initial ‘default’ zoom level. Ideally, this is a zoom level that reduces the number of clicks required before a user can pinpoint the location of their problem.
And here’s where we encounter a tricky problem. The world is a varied place – some towns are very dense with buildings and streets crammed close together. In these areas you need to default to a zoom that’s quite ‘close in’, otherwise it can be hard to locate your problem.
But out in the countryside, we have the opposite problem. You can have huge areas where there’s nothing but blank fields or moorlands. If the default map zoom is ‘close in’ here then users are likely to see a big map full of nothingness, or maybe just a single stretch of unidentifiable road.
So, what is to be done?
The answer is this – every time you search for a location in FixMyStreet the website does a check to see whether the location you typed is in an area where a lot of people live, or very few people live.
mySociety has been storing this population density data in a webservice which we call Gaze. If the area you searched for is in a densely populated area we assume that it must be an urban location, and the map starts with a helpfully zoomed-in map. But if you’re in a sparsely populated area then it’s probably rural, so FixMyStreet starts zoomed out, making it easier to get an overview of the whole area.
Where do we get the data from? Our late colleague Chris discusses this in a blog post from 2005 — the short answer is NASA SEDAC and LandScan. It’s an interesting example of how unexpected things can happen when data is made public — if population density wasn’t available to us, we wouldn’t have been able to put this small but clever detail into FixMyStreet’s interface.
If you conduct yesterday’s exercise a few times, it’s fairly likely you’ll encounter a common problem with most websites: the dead-end page. Someone has progressed along one of the many paths through your site, and now they’re at a page where they can go no further. This, very simply, should never be allowed to happen.
Now, I’m not talking about the ever-present get-out-of-jail-free card of a standard header or footer that always lets people get to some of your key starting points again — that’s not progressing: that’s simply going back to the beginning. No, I’m talking about harnessing the momentum someone already has. Someone is merrily moving through your site, sufficiently engaged to actually click links and do/discover more, rather than just bouncing straight back out to somewhere more appealing. If they get to a page where there’s nothing obvious to do, or nowhere obvious to go next, then you’ve lost them.
There are two main ways out of this problem. The second, more indirect approach, which I’ll talk about in more detail later, is simply to make sure that everything that could be a link is one. But ideally you should also have something much more direct and obvious that you want people to do from this page. You site may be super tightly focussed, with only one thing it’s trying to drive every visitor towards. Or there might be lots of options. Either way every page should be clearly and explicitly helping people towards at least one goal — and it should be obvious to anyone looking at the page what that is.
If someone is simply browsing at your site out of curiosity, you don’t even necessarily need to drive them towards some other form of action yet — you can simply provide them more options to go deeper, or view other similar pages. One particularly effective, but often-overlooked option is to let them sign up for alerts when something new happens — when there’s new information on this topic, or when a person concerned does something else, or even just when someone adds a comment to the page. The options will differ depending on what the page is, but the key underlying approach is the same absolutely everywhere: after someone is done with this page, make sure there’s something obvious for them to do next.
When building a website most people give most attention to the front page. After all, that’s probably the page that will be viewed most often ((Although, if most of your traffic comes from google searches, or deep linking from other sites, both of which we’ll talk more about later, that may not even be true)). One or two other key pages probably get quite a lot of care and attention too. But after that there’s usually a sharp drop-off, with many pages looking like they were simply knocked up in 15 minutes by a developer who hasn’t had his morning coffee fix yet.
This is often the cause of the great disconnect between what you and your friends think of your site, and what the rest of the world thinks of it — you judge your site by its best bits, but people who actually use it judge it by its worst. When it comes to a great user experience, every page matters.
A well known large corporation, renowned for making job applicants go through many, many rounds of interviews, uses one of those interviews in a very simple and effective way. In it the interviewer takes one single point mentioned on the candidate’s CV/resumé, and quizzes them on it in-depth for an hour. The vast majority of people have something in there that, even if it’s not an outright lie, is still somewhat embellished, or wishful thinking — maybe an exaggerated account of what they achieved at a previous job, or a skill they haven’t actually used since that one job 10 years ago, or an interest that’s really been dormant since college. Pretty much everyone has something in there that’s unlikely to withstand an hour of deep questioning.
On a semi-regular basis you should carry out a similar process for your site. Whether this is something you’re actively in the process of building right now, or something that’s been running happily for 10 years, pick a single page, grab everyone you can (and maybe some pizza) and spend a hour digging into it in painful detail.
Look at it in several different ways. Print it out and hand it around — some copies in colour, some in black and white. Blow it up on a big screen or projector. Look at it on a mobile phone. Listen to it on a screenreader. Even look at it upside down. Can people tell at a glance what page it it is? How do people get there — both from within the expected flow, and also from elsewhere: do people come to it from Google searches? If so, for what? Has anyone ever linked directly to it from Twitter? Why? What can you do on the page? Where can you go next?
If you have real facts and statistics about all these things that’s good (you should!), but don’t look at them until after you’ve discussed what you think the results will be. Then try to work out why the answers are different (they will be). Try to look at the page through fresh eyes. Then go find some people who’ve never used the site and see how their fresh eyes differ from yours. Don’t even tell them what the site is: what can they tell just from looking from this page? If they found themselves on this page, what would they think they should do? Why does that differ from what you think they should do? If this was the only page they ever saw, what would they think of your organisation? Does it entice them to want to discover more, or do more? Or do they just shrug their shoulders and return to Facebook as quickly as possible?
Again, if your TODO list doesn’t grow dramatically from this exercise, you’re doing it wrong.