Remote writing: technology for the online writers room

How can a team of writers create a story when they don’t share the same city, schedule or way of working?

That’s what my two writers rooms faced. And to make the problem more complex, both teams started with a mere seed of a story idea.

Fortunately the writers rooms comprise 8 extremely talented writers who are willing to engage with the problems and to share their own approaches and ideas.

This post is about how we overcame these obstacles and how we adapt to new ones as they come along, for the project is still ongoing. It’s about how you can write together as a group remotely, in your free time, using free tools.

The problems

I formed 2 writers rooms, with 2 different story ideas, but the same goal — to create a story as a team.

The end goal is not to have a finished book or screenplay, but a detailed summary breaking out what will happen and in what order.

I chose this goal because a strong story comes across regardless of format — though the medium is important to shaping a story, I took the idealistic approach that a good story can be told in a variety of media.

The aim was to get the story in its clearest form. To me this is a treatment, a summary of the story.

To get there that we need a range of tools to help us explore ideas, comment, develop them, review and refine then review them further.

What we wanted

This project is much an experiment to find how best to write remotely using Agile methods as it is a goal to produce a good story (with the aim is to succeed at both).

The team knew it was an experiment and shared their technological or availability constraints.

But before we delved into looking at technical solutions, we had to solve the biggest barrier — personal separation.

Technology cannot replicate what it’s like to meet and know someone. That meant the teams had to meet each other.

This involved a kick-off workshop in person and was a key requirement. A one day workshop won’t solve all problems of knowing others, but meeting in person meant writers were more than just avatars and faces on a web chat.

Only then could we look at problems of technology. Only then could we look at using technology to help us talk.

Tools for the job

First it was agreed that whichever tool we’d use, we would approach each other with respect and to be constructive regardless of the medium.

Second, it had to be fairly straightforward to use across the range of technologies that the writers had.

Finally, it had to be free, or at least very cheap, as this project has a tight budget.

Through my freelancing I was used to Trello, Google Drive and Slack (a holy trinity in UK government when it comes to project management). They’re free so I used them along with Zoom:

  • Zoom (with subscription, free plans available) for conference calls — it works across multiple platforms and allowed writers to dial in from around the world without too much faff
  • Trello (free) — to manage tasks and resources (such as definitions, examples of templates and so on). Mainly used at beginning but to help team understand the documents as they grew. Cards were used to discuss ideas
  • Google Docs (free) — for longer ideas and for scene exercises. Handy for leaving comments on ideas or for free text, though the default of view-only sharing and having to submit comments keep causing problems
  • Slack (free) — each team had a channel to discuss ideas, one to schedule catchups (with simple voting on dates) and a general channel for both ideas

Review of technology

These tools have largely proved successful. The work is progressing and we are learning, which are the chief measures.

Most of these tools were new to the writers but all picked it up quickly and took the initiative. Slack has proved the most used, from ideas discussion (though these sometimes need corralling into a new document) and for general updates and reminders.

Getting Slack to do automatic reminds and nagging with its bots has helped take some pressure off managing two teams.

If I had the budget I think that combines many of the above but for now it’s too expensive.

Technology is just a tool for better stories

The aim of all this of course was to produce a story. Technological tools are great only if we have something to say.

Next time I’ll show you how we started from a simple idea and developed it into a complex story with a range of characters.

The project is ongoing and I’m happy to discuss further with if you’re interested. Despite the name dropping this post has not been sponsored or endorsed by any company.

Originally published at


A problem with crafting stories

Why would someone hire a team of writers to form a writers room when they don’t already have a show in production?

For an experiment in storytelling.

We devour stories and we consume more every year, thanks in part to the growth of online video through the likes of Netflix or Amazon Video, audiobooks with Audible, and the increase in book and comic sales.

Being “ story telling animals” it’s no big surprise. And technology is helping us get more stories.

I’m a great believer that technology is a tool that enables people to fulfil desires. And we desire stories.

The growth over the past decade of decent internet access and things such as cheap ereaders and cheap, high quality internet subscriptions, and free user generated content on YouTube, blogs, podcasts and story sites means that we can get an unimaginably large amount of stories cheaply and quickly.

This boom is not just related to fiction. There has been growth in factual stories — TED talks and even better PowerPoint presentations, along with ‘scripted reality’ shows such as Love Island.

New technology, same methods

Yet with all this technological change, there has been little innovation in how books and screenplays are produced since the development in the USA of writers rooms in the mid-20th century.

I’m generalising massively but stories are still either created by:

  1. A solo writer or a pair of writers (rarely more) who write an original idea or is commissioned to do so by others, such as a production company
  2. A writers room of a group of writers who’ll discuss ideas and then go off and write an script by themselves, almost always for a TV or radio show rather than a film

Even with the input of and editors and showrunners, the bulk of the writing and fleshing out is done by one or at most two people, often working in a waterfall method.

That is, writers go away and write a couple of drafts, get some feedback and it’s either adjusted or shelved. This feedback can be from an editor, agent, producer or a creative writing group.

For professionals and amateurs this process broadly the same — the writer acts in isolation from feedback for much of the time.

The problem with waterfall

This means that for both professional or amateur, feedback on writing is usually at the final stage. That’s fair enough, for it takes time and effort to help someone and go through their writing and they want to see something finished.

So feedback is often given towards the end, once the bulk of the story has been completed.

When a lot of feedback is given at once you have to pick and choose the most important feedback to give. It could be about the character, the structure, the writing, the plot, the ending or a key scene. And if there are a lot of things to fix you risk being overly negative doing it all at once.

Even getting quality criticism can be tricky, which is why there are many services offering script and novel feedback for writers. But there’s no guarantee they can fix all problems and for new writers selling a story, agents and producers want something ready to go, pret a vendre, not something that they have to work on.

This means that unknown writers with a story that has a core of a great idea but too many flaws, no matter how fixable, have little chance of a sale.

Better writing through better processes

One innovation brought in when the Government Digital Service was launched was that teams would use Agile project methodology for all projects.

Including writing content for webpages. It was a revelation.

Joining an Agile writing team helped in several ways. First the focus was on the audience, what each page needed to tell them. breaking each page down into its structure, reviewing with colleagues and subject matter experts, writing it, reviewing and writing cycle.

While a single writer could have got something live quicker than the team, the page that did go live had consistency, quality meant it would stand longer and serve more users.

So if it works for web content why not creative work?

Agile creative writing

My first step was to test as a concept. I created the Agile Storytellers Meetup in London to test the concepts while teaching writers about Agile.

My key learning from this was holding a retrospective at the end of each to iterate on what works (or doesn’t).

Combining my learnings from this along with user research and conversations with those in the industry I developed some principles:

  • Quality sells — contacts can get you in to an interview but without quality there’s no point
  • Make it a page turner — if you don’t make it interesting no one will want to read it
  • Work with others and their feedback, but have a clear vision of what you want — feedback is useful but must be in the context of your lodestar, your vision of what you’re aiming to achieve

So I set out advertising for writers to join me while we aim to put this into practice. And that’s how we’re working on a screenplay and a book as a writers room.

Next time — the problems with team writing and ways to fix them.

Originally published at


Of faxes and futures — Agile storytellers March 2019

How can an idea go from a light comedy about a weatherman getting accurate weather predictions by a fax machine (of all devices) become a Cold War industrial thriller set in Antartica about sex discrimination? Through the power of Agile of course.

At the latest Agile storytellers session we focused on Agile brainstorming and idea refining techniques to make ideas good enough to proceed with.

So this was a two part operation — not just coming up with ideas, but using Agile methods to focus on getting results quickly. And we did it using loglines.

20th Century Fox

Out of many, one idea

Loglines are one-line summaries of a film’s plot. Examples include:

“A New York cop in LA to reconcile with his wife must save her when her building is taken over by terrorists” — Die Hard.

“The youngest son of a Mafia don is reluctantly pulled into the family business when he must avenge an attempt on his father’s life.” — The Godfather

We had a lucky dip of print outs of different loglines we found on the internet, each drawing about half a dozen and then putting forward the 1 or 2 we thought best from our selection.

We then held a simple version of forced ranking, an Agile method of making people have an opinion on things they didn’t have.

The first logline we lay down was set us our middle rank and the other ideas were then laid as either better or worse in relation to it. We then reached the top 2:

Logline A: “After discovering a fax machine that can send and receive messages one day into the future, an impossibly inaccurate weather man struggles for career advancement while trying to maintain the space/time continuum.”

Logline B: “Two gay men from San Francisco move to a small Wisconsin town to open a sushi dance club.”

Deciding on and refining an idea

Both loglines had an equal amount of supporters in our vote. Taking an inspiration from 6 hats thinking we looked at it beyond our initial feeling. While we thought the sushi club sounded fun, we didn’t know enough about being gay men in San Francisco and/or Wisconsin, nor sushi or dancing to be able to make a story that didn’t rely on stereotypes and assumptions.

We then took our chosen longline as our draft vision statement. This meant it needed to be unambiguous, clear, fit with our values, be realistic, and short.

How to do this? First we thought about the questions and ambiguities that the statement prompted. We wrote each question on a sticky note then reviewed and grouped each question around a group, deciding on and labelling the groupings as:

  • The character
  • The rules
  • The setting

Now we could have had these groupings already planned as these are fairly standard throughout stories, but it was good to see them come about organically.

Everyone has ideas — everyone

Now it was time to get ideas on how to flesh out the story from these questions. But not everyone said that they had ideas. They were wrong.

The idea ball (roll of tape in this case) was thrown around the group. Every time the ball was received the holder had to come up with a suggestion for one of the 3 groupings or else pass. The ideas were noted.

Each idea could be independent of what went before and the aim was to generate ideas, not to critiquing or question too much on previous ones (although we did slide into that some times).

By the end and despite initial protestations of being bereft of ideas we had a rough idea of the character, where they were and when it was set and the rules of the world.

Being led by ideas, not forcing them

It was near the end that the rule about the fax — which had generated the most queries in the sticky note section — went from being a magical fax from the future to a regular fax, but with a message picked up by someone who shouldn’t have.

In part it was because we kept asking how the fax worked, what the timeframe of its predictions was, what the protagonist could do to solve the problem. Seeing as we saw it related to climate change, fixing it in a day was unrealistic, to put it mildly.

So we asked where would climate be important, the most visual place? After debate we decided on Antartica and once we did that ideas flowed.

That the protagonist would be locked up at some point and have to escape, that something big had to happen (a glacier collapse). That it had to be man-made so that a man could stop it.

But then we realised why a man, why not a woman, particularly as most of the group at the meetup consisted of women?

So why was she in Antarctica? To prove something? And while sexism is certainly no longer vanquished, the fax as a sole means of communication coupled with a more sexist time seemed appropriate.

Short time, many ideas

By now time was catching up on us and we still lacked a story, though we had ideas and a protagonist.

With pass the card we each wrote an idea for one topic then passed it on to be added by the next participant. Read out at the end we modified it somewhat but ultimately had a rough spine of a story and its key players.

Pass the card

But a story needs its memorable moments. So we took a sheet of paper each, divided it into eight and each drew a key scene or sequence — crazy eights.

Crazy eights ideas by one of the more artistic members

An MVP output

Once we shared we cherry picked the ones we liked. And behold we now had a minimal viable product (MVP), or minimal viable story, as an output:

  • a setting — Antarctica, during the Falklands War, due to faxes being key and the reason why they may be even more cut off
  • a big idea — what if someone found a message that they shouldn’t have, was trapped with the bad guys and isolated from help by thousands of miles
  • a protagonist — a female meteorologist who has something to prove (yes this is still fairly 2D but better than before)
  • an antagonist — the corporation that wants to carry out a mining test that could fracture an ice shelf (again, 2D but has a motive)
  • a ticking clock — the test that will cause a glacier to splinter off that will cause flooding and other damage
  • a series of key events — finding the fax, the entrapment, the escape, the finding of one of Scott’s old supply bases just when all seems lost, the climax (sorry, you had to be there)
Less artistic ideas by myself

Summary and lessons learnt

So in the space of 2 hours we went from a pool of wildly different ideas to one that only had the word ‘fax’ in common with what we created.

We were proud of how much we got done in such a short time. It wasn’t perfect but it was a lot more than the zero we had 2 hours prior.

As usual we ended with a retrospective to find out what worked and what didn’t work.

Overall the team liked taking a few ideas and building from there, the collaboration and how we got different points of view yet agreed on an outcome.

The team felt they learnt about listening, sharing and expressing, and to build on ideas.

But the venue didn’t score as well. We were in Queen Elizabeth Hall on the South Bank and while the staff and bar were lovely, we did get a few interruptions for spare change and had neighbours who disturbed us.

This was a pity as the last venue, WeWork, was seen as too formal. So the hunt for the Perfect Venue (R) continues.

For the next Agile Storytellers session visit the Meetup Group.


Civil servants are user research participants too

Carrying out user research across the public sector is not the same as carrying it out with members of the public. That at least has been my experience of carrying out half a dozen different civil service-focused Discoveries.

As the Government Digital Service here in the UK likes to point out, civil servants are users too. But it’s a broad sector and my research projects have included central, devolved and local government, agencies, the police, and the NHS. Here are my experiences in light of the new guidance for services for civil servants.

Planning user research for civil servants

The first thing I do for all projects is meet the team and host a research question workshop. Where this differed from other workshops is how we thought about users.

We quickly decided that ‘civil servant’ was too broad a term for users and looked at the Civil Service profiles and Departmental IT profiles.

We found when reviewing civil servant personas from previous research that some are often just their job titles. So we did two things.

First, we adapted the job titles into roles to reflect that users across different teams may have the same fundamental duties and needs but different titles. This allowed us to see patterns and groups.

Second we wrote our potential users and their stories not just ‘As a…’ But ‘As a…’ ‘+ Who’ (eg” as an assistant who is in charge of a team’s room bookings”).

This helped us to really narrow down who our users were. It also helped us resolve one debate we had about who were end users of a service and who were our chief users for one Discovery, which to our surprise were not the same.

We also had a fairly clear idea about the end users but for the Discovery we determined it was more important to know who would implement and make decisions about the proposed service and their needs.

Cross-government help

What really saved time was posting what I was working on to the cross-government user research Slack channel and mailing list.

While my team had contacts, other user researchers put me in touch with their teams when relevant. In some cases they even had previous user research I could look at — with room bookings, for example, I had 3 different previous projects I could study and borrow form.

As you may be aware, government has a lot of meetings and forums and groups. Going along and inviting myself to relevant meetings helped in multiple ways: I got research from the meetings; I got contacts; and I got people to spread the word about what I was doing.

The tricky bits of civil service research

User research is mostly for getting information from users, but on my projects the civil servants I spoke to expected more from interviews, particularly if a team member was present.

In some interviews it did get bogged down when team members wanted to defend or tell why the problem the user mentioned was, and that’s not the aim of interviews. The decision has to be taken on the value of having a team member be there to take part in research and how to control the research session.

Confidentiality was also a concern. It’s hard to be truly frank as a user if the person who designed the system you’re criticising is in the same room.

One strategy was to allow for time at the end for Q&As between the team and users, and to shut it down if it went too off-topic.

This was even trickier in workshops, yet one reason we could get so many participants to attend was that our team of experts would be there. It was a question of balancing your desire to get information while rewarding the fact that professionals were giving up their time and so expected something in return.

Participants were also keen to know the next steps. Asking product managers to vow to blog at the end of the Discovery, Alpha or Beta meant I could tell users that there’d be a digest of learnings, and I invited many to the final Show and Tell.

What I learnt

We don’t share enough with other user researchers. And a lot of user researchers across government have worked on similar projects with similar problems and needs.

Contacting others can be easier due to Slack, public blogs, meet ups and so on but it requires more chasing and more channels to monitor. Combine this with projects using the same users and there can be a case of research fatigues for participants.

Some blockers were technical and unique to the civil service. GDS doesn’t have .gsi in its email (a ‘government secure initiative’ that’s going anyway in favour of better cyber security behaviour), and lacked a landline. For some not up to speed with the latest policies this was a red flag and was told I “couldn’t be trusted” with a response.

With so many departments and agencies (despite decentralisation) along with local authorities it can be tempting to stay in London and its area to meet users.

Yet bursting the London bubble and travelling the country was essential.

Hangouts, Appear.In and other remote tools are great but opportunities to observe other working areas were essential to get a proper view of work. They were often keen to meet someone who was willing to come see them so it was a positive session for all.

Overall it’s been an enjoyable experience. Civil servants are not just users, they’re people too. Shocking, I know.

Researching in government is rewarding as you have experts in their fields and they love talking about their work. Even those who are unhappy usually end their interviews with “sorry for the rant” despite having given you reams of information.

And you hope that by the end of the project your team will have had insights and findings that will help a range of talented people across the country do a better job and so help the public.

Note: this was originally written for the GDS blog but due to team changes got lost to the aether.


User research is statistical significance

User research is to design and product development as statistical significance is to data.

You can’t be confident in figures if you haven’t carried out significance tests. And you can’t be confident in a design or product change if you haven’t carried out user research.

Yet businesses that baulk at treating data as gospel without statistical significance tests will make product or design decisions without a jot of user research.

I’ve worked for organisations like this, perhaps you have too.

What is user research?

User research is many things, but in practical terms it’s the tangible outcome of making your users, audience or customers the heart of what you do.

It’s one thing for a company to tell us that customers are their “number one priority”.

A company shows it by having user researchers who learn about their users: who they are, what they do, what they want, what they like and dislike, what influences them.

User researchers uncover these findings through interviews, observation, usability studies, surveys. Then they interpret and gather insight through multiple rounds of research.


Insight is the output: you find out who exactly your users are, and what their pain points and needs are. Insight is shared with the wider team (and the team should be joining in on research sessions too).

These findings sit within a goal. This can be a project, business or organisational goal, and how the product or service will best serve its users.

This is a very quick overview of it and there are many places to find out more about user research, how it improves service design and why you should do it.

What is statistical significance?

Let’s say you’ve carried out A/B tests on two web pages and design B led to a 10% increase in goal completions.

Does this necessarily mean that design B is ‘better’? You could have got lucky with a hoard of spendthrift shoppers logging in together, or unlucky when the internet failed during design A’s slot.


The point of statistical significance is to be able to say that the results are likely to be true, a “low chance of an effect that actually is a false alarm”. That if you repeated this you had a good chance of getting similar results.

Newspapers and other everyday presentation of statistics typically omit statistical significance for simplicity. This is understandable, but statistics used in research and business must include it if they want to understand their data. And if the business does not run these tests, why not?

Statistical significance then helps give you the confidence — not certainty — that your findings are true. That your results weren’t due to a lucky (or unlucky) sample or events.

How user research statistical significance

User research gives you confidence. Confidence that what you’re doing has an effect due to changes your team made and not due to chance. Confidence that audience tastes are changing or a competitor has emerged.

Confidence that when the CEO says that they don’t like something that you can push back because the users say otherwise. That you have research, not just opinions.


User research gives you confidence but never certainty. That’s why research is an ongoing activity, much like how significance tests are carried out on each new result.


A danger of statistical significance is that it can give the appearance of scientific certainty when none is there. For example, produce Google Analytics data with statistical significance and it’ll appear the more ‘scientific’ result.

Yet the analytics is the outcome of people’s behaviour, and — unlike interviews — it’s hard to follow up and probe why a user did what they did with analytics.

Finally, both statistical significance and user research need to state the practical significance. Both can say that there is an effect but both need to say what the practical outcome is. For example, whether the problem is a mere annoyance or one that prevents users completing their task.

User research > statistics?

Both statistical significance and user research give you confidence in your results. But good user research includes the user impact by default.

A key part of user research is that the whole team should join in, and so will expand their own knowledge. How often does the team join the web analyst and contribute to their research?

User research can probe and build understanding across a team in a way that statistics by itself finds hard to achieve.

And any company that wants to be serious about its development needs user research as much as it needs statistical tests on its data.

Author Editor's Pick General Jonathan Richardson Link Opinion Original Writing Research Review Site Crash

Jonvocation is Considered Words!

This site is no more! Head to for all the latest on writing as a profession.




General Jonathan Richardson Site Crash

What is Site Crash?

Do you want more people coming to your website ? And do you want them staying for longer and recommending you to others? Then let me introduce Site Crash.

I’ve improved websites for several years, tightening up the content and vastly increasing traffic, and while it’s great getting paid to do this, it’s time to give something back to charities, voluntary sites and other places that deserve more traffic but may not have the time or resources to do the work needed to improve them.

I’m an editorial expert – I look at not just spelling and grammar, but whether a site is confusingly over-written. You know what I mean, those bitter flavours on the English tongue – meaningless jargon, buzzwords, business-speke. More importantly, I’ll look at how you’re selling your site.

Site Crash

Selling a site

Everything is sold.