Content Creation Flow (5 mins reading time).

Today we’re going to talk about an effective way of defining new product features.

A product feature can be defined in two ways – from either a marketing or engineering perspective. The marketing approach means explaining how the feature benefits the customer, and the engineering perspective means explaining how that feature works.

Some product managers may miss this distinction and explain a new feature to their engineering team from a marketing perspective. As a result, engineering may work really hard and possibly proceed in the wrong direction, losing time and money for the company.

For example, let’s take the well-known concept of an online marketplace that sells several products and describe an exciting new feature from a marketing perspective. Our marketplace will now display a list of 10 featured products on its home page.

Well, engineering will have lots of questions. Who will feature the products? How will they be featured? How long will they be featured? Who will un-feature the products? All of these issues have to be clarified.

At Astrails, we’ve come up with the concept of Content Creation Flow. It’s a way of first explaining how data is created in the system and then understanding how it’s consumed, instead of vice-versa. Also, at any given time we can only use terms that were defined beforehand (i.e. objects that have already been created). It makes the concept a little harder to define, but so much easier to understand.

For example:

Facts - application admin users moderate the products; a products back office UI is used to edit/update the products.

Flow - application admins should be able to mark a product as “featured” through the back office UI. The ten most recently featured products should appear on the home page.

In this example, the creation process is described before the consumption process.

This makes it easier for engineering to understand and implement the feature. In our example, each product will have a featured timestamp. In order to feature a product, application admins will trigger the timestamp to be set to the current time. The 10 most recent products should appear on the home page in descending order of those timestamps. We’ll cache these 10 products and invalidate the cache when any product is changed or when a different product is featured by the application administrator. Crystal clear. For engineering.

This concept can and should be applied to wireframing and designing user interfaces as well.

Let’s assume again that we’re building a new online marketplace. The designer starts by designing a home page instead of starting with the inner pages, and presents a first draft showing 10 featured product boxes. Each box has a product image, product name and a short description.

Engineering then receives the homepage design and discovers that there is no short product description field at all. So, what now? Engineering can add this field, but they don’t have a UI for the seller to provide a short description. The web designer can remove the field and use the seller’s name instead. In either case, precious time has been wasted.

A better way to develop the product would be to design the seller’s product-editing page first. Once that is ready, designers will know that the only fields supported are product name and long product description. Long descriptions can obviously not be used in a small product display box, so the designer will use the seller’s name in the homepage design in the first place.

Everything is clear from the engineering perspective - the data to be consumed has already been created and the engineers know how to query it.

So, we discovered that feature specs are described more clearly using Content Creation Flow. Designs and UI can also be produced more efficiently according to this flow.

It turns out that engineering can use the same flow as well and save lots of time.

How? Let’s imagine the following situation. Engineering got specs for some new exciting feature. The specs are 90% complete. The engineers are ready to start coding but there’s an editing screen that hasn’t been designed yet. They decide not to wait. They’ll just seed some data, render other pages that use seed data and get back to that editing screen later. After a while, it turns out that the editing screen has more fields then they expected, with complex relations between them and seeds are not good enough. Now engineering needs to refactor the code and throw away lots of their work before they even start adding the new fields. Result: time wasted.

If they had started with the editing screens, all of the fields and relations that will be used later would have already been defined.

There’s nothing wrong with seeding some data for development, but it’s probably not a good idea to do so before it becomes clear what the data will look like. So, creation before consumption. Always.

If you have any questions about content creation flow, or any questions at all, feel free to email me at [email protected].