How to handle content state for a writing project
We are looking to work with experienced technical writing teams and freelance writers who are interested in improving their workflows and making more money along the way.
Vewrite's product is based on structured workflows with discrete content states. Let's look at how that impacts how we design the product.
We've been thinking hard about what workflows and the state of content actually means for the better part of a year now. Before we dive into the nitty-gritty details, perhaps we should define some of the basics first.
Deliverables are written content pieces. For example, if you have a project for a client and they require that your team writes ten content pieces, each of those is one deliverable. You deliver them to the client.
At Vewrite, we're big believers in using live prototyping to get a deep understanding for what actually works with real users. It's fine to have beautiful designs in Figma, and often better to have clickable prototypes that you can use to get a feel for your product, but in truth none of these things will really give you the feedback that you need to progressively improve your offering.
Our initial implementation assumed that each workflow would have a set of states, and each state would have its own content. Conceptually this is straightforward, and from a development perspective it isn't hard to make into a reality. We implemented this in a couple of weeks, and pushed it out to our core group of beta testers. Their initial feedback was that it was clunky and misrepresented how they actually worked. Highly valuable feedback for a gestating product!
