Content Inventory System Design
Future-proofing an educational software startup
Introduction
t.ux (teach user experience) is an educational platform for people looking to learn more about UX and UI design. It's meant to be a companion resource to bootcamp students and independent learners.
The breadth of content required for an educational platform means that a content inventory system, or catalog of the entire contents of the product — from the text, pictures, and documentation — is paramount.
My Role
I spearheaded this content inventory system design for our t.ux content creation system, taking the project from development to deployment.
I worked with other designers and engineers to do a current state analysis before designing the system, testing it internally, and scaling it across our teams myself.
“Design is a plan for arranging elements in such a way as best to accomplish a particular purpose.”
This quote encapsulates my mission for this case study.
What is the problem?
As a writer, I immediately had some copy-edits to suggest for t.ux’s content. However, I quickly learned that the copy only lived within Figma text boxes.
There was no safe repository where the words, the pictures, and the content of t.ux could be edited, tracked, and connected to our design files.
In addition, there were inconsistencies of information in the channel of communication between designers and engineers, leading to disparities between team understanding and time lost spent by working on tickets that were ultimately not relevant to our MVP.
A path to completion for a designer, or when a ticket would be marked as complete, is when a t.ux learning activity on a UX topic, such Heuristics, Accessibility, or Research Methods has been written, mocked up in Figma, prototyped, and tested.
How it originally looked to edit content in Figma.
How is content currently created?
In order to get a better understanding of the current state of content creation for t.ux, I roadmapped my initial actions.
First, I created a Notion board outlining my plan for the scope of the project.
Then, I inventoried my assumptions about how the process currently worked.
I interviewed fellow t.ux creators in order to collect data on how they created content for t.ux.
Lastly, I created a current content creation flow, pictured here, to offer a high level view of the creation process.
Screen recording of content creation flow I created. Note the number of steps!
Who are the users I’m solving for?
The users here are the content creators, designers, and engineers building t.ux.
What are their needs?
The more content our users can create, the more products we can push out to delivery. Based on my initial research, I then outlined our needs.
What we need is a:
scalable, consistent way to automate the content production process, so that we can have
an effective and accurate communication chain between designers and engineers, so that we can all spend
less time doing busy work and more time creating products.
What are the goals?
First, simply, our goal is to have a place to organize and track content.
Secondly, we want to build a place for “future friendly” content, which anticipates user needs, provides a scalable structure, and is a navigational model.
Lastly, it’s a place that can bring meaning to our team, something ambitious that motivates us to put in that extra effort to achieve high functionality.
What is the vision that defines the MVP?
A thriving, living digital system that increases creativity for t.ux content creators and bridges the information gap between designers and engineers.
How did I get to a solution?
I researched content inventory systems, reading articles, and searching for options currently on the market, all while considering the needs of our lean startup. Ultimately, because many of our design files already lived within Google, I decided a Google Sheet template would offer a no-cost solution that fits within our current work flow.
Having the opportunity to design the system while simultaneously testing it helped me stay agile because I could share content system solutions with my design team simultaneously while they were creating content, receiving immediate feedback and opportunities for further iterations.
What does my proposed and tested solution look like?
With user goals at top of mind, I designed a Google Sheets template for t.ux content creation that could help solve our goal of achieving consistent scalability within a content inventory system.
Within it contains:
tabs for content and each question type,
cells for every building block of content needed to build a page,
as well as a home for sidebar navigation and research sources.
Users are able to copy the template and fill in cells after they’ve researched and ideated content ideas. The individual templates are saved within our data repository.
Screen recording of content inventory system I designed.
In addition, I offered another solution to users to test which focused on time saving and reducing manual information input disparities.
Being able to connect our content inventory system to our Figma design system was key, so, after market research, I deployed the Google Sheets Sync Plugin to my team. By using commands in the naming conventions of our Figma layers to a corresponding Sheets cell, the Plugin allows you to connect data cells from a Google Sheet to content and media elements in a wireframe.
Screen recording of Google Sheets Sync Plugin I tested with users.
How did I test?
First, I employed guerrilla usability interviews as a form of generative research.
I was fortunate to be able to design this system while implementing it. This meant, in practice, that I interviewed all 10 designers and 3 engineers on our team while they were creating content and building activities for t.ux. I was able to answer questions such as:
quantitatively, how long does it currently take to create an activity in t.ux?
The answer, at least 1 month from ideation to testing.
qualitatively, how does it feel to create content in t.ux?
Users responded that the process felt like the opposite of lean. The steps to complete building an activity from the ground up lacked clarity and consistency.
My initial notes for the content creation flow based on user interviews.
Next, I gathered evaluative research by bootstrap usability testing the content inventory system design.
The task I gave to all 10 designers was simple: create an activity within t.ux. I observed user’s behavior throughout the content creation process, taking notes, sitting in on design meetings, fielding feedback, and regularly following up with users to uncover problems and discover opportunities within my design.
Observing my users test out the Plugin. I’m in the pink shirt!
What are my measures of success?
3 minutes
By introducing the Sheets template and Google Plugin to our creation flow, the design implementation of the activity sidebar navigation went from taking 3 days to build in Figma to 3 minutes.
50%
I succeeded in reducing time spent to complete an activity by 50%, from one month to two weeks. By clarifying the steps necessary to complete an activity, providing the framework of a template, and reducing production times with the use of the Plugin, I was able to streamline and quicken the design process.
10/10
Through my evaluative research, I uncovered that every designer tested thought the spreadsheet helped them create content more easily because they could see the content components required for each page and they had the information needed to visualize our content creation model.
What are the constraints?
Manual labor can lead to information disparities.
After observing how the system works in practice, and communicating with members of the design and engineering team, the plugin was sometimes buggy. It demands a lot of manual labor to figure out how to work it properly, and the more manual labor users spend on the plugin and spreadsheet, the greater chance of disparity of information between team members.
Lack of systemic communication to implement changes.
There is a major consideration we need to give towards how changes are made and communicated, and where the Parent information will live and be accessed between designers and engineers. What we as designers create in terms of content should be in the form exactly how engineers need to use that information for deployment, and it’s unclear that my solution is the most effective in practice for deployment.
Reliance on outside products.
Lastly, do we want to be reliant on outside products like the plugin and Google? For instance, the Google sheet has to have public viewable share settings to work. Will that lack of privacy impact us in the future? Is there a way we can build a content inventory system internally?
What are the next steps?
A content inventory system requires continuous monitoring and updating, and responsibilities have to be shared. What we need is team buy in for the accountability of the system. Sufficient conversations still need to be had between designers and engineers so that we’re all, as a team, creating the architecture of our content model.
So, we’re at the piloting stage here, but my goal is to get our content inventory system to:
scale, and formally expand across all of t.ux so that we can…
sustain, solidify, and optimize our content inventory system so that ultimately…
we’re thriving, while also innovating and seeing a return on the investment of our time.
What’s the why, and how do I feel now?
Helping others succeed is a driving factor in my work, no matter the subject. It was gratifying to create a system that made things easier in my colleague’s lives, and be able to test and iterate on it in real time. My hope for this content inventory system design is that it continues to open up creative opportunities amongst my teammates, while tacking on an insurance policy, if you will, of content storage for our software.
Working within a startup environment was both a blessing and a curse in this case. I had the opportunity to build a work flow system I would probably never have the opportunity to have a significant hand in at a large business. However, because our lean startup is still aiming for MVP while we push for market delivery, a content inventory system is just one piece of a much larger puzzle still being put together as we build out t.ux.
