Design Principle 9 – We will build, test, learn & iterate
Studio Notes | Short Reads
This post is part of a series exploring the Design Principles for Government in Ireland. If you’d like to start from the beginning, check out our introductory post here.
Design Principle number 9 is perhaps the most powerful of all 10 principles, but also probably one of the more challenging to the status quo. In design school we learn about “prototyping”. Most people are familiar with pictures of architects working on miniature models of buildings, or fashion designers placing fabric on a “dress form” or mannequin as they figure out their design.
This is a smart way to test possibilities, learn, make changes, and vitally – to do so quickly and cheaply. Architects’ models are a lot cheaper than fully constructed buildings, rough cuts of cheap fabric are not nearly as valuable as the finest Italian materials. These techniques help designers figure out details, test with their clients, learn vital new things, and make changes without costing the earth.
This design principle demands that public services apply this same process to the ways in which we design and deliver services.
The Prototyping Cycle
“Build, test, learn & iterate” is a cyclical approach. The first step, to get us started – is to listen. This is what principles 6, 3, and 1 ask us to do. We should listen to those who use, work in, and are affected by a service in order to better understand the context, and this helps us decide what to build, kicking off the cycle.
There are then three essential ingredients required to get this right.
- A prototype – a thing, an experience, or a process you are going to create
- A question – what is it we are unsure of, what do we want to learn?
- A person – who do we test this with in order to get feedback and answer our question?
The word “build” here needs to be taken lightly at first. What is the smallest, cheapest, quickest thing we could to do test and learn more about our proposed change or development? Sometimes this is as simple as producing some prototype forms for people to fill in, or testing some new signage in a public office. Other times it might mean creating “clickable” mockups of a new webpage or app interface.
“Testing” means showing this prototype to someone – often a service user or staff member, even better if you show it to a handful of these people for more feedback, always ensuring you’re asking the right questions.
“Learning” means documenting feedback and drawing conclusions from it. This requires humility – we are not trying to prove we were right, our idea will, and likely must be change based on people’s feedback. We take these learnings on board.
“Iterate” means making necessary adjustments, changing the proposal or concept in response to feedback, thankful that we haven’t spent millions on technology, time, or launched a new service which might later have struggled.
The Challenge
This way of working is common sense. You start small, work fast, learn quickly, and reduce risk as a result. The huge challenge is that this approach conflicts with business-as-usual in many organisations.
Policies are written and then launched. Services are funded, resourced, developed, and then launched. Technology – huge amounts of technology – are specified, procured, developed, deployed, go through a small amount of “User Acceptance Testing” (the clue is in the title!) and then launched.
The result of this is increased reliance on assumption (see principle number 6), increased risk, increased cost, and all too often ineffective services.
To truly uphold design principle 9 we need to completely adapt our ways of working. Large “stage gate” project management methods must go, continuous discovery, design, testing and development must replace these processes. This design approach shares a lot with agile methodologies, we must insist that assumptions are banished from the way we work.
What Does this Look Like in Practice?
The closest thing to prototyping in public service terminology might be the idea of a “pilot”. This principle asks that we go further than trying to prove something works and open our minds to learning why something doesn’t work and how it might need to be changed.
In our work with Dublin City Council to co-design a consultation process for disabled persons organisations’, pilots allowed quick testing of the process on three separate projects across Dublin City.
During those pilots we learned from disabled persons organisations’, staff within the council, and other stakeholders. We were allowed space to understand what was working, what needed to change, and what should be eliminated from the process.
A “Learning Log” was established where all learnings and subsequent iterations of the process were tracked. We met fortnightly with pilot teams to review progress, which was invaluable as it allowed our team to learn quickly and to adapt the proposed process to meet the evolving needs of each pilot and everyone involved.
The final process looked quite different from that which was first defined and was launched in winter 2023 with support from several disabled persons organisations’.
Prototyping for Digital – the HSE Health App & Cork County Council
We’ve also been working with the research and design team at the HSE to support the development of the HSE Health App, launched in early 2025. During this process our work included the testing of “clickable” digital mockups, that feel like the real thing, with members of the public, patients, and staff in hospitals.
Sometimes these prototypes were very simple – but built to help us ask the right questions and get valuable feedback. Occasionally we just made these out of paper, with printouts of the potential app designs! Prototypes are useful if they evoke the response you need in testing to inform and learn what needs to be iterated.
A final example is the work we did with Cork County Council to explore the potential futures for their corporate services intranet service. The prototype in this case was “clickable” – it could be explored as if it were a “real” website, but made in Microsoft PowerPoint… a quick and easy, and very very cheap way to test with users, get feedback, and quickly make changes which might inform the eventual solution.
These are three, each very different, examples of building, testing, learning, and iterating.
How might we get started?
Getting started on this principle couldn’t be easier… it’s a three-step process… think of something you need to learn about your solution (a question), think of something you can make or show to get feedback, then go and meet someone to ask them.
This could be as simple as a sketch of a website on a page, setting up some temporary signage, or mocking up a new type of form for use in a service. It could be as complicated as piloting a new process with multiple stakeholders or hiring assets like furniture or technology to temporarily test something without needing capital investment.
Try it out. Don’t forget to talk to service users and affected stakeholders so that you get feedback. This is a powerful design principle that can really impact on how quickly and effectively we progress transformation.
