Build services people can use.
Three selected ideas from Government Design Principles.
Start with your material, or explore a workflow that fits your work. Every route leads to the same focused card editor.
An existing article, professional point of view, or reflection.
Here, selected Government Design Principles become four connected cards for a professional audience.
Create independent insights or a connected sequence, then export PNGs. PDF document carousels are not included yet.
1. Start with user needs Service design starts with identifying user needs. If you don’t know what the user needs are, you won’t build the right thing. Do research, analyse data, talk to users. Don’t make assumptions. Have empathy for users, and remember that what they ask for isn’t always what they need. 3. Design with data In most cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork. Keep doing that after taking your service live, prototyping and testing with users then iterating in response. Analytics should be built-in, always on and easy to read. They’re an essential tool. 4. Do the hard work to make it simple Making something look simple is easy. Making something simple to use is much harder - especially when the underlying systems are complex - but that’s what we should be doing. Don’t take “It’s always been that way” for an answer. It’s usually more and harder work to make things simple, but it’s the right thing to do. 5. Iterate. Then iterate again The best way to build good services is to start small and iterate wildly. Release minimum viable products early, test them with actual users, move from alpha to beta to live adding features, deleting things that don’t work and making refinements based on feedback. Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If a prototype isn’t working, don’t be afraid to scrap it and start again. 9. Be consistent, not uniform We should use the same language and the same design patterns wherever possible. This helps people get familiar with our services, but when this isn’t possible we should make sure our approach is consistent.
Human-edited source selections and adaptations, shown with our card renderer. Not a live AI result.
Three selected ideas from Government Design Principles.
Teaching notes, concept explanations, and classroom examples.
Here, a NASA Space Place explanation becomes four cards on Earth’s tilt, opposite hemispheres, and a common misconception.
Use a knowledge set to connect a concept and its explanation. Review accuracy and suitability for your learners.
Earth has seasons because its axis does not stand up straight. As Earth orbits the Sun, its tilted axis keeps pointing in the same direction. Different parts of Earth receive the Sun’s direct rays during the year. Around June, the North Pole tilts toward the Sun; around December, the South Pole does. The two hemispheres have opposite seasons. Earth is closest to the Sun in January and farthest away in July, so distance is not the cause of the seasons.
Human-edited source selections and adaptations, shown with our card renderer. Not a live AI result.
1 / 4
Earth’s tilt changes which hemisphere receives more direct sunlight.
Source: NASA Space Place · What Causes the Seasons?
A method, public framework, or professional insight.
Here, public service-design principles become a five-card client discussion: the goal, evidence, an explanation, iteration, and a recap.
Explain a method in language a client can follow. Confirm authorization and privacy before using client material.
1. Start with user needs Service design starts with identifying user needs. If you don’t know what the user needs are, you won’t build the right thing. Do research, analyse data, talk to users. Don’t make assumptions. Have empathy for users, and remember that what they ask for isn’t always what they need. 3. Design with data In most cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork. Keep doing that after taking your service live, prototyping and testing with users then iterating in response. Analytics should be built-in, always on and easy to read. They’re an essential tool. 4. Do the hard work to make it simple Making something look simple is easy. Making something simple to use is much harder - especially when the underlying systems are complex - but that’s what we should be doing. Don’t take “It’s always been that way” for an answer. It’s usually more and harder work to make things simple, but it’s the right thing to do. 5. Iterate. Then iterate again The best way to build good services is to start small and iterate wildly. Release minimum viable products early, test them with actual users, move from alpha to beta to live adding features, deleting things that don’t work and making refinements based on feedback. Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If a prototype isn’t working, don’t be afraid to scrap it and start again. 9. Be consistent, not uniform We should use the same language and the same design patterns wherever possible. This helps people get familiar with our services, but when this isn’t possible we should make sure our approach is consistent.
Human-edited source selections and adaptations, shown with our card renderer. Not a live AI result.
A client discussion framework, adapted from Government Design Principles.
These are illustrative workflows, not customer stories or promises of results.