We’ve written on this blog before about our approach to transforming our customer experience. A key component of this has been the implementation of our new customer platform.
The Digital Team was an early adopter of the customer platform for hosting our website, which involved a concentrated period of development, data migration, testing and deployment to take live. (not to mention a few sleepless nights!)
We’re now many months into ‘business as usual’ after its launch, but work goes on making improvements and developing new services.
New microsite for Fostering
An early priority for us was to respond to a business need to help raise the profile of our Fostering service and create an attractive home for them on the web.
This was the second microsite development on our customer platform and was far quicker to launch as our developers were more up to speed with the customer platform; conception to prototype took just 3 weeks.
A key principle we wanted to follow was reusing components already developed for the main website to save time and reduce our technical debt. This has proved to work both ways, as new components developed for the Fostering site can also be used on the main website. A great example of this is our timeline component which provides an accessible process flowchart; we are looking to see if this can meet users needs for our Local Offer users.
This was also our first time working with an external agency to supply the design concept. At first this felt challenging, but the end result looks terrific.
The project wasn’t without its pain points, but we’re now starting to develop our rhythm of how to work together; batching work into sprints and liaising with our internal clients to sign off aspects as we go.
A product-based approach
So that’s great for projects, where there’s lots of focus and activity around delivery. How do we replicate that for ongoing development of the CMS?
We’re starting to move to a more product-based approach in Dorset to help create accountability, set standards and make key decisions.
Using technology layer themes we’ve identified a series of Product Owners with their own portfolios. Mine is for the ‘presentation and non-transactional services’ layer, which lines up nicely with the website, but also with web applications that we use and new developments in the customer platform we want to make.
Putting product ownership into action is proving to be an exciting way to work
Creating a roadmap
After we’d migrated the website to the customer platform, we found there were a growing number of things we needed to do to help make the site more successful. These included:
- addressing technical debt from the migration
- picking up suggestions from our accessibility audit
- working on feedback from users
- capturing ideas from content designers
Having a roadmap where a backlog of development is created is also a core concept for product owners, so this felt like a good fit here.
As our ICT developers were using Azure DevOps to manage and deploy changes, it made sense to adopt this for our roadmap so we could ‘speak the same language’ as them.
The advantages this brings are:
- we can break feature requests into user stories with their own acceptance criteria, or tasks for actioning
- we can keep all relevant documentation and discussions in the same place (which was really helpful for our accessibility report findings)
- we can prioritise and features for more easily batching into development sprints, ensuring developers have access to all the relevant information they need
- we can track delivery using the built-in Kanban board
It also helps ensure we don’t lose sight of what’s important to the business. A hot topic in the last week has been the need for an approach to Easy Read, so a new feature is being added to the roadmap for fleshing out in more detail as we gather more information on needs and good practice elsewhere.
Design Group
One of the initiatives we started in the Web Team was to create a working group to make decisions on new patterns and components for the customer platform (or changes to improve existing ones). We wanted to encompass our One Team approach in ensuring we gave an equal voice to everyone involved while having proper governance.
Our answer was to follow the good practice set by the LocalGov Drupal project in adopting Sociocracy as our way to work (you can watch a video of how this works on the LocalGov Drupal YouTube channel). Having a formal proposal written for any ideas ensures we have data to back up our reasoning or highlight existing design patterns we are using as a source of best practice.
This has proved a hit with the team – you can read our Content Designer Lee Baker’s thoughts on his blog – as it helps us document decisions and plan their implementation too. The mantra ‘good enough for now, safe enough to try’ helps us release changes more quickly but also reinforces the need to check their success and iterate where needed.
Examples of proposals agreed so far by the Design Group include:
- developing an accordion component to help users see an overview of longer content, based on the GOV.UK design
- developing a section-based notification banner for important messages on service disruption, based on the GOV.UK notification banner, but adapted for other uses
- removing carousels from our design system as evidence shows they do not work
- developing a long-form HTML content type as an alternative to PDFs, based on designs by Brighton & Hove and Buckinghamshire
We’ve also used the Group to help feedback on design proposals for the forthcoming customer account
Next steps
We’ll soon be working with our Communications Team colleagues on creating a new site for news and blogs. Once again we’ll be looking to reuse components and further refine our approach to development on the customer platform
