How to handle content state for a writing project

Problem Introduction

Understanding the Role of Content in Workflows

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.

In Vewrite, there are a few canonical items, and their relationships, that define how the system works. We have:

• Workflows that have states
• Projects that have workflows
• Deliverables which belong to projects

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.

Each of these deliverables gets pushed through a workflow which will have a set of discrete states.

Using Live Prototyping to Expose Product Weaknesses

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.

You need a live prototype that someone can try to use.

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!

When we dive deeper into why our users feel that way, we can get some insight into how they are trying to use the product. At the heart of the problem is a product assumption that all states (and their content) are equal. This is, of course, not true for most writing projects.

When writing, you'll tend to have a core deliverable and a constellation of actionable items around that deliverable that are supportive in nature. This sounds is very abstract, so let's break it down and explain exactly what this means because it really gets to the heart of the issue.

You're writing an article which will eventually be published on a client's website. Typically, you'll agree with your client what the scope of the article should encompass. This is your topic, and there will be some research that goes into figuring out the exact details of what you'll be writing. As a way to make sure that you and your client are on the same page, it's good practice to build out a rough outline of the written piece and get that approved before you start writing the draft. Once you have this outline approved, you can write your draft, and get your client's feedback. It may take a few rounds, but eventually you and your client will be happy with the output and the deliverable will finally be approved and published.

There are discrete steps along the workflow, but it isn't linear, and the content that eventually builds out the deliverable itself has a life-cycle that supports the end product.

If we approach this in a linear fashion then we encounter a few problems with our initial implementation:

1. It's hard to reference information that is critical for the writing process if it is closely tied to the the states in the workflow
2. Referenced information like research materials, outlines, and review comments are not static and likely will change during the life-cycle of the deliverable

Not an ideal way to work, and not good enough to supplant the current ways that writers get things done. We thought that we can do better, so we went back to the drawing board.

The Problem

The problem that we really have been wrestling with is, "what is content itself as it gets pushed through a workflow?"

It's not a simple problem because what the content is often depends on the state that you are currently in within the workflow. For example, a deliverable that is in the OUTLINE state will have content that is an outline and will not be a written draft that you'd deliver to a client. It isn't equivalent to the draft and likely needs to be referenced during the writing process itself. It is its own thing.

Each state's content may be something else, and how Vewrite as a product handles these different states and the associated content is not straightforward. From a user experience perspective this can be clunky and unwieldy, and requires an elegant solution that ensures that the stream of work is easy to follow, and most importantly: doesn't get in your way as you do it.

Designing a Solution

Defining Success

For us to be able to confirm that we have successfully designed and implemented a solution, we must be able to define what success means.

In this case, we want users to be able to:

1. Use the Workflow to define who does what and when
2. Have access to supporting information, like requirements and outlines, during the writing process

With this in mind, let's take a look at the proposed solutions and discuss their pros and cons. Then we'll show which of them we selected and talk shortly about why.

Proposed Solution

Now that we have defined what our success metric is, we can set a clear set of requirements for Vewrite's deliverable creation feature.

1. Core focus - should be on the core draft and the writing/review process. That's where the biggest value is.
2. Constant access to - these features:
   1. Deliverable requirements content
   2. Outline content
   3. Draft content
   4. Review comments content
   5. Current state
   6. Current assignee based on state

Instead of duplicating content from state to state within the workflow, which is both clunky and irritating to actually work with, we're proposing that users will have one set of content that they have access to update depending on the state that the workflow is in.

The deliverable will have, instead of a set of discrete content blocks for each state in the workflow, a single set of content that includes:

• Deliverable requirements - set by the creator and editable by the writer
• Deliverable outline - created by the writer, comments allowed by the stakeholder
• Draft content - created by the writer, comments allowed by the stakeholder
• Review comments - created by both the writer and the stakeholder

We experimented with different layouts that allowed the users to have instant access to these content types. Each had pros and cons that we weighed against eachother. Let's take a look.

Tabbed content sections

Concept - The tabbed content section concept leverages the commonly used tabbed UX paradigm, where each tab contains a page of information, cleanly segregated from the other pages.

Pros

• It is good for creating a clear delineation between different sets of information.
• There is no visual or conceptual bleed between what you are looking at and the adjacent documents.
• We can show review comments in a parallel column.

Cons

• There's a concern that tabs don't elegantly collapse for mobile devices, and that the user experience will be compromised.
• When you want to reference information it requires extra clicks and there is no way to view two different types of information at the same time.
• There will be a slight delay when loading content which means that for each tab switch there will be a small, but measurable break in the flow of work. It's a similar problem to what users are already experiencing right now (500 - 1500ms) and we don't want to duplicate this for these initial prototypes.
• Tabs seems like a fairly old-school user experience solution for this type of problem.

Side-by-side panels

Concept - The side-by-side panels concept is intended to allow users to always have access to reference documents during the writing process. The intent is to reduce task switching while producing content.

Pros

• Less cognitive overhead when writing since you have everything that you need right in front of you.

Cons

• For any laptop or smaller sized device, there isn't really going to be space for four columns of layout (main nav, reference, writing, review), which a user would likely need to comfortable. This means comments will have to be inline and only show on hover or selection.
• The layout becomes much more cramped with all of the information constantly show.
• To make this work, we'll have to have even more collapsible panels, which aren't very mobile friendly.
• Too much information in one space doesn't allow for a focused writing experience. We want users to have quick access, but we don't want it all in their face all of the time.

Endless scroll

Concept - Users are very used to long scrolls in modern applications and we believe that having all of this content available for them in a linear fashion will give a more natural and comfortable user experience while writing.

Pros

• Works well across all device sizes and formats.
• There's a rough approximation of the workflow in the display format.
• Breathable, comfortable writing experience.
• Content is loaded all at once, making it easy to view without delays.
• Modern experience that people will find familiar and comfortable.
• We can discretely hide and show access to editing depending on state without affecting the overall layout.
• We can show review comments in a parallel column.

Cons

• You can't show reference content at the same time as you are writing and will lead to some higher cognitive load.
• We'll need some way to "flip" between sections, in a similar manner to tabs. We will need some way to "jump back" to where the user was.

Selecting a Solution

The Winner Is...

In the end we decided to go with the last solution, the endless scroll. It provided us with a simple layout and access to all critical features in one straightforward package. We believe the few cons that it has will be outweighed by the obvious pros compared to the competitor designs that we did not run with.

If you're interested in being a beta tester, let us know by joining the waiting list below. We'll get in touch when we're ready to go. If you have a writing team and struggle with staying on top of things, we're sure that you'll love what we've built.