The brief
Made Tech hired me to join the Homes For Ukraine Team to run a Discovery project in April – June 2026.
The Ministry For Housing, Communities and Local Government (MHCLG) created the service quickly in 2022 after the Russian invasion of Ukraine. They worked with a Big Tech supplier, Palantir, to build a service based on the Foundry platform. They then brought the system in-house to make it more usable and accessible.
The Share platform enables MHCLG, the Home Office and Local Authority staff to securely share data:
When I joined, the team were under pressure to reduce their team size. They hired me to run a Discovery project to find out how to reuse their in-house Share system and make a case for keeping the team at full capacity.
The team wanted to explore:
- ways of reusing the tech stack they had developed
- opportunities for working with other teams in the department
What I did
Researched my team
I’m a contract designer and I change jobs a few times a year. When I arrive at a new organisation I meet everyone I can to get a feel for the team and the culture.
- their deadlines – it turned out they had a service assessment coming up, on top of this discovery
- their timelines – my project was just be one piece of work in a bigger Digital programme
- governance – a Deputy Director sponsored this piece of work but they had another Statement of Work to write at the end of it
- the team set-up and size, and people’s likes and dislikes – these influence how I work
- the current strategy and goals they have in place
I also try to find out about the organisation’s culture, based on what they tell me.
Tested assumptions with desk research
For my approach I was inspired by Kola Wale’s article Designing with assumptions using a hypothesis-driven approach to service design in complex systems.
We researched the following:
- rules for procurement and tech infrastructure, including MHCLG’s data strategy and the government’s Green book and Technology Code of Practice (TCoP)
- news articles and academic papers about Digital Sovereignty and in-sourcing
- news articles about humanitarian crises
We were then able to challenge some assumptions:
Homes For Ukraine is set up to deliver a response to a humanitarian crisis. As the Iran conflict was going on in the background we could expect there might be another refugee crisis. However, it’s hard to predict when this was going to happen, or what the government’s response would be. The team therefore couldn’t assume they would be asked to deal with a new crisis in the near future.
We also learned government tells delivery teams to reuse technology where they can, and use in-house staff where possible. In practice teams often do reuse technology. They worry about funding, technical debt, service assessments and picking good solutions.
So, in future we could assume that other teams would want to work with us, but we’d have to work with their existing habits and goals.
Ran research
Service designers often run research. In this case I was asked to lead a small team including a Business Analyst and a junior User Researcher to run a Discovery.
We ran a total of 19 short interviews with teams and people, including attending large team show and tell meetings to get feedback from groups of people together.
We used the sessions to
- find out about teams’ services, including their pain points and challenges
- check which features of our service they would want to re-use – the service patterns, the tech stack, or an individual component like Single Sign-On
By the end of the discovery, we had a rich set of interview transcripts to draw on. We ran affinity sorting to pull out themes with good quotes.
We also had a shortlist of teams who would be a good fit for our team to partner up with in future.
I turned the main outputs into diagrams for our final Discovery report.
Co-designed a future service
I planned co-design sessions from the beginning. We brought back the people we interviewed to
- review our research outputs
- vote on aspects of our service they could re-use, to create a heatmap
- decide if they wanted to work more closely with the Share team.
Co-design helps us check our understanding and capture any ideas which haven’t come out of the research.
At the end of the co-design sessions, we had a clearer idea of how collaborations with other MHCLG teams would work. We also had a ‘heat map’ of which components and capabilities appealed to other teams, to reuse.
Created new operating models
The team already had written goals in place for the financial year. I didn’t have a say in rewriting their team strategy, as they had already agreed this with senior managers. The best way to influence their future thinking was to help them develop new operating models.
I ran weekly playbacks for the whole team to gradually evolve what these would look like. I took the team’s current size as a starting point: it took 24 people to fix bugs and deliver new features. Team members included UCD, Business Analysts, leads and developers.
We had found out where our team could find new collaborators, in the MHCLG ecosystem.
We also learned how technical teams make decisions, and how to influence them.
The outcome
The product owner and delivery manager went back to the funding board with a clear idea of what to ask for for their service. For my Service Design work I get people to think about the best service they can offer and work out their top priorities.