Perfect 
If you have a liking for Apple products, then indirectly you have a liking for the design principles of Dieter Rams, whose work as Chief Designer at Braun has been credited as a major influence on Jony Ive, the former Chief Design Officer at Apple whose design ethos can be seen coursing through the veins of every Apple product since 1997. Dieter Rams himself coined his 10 Principles for Good Design as a handy distillation of his whole ethos.
Good design:
-
is innovative – The possibilities for progression are not, by any means, exhausted. Technological development is always offering new opportunities for original designs. But imaginative design always develops in tandem with improving technology, and can never be an end in itself.
-
makes a product useful – A product is bought to be used. It has to satisfy not only functional, but also psychological and aesthetic criteria. Good design emphasizes the usefulness of a product whilst disregarding anything that could detract from it.
-
is aesthetic – The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being. Only well-executed objects can be beautiful.
-
makes a product understandable – It clarifies the product’s structure. Better still, it can make the product clearly express its function by making use of the user's intuition. At best, it is self-explanatory.
-
is unobtrusive – Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user's self-expression.
-
is honest – It does not make a product appear more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.
-
is longlasting – It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today's throwaway society.
-
is thorough down to the last detail – Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.
-
is environmentally friendly – Design makes an important contribution to the preservation of the environment. It conserves resources and minimizes physical and visual pollution throughout the lifecycle of the product.
-
is as little design as possible – Less, but better. Simple as possible but not simpler. Good design elevates the essential functions of a product.
When we talk about ‘design’, of course, we don’t just mean the logo and the colour scheme on a website – we also mean the content design, the user journey and the Interaction Design, and the Service Design underpinning the delivery bringing the service to and from your screen.
What is design anyway?
There are gigabytes worth of articles going into whatever level of detail you like answering this question just a DuckDuckGo query away, but to save you a rabbit hole the short and snappy working metaphor for design I like to use is planning – if something has been designed, it has been planned; the elements of the design haven’t just been plopped onto the page because the person likes that font and the colour or the feel of the wood the product is made from or because the case obviously needs a received status, a close status, and something in between. Something has been designed because the designer has fully considered the starting conditions and the end goal and created a map of how to get to one from the other, taking account alternative routes because of the possibility of a mudslide blocking one of the paths and the knowledge that one of the participants has additional needs which mean they’ll need help in completing that goal.
How might we translate the 10 Principles into designing for local government digital services?
In the following I’ll mention a few bugbears which colleagues and former colleagues have heard me rant about more than enough, but hopefully those bugbears are accompanied by ‘do this instead’, and even where I don’t offer specific advice on what I think is a better alternative, at least the description of a practice to be avoided can guide you to look elsewhere.
Good design is innovative
I’ve written endlessly about innovation in LocalGovDigital, offering ideas of new ways to deliver our services – some of those ideas may have been good ideas at the time but bobbins now, some of them may have been ideas ahead of their time that their time is only now or their time is still to come. Some of those ideas may indeed have been bobbins at the time and still be bobbins now! But the point of good design being innovative is not about looking for the latest shinies to the website because somebody influential saw a feature on an e-commerce website and thought it looked cool.
The point of technology is to help users solve problems. The point of innovation is to help users solve problems more easily today than they were able to solve them yesterday. It’s our job as digital strategist-practitioners to be on the lookout for new ways of delivering services, new tools which come available, and testing their viability for improving on the existing or non-existent solution to the problem. Some of that will be contextual for the service and will be dependent on the competence of the implementation – a VR walkthrough of a premium space for commercial hire may sell that space more effectively than some low end mobile phone pictures of the space, but a VR walkthrough of the reception area of the Civic Centre is unlikely to be solving any problem that even exists, let alone solving it better than just a decent ordinary photo of it will.
Good design makes a product useful
If innovation is about solving a problem today in a better way than the problem was solved yesterday, making a product useful is about establishing that there was a problem to solve and solving it in the first place. Who has the problem, and is the solution to that problem of benefit to both the citizen user and the council user? Does it create a solution for one user class but a problem for the other user class? Is the problem a universal problem or a contextual one – and therefore should the solution be applied universally or contextually?
In modern parlance, we call the principle of making a product useful User-Centred Design.
Taking an example of online citizen accounts, it’s a reasonable assertion that the existence of them overall can be of benefit to the citizen in being able to track progress of service requests and problem reports, but is it always useful to them? It will often be useful to a citizen to have a record of when they reported their recycling pod as having gone missing so when they subsequently complain about the replacement not having been delivered they can easily login to refer back to the reference number and date they reported it. Better still, they can easily login and from the view of the record escalate the service delivery failure right there rather than having to go to a completely different system hosted on a completely different page of the website to complain about the failure.
But does your user research demonstrate a groundswell of citizens who find it useful to not only report potholes and flytipping online, but also to login every other day to check on the progress of that report? Of course, in a county of a million people in an infinitely expanding multiverse, there are of course citizens who will find that useful. If it’s no skin off your nose to simply plug the back end line-of-business system used to manage the progress of dealing with the pothole and the abandoned fridge into your citizen account system, then by all means do it. But if that in itself is going to be expensive, consider whether there are other items in your innovation backlog which can deliver more use to the citizen.
Mandatory login for a citizen account is rarely useful for a citizen. It’s barely useful for the organisation. Don’t make citizens login in order to report or request services they used to be able to phone up for.
Good design is aesthetic
You can probably guess because I’m writing this article that I like the clean minimalist design aesthetic of Dieter Rams / Jony Ive / Apple. That of course is my personal and subjective preference, which others are free to disagree with; I won’t argue with them. Much.
There are certain graphic design aesthetics which are, for want of a better way of putting it, national. Compare for example the design elements of a USA news channel with a UK news channel – look at the amount of information on the screen in tickers and in the Lower Third, look at the font choices, the aspect ratios of design elements, the use of colour, use of blank space around information, etc – when you sit down and perform a detailed analysis and compare CNN, NBC, ABC with BBC News, Sky News, and even, dare I say it, GB News, you’ll see not only does each channel have its own channel identity, but you’ll also see the shared common aspects of the USA channels which are different from the shared common aspects of the UK channels. That is to say, there is a shared on-screen design aesthetic for USA news channels, and a shared aesthetic for UK news channels.
I’m not noted amongst my colleagues and former colleagues as being somebody who minces my words; there are too many council websites where the visual design is an abomination. It is clear there has been little design applied to on-screen elements in the context of other on-screen elements. Depending on who might have supplied an asset and when, there are too many council websites where you’ll see a button with a round bevel on one page and a button without a bevel on another page, where you’ll sometimes see gradients and sometimes you won’t, where you’ll see colours which don’t fit in with any of the other colour’s in the site’s palette because the person responsible for that page ‘wanted it to stand out’.
There are some council websites which have the starting point of a shared aesthetic by virtue of the web Content Management system they are built in, and when; you can often spot a website built in LocalGovDrupal from its home page because of its top bar of solid colour with the logo and some meta-links, followed by the full width hero image with the search box in it, followed by top tasks and then a top services list, etc. You can often spot and date a Jadu website from its use of icons on the home page for top tasks.
What would be nice to see would be a common UK Local Government Design Aesthetic – not an enforced blandness where every site looks like a copy and paste of every other site with just a global find and replace of ‘Yorkshire’ for ‘Lancashire’, but a common aesthetic which, like the way in which you can tell BBC News apart from Sky News apart from GB News but at the same time you can switch any of them on and know visually you’re watching a UK news channel, you can go to any UK council website and see that it’s a UK council website you’re on, and if you want to do something on that website you’ll know from experience of using other UK council websites where you might have to click to do it. Such a common aesthetic could be produced as a result of an analysis of the best of current websites, and also the worst. I might even put some effort into starting such a process myself in a future article.
Good design makes a product understandable
If you need to give users instructions on how to complete a form, your design has failed.
If you need to tell people the login button is at the bottom of the screen, your design has failed.
If a user gets half way through completing a form only to be told on page four of the form that they need to go and get some extra information from a document they should have somewhere – or indeed, upload that document – and page for of the form is the first they’re learning about that, your design has failed.
(All that said, I still have no idea what I might have called a dropped kerb before I worked for a council and discovered they’re called dropped kerbs)
Good design is unobtrusive
A common problem on council websites is filling up the top of the page with banners containing Mildly Important Information, so many banners the page looks like a local park noticeboard. Service owners are quick to demand yet another banner be put on their pages, or worse the whole site, and slow to agree to those banners being removed when their urgency is no longer relevant. When you’re piling banner upon banner all over the site, replacing one banner with another banner, and never leaving the site in a banner-free state, those banners become meaningless. They not only get in the way of the user doing the thing they’ve come to the site to do, but they also don’t serve the people asking for the banner in the first place, because if their audience hasn’t seen the information in the banner because they’ve ignored it or simply not seen that the banner talking about their new council tax bill has been replace by a banner talking about cost of living support, then that’s to nobody’s benefit. A banner, especially a sitewide banner, should only be used in cases of emergency, where a service delivery problem needs highlighting to the user, or where it’s critical every user of the page or site sees it. Remove the banner the moment the point of criticality is over; if the criticality is ongoing for weeks or months, then it’s no longer a critical emergency and the information needs instead to be treated as generally important information rather than critically important information.
Good design is honest
Remember further up the citizen account and its usefulness? How many council websites make grand claims for the usefulness of their citizen account which aren’t met even where the functionality actually is useful to the citizen There’s one citizen account platform in common use across the sector which on the login screen proclaims ‘Once signed in you can track the progress of your cases and collaborate in real time. Don't have an account? Register, it takes less than a minute’.
Whilst it’s true that the platform in question does indeed support the possibility of real-time collaboration where on an individual case details page updates appear as they’re posted by any user working on that case without anybody needing to click refresh, with status changes and messages logged on the timeline, but how many councils are making full use of that real-time collaborative capability with their citizen users? How many times even have the resources to deploy staff to update a citizen’s flytipping report beyond the level of detail of saying it’s been received and then subsequently possibly add that it’s been removed? If you’re telling citizens they’ll be able to sit in front of a live chat system, where they can post a question asking when the pothole is going to be fixed and get an answer within minutes, but no such answer is going to be forthcoming, then you’re not being honest. Also, have you actually timed the real end to end process of registering for a new account?
Good design is longlasting
It’s at least fair to say that the UI Design of many council websites lasts a long time, even if the reason for that is because staff resources to spend time refreshing the design every year or every couple of years have been slashed over the last 10 years or so.
A longlasting Service Design will be a simple and modular Service Design. The steps necessary to complete an end to end service delivery process – and the accompanying design documentation - will be reduced to as few steps as possible, with as few decisions as possible. Where there are many decisions and many steps which genuinely are necessary in the Service Design, try to see if a modular approach is possible, where you sandbox design components to minimise the impact of changing one part of the design on other parts of the design. Similarly modular and sandboxed UX and UI Designs can also help you to create a longlasting overall design whilst leaving you free to update the modules according to changing needs.
In short, you can’t anticipate what exactly you might need to change from year to year, or even at times from month to month, but you can design in such a way that the impact of change is mitigated.
Good design is thorough down to the last detail
When you’re designing a digital interaction, from the Service Design through the UX to the UI Design, you’re going to need to test it, right? You’re not just going to need to test it in your development and User Acceptance Test environments, you’re going to need to test it in Production. You’re not just going to need to test it once when you think you’ve finished building it, you’re going to be needing to test it time and again for the years following, when you make changes or when a problem arises. You feel a bit of an idiot setting your name as ‘test please ignore’ on the form submission, but even when you do how often do you get an email from somebody an hour or a day later asking you if this was a test submission? One way of being thorough down to the last detail in a piece of design might be to incorporate the necessity for testing into the design itself – the ability to clearly mark a form-to-case-management submission as a test not just by having your name as Test Please Ignore, but incorporating the fact of a case being a test case as a Status when the case is closed, and/or a flag as part of the case metadata.
That’s just one example of being thorough to the last detail, of thinking through not just the stated requirements and how to implement them, but also of thinking through the implications of the requirements that haven’t been stated. Minimum Viable Product means just that – it's supposed to be what you deliver as quickly as possible to get the service used to using their new tool to help them refine the requirements the Business Analyst wrote down into Real Requirements; it’s understandable when an MVP has rough edges, but it shouldn’t be acceptable to leave those rough edges in the final delivery.
I hopefully don’t need to talk about consistency and precision in the UI Design and the Content Design, about the need to ensure you don’t get a situation where some forms ask for the user’s contact details at the beginning of the process and other forms ask for the user’s contact details at the end of the process. You already know about that, right?
Good design is environmentally friendly
There probably aren’t many carbon emissions which can be saved by adopting Jony Ive’s clean minimalist UI design aesthetic over something more 1980s looking, it’s true, and big flashes whilst causing a lot of visual pollution on the screen aren’t really responsible for the degradation in water quality or reduction in biodiversity. But what about Service Design? And Infrastructure Design?
Does the Service Design introduce myriad steps into a process for which the necessity is arguable? Extra steps means extra work means extra resource means more energy expended in delivering the service. If extra steps also mean copying data from one system to another, rather than the service end user using the exact same system to work in that the citizen end user uses to make the request in the first place, that’s duplication, triplication, quadruplication of data in a data centre. Which then introduces the matter of data retention periods – it's inevitable for the time being that there will be some duplication of data occurring because the creation of One System To Rule Them All isn’t coming any time soon.
So when the citizen user completes a missed bin collection form, often that will result in the form submission being stored in the form database, an email being sent to a service mailbox (as well as to the user themself), the submission being stored in the CRM database, and then also being stored in the back end line-of-business system. That’s four systems all holding the exact same data. There may be good reasons for all four of those systems to be holding that data for a period of time, but do they all need to hold it for the full five years your global retention policy specifies? The financial cost to the organisation of keeping huge amounts of data for long periods of time may well be pennies, but there is an increasing understanding that the carbon cost of not just lakes but oceans of data languishing in data centres long after the user of that particular system’s need has passed is not a trivial one. You should only purge on creation for any given system in the chain if there’s a defined security reason to do so – such as where financial details are taken – because glitches in a chain always happen and if you have a copy of a form submission everywhere for a reasonable minimum period of time you can recover it if an error has occurred. But consider which systems in a chain can have a retention period of one month, which might need three months, or a year, or 18 months. Can you design your data retention in your systems in such a way that means you can purge non-essential parts of a submission but retain essential parts – for example, when compiling management information and comparing year-on-year trends, you might only need to surface the number of pothole reports in any given ward and the size of them, you won’t need to compare the free text details where the citizen went on to mention the pothole was just in front of the Spar and kindly provided a photograph too.
Good design is as little design as possible
One of my favourite actors is Dominic West. Less so these days because he’s such a famous name so he’s instantly recognisable, but taking three of his notable roles in his earlier career – Jimmy McNulty in The Wire, Fred Casely in Chicago, and Hector Madden in The Hour, I completely failed to notice at the time that all three roles were being played by the same actor, such is his skill as an actor that the watcher focuses on the character rather than the person playing the character.
Good design is the same; if the user of the missed bin reporting service is made aware of glitches in the reporting process – blockages to complete the form, difficulty finding the form, a page and a half of text telling them it was probably their fault the bin wasn’t collected before they even get the link to the form – there's too much design getting in the way. If there’s a hold up between the user pressing Submit, and the bin actually being collected there’s too much design getting in the way. Why does the user even need to report that their bin hasn’t been collected anyway? How come the council doesn’t actually know it failed to collect somebody’s bin and sent them a notification, perhaps via their citizen account, saying sorry straight away and managing their expectation as to when it will be collected?
Conclusion
Understand, though, that by preparing this I’m not claiming to be Dieter Rams or Jony Ive, I’m not setting myself up on a pedestal of perfection. There are plenty of aspects of my own current and past work where I’ve fallen short of the Principles; I know I’ve committed at least one infraction listed. But I’ll be using it to test my future work against, and where time and other constraints permit I’ll be going back over previous work to see where I can bring it up to my own modern standards. Hopefully if you agree with the Principles you’ll be able to measure and design your own work against them too.