×

Category: User Centric Design

Service Standards for the whole service

How the service standards have evolved over time….

Gov.uk has recently published the new Service Standards for government and public sector agencies to use when developing public facing transactional services.

I’ve previously blogged about why the Service Standards are important in helping us develop services that meet user needs, as such I’ve been following their iteration with interest.

The service standards are a labour of love that have been changed and iterated a couple of time over the last 6 years. The initial digital by default service standard, developed in 2013 by the Government Digital Service, came fully into force in April 2014 for use by all transactional Digital Products being developed within Government; it was a list of 26 standards all Product teams had to meet to be able to deliver digital products to the public. The focus was on creating digital services so good that people preferred to use them, driving up digital completion rates and decreasing costs by moving to digital services. It included making plans for the phasing out of alternative channels and encouraged that any non-digital sections of the service should only be kept where legally required.

A number of fantastic products and services were developed during this time, leading the digital revolution in government, and vastly improving users experience of interacting government. However, these Products and Services were predominantly dubbed ‘shiny front ends’. They had to integrate with clunky back end services, and often featured drop out points from the digital service (like the need for wet signatures) that it was difficult to change. This meant the ‘cost per transaction’ was actually very difficult to calculate; and yet standard 23 insisted all services must publish their cost per transaction as one of the 4 minimum key performance indicators required for the performance platform.

The second iteration of the digital service standard was developed in 2015, it reduced the number of standards services had to meet to 18, and was intended to be more Service focused rather than Product focused, with standard number 10 giving some clarity on how to ‘test the service end to end’. It grouped the standards together into themes to help the flow of the service standard assessments, it also clarified and emphasised a number of the points to help teams develop services that met user needs. While standard 16 still specified you needed a plan for reducing you cost per transaction, it also advised you to calculate how cost effective your non transactional user journeys were and to include the ‘total cost’ which included things like printing, staff costs and fixtures and fittings.

However, as Service design as a methodology began to evolve, the standards were criticised for still being too focused on the digital element of the service. Standard 14 still stated that ‘everyone much be encourage to use the digital service’. There were also a lot of questions about how the non digital elements of a service could be assessed, and the feeling that the standards didn’t cover how large or complicated some services could be.

Paper and Digital

The newest version of the Service standard has been in development since 2017, a lot of thought and work has gone into the new standard, and a number of good blogs have been written about the process the team have gone through to update them. As a member of some of the early conversations and workshops about the new standards I’ve been eagerly awaiting their arrival.

While the standards still specifically focus on public facing transactional services, they have specially be designed for full end to end services, covering all channels users might use to engage with a service. There are now 14 standards, but the focus is now much wider than ‘Digital’ as is highlighted by the fact the word Digital has been removed from the title!

Standard number 2 highlights this new holistic focus, acknowledging the problems users face with fragmented services. Which is now complimented by Standard number 3 that specifics that you must provide a joined up experience that meets all user needs across all channels. While the requirement to measure your cost per transaction and digital take up is still there for central government departments, it’s no longer the focus, instead the focus of standard 10 is now on identifying metrics that will indicate how well the services is solving the problem it’s meant to solve.

For all the changes, one thing has remained the same thorough out, the first standard upon which the principles of transformation in the public sector are built; understand the needs of your users.

Apparently the new standards are being rolled out for Products and Services entering Discovery after the 30th of June 2019, and I for one I’m looking forward to using them.

Launch!

Producing Code or Fixing problems?

The role of Developers in user centric design.

I’ve been working with Developers of different flavours for almost a decade now, and in that time I’ve worked with some amazing Devs, and some frustrating ones; the same as any role it depends on the person.

I’ve also encountered a lot of stereotypes about Developers, primarily that they’re all introverts who like to work on their own, which is as true as saying all Product Managers must be extraverts.

In the last couple of years I’ve also been lucky enough to take part in recruiting and interviewing Developers, and as such I’ve found it fascinating to discuss the role of the Product Manager and the role of Developers, how we can work better together, to support each other and get the best out of each other.

I’ve found it very positive to see the role of the Developer begin to be more central within user centric design, and to have more Developers proactively taking part in user research and design sessions. The days where meeting user needs was solely the domain of the User Researcher and the Product Manager, and that Developers only cared about producing code felt like one we had, at least within Government Digital circles, left behind.

Code

As such, it almost felt like having a bucket of cold water tipped over my head to be told recently that Developers shouldn’t be overly involved in user research, and should be focusing on producing code.

As a Product Manager I don’t want Developers who just produce code, I’ve seen in the past the dangerous waters that can lead to. If you don’t understand why users are doing things, what their needs are, the problems we are trying to fix for our users, then how could you, as my technical expert, challenge me? How can you understand the options and give me advice on how best to tackle the problems we are trying to solve? How can you ensure the code you are writing actually meets the requirements if you don’t understand why it’s needed?

The best Developers I’ve worked with have been proactively working with the user researchers to suggest things to test, using tools like A/B testing to help explore the options and determine the best solutions we can test to help fix the problems we’re trying to solve, using feedback from users to iterate and learn and improve.

Product Development Team

I recently did a google search for the ‘role of developers in user centred design’ and was saddened to see there wasn’t much out there, other than a few scholarly articles citing the importance of getting Software Engineers and Developers to integrate user centric design into their approach.

So maybe this is where we are going wrong, maybe we are not talking enough about how important it is that user centric design isn’t just the domain of the designers and user researchers. That the principles of UCD are just as important in the development stage as the discovery phase.

As the Government Digital Service famously said, ‘User Research is a team sport’, and we need to makes sure everyone gets the chance to play.

What is the role of Business Analysts within agile?

Analysisng the role of the Business Analyst.

When we were looking at the Digital, Data and Technology (DDaT) roles and capabilities back in 2016, one of the roles we really struggled with was the role of the Business Analyst (BA).

Not because we didn’t agree that it was a role (because we absolutely did) but because we struggled to define the scope of the role in comparison to things like; Product Management, Design or User Research roles.

It’s one of the questions, that three years later still comes around regularly. Who is responsible for defining the requirements? What is the role of the BA?

Who holds the requirments?

The role of the BA in an agile team

One of the problems we had back when we were defining the BA role as part of the DDaT professions, was that the Government Digital Service didn’t have BA’s in their teams. Similarly, the original Scrum Manifesto only has 3 roles in an agile team, the product owner, development team members and scrum master.

Because traditionally, the BA acted as the link between the business units and IT, helping to discover the requirements and the solution to address them; when multidisciplinary teams bought those members together the role of the BA became less clear.

This has meant when adopting agile, different government departments implemented the role in slightly different ways. The biggest trap I have seen teams fall into was the BA getting stuck with all the admin roles for the project.

Roman Pilcher argued for those BA’s moving into Scrum there were two options, becoming the Product Owner, or becoming a ‘team member’.

While I agree that Business Analysts are a key member of a multidisciplinary team, I disagree with this assumption that everyone on an agile team who isn’t the scrum master or the PO is simply ‘a team member’ I think the Business Analyst is a critical role (especially for Product Managers!) that brings unique skills to the team.

So, first things first let’s look at what requirements are in the agile space.

Certainly, within digital government at least, we use a user centric design approach. We are developing products and services that fix the problems that our users are facing. We are identifying user needs and testing and iterating those throughout the product development lifecycle. A lot of the time this conversation about ‘user needs’ has replaced the more traditional conversations about ‘requirements’. Which is good in some ways, but has also led to a bit of confusion about what Business Analysts do if it’s not gathering requirements. Who owns the requirements now?

Are user researchers responsible for gathering the requirements from external users (user needs), whereas Business Analysts are responsible for gathering requirements based on what the business needs (sometimes called business user needs)?

That line of conversation worries me, because it suggests that we don’t need to carry out user research on internal staff, it forgets that internal staff are users too.

So, what is the role of the BA?

In my experience the conversation about who is responsible for gathering requirements is symptamatic of the limitations of the English language, and our obsession with ‘ownership’.

User researchers primarily focus on gathering more qualitative data; why users behave the way they do, how things are making them feel; probing their views and opinions to understand what it is they actually need etc. They will help understand who they users are and verify what the users need. They will work with the team to test design assumptions and help ensure the options being developed meet user needs.

Business Analysis primarily focus on gathering the more quantitative data about the process; both the ‘as is’ process, and the future process we are designing. They work to understand how many users are being or will be affected? What are the cost/time impacts of the problem as identified? What value could be gained through the implementation of any of the options the team are considering?

They help identify the stakeholders that will need to be engaged, and how to best engage with them. They will turn the user needs into user stories that the team can develop and identify the metrics and success criteria for the team to help them measure value.

Where you have a Product or Service that is live and being used by real users, the BA will work with Performance Analysts to understand the feedback data coming from the users.

User Researchers and Business Analysts will often work closely together, while BA’s will use tools like process mapping to identify pain points, user researchers will work with them to map the emotions users are experiencing so that we can fully understand the impact of our current processes and the value we can release by fixing the problem. When User Researchers are planning in research sessions etc., they will often work with BA’s to get the data on where best to test in terms of locations or user groups.

Good Product Managers will use both the Quantitative and Qualitative data to help them pick which options to test. Designers will help both the user researchers and business analysts look at the data and design prototypes etc. to test with users.

For me, each role is clear in its scope, and their need to work together to identify the right problems users are facing and the best way to test those; and it’s not about what individual owns the requirements, because the answer is the team do.