In this blog post I will reflect on what we learned about designing digital services in the City of Helsinki last year, especially focusing on agile implementation and product-orientation. In this blog I will discuss:
- Why delivery is so important?
- Why product thinking is not the enemy of service design?
- How can agile help service design?
Many of the learning in this blog are things I wish I knew two years ago. At the same time, I know my thinking will change again this year.
It was around 2013 as the mantra “strategy is delivery” surfaced in government digital transformation rhetoric. Ten years later, it is still the top learning for our design team working on one of the biggest website projects in Finland.
…it is notable that delivery of services, whether they be information or transactional, has come before final strategy work is completed. Or put more simply, in an analog world policy dictates delivery, but in a digital world, delivery informs policy. This is what agile means for Government and its services… — Mike Bracken, 2013, UK government digital service
Delivery is always a compromise
In our design team, we have recently learned a great deal about implementation and actually releasing new products and services. This past year we have released 7 new websites and built 2 digital products. While our starting point has always been a mission to deliver a new CMS platform and get rid of the old one (with 580,000 pages), we had also adopted other goals for our transformation journey. We want to dramatically improve customer experience and transform how our city organization develops services in a user-centered agile way. Yet, I realized this year that it is only so long that one can focus on strategic missions without actually delivering a product or releasing a service for end-users. I still feel somewhat uneasy about the compromises we need to make as designers in order to deliver. But in the end, we can achieve better quality and culture change when we show results and actual new services, versus aiming constantly too high and releasing nothing.
What we learned about delivery:
- Aim to release quickly, even though the product or service is not perfect.
- You will learn important lessons from delivery as it is almost impossible to know beforehand what is needed and what actually happens during those steps to MVP release.
- To release quickly will also help you improve the solution as you see how the service is performing and users are giving feedback. Even the best user research and testing beforehand cannot perfectly predict what you need to know about user needs and the service concept. We also need to know how it actually works in operation.
- To make sure you keep the high-level mandate, commitment, and funding for design and user-centered development, it is important to deliver and show results. If there is pressure to cut down design and focus on technology-led platform migration, the best way to keep things design-led is to appease and show you can still deliver actual services and products. It is important to also show that the migration is progressing while your organization has been successful in learning new skills and mindsets.
As a service designer, I have always felt that product thinking is the opposite of service thinking. This past year has taught us that product thinking can support service design. I rejected this idea for a long, thinking it results in me having to compromise my mission to create end-to-end services. Lately, we have realized that product thinking can actually help us deliver those end-to-end services. Product thinking helps us understand what are the common nominators for services: what patterns are shared between business units, and what functionalities, features, and page templates form the basis for all services. Furthermore, product thinking enables us to be more cost-effective in building digital services.
What I mean by product?
In our case, we have one product “the hel.fi” which is built on two platforms: one using WordPress and the main site using Drupal. The platform means that we have the product and its DevOps capabilities set up. This enables anyone inside the city organization to start building their website. Drupal is a technology type, but the platform is something we created for the city of Helsinki. The product is the compilation of UI components, page templates, integrations, and the CMS itself. Since our WP and Drupal executions still differ from each other, I feel like saying we have built two products. Yet, in the end, we should have one hel.fi product that enables anyone (in the biggest employer organization in Finland with 40,000 employees) to develop a website that 1. looks and feels like Helsinki, 2. has all our core system integrations built enabling the use of data, 3. offers key additional modules such as search, media bank, etc., and 4. has hosted with DevOps (in our case Azure Openshift platform).
With themes such as living, education, or healthcare, I used to think that designing a digital service concept should always be distinct and unique to each theme or service area. I used to think that it is impossible to create an over-arching concept for a city-wide website with such different types of services. Yet, we have learned to understand that there can be and should be some shared basis — a product with building blocks and rules and patterns.
Product thinking has also led us to understand why we need to combine my team’s work with the existing Helsinki design system and create one shared design system. Product thinking can help us achieve an important goal of unifying the digital experience in city service and communication channels. Developing a product and a design system ensures that everyone is using the same basic structures and building blocks, even when the service itself is very distinct.
How to use products to deliver end-to-end services:
- Use product thinking to identify the minimum shared patterns, structures, and building blocks. You will save resources and create a sustainable way to manage and develop your digital services.
- Create a product to ensure delivery and it will allow you to focus your efforts on the services, customer experience, and impact.
- Aim for one design system across technologies. This will be the only way to really achieve a unified customer experience across different channels.
- Product thinking is not a competitor of service design, but more like an ally. Product thinking will teach you about the implementation of concepts and delivering services.
Agile development and service design
As our software development team started out in Autumn 2020, I kept googling for answers about combining design and development. I knew we needed to adopt agile, but I kept struggling to fit design into agile. We were lucky to have agile coaches join us and help figure this out. They did not have straight-up answers and prescriptions, but they helped us to discuss and experiment, in effect co-design, our own way to combine design and agile.
Why agile is not enough
As a service designer, I was struggling to explain why design could not be neatly fitted into agile. I felt that it was not enough to get one sprint for design before software development. I felt it was important to gain a deeper understanding of users, systems, and the current situation before jumping into implementation and solutions. I felt that we needed a co-designed service concept, not a quick-and-dirty product vision canvas. I felt we needed to have the business side ownership and not a software focus. I felt we were about impact, people, and daily life — the city is primarily, after all, a place and community, not just a bureaucracy or an organization delivering digital products. I still feel this way, but we have found a way to keep true to our design philosophy and learn agile software development.
Here is how service design is making agile better
- A deep empathic understanding of users, customers, and residents of our city is needed to deliver the services and impact we aim for as a city. Service design will help us achieve this with user research and co-design.
- Service concept or service vision will help guide the development with a strategic North star. A service vision is about customer experience, strategic impact, and holistic end-to-end, front-to-back, multichannel services. Service vision helps tie the product to business goals.
- We deliver services for people and help make daily life in the city more meaningful, happy, and sustainable. Developing software is one of our ways to help make that happen, but it is not the main purpose of a city. Service design helps agile bridge the gap between technology and business.
The secret is in the rituals, roles and MVP
How did we then actually do it? We learned a lot about rituals that can help us communicate and work together. We learned about the different roles we need to succeed, especially about the integral role of the product owner (PO) and what it means in our city context. We learned about defining MVPs in order to avoid the waterfall trap.
Agile rituals work well with design
What can you do when you have around 15 designers, 15 developers, and 15 POs working on 2 products and 20 digital services (and 800 content producers and 750 services with over 1000 digital channels)? It becomes impossible to run the usual project meetings or just adopt the basic agile rituals. We had to design our own rituals, and we are still iterating.
Two weeks sprints with ritual day
Rituals keep us together, otherwise, we might be so deep in our own corners of work that we would not come together and see the big picture. Having two-week sprints and ritual days enables this. We have a series of reviews, then a retro, and finish with sprint planning.
Reviews make our work transparent as we show and tell what we have been working on, give each other feedback and make sure we are moving in the right direction.
Retros are important for mental wellbeing and team spirit, but also to address any problems in our ways of working often enough. Retros can be a draining therapy of complaints, but we have been learning about improving our retros also. Here’s a guide for better retros from our agile coaches (only in Finnish).
Sprint planning allows us to use a shared tool (Jira) for project and product management, yet the main benefit of it has been in prioritizing work and evaluating workload. We are still on the fence about whether Jira is the best tool for managing service design sprints, but it has been important for learning about the tool and documentation style that eventually is needed when our designs move to development.
A product owner helps keep the ownership in business
We hosted a series of workshops with our first product owners in the city of Helsinki back in late 2019, and early 2020. We found out that there is no such a thing as official product owners, I mean the kinds you read about in agile guides. The Helsinki POs were a mixed combination of project managers, business owners, and tech leads. There were no unicorns.
With the start of hel.fi project in summer of 2020, we took up the challenge of creating a generation of “real” product owners. I guess real here means we wanted to design a PO role that would suit our city’s needs the best way.
Most of the people working on websites in the city have been communications experts, not the ICT people or the business people. Our mission was to bring these people together during our hel.fi transformation program. For PO roles we ended up getting mostly communications experts as they had the motivation, allocation, and ambition to lead our new websites. The challenge has been that most communications people are new to user-centered design and agile software development. That 15 POs we now have, have been the pioneers and courageous champions that have taken the tough journey to learn a massive amount of new skills and adopt a totally new mindset.
How to go from zero POs to 15 great ones?
1. Find the likely crazy enough first two people go for the unknown. Throw them at the deep end of the swimming pool and they will learn the ropes. Support them the best you can.
2. Set up a PO coaching program. We designed a series of 9 coaching modules to teach our new POs the role during their first 8 months while going from service design to MVP release. Our modules teach the POs about service design, agile, working with software development, managing and prioritizing backlogs, figuring out MVPs, and setting up CX metrics. Our three agile coaches do these training together with the design team.
3. Find and cherish the agile coaches you have. We have had amazing coaches Miika and Karo from Withmore. Their positive attitude, incorruptible agile mindset, and persistent resistance to bureaucratic suffocation have been defining in our success.
4. Do not just train POs about agile, but use the training to coach them about service design and user-centered development. We start by introducing our POs to a fantastic online course on service design in government, open for anyone and developed by HAUS (only in Finnish).
MVP definition is a tool to build an outcome together
One of the things we have struggled the most with has been MVP definition. Our releases are running late and our MVPs are too bloated. This leads to a very long time until we see what the end-users think about the actual delivered service. It also leads to our design team and software development teams working inefficiently as projects pile up and queues to development grow and grow. Learning about the MVP mindset and developing the right process of MVP definition and documentation have been crucial for us this past year. Here is what we know about it now.
Reflect and iterate
Constant reflection and iteration keep you learning about why the MVP definition is failing. We have identified five core challenges for MVPs in our general work:
- What is an MVP if the queue to development is over 6 months?
- What kind of MVP documentation is useful for different actors, such as software developers or POs?
- If you have 15 services or projects in your kanban, prioritizing across projects to find a product backlog is hard.
- Uncertainty of what happens after the MVP release will make POs and business leaders bloat the MVP requirements.
- MVP in agile focuses too much on features, not addressing issues such as content production.
We are now starting up our fourth cycle of MVP definition, with 3 projects at each cycle. Each time we learn what worked and what did not. We are currently implementing the following style of MVP definition.
MVP mindset needs coaching
I have personally learned a lot about the MVP mindset from my own PO work for the Playbook we delivered with Futurice. Then my MVP was crystal clear (“supporting new POs at the beginning of projects”) and it helped me to relax about all the million things I wanted to also include in the service. To accumulate MVP thinking and the right mindset in POs and their core teams, we start the process with a 2h workshop with our agile coaches facilitating. From there the MVP definition process will continue for 3 x 2 weeks during which the PO will get intensive coaching on MVPs.
MVP documentation helps with handover when you get it right
At first, we just thought we needed an excel sheet of Jira-style user stories for our MVP documentation. This was something that service designers needed to help the PO do at the end of the concept development, in order to achieve handover to software development. The idea of service designers doing the user stories for developers seems funny now, but I really thought it could be done. We have had to learn the hard way that it is not the way. Developers need to be involved in writing user stories, and most of all there is a lot of refinement that needs to go on first before a Jira-level ticket is born.
Our five key outputs for MVP definition
- Write up your MVP spirit for the business side. Use for example an MVP canvas and visualize the value proposition, objectives, and metrics of the MVP.
- User story maps. Describe how core user journeys are delivered in existing components and what new features are needed at MVP and ideas beyond.
- Table of features. This one slider helps you to communicate efficiently the new features your service design concept has been drafting. You should include the justification and priorities for each feature.
- Wireframes, prototypes, or UI layouts. Depending on timeframes and resources, there need to be visual designs to explain the service and the new features.
- Site map for MVP. We design a site map for the service vision, but there needs to be one for MVP as well. The sitemap should include the pages, their hierarchy, page template, and the purpose of each page.
- User testing report is also an important part of our handover process. We do early testing with users when we involve them in concept validation. The reactions and feedback we get from users testing the service concept need to be included in MVP documentation as it helps guide the iteration during the MVP delivery.
We do MVP definition step by step during the last 3 service design sprints of our service concept model. It is a gradual process with outputs getting iterated and the PO gets support for managing the MVP vision and prioritization. Our services designers, UX/UI designers, user researchers, content designers, and architects all participate in the process and drafting of the documents. It is a group effort, while the PO should feel ownership of these artifacts.
Summary of key learnings on “strategy is delivery”
The past year has been a tough school in learning to bring design and agile closer. Here are three key learnings from the past year: Nothing is more important than delivery, not even strategy.
- Nothing is more important than delivery, not even strategy.
- Build product-first in order to design for end-to-end services.
- Service design is bad at implementation, agile will help remedy it.
- Support the growth of POs and get your MVP definitions right.