9 July 2021

Ideas into user needs and on to tasks

Blog from Oliver Hannan, Product Manager at the National Archives, formerly of London Councils.

I’ve been working with the LocalGov Drupal team on workflow, content lifecycle and scheduling. This means the team have been examining ways for users of Drupal CMS to regulate content before it’s published, apply lifecycle management to existing content and schedule content to be published or unpublished.

I felt it’s worth documenting how we did this to help other teams work through ambiguity. Specifically when taking proposed product features through to sprint planning and onto discrete tasks for developers. I learnt some new ways of working and will hopefully be able to apply them in future.

Form the group

The team at LocalGov Drupal is getting bigger. To aid decision making we formed working groups based on the sociocracy model, circles of nested hierarchy. I won’t go into that in depth here, you can watch a video about it, but the idea of reaching consent rather than census has been key to making decisions quickly.

The group we formed ended up being some product managers, a content designer, a Scrum master, a designer, developers and user researchers. Beyond these titles they are all lovely people. That helps! Some people wore multiple hats but it was a multi-disciplinary team and all the better for it.

Initial meetings were too broad and we underestimated the scope of the work. This style of working groups was an experiment for LocalGov Drupal but one clear learning was that defining the group’s “aim and domain” earlier would have helped us get there quicker. Aim = goal/purpose, domain= area of authority. Next time!

Slack, blah blah

We discussed what was required on Slack. LocalGov Drupal talks about a lot of stuff there.
Screen shot of Slack

Loads of people chipped in, sometimes we got stuck in the details but there was clear momentum and shared needs. But, Slack or any similar platform, has it’s inherent problems: stuff gets lost and prioritising is hard. That said, it’s still the easiest way to start the conversation on requirements.

It felt right to push on.

Miro this, miro that

We used Miro to initially brainstorm on user needs using the classic “as a X i need X so that I can X” framework. Doing it virtually was necessary as a distributed team, in person would have worked fine too.

In doing this we realised again, the scope was large and we were trying to deal with lifecycle and scheduling as one. Workflow naturally became the priority with scheduling a close second.

For the lifecycle problem we looked at other models in use, like Oxfordshire council. Then we wrote user stories for:

a head of comms or head of digital job role
content designers
and then users, generally.

This came pretty easy and we could make assumptions we thought were fairly safe at this stage.

Double diamond meeting

We didn’t get all the way through this process but it was a useful framework to look at the feature with creative thinking. Here’s the process we followed, feel free to make a copy.

In this instance we used the lightweight workshop template.

Miro doom

We took the Design Council work back to Miro and fleshed it out further. At this point I found it hard to understand if what we were doing would be useful for developers, it seemed far removed that we’d be able to translate user needs into discrete tasks. The Miro board we’d worked on was also now huge.

Here’s a link to just the stuff about workflow on Miro.

User stories, permissions matrix, approvals dashboard

Despite my doubts, we refined the user stories again, and got them down to even tighter versions based around permissions groups. For instance:

As a content editor, I can set a date when content needs to be reviewed, to ensure that information is accurate and up to date
As a content administrator, I can set a default review date for all service pages based on a policy (eg. yearly)
As a content administrator, I can see a view showing all pages that need to be reviewed
As a user, I can see when a service page was last updated/reviewed, so that I feel confident the information I am reading is up to date.

We also realised we would need to define the names of the permission groups. At this stage we had:

Author — user who writes stuff but can;t publish it straight onto the website
Publisher — can publish their own stuff and other users
Administrator — control everything else.

This seemed fine and I deferred to the content designer in the group who agreed it could work. This input seemed key, maybe content designers make digital government happen! Get this right for them and we’re on the right track.

This meeting could have been a meeting that could have been a…

Working group, structured

The group met again, this time using a more structured working group meeting format. The aim of this meeting was to define the group, it’s authority, time people could commit etc. in a formal way.

Here’s a link to the structure we used. Feel free to make a copy and save the document. We achieved the desired output and formalised roles.

Working group, rolling

We also set out a less formal rolling style meeting that could happen weekly. Here’s the structure we used. Feel free to make a copy and save the document. These meetings were in our calendars to make decisions quickly using the sociocratic style aim to reach consent not consensus on proposals made.

We would move on unless anyone had “a critical concern”. This was successful, we made clear decisions and shared them back to the wider group. Decision included which terms to use to define permission groups, (which was then iterated on a couple of times) and to test existing Drupal modules as MVP.

This meant we could use something as a prototype before writing any custom code based on the very specific requirements we had. These routes may seem straightforward but I’d guess they would have taken substantially longer had we opened them up to the full LocalGov Drupal group.

I had concerns that we were making these decisions across LocalGov Drupal with only 3 councils present. It remains a valid risk that we’ll produce work that only fits those 3 and isn’t much more than UX theatre. This concern was challenged by iterating again and again with the users we could reach and always sharing with the wider group of councils on outcomes.

I also reminded myself that this was a set of features for internal users — councils officers, content designers, and other local authority staff. They were the users being consulted here. Finally, the process was being facilitated by a multidisciplinary team (even if some of the processes were new to some of us) and an experienced designer and Scrum master from Agile collective.

Sprint planning

The next stage was sprint planning and I attended to help where I could with translating the work for the devs involved. David, a product manager who originated a lot of the research and Ben, who played a vital role as content designer, couldn’t attend.

This was challenging and I felt I didn’t know the stages David had outlined well enough. Learning here would be that it’s better to have more people who know chunks of a process or feature than one person with a grand plan. Is that obvious? Maybe, but it’s also hard to execute. Decisions made in our rolling meetings were discussed and translated into Github issues and planned into discrete tasks.

Github

David did a great job in getting the work into GitHub then as a group we iterated further. We made sure they could be worked on as tasks we all agreed on. I’ll be using what David did as templates in future because I think they worked well.

Have a look at the work so far.

Steps we took (recap)

Ideas

As a group, LocalGov Drupal has a lot of ideas about what needs to be worked on. Shared needs can be fairly obvious, currently there’s too much, so the prioritisation work needs to encompass what’s most important and what’s possible. The learning here is that doing too much is a real danger and we underestimated the scale of the work. Addressing this as early as possible would have been better.

Form the group

Forming the group who were interested in this problem was quite simple but getting commitment to time wasn’t that easy. I’m not sure that will change as we progress. The individuals involved in this particular problem were all willing to work through ambiguity as the first working group.

I personally found that a real challenge but I was also ready for it and this might not always be the case. The learning here was that trust was important. Using new ways of working to solve knotty problems is a challenge and you need patience.

Chat!

Getting the chat going on this topic happened naturally but it still required enthusiasm and coaxing at times. Often I couldn’t devote enough time and I couldn’t attend all of the meetings. The key stakeholder here was a busy content designer who had loads of competing priorities.

Reporting back in a measured way was key and the learning was that the reporting efforts needed to be counted as part of the work, not extra. Meetings should be recorded and decisions should be stated clearly on Slack and in minutes. I’ve found the asynchronous ways of working that LocalGov Drupal employs generally do work for that.

Workshops

We did a series of workshops to capture user needs, ideas about how workflow should exist and to build personas. These were time intensive and often quite draining, we ended up with an intimidating Miro board. That thing is huge. The learning here was that skilled facilitators were key, we definitely had that thanks to the Agile collective’s input.

Both to run through the Double Diamond work and the sociocracy model for making decisions. Thanks Maria and Richard!

User story refinement

Refining the user stories and research over and over seemed pretty far removed from any actual tasks for the developers involved. The learning was that by the time we reached sprint planning, the work David moved over to Github was quite well formed.

By revising again and again the content designer and product people in the group could talk about it in a language that was transferable to tasks. That was then put into sprint planning. Trust the process.

Meeting: formal and ongoing

By formalising the group in a very well structured meeting we defined who was doing what and when. The notes taken were key. After that we could have quicker and more targeted meetings that were a bit more fun. The learning? Taking notes and sharing them is important, it might not seem that “digital” but it prevents any Jackie Weaver moments.

Tasks for developers

Translating all of this into tasks for developers was daunting. The learning was that without structure and facilitation it would have taken much longer and results would possibly have been less well coherent. Hours of workshops did translate to tasks and hopefully we’ll get quicker at that.

This blog first appeared on Medium.