How to not make great government websites: use random domain names instead of a single dedicated tld, different contractors and design for each, make sure there's enough overlap in functionality in-between each of them, and then regularly remind everyone that it's very easy to scam you with fishing attacks.
Here are just some of the official French websites:
service-public.fr
impots.gouv.fr
gouvernement.fr
ameli.fr
vie-publique.fr
info.gouv.fr
santepubliquefrance.fr
And of course, you never know where to look for information, and sometimes it's replicated to other official websites with differences.
Let's not forget the weird decision they made with the ac- domains, too. Instead of having all of them under one domain, they just use a naming convention: ac-nice.fr and ac-aix-marseille.fr are both official. It should've been nice.academie.fr and aix-marseille.academie.fr, imo.
it also looks dodgy to be honest. Also if you click too much while logged in they detect "suspicious behaviour" and block you from logging in again for a couple of days without warning, saying don't call customer service, they won't help you (very frustrating if you are short on time). They also have the option of maestro for payment (was decommissioned years ago in Europe) and don't accept real credit cards, only debit apparently.
That's a very unfair take. The examples you list are of a completely different nature.
> gouvernement.fr info.gouv.fr
These are the same website. gouvernement.fr is a legacy URL that redirects to info.gouv.fr. Why did you include both?
> ameli.fr
As I'm sure you know, in France, social security is not administered by the government directly but by the social partners. They're in charge of managing ameli.fr, not the government. Go there, you won't find any logo from any ministry. Why did you include it? With this and the previous example, I cannot shake the feeling that you're on a mission to denigrate with little regard to the facts.
> vie-publique.fr santepubliquefrance.fr
These websites are basically blogs about respectively the institutions of the republic and about public health.
> service-public.fr
General informational website. For most sensitive procedures, you're redirected to a .gouv.fr website. Yes, it could have had a .gouv.fr URL, that's true.
> impots.gouv.fr
Yep, that's the tax website. You can notice it's official thanks to gouv.fr, like all website where you do actual online procedures.
And then, the French governement has released an official and mandatory Systeme de Design [0], to have an unique visual identity across all official websites.
I was making a non-exhaustive list of the ones that came through my mind.
> As I'm sure you know, in France, social security is not administered by the government directly but by the social partners.
What matters is whether that's an entity of the state or of a third party that is potentially trying to scam you.
I could have included pole-emploi.fr, oh sorry, I mean, francetravail.fr in my list.
All of the above plus the ones of the sibling comments under a single .etat.fr, .admin.fr, .public.fr, .france or whatever would only make sense. None of us would have to double-check again whether the information we're getting or form we're filling is official or not.
Yeah here in Portugal we have a ton of those too. Each municipality has its own cm-<name>.pt domain, but there some exceptions. For example, Lisbon's domain redirects to lisboa.pt, and while no other major city I know does this, almost all of them have separate website and domain without the cm- part.
I'm genuinely curious if people still think gov.uk is a good example - or I guess, as good as it was.
I'm slightly biased from past experience but my feeling is a lot of the critical thinking that went into gov.uk has been lost. I just can't see the original form of GDS having an cookie banner on gov.uk for example. These were the guys that rightly pointed out that there is no actual need for people to have user accounts to access most govenment services and that no one cares about what govt department they are forced to interact with and yet, I reccently had to create a DVLA account to get an updated drivers liscence (something that happens once a decade).
I think a lot of the more recent issues with gov.uk are the result of some defanging of the central service, leaving departments with more rope to do their own thing and believe that they know best.
Identity in particular is a complex subject, AIUI the original Verify project had to exist in the shadow of the No2ID campaign, which led them to avoid a centralised ID system. This then led to a much more complicated approach that was unable to cater for the needs of some of the departments.
For example, HMRC needed individuals and companies to be able to log in, and for whatever reason this was deemed unworkable with Verify, and thus they build the grandly titled "goverment gateway" auth system - and then I would assume that other depts saw this and decided that meant they could or should build their own auth systems too.
It depends. Usually local councils' websites are purely terrible.
DVLA is mostly very good, I'd say. Especially when dealing with vehicle registration, ownership change, taxing etc.
HMRC is in a category that I'd call "scary". Their website is nice and all but if you ever get locked out of their mobile app for confirming identity (or you delete it by mistake), it's really hard to fix the issue. This is connected to the fact that UK has no national ID card so they use various heuristic to confirm your identity.
UKVI is probably the worst as they don't offer a consistent experience. You can tell that some of their websites were developed in early 2000's and never updated.
It's hit and miss, but I still largely like it when I have to interact with it.
I just re-registered to postal vote from overseas, and the information and links were a labaryinth, often sending me in circles.
Out of exasperation – since I thought my use case didn't match what I was looking for – I clicked the big green "Start" button on the wizard and it worked swimmingly.
When re=applying for a passport in the recent past it was great too, even allowing me to upload a photo from my phone.
Perhaps they have focused on some key interactions that would typically be seen as complex.
The Identity side of GDS has definitely been the worst. I wonder if due to the politics around that service, the thinking has stopped and the Just Get It Done, Even If It's Silly crowd has replaced it.
The identity side has allways been a problem (P)politically and technically.
I think the original GDS was completely correct in basically forcing services not to have them, they are unnecessary for almost/all transactional inerteractions - where they are useful is for things with long term, cosistent interactions i.e. where theres an actual relationship, such as benefits or tax - unfortunatly HMRC and DWP both want to "own" the relationship as individual departments (or even benefits) rather than as a part of the government, and the UK is adverse to anything that looks like a national identity system (ignoring the fact we already have national insurance numbers for everyone(?), passport numbers, etc.)
Where I think the loss of critical thinking bites the most though are the small things:
- cookie banner on gov.uk
- my DVLA password, had to have numbers etc (despite password compostion rules not been a recommeneded best practice for almost 10 years [thanks NIST / GCHQ])
- forms are now so simple due to the mantra of "only ask one thing at a time" that you lose all context as you now have a page for "name", "date of birth" etc. instead of one page for "personal details"
I've participated in some user research with the team building it and I've also designed GOV.UK services pre-One Login that needed to verify people's identity. It's obviously a very difficult problem to solve when there's no universal central ID database. The people working on it are definitely cognizant of the failure of Verify and they're keen not to repeat it.
I do hate the 'GOV.UK One Login' name though. It's previously been called 'GOV.UK Account' and 'GOV.UK Sign In', I'm not sure what was wrong with either of those.
Renaming stuff is the easiest job, so it gets done first :) Thanks for your work on gov.uk. I interviewed (a five hour interview!) with GDS about 6 years ago, and it was a nice place. I declined the offer in the end, but it always looked very promising.
Amen. I've been living abroad in the US for 7 years, so have had to use it for a number of things (including setting up proxy voting), and it's always been clear, easy, direct, and reliable.
My sister and I are currently handling my mother's recent death, and with the exception of one slightly-out-of-date piece of information (you no longer need to pick up the Cause Of Death form to exchange it for Death Certificates - the CoD form is forwarded to the registry office), it's been extremely helpful.
Recoding America, a book about improving the quality of software used by the US federal government, had good things to say about how the UK did things and what we could learn from them.
Dave Guarino needs to read Seeing Like a State, Seeing Like a Bank, and Seeing Like a Data Structure. And then write his own Seeing Like a Government Website.
I know Dave personally, and I can assure you he’s read Seeing Like a State! In fact, if you spend more than 30 seconds in his presence he’ll probably give you a copy.
The UK Government's efforts to make their services digital, easy to understand and workable is such a great effort. The digital department also has many common tools to help such as notifications, forms, payments as integratable APIs instead of each government unit needing to procure this (at great cost) themselves!
an always up to date list of public holidays, makes automated workload planning and working day delivery calculations so much more reliable in our internal app.
If true, it displays celebration bunting on the front page on that day. Seems to be true for all holidays except Good Friday and the Queen's funeral (plus one (probably accidental) Easter Monday). https://github.com/alphagov/frontend/commit/5466c5f9ecc896a4...
I thought this was an interesting read. There's certainly a lot of room for improvement for websites that allow you to sign up for government benefits (although i suspect in some cases the friction is intentional).
My biggest gripe with govenrnment websites is not the parts where they're taking in user data, but the parts where they silo their public data. In my experience this is the worst at the local and federal level. Infuriatingly, my local city council does not OCR their most recent minutes, but they do OCR their archived minutes. So you can search their minutes, just as long as they aren't relevant anymore. Another thing is using javascript buttons to serve PDF files, and filenames have no refeence point with their titles. So if you need a few at once you've gotta stop and manually change the filename from 123455325.pdf to something intelligible.
> (although i suspect in some cases the friction is intentional)
I've worked on the first digital forms for NAV in Norway, which handles parental leave, sick leave, when you've lost your job etc.
We didn't want friction. People have a right to this help and money, and making people self served is a win for all:
- around 90 % of submitted paper forms had some kind of error, which the case worker would have to fix while entering the form manually into the case system. Often had to contact the client and spend so much time on things not giving value.
- people would have to contact case workes constantly, because the forms were made by lawyers. "If you filled in 16a you also need to fill in 46ac and 47f" would give a huge tree of possibilities most people couldn't navigate.
- making the form digital, we could conditionally show the correct parts. We could pull in data from other systems and prefill parts (like your employer, registered kids, address)
- the first version we actually just sent to a printer and someone would print and mail all digital forms so the case workers still would have to do much of the manual typing, but at least we quickly made it easier for the clients.
- then later when the case systems were ready we could instead push some xml directly instead of mailing paper. The clients didn't notice a difference. But this to say that we really tried making their lives easier even before everything else was in place.
- the core is that we want the case workers to do less of the useless things, and spend their time doing the valuable things.
- the first digital version of the parental leave form was basically what we kall "strøm på papir" or "electrical powered paper". While it was digital and easier to use, it didn't solve all issues with the paper form, as it still contained all questions and was huge. Then it was a lot of work, political, with lawyers, even law makers, if the next version could be better. Is there things we could stop asking for? Could the law be streamlined and edge cases removed? Etc. All to make it so that the common 95 % don't have to be confused and have to read and understand lots of stuff only relevant to a small minority.
> When we started working on GetCalFresh, the online application was about 200 questions across 50 or so screens.
And that is why people who want to send you marketing e-mail have literally a single field: e-mail address. Not even a 2nd field "name" so they can send you personalized email, or "date of birth" so they can send you special offers for your birthday.
> It’s important to understand that it’s often not the conscious choice of users to arrive at your site without JavaScript. We did some research and discovered that 0.9% GOV.UK visits are by people who don’t have JavaScript available and haven’t chosen to turn it off.
I've moved to "transient network faults" as my defence against creeping JS. What if the HTML gets to the user, then their mobile connection drops? The page should at least look vaguely sane.
I worked in the public sector of Denmark for years and you’re going to have some real issues handling authorisation of users from external sources such as our digital identity called mitID without JavaScript.
Some forms and many parts of a government website can indeed be done without JS and should at the very least be done with server side rendering to minimise the usage of JS as much as possible. But large parts of a “modern” government website will typically require some JS in order to operate properly.
I would somewhat strongly disagree . Using JavaScript allows for a more interactive interface, where cause and effect are more clearly visible, and where the relationship between answers and further questions is more obvious.
For example, it's common for govt forms to have sections like "fill this part in if you're a resident" and "fill this part in if you're a visitor".
Elsewhere in this thread, auto-saving is mentioned, trivial to do with javascript, (and more privacy respecting to do if using local storage.) The alternative is "one page per question" - which is the slowest way possible to fill out a form (and not inconsequentially puts the highest load on the server.)
JavaScript is part of the web, and offers significant UI and work-flow advantages. Govt (or indeed any site) that eschews it is unnecessarily degrading the experience for the vast majority because some sliver of the audience don't like it.
It allows for more interactive forms, but also frequently makes cause/effect confusing. e.g. things like autofill or tabbing or sometimes just typing quickly can cause forms to break because they think you have not filled out a field, and it's doing something stupid to make it so you can't fill out the next field, so you end up having to delete and retype text to get it to pick it up.
Governments often have complicated forms that need to cater for a broad range of users. So you need things like conditioning steps, file uploads and progress saving.
Broad range of users means keeping it simple and sticking to the standards.
The complexity of government forms is not about fancy custom dialogs, elaborate data types or cute animations. There are usually a lot of (simple) questions. Yes/no, checkboxes, dates and times, free fields. The list is not endless.
These forms needs to be frustration free as possible. IME all easy targets if you don’t use JS.
gov.uk recommends having a single question per page - principally to make the form easier for users, but it also means you can handle progress saving and conditional sections and so on server-side.
gov.uk is pretty good, and their forms are quite good. But there are definitely still places where this design is worse than one using JavaScript.
For example when paying for tax free childcare you have to enter a date for when you want the payment to go out. Not only is the date picker just three edit boxes (no "tomorrow" button for example), but it isn't validated at all so if you put in today's date (quite reasonable) and click next it will only tell you on the next page that you can't use today.
It would be much better if a tiny bit of JavaScript told you as soon as you put the date in, and if it had a "tomorrow" button, which would also require some JavaScript.
> It would be much better if a tiny bit of JavaScript told you as soon as you put the date in, and if it had a "tomorrow" button, which would also require some JavaScript.
There's so much research that shows the opposite.
You might prefer that but government websites need to work for everyone, and showing validation messages automatically confuses less technically able people, and it's really hard to make it fully accessible.
At which point do you announce the mistake to a screen reader? Where do you shift focus? etc.
It was designed this way for a specific reason. Services that feel the need to extend or change it do have the option to though.
> Do not validate when the user moves away from a field. Wait until they try to move to the next part of the service - usually by clicking the ‘continue’ or ‘submit’ button at the bottom of the page.
Yeah the character count is a bit of a special case because reaching the limit without going over would be very inconvenient.
Hardware. Lots of hardware. The first law of govt sites is insanely high usage, clustered around very specific date and times. The first rule of govt websites is "thou shalt not crash".
For startup folks dreaming of growing a single horn, over provisioning is an indulgence, scaling design an all-too-often vanity.
But govt sites should be designed for insane scale from day 1.
I disagree. Most content on government sites is static content, you could fairly easily deliver much of that to a large population with relatively little hardware, assuming the software is developed such that static delivery is possible.
There are "processes" that people need to complete, but these are typically life-changing processes, things you do once in your life, or maybe once a year at most. Even if those are clustered in time as you say, and most aren't, it doesn't take a lot of hardware to run most of those processes, especially if again the software is designed well and to pull things off the critical path that don't need to be.
The healthcare.gov rollout is often pointed to as an example of these things going wrong, the site crashed, and it would be easy to say it needed more hardware, but actually the core issue was that it was "enterprise software" – it was software built by people used to building software for small numbers of expert users in a company who might go through training, who might be using on-prem servers, who might have a lot of complex business requirements. The big improvement came when a bunch of producty-UXy sorts of people came along and scrapped most of the system, made a simple piece of user-facing software that did the minimum necessary, and built it with modern (at the time) web technologies, not from throwing hardware at it.
USPS tracking should be using an indexed id (you don't want to allow partial matches/searches here), so I'd expect even very modest hardware to handle 10s of thousands of requests per second. Likewise with things like CRUD forms.
Right now your link shows only ~5700 requests in the last 30 minutes for GSA advantage, or ~3/s. Sex offender registry has ~3500/30m or 2/s. Even USPS tracking is only at ~12k/30m or ~7/s. It's still only 9am on the west coast so maybe they need to handle 100000x traffic for peaks, but I doubt it.
Yep HealthCare.gov , but its by far not the only site to struggle. And hardware goes beyond cpu and includes things like hardware for the database, resilient fall-over, network bandwidth (ok, less of an issue these days) and so on.
Sure, it takes more than -just- hardware, and yes sites can be more-or-less resource hungry. But ultimately "the server is offline" is not a good thing.
Lots of things cluster when you don't expect it. Like sites to take bookings for national parks (as an example).
Scale from day one is a good point. Unlike a commercial website, users are required to use a government website (or use a paper equivalent) so usage can rapidly jump from zero to every citizen.
In the US, Federal government websites total over a billion sessions per month [1].
Here are just some of the official French websites: service-public.fr impots.gouv.fr gouvernement.fr ameli.fr vie-publique.fr info.gouv.fr santepubliquefrance.fr