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:

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.

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.