-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Structured writing workflows article
- Loading branch information
Showing
7 changed files
with
100 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
81 changes: 81 additions & 0 deletions
81
content/articles/5.why-you-should-use-a-structured-writing-workflow.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,81 @@ | ||
--- | ||
title: "Why you should use a structured writing workflow" | ||
image: "/content/structured-writing-workflow.png" | ||
description: "Let's take a long, hard look at why Vewrite is built the way that it is." | ||
date: "2025-02-19" | ||
author: "Rami James, Founder" | ||
authorLink: "https://www.ramijames.com" | ||
readingLength: 5 | ||
--- | ||
|
||
## What are structured workflows? | ||
|
||
Structured workflows, which Vewrite relies upon heavily in its design, are simply a way to standardize the writing process so that it is more manageable and professional. These allow all participants in the process to know what they are supposed to do and when. | ||
|
||
A good workflow will have: | ||
|
||
- **Clear steps for all participants** - everybody should know what they are supposed to do | ||
- **A logical order of operations** - each state should flow into the next | ||
- **All work included** - at the end, you should be done | ||
|
||
This means that you can take a project through a workflow from beginning to end and rest assured that when you've walked through it completely, there is nothing left to do. | ||
|
||
A good workflow is peace of mind. | ||
|
||
### The pitfalls of working without a structured workflow | ||
|
||
I have written hundreds of articles, both under my name and ghost-written for dozens of companies, and managed quite a few teams across multiple disciplines. This experience informs my dedication to structured workflows as a way to avoid the most onerous pitfalls that are common across all written projects. | ||
|
||
My experience with writing content and leading teams tells me that: | ||
|
||
1. You want to get early sign-off on an outline so that the client or stakeholder knows more or less what they are getting BEFORE the writer spends a few days on it. **An outline can take 30 minutes. An article can take ten hours**. | ||
2. You want it to be super clear when you're supposed to be writing and when you're supposed to be reviewing. Having the reviewer (client) just pop into the middle of the process and "make suggestions" is disruptive and leads to a bad product. | ||
3. Teams need structured tools not just for producing work but for **creating transparency in the team**. People who are managing 40-50 articles being written in tandem absolutely require something tailored to them to know what state each article is in, and whether or not someone needs poking to keep going. | ||
|
||
Highest in the list of things to avoid are: | ||
|
||
- Having to redo work because of **lack of consensus** with a client or stakeholder | ||
- Unhappy clients or stakeholders because things are **incorrect or badly researched** | ||
- Lack of project state transparency that leads to **bad estimates** and confusion in the team about what is done and what isn't | ||
- Late work and/or slipped deadlines which **break trust** with a client or stakeholder | ||
|
||
With these in mind, let's take a look at the writing workflow we use at Vewrite. | ||
|
||
## Vewrite's workflow | ||
|
||
Vewrite's workflow is designed for writers who work in a group and have either a client or stakeholder who they are accountable to. This generally covers devrel units, marketing groups, and content creation teams who all together create technical pieces, articles, blogs, whitepapers, and proposals. | ||
|
||
 | ||
|
||
### The Workflow | ||
#### Get Started | ||
Our default workflow starts with the **project manager setting requirements**. These are just a few sentences that cover: | ||
|
||
- What topic the writer is supposed to write about | ||
- How long the piece needs to be | ||
- Any links or references that the client has provided | ||
|
||
#### Gather Information | ||
Once the project manager starts the deliverable, the writer is assigned the piece. They are expected to **go and do some basic research** about the topic to ensure that they know what they are going to cover. Vewrite provides a place in the Document Manager to keep these notes as reference material for later in the writing process. | ||
|
||
#### Create an Outline | ||
When the writer feels that they are ready, they can **start writing their outline**. An outline is simply a structured set of bullet points that outline what the deliverable will cover. The point of this is to get a sign off early in the process from the client or stakeholder so that they can give feedback and input before the bulk of the work is done. | ||
|
||
#### Outline Review | ||
The writer completes the outline and passes it to the assigned reviewer. They have the opportunity to **provide critical feedback** now (and send it back to the writer for fixes), or to approve it as-is. Once approved, the deliverable can not be moved back this state. | ||
|
||
#### Writing Draft | ||
We now have a set of organized research notes, and an approved outline. **It's time to get to writing!** | ||
|
||
#### Writing Review | ||
As before with the outline review, the reviewer has the opportunity to **read the draft and provide comments and feedback** about the deliverable's draft. Once approved, the deliverable can not be moved back this state. | ||
|
||
#### Approved | ||
We now have an approved, completed draft that the stakeholder or client can **download as a Markdown or HTML file**. | ||
|
||
## Vewrite's core mission | ||
Vewrite simply strives to take the writing process and ensure that, when done in a team context, it is as well-organized and straightforward as is humanly possible. It's a way to maintain visibility while getting out of the writer's way as much as possible. | ||
|
||
The point is categorically not to get directly into writing as fast as possible. **Vewrite is not Google Docs, it's much more**. The goal of Vewrite is to have a structured workflow with sign-offs so that there aren't opportunities for walking too far in the wrong direction. | ||
|
||
Our core mission is to keep your team of writers on track. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.