Day 1: Embedding Service Design and Agile Practice with UK Planning Teams to Create Services that Last
— Hello everyone and welcome to talk
- Embedding service design and Agile practice in public sector orgs in UK, with a focus on creating services that last
- Goal is to take some responsibility and long-term viability for products and services
— Question that led to talk, and frame as provocation
- Should service designers have a role in the long-term visibility of the service they develope?
— By viable, we mean fundamental definition of word, and not one cobbled together
— Viable: A viable service is one that not only functions well but can also develop, grow, and flourish
— Beyond working, and thinking how well service lasts, but focusing on maintenance and how it lasts beyond our involvement as service designers
— So in short, the answer is “yes”
— Explored service design in two parts
- Team that can build and how to embed agile approaches
—Service designers need to create a broader environment that enables the service to flourish
— Our context for the talk is as follows:
- New back-office planning system
— For context, in the UK, where we work, most public services are delivered by local government authorities
- Councils are responsible for various services, and local planning
- If you are local business, looking to plan something, you need planning permission from planning authority, equivalent to building permit
— Run by planning teams and highly trained and make decision based on local and national org
- On behalf of government and community need to make sure development is fair and legal, and that development to benefit community
- Local council makes sure approaches are cost-effective and efficient
— Many people involved in system
- Need to consider people outside of planning officer, and all who get valuable through systems
— Planning officers at the heart of the system were grappling with software that didn’t meet needs, with a lot of manual tasks, and lots of paper and documents moving around
- Hard to deliver outcomes as a resul
— UK government had invested in huge digital transformation and new products to apply for planning, share planning applications with public, BOPs to assess and plan applications, and other items
- Lot of different stakeholders brought to table, planners, policy makers, and wide ecosystem
— When started thought ecosystem might look like the diagram above outlining planning process
- Plan X— Product to apply for plans
- DSN— Community consultation
- BOPS— Enable planning decision
— Developing BOPs for five years, and vision has been to create something scalable and transformational at national level and how to get people to adopt and maintain it
- How did they evolve ecosystem to support scalable vision?
— Found they created team that could build and maintain a service— all people involved in service ecosystem who will live and breathed the service
- Bringing Agile mindset to public environment, where development has been relatively linear and involved doing workarounds for limitations
- While service around tech doesn’t function way it should
— Let’s remind people of Agile manifesto
- Better software comes from principles listed above
— Something to guide design and development and bringing together agile with user-centered design
- Working services over extensive mapping
— Talk through how built team based on manifesto
— Using image form design thinking to move beyond viable and flourished
- Think of relationship between desirability, (people want to use the system) feasibility (what is possible to build in a cost-effective way), and viability (the system works in context and things add up)
— Worked directly with subject matter experts, to share knowledge about digital and agile as they want and helped seed thinking on Agile and service design by local authorities themselves
- Adaptable approach to bring new people in, around ongoing learning
— Found working with team and deep understanding of what person brought and how to support each other
— Overview of signals of success with Agile methodology and key bridge for linking culture and activities on the ground
- Observing people online and in-person
- Co-creating by sketching
- Critique feedback and exploration
— Embedded in rapid 2-week sprint cycles to break away from processes
- Transparent way working with teams and designers, to interpret planning languages across whole service
— Agile meant we needed to bring together blended team working closely together
- Rather than linear hand-off, we needed teams to work side by side
- Short loops of iteration, rather than long loops
— Always worked side by side with sketching and design feedback sessions and observed user testing, and sessions across different domains
- Negotiation in middle allowed us to work through things together, outside of siloed thinking
— Useful for key challenge
- Balance localization and standardization of services and where to cater for different contexts and processes, and what planners needed systems to do for them
- Where were new powers needed to access relevant data
— Initially, working in blended team with planning officers and domain experts
- Limited to what they knew and more comfortable with
— Capabilities grew over time, and could engage in wider perspectives of feasibility, visibility, and desirability
— Example of this is where those who did workarounds, and collaborative approach to work with design principles with user needs and collective vision for process
- Moving from documents to data, and right information to users at right time
— With hearing planners reference themselves in conversation
— Users became more confident participating in design conversation and doing testing with own teams and approach with other councils
- Planners can also follow story of their collaboration and how input led to tangible improvements
— Often service design, can focus on desirability of puzzle, and making sure what people want to use
- Long-term though need to think about feasibility and viability
— By creating team that can build, can leave desirability to product owners, and focus on things like procurement
- Planners are process-driven, and constrained by tools they use, with little agency for requesting change
— Support planners and change to how they work
— Sheer number of planning application types to support, with own rules and legislation
- Designing and building with platform and new application types themselves
— Rapid expansion and delivery of working services
- Culture of planners as subject experts, with planners as experts driving process that enables change
- Shift in our role to investing and building community to tackle common challenges that fell in gaps of what was already done
- Read finer scope and what made service work
— All of this led to reducing time to process planning application by 30%
- Eliminating chances for mistakes and human error, and enabling planners to use training and skills for more impactful cases
— Wouldn’t have been possible with user engagement we did, to uncover nuances and fantastic service
- Team that could build and be part of ongoing basis was crucial
- Now challenge to procure and adopt BOP and make viable in public-sector market where people need what works now and IT teams want to buy whole thing to save money on
— So how can we create an environment where the service can flourish and how are service designers involved in that task?
— Idea of service ecosystem at start
- As we worked in ecosystem, saw interface of wider service ecosystem, and evolved to stage with 80+ councils involved, and national bodies involved and coalition of existing market players
— New team shifted our perspectives, and new challenges happened as we moved beyond viable product, and doing service design beyond bounds where we worked on so far
— Shift in perspective happened because of our team-wide perspective, to make sure we could meet procurement and feasibility needs, along with what could change planning as job to be done
- Not overnight, but done in an iterative and self-reflective way
- A new way of working developed
— New ecosystem layered on top of old one
- Looked at longer term outcomes, and how it led to better outcomes overall
- Interfaces between initial service ecosystem and enabling standards and strategies
— Required more stakeholder collaboration and integration of new perspectives into our services as we moved forw
— To sum up, we had question above: “Should service designers have a role in the long-term viability of the services they develop?”
— I hope we have shown answer is yes, and thinking beyond viable, and all things service needs to flourish in long-term and complex environment
- Loose definitions of service design helped us achieve our goals of good services
- Service Designs need to be able to fill gaps between what other people can do, and helping people do new things like service design through Agile
— Whether commercial company or public service, change is fundamentally about people
- Approach supported change, and helping teams flourish
- Need to build off conditions for ecosystem to thrive and then work carefully to bring parts of service together
— Here is a quick summary of signals of success to make sure it works for more general context
- Other stakeholders to form new teams and parts of ecosystem
— End with quote with Matt Wood-Hill, and service owner for open digital planning program, and helping government plan
- PlanX and BOPS helped develop a community for change, and great summary of our impact
— Thank you very much, and we look forward to questions
Questions
- What are skills, tools, and training to do this work on moving beyond viability? What did you have to bring in to make the practice work, and how it relates to common service design view on focusing on desirability?
- Value in learning-by-doing, and not calling ourselves a particular type of designer
- Asking certain questions and people working on council.
- Each team brought things to table and different products
- Embracing fact we don’t know, but being up for taking on new tools and processes— and tools will come as we deal with various challenges
- Value in learning-by-doing, and not calling ourselves a particular type of designer