Content Strategy at Cuddle.ai: Part II-Frameworks and solutions
In part I, we covered why having a content strategy was important for us at Cuddle.ai, what is UX writing and certain basic guidelines which you should follow while writing content for your product. If you haven’t read it yet, here’s the link.
In this article we are going to cover the following things:-
1. Categorising information
How we took printouts of every screen of our product and organised them into relevant categories — empty states, error messages, etc.
2. Creating and applying the frameworks.
We then made frameworks for each of the categories and refined the copy following those frameworks and the guidelines mentioned in part I.
3. Gathering inputs from stakeholders
The last section covers how we gathered inputs from other stakeholders in the company and made sure everyone follows the same frameworks, moving forward.
Categorising information
When we set out to implement the content strategy, we realised it was highly important for us to do it across the whole product and platforms (iOS, Android and Web). It was also important to visually see all the screens together to be able to decide which buckets the copy on those screens fall under. For instance, there were error messages across the product, there were empty states for each of the feature and flows. We came with the following categories according to the kind content across our product:-
The next thing we did was take physical printouts for all the screens across the product. We then stuck similar screens together into the above categories on a big whiteboard.
Bonus: After taking these printouts, we have our whole app in our hands, literally. And it feels so good to actually be able to look at those screens on paper and not just on digital media.
Creating and applying the frameworks
Now we had all our screens properly categorised according to their content and function. Next step was to pick up these screens, category-wise and then see if the content varied across them and whether it was following the basic content guidelines. We then had to make it consistent, and ensure that the consistency is maintained, moving forward — here come frameworks. Let me explain how we ensured the above points with examples for each of our categories.
This category has all the screens where we onboard our users to the new features in the app. There were around 15 screens under this category, below are 6 of those screens.
As you can see, although all of them are first-time onboardings their usage and copy differ according to their functions. We made the following observations for the screens that fall under this category:-
1. Usability — How to use a feature
Eg. Swipe to navigate through trackboards
2. Single line — Explaining a feature to users
Eg. Track answers to monitor them over time
3. Explanatory — Defining a feature
Eg. Trackboard created by admin
All the 15 screens, fell under one of the above buckets. So we defined the frameworks for each of the above buckets. Below are screen-by-screen examples of how we defined and applied the frameworks.
This category has screens where we ask for user inputs — login, renaming, etc. There were around 5 screens under this category, below are 3 of them.
This category has screens where we show the loading of the next state or current progress to the user. There were around 5 screens under this category, below are 3 of them.
This category has all the screens where we direct users to an empty state. There were around 5 screens in this category, below are 3 of them.
This category had all the screens which showed the feedback of an action that the user has performed. There were around 8 screens in this category, below are 3 of them.
This category had screens where an error was communicated to the user. This error could be a system error or one which might have occurred due to some user action. There were around 12 screens in this category, below are 3 of them.
Gathering feedback from stakeholders
The above examples showed how we refined the content for each of the screens, in each of the categories for our product and made them consistent. The next step was to gather feedback on the above exercise from other stakeholders, including the product, sales, marketing and tech teams. And also make sure that they also follow the same framework while writing any product content in future — so that we maintain that consistency.
For ensuring that, we shared 2 presentations across the team with all the information we shared with you, in this article and the part I. For collaboration and feedback, we used dropbox paper. Below are screenshots from the dropbox paper document which we used to convey the content proposals and gather feedback from the team:-
In the document, we have also defined certain rules that must be followed across the product for consistency:-
Pro Tip:
When we gathered feedback from the team, we came often came across situations when different stakeholders had varied opinions regarding the usage of a particular word. For example, See this answer v/s View this answer
We used google trends to resolve such conflicts
No logic can beat data
Today, we have a long breathing document which has all-new refined content. The whole team follows this document, to decide what and how to write content for their projects. This exercise has surely helped us in making our content consistent across platforms and products.
Please let us know if you found this series useful. We will be more than happy to help you in case you are planning to do a similar exercise for your product.
