Article

Using the local digital declaration to get your digital work going

Photo by Amélie Mourichon on Unsplash

The local digital declaration is three years old as I go to keyboard. I was privileged enough to be around at the time it was being put together, had some small input into it, and helped to promote it. I think it is well and truly a good thing.

What it does is define for the whole local government sector what digital is all about. It removes those misunderstandings that digital is just about channel shift, or better websites, or one single other thing. It explains that while good digital is not just about technology, it also is about technology, and how you have to get that and the culture right to make progress.

Hundreds of councils have signed up to it. Many did so, I am sure, because it was a commitment to doing things right, and because they believed in it. I suspect some signed up because they wanted to be in the cool crowd, even though they weren’t really bought into the whole thing. Plenty signed up because it meant they could apply for some funding. That’s a shame, but it’s understandable.

The truth is, signing up to the declaration is easy (thanks to it being a good digital service!). Living up to it is hard, and I would wager that not one single council could really say they are living and breathing every ambition and commitment in there. But that’s ok – it’s fine to be aspirational, as long as you are actively aspiring, and not just doing nothing.

Signing the declaration, or making a big deal of trying to meet all of its statements if you signed it a while ago, is a great way of getting some momentum going on your digital work.

Here’s 5 ways how to get cracking right away:

Use it to get the bosses excited about digital

Get some senior people together on a Teams or Zoom call, and take them through the declaration. Focus on the elements of it that are likely to resonate with them, such as:

  • fixing the plumbing of poorly implemented line of business software and untangling the spaghetti of multiple systems that overlap and don’t talk to each other (apologies for the metaphor mixing)
  • focus on the transformation of organisational culture and ways of working, which will be at the top of many people’s minds, particular now as we exit the lockdown of 2021
  • emphasise the potential for sharing technology, research, experience and knowledge through the network of signatories, including the great funded projects that can be tapped into
  • maybe mention the funding too if there’s still some available. Free money always goes down well

Encourage the leadership that this presents a clear to do list to become a sector leader in digital, as long as there is some commitment to making it happen – and maybe have a few small exmaples up your sleeve of things you could get on with quickly, and can report back to show progress.

Start blogging

A key part of the declaration is bringing the really positive open working culture of the internet age into our organisations. The best way to do that? Start blogging.

Seriously, it is not hard – and it is a great test of your mettle as a change agent in your organisation, and of your organisation’s commitment to the digital agenda, particularly if the culture where you work is one where blogging is a tricky thing to get started with.

There are loads of models to follow, but the really easy one to do, I would suggest, is:

  • register a blog at wordpress.com – it’s free and easy, and you don’t need to ask permission to do it. Call it something like [Name of Council] Digital – simples.
  • write some weeknotes. Just a quick bulleted list of what you’ve done that week, if your nervous, or try something more contemplative if you’re confident about it. Check out the web of weeknotes site operated by Matt Jukes for inspiration.
  • when you’ve published a few posts, show your boss and explain how it helps meet the declaration thing you spoke at with them a few weeks ago. Ask if you can email a link to your weeknote to the leadership team every week to get them interested

Boom! You’re on your way to an open, digital culture. Now get cracking on laptop stickers and posters.

Run some service assessments

Sometimes this is seen as an incredibly daunting thing to do, but actually done the right way service assessing is a great way of introducing people to what is really important in delivering good digital services.

Now, for those working with very estblishment outfits like GDS and others, service assessments can be pretty formal gateway style checkpoints, to prevent poor digital services from going live. That’s exactly how it should be for such organisations, but if you’re just starting out, then a bit of compromise is needed.

Instead, use the service assessment process to demonstrate to folk across your organisation what good looks like, and how much of a positive impact just doing a bit of user research could have, or how we could be really sure our information security is spot on, or indeed how we could have saved money if we’d just used that thing IT bought last year, rather than buying another new thing just for this service.

Find some enthusiastic friendly folk to be on your panel. If you can find someone from another organisation who has done it before, all the better. People don’t need to be digital experts, they just need to be interested and curious, and maybe have had a read of the service standard beforehand, and be good at asking sensible questions.

At the end, rather than a strict go/no go decision on whether the service can go live, you’ll have a list of improvement that could be made to it, or maybe a checklist of things to do on the next service you’ll work on.

At Croydon we did a very early service assessment on our own digital blog which was a great, low risk place to start. Here’s the summary report which gives a flavour, and how it’s not that scary a process, not really.

Get involved in a funded project

The declaration fund enabled a lot of projects to get going, and several of them have survived into being in a usable state. That sounds like faint praise, but it isn’t – it’s only right as you go through the cycle of discovery to alpha then beta then live that some stuff drops out along the way. We can’t do everything all the time, after all.

Take a look through, especially those that made it to the beta phase, as these really ought to be thing you can make use of. I’m particularly proud of LocalGovDrupal – an open source, website in a box for councils that is now being used by several councils, including Brighton and Croydon.

If you’re at the right stage to make use of something built by the sector for the sector, then that has to be a great win for you, your organisation and your digital plans.

Join some networks and start sharing

Collaboration is key to the declaration, which is music to my ears. It’s what drives SensibleTech, after all, and inspires me to share this stuff with you all.

You can get together with others in exactly the same position as you in other organisations up and down the country by connecting through groups such as LocalGovDigital and OneTeamGov. There’s also a bunch of helpful people on Twitter who you can track down and LinkedIn can be useful too for meeting folk and finding out what others are up to.

Also take a look at the events that folk like Nick Hill run, which are free and provide loads of opportunities to meet and learn from others.

If you’re nervous and not sure where to start with joining some of these network, just yell, I’d be happy to introduce you.

Creating simple user personas

Photo by Daria Nepriakhina on Unsplash

Personas are a great place to start with user centred design, particularly if the whole practice is new to your organisation. This is because they can provide a quick and cheap way of ensuring your project puts the different types of user at the heart of your service design process.

Personas are fictional representations of the different types of potential users of your service. Well written ones can bring the important user types to life, which is why it helps to make them as realistic as possible. They also help to give the project team focus, by constantly reminding them of what really matters to their users. Finally, they are a great way of engaging stakeholders with your work, introducing personality and something relatable.

They can have their downsides though:

  • often personas aren’t based on user research, but assumptions
  • they can sometimes focus on what user’s want rather than what they need
  • they can get stale quickly – don’t fall into the trap of not updating them or using the same personas over and over again
  • They should not be the only form of user centred design that is used in a project – personas are not a shortcut or a tick in a box

So make sure you use them properly, and most importantly of all – do your research first!

To make your life easier, here is a simple template to use for your user personas. Feel free to amend it in any way you like to make it work for you.

Hope it’s useful!

Matching user needs with tech capabilities

Photo by Patrik Michalicka on Unsplash

Something that I have found helps an awful lot is having a simple way to match identified user needs with the technology capabilities needed to meet them.

It helps in two main ways:

  • by encouraging people to consider the user needs they are trying to meet before thinking about technology solutions (always tempting, but dangerous!)
  • by reinforcing the message about capability-based technology delivery, as opposed to always thinking in terms of single monolithic systems

By considering user needs first, then identifying individual capabilities to meet them, it’s possible to come up with solutions that are more likely to succeed and can often be cheaper and quicker to implement.

A good example of when I used this was when I was advising on a new intranet project. The initial requirements list had all sorts of stuff in it – HR policies, telephone directory, social networking, better collaboration (whatever that means!), and loads of others.

I was able to break it down into the needs we were trying to meet, and then come up with the technology capavilities to meet those needs. I found that adding an extra translation layer betwene the teo – tasks – helped with doing this. Here’s an example below:

  • User need: I need to know if my pay will increase this April
  • Task: quickly and easily access details of pay grades and scales, via search or navigation
  • Technology capability: publish pages of content

Pretty obvious perhaps. But let’s look at another need:

  • User need: I would like to understand the organisation’s policy on remote working
  • Task: find and read a policy document
  • Technology capability: share and manage versions of documents

Now, traditionally both of these things are requirements for an intranet. But broken down in this way, we can understand that we need an intranet to publish pages of content, but perhaps for the sharing of formal documents, a more specific capability is needed?

I then add a fourth column, which outlines the potential technology to deliver the capability. In the latter case, this could be a system such as Sharepoint or Google Drive, which may already exist in the organisation.

By following this process through with all the identified user needs, you’ll end up with a list of what technology you’ll need, along with a map of what you already have that can do those things, and where you have gaps.

To make it super easy, here’s a Google Doc template, with a worked example for the intranet, that you can copy and make use of.

Hope that’s useful!

Do you need a digital programme?

Photo by Alvaro Reyes on Unsplash

The mechanics of making digital change happen in an organisation can be really complicated. What works in one place may well not stick in another. It all depends on strategy, structures, politics and personalities.

One common approach is to have a clearly defined digital programme. In many ways it makes perfect sense: you have a strategy in place, and a programme to implement that strategy. Having a programme helps you bid for some (most likely capital) money to help make it happen, you get a clear timescale to work to, and some benefits (savings!) to realise – not forgetting a programme board to report back to the big-wigs on how you’re progressing. What’s not to like?

Let’s look at the pros:

  • Unlocks money ✅
  • Allows you to recruit people ✅
  • Buys technology ✅
  • Clarity of purpose ✅
  • Clear governance ✅

Sounds pretty good! But wait, there’s cons too…

  • Capital money will disappear ❌
  • Those people you recruit are only there for the length of the programme ❌
  • Have you set aside time and money to ensure your new digital products are transitioned to BAU support? ❌
  • What are you going to do about continuous improvement? ❌
  • How are you going to keep those big-wigs excited about turning up to your board, two years in? ❌
  • The admin overhead can be significant if you aren’t careful – who is updating the programme plan, and generating the highlight reports? ❌
  • You’re on the hook for those savings – are they really in your power to deliver? ❌

The last point is crucial and getting consensus on this early is vital. Capital funds for programmes are usually given on the basis of a business case – in other words, for every £1 invested, £3 is expected to be saved. But, whilst the money is funding digital activity, the savings won’t be coming from the digital team – they will be created within the departments where services are being redesigned. As part of a programme, there must therefore be absolute clarity on what savings are coming from where – and a willingness to offer them up when the time comes.

A digital programme brings focus, and resources. It will get you going for sure. The danger is that it is temporary and they rarely allow for the planning and investment needed to maintain a new digital estate in a business as usual situation.

They can also become real pressure cooker environments, causing stress, anxiety and burnout – so you do have to make sure you look after yourself and your team, especially in the run up to board meetings.

Sounds like I am pretty against digital programmes. Perhaps I am – my preference would always be to build a permament team to do this stuff. Make digital change the business as ususal! It takes out a lot of the stress and anxiety, and makes it far easier to embed digital ways of working, and the core concepts and culture of agile, user centred design and so on.

However, in the real world, creating a digital programme is a mandate to get things done, as well as a shortcut to funds, which means people and new technology, if you need it. If you do go down the programme route, then the two most important things to get in place, for me, are:

  • agreement and clarity on savings and where they come from
  • a plan for the transition to BAU for the new digital services, and a properly funded regime of continuous improvement.

Creating good, simple user stories

Photo by Felipe Furtado on Unsplash

User stories are the strongest way you can capture requirements for your digital service and are another key component in taking a user centric approach to design.

Rather than the old way of doing things, of producing a specification document outlining every single feature that a product needs to have, user stories focus on the needs of the users of that product, and specifically on their outcomes.

This focus goes a long way towards producing services that are usable and deliver end to end, rather than breaking down halfway through because a feature ‘works’ technically, but doesn’t do what is expected or needed.

Additionally, user stories can be a great way to bring a product to life when describing it to stakeholders. It really demonstrates a new way of talking about digital services and technology, and can be very meaningful to non-technical folk, giving confidence that you’re doing the right thing.

In a multi-disciplinary team, the user stories are usually the domain of the product manager, written with the input from the rest of the team. If you don’t have all the roles in your team, then do try to have a single person responsible for the compilation of user stories – and try to have someone non-technical doing it, to avoid the temptation to leap into solutionising too soon.

Writing a good user story follows a certain format:

  • As a…
  • I need to…
  • So that…

For example:

  • As a new, and busy resident who drives to work in the town centre
  • I need to apply for a parking permit online
  • So that I don’t run up loads of parking fines

That’s quite a high level example (often referred to an ‘epic’ story), so we can probably come up with a more granular user story:

  • As a resident who has applied for a parking permit online
  • I need to be proactively kept informed of the progress of my application
  • So that I don’t need to keep contacting the council

Note that the user story doesn’t explicitly state here what the solution is. The focus is on the outcome that the user needs, not the technology that will enable it.

The technology is likely to be mentioned in the second main element of a user story, which is the acceptance criteria. These are descriptions of what done looks like for this story. The GOV.UK Technology blog shares a nice method for writing good acceptance criteria, based on the pattern ‘Given… When… Then…’.

Additional information for a user story might include the prioritisation of that story, so the team know how important it is to get that story completed, and also the size – how much effort is likely to be needed for the story.

Here’s some tips for writing good user stories:

  • Keep them small. If they start getting to wide in scope, treat them as an epic and break them down into smaller stories
  • Avoid the temptation of repeating your ‘I need to’ in your ‘So that I can’ – which is a really common error. For instance – ‘As a manager, I need to access my team’s performance dashboard, so that I can view the perform dashboard’
  • Don’t treat individual technical pieces of work as user stories. They might be important to the project, but that doesn’t mean they directly contribute to meeting a user need, and doing so can clog things up and spread confusion about what the outcome of the project is intended to be
  • Try following the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) formula for producing good user stories. It’s a handy framework to ensure your stories are what you and your users need. Read more about that here.

To make life easier, here is a simple template for writing user stories. Feel free to amend it any way you like!

Hope it’s useful!

Load more posts!