UX Case Study: Modular Content System
Context:
Thoropass's compliance management platform guided clients through the implementation of security frameworks like SOC 2, ISO 27001, and HIPAA. Small clients might only need one of these security frameworks but as Thoropass moved upmarket, larger clients often wanted to implement and manage several security frameworks at once.
Unfortunately, the expert content in Thoropass’s platform was written and released for each framework individually, sometimes months or even years apart. This meant that if a client purchased more than one framework, they would be forced to see multiple versions of their instructions, instructions that often conflicted with each other. Depending on their combination of frameworks, clients could see up to 80% redundant content, leading to duplicated work and serious confusion.
Understanding the problem:
We conducted user interviews with key customers and our own customer service managers to determine how deep the problem was. Some of our key insights:
The existing experience was so confusing that many users didn't even realize it was happening to them. They just thought the platform was bugged and would mark "duplicate" instructions done without looking deeper.
Thoropass touted itself as smart platform, and users expected to see one piece of instruction per topic that covered all their frameworks.
Our customer service managers would, when feasible, go into the customer's environment themself and mark off as many tasks as they could to ease the burden on users.
The issue of duplicate content was everywhere in the app. For just one example, when clients with both SOC 2 and HITRUST content needed to conduct access reviews (Access reviews are the process of validating that users have the correct access to resources in your company), they would see these two pieces of instruction:
Expert content for SOC 2 and HITRUST for the same task.
Where does the user start? How do they know what to do and what not to do? It was unacceptable to force the user to compare and contrast multiple sets of instruction before they could start their most essential tasks.
Now imagine this issue repeated across a dozen frameworks and hundreds of topics. It was, for some clients, a very understandable dealbreaker.
Designing our solution:
We needed to design a unified system that displayed accurate content no matter what products the client purchased. This meant a system that would:
Programmatically arrange content for the user depending on their frameworks
Understand where multiple frameworks conflicted and know how to reconcile those conflicts
Be extensible, something that could be built upon when implementing future frameworks
Use our existing content as much as possible
I was tasked by my product manager to design a content schema that could meet these requirements. One of the first tasks was to analyze our existing content to inform our plan and the results were promising. Due to content guidelines that I had implemented the previous year, most of the content was already following a common sense patterns.
Element breakdown of two pre-existing instructions.
If you look closely our examples above, you might notice that although the instructions look very different from each other, they mostly agreed on what goals to accomplish. In the case of access reviews for example, all frameworks required that you:
Periodically perform reviews
Review every system being audited
Document the process
Instructions may disagree on the specifics of these goals (Are emails acceptable as evidence of the change, or is it an IT ticket required? Does the review need to occur quarterly or biannually?) but these differences can be smoothed over with the right use of language.
In some cases, a more rigorous framework may have additional requirements on top of the typical instructions (e.g. Generate access lists for physical security badges in addition to digital systems). I began to refer to these as cumulative requirements, items that could simply be added on top of each other without issue.
More rarely, two frameworks may have mutually exclusive requirements. Common examples would be frequency, such as requiring that a certain activity occur annually, biannually, or quarterly, or the strictness of a requirement, such as one framework requiring passwords to be minimum 10 characters in length and another requiring 14 characters minimum. I referred to these as conflicting requirements, and we would need to have a way to measure these conflicting requirements against each other and display only the most relevant one. They always existed on a kind of spectrum, from least strict (e.g., annual testing) to most strict (e.g., monthly testing), and we would need to develop a ranking for each conflict to ensure the most accurate info was being shown.
As we did lo-fi exploration of our schema requirements, we kept in constant contact with our engineering team to understand what was possible, as well as updating our subject matter experts to gauge the eventually effort for translating all of our content into the new system.
Early explorations continuously lead us to a kind of LEGO model of composability, where composable blocks of content could be stacked together in the correct order. Our existing content didn't have any visual or structural elements beyond text formatting and bulleted lists, so the end content would simply be an arrangement of <p> and <li> html tags.
After a proof of concept was approved by our stakeholders, I was personally tasked with writing the MVP of our schema using our two most popular frameworks, SOC 2 and ISO27001. Recall that this schema had to be extensible, or able to be built upon, so it was important that I move to a third framework as fast as possible to confirm that the project was something that could be maintained into the future. Additionally, my wife was pregnant and my paternity leave was scheduled, leaving me with 6 weeks to transform ~45,000 words of dense SME content into our MVP, as well as hire and train a contract content writer to maintain it while I was away.
The result:
We created and launched an all-in-one content solution that programmatically created the content our users expected to see. Below is an example of the new, unified set of instructions, including the highlighting system used to indicate changes to the user’s content when new products are added.
It’s difficult to understate the importance of this solution, but also very difficult to measure it. This was an issue that touched every user in our platform.
