A quick note about an amazing UI from Writefull called Sentence Palette that shows how to combine structured content with prompts to write in a structured way. It nicely fleshes out the granular structure of a complex document down to the sentence level. I see broad application for this kind of approach for many kinds of content.
The deep analysis of large content corpora reveals common patterns not just in the conceptual organization of topics but also in the narrative patterns used to discuss them.
Writefull has assessed the academic writing domain and uncovered common text patterns used, for example, in article abstracts. LLMs can draw upon these text fragments to help authors develop new content. This opens up new possibilities for the development of structured content.
There are literally hundreds of CMSs on the market, possibly thousands. So much choice, but often so little satisfaction, judging by the gripes of end-users. Why is the right option so muddled? Old CMS vendors soldier on, and new ones enter the market all the time, promising a better future. How do we make sense of this?
A large part of the answer is the CMS buyer, and CMS users, are different people. The buyer and user have completely different relationships to the CMS. The buyer has either budgetary authority or responsibility for implementing the CMS. The buyer decides what to buy based on budget or infrastructure considerations. They dominate discussions of CMSs during the purchase phase but disappear afterward.
Only after the CMS is purchased do users gain much notice. They now have to “adopt” the CMS and be trained on how to use it. While they may not have had much say in what was purchased, they may nonetheless be hopeful their new solution will be better than the old one. After years of complaining, the user at last enjoys the spotlight. They get a new system and training. However, following a honeymoon period, users may notice the new system has many of the same issues as the one it replaced. Their CMS doesn’t satisfy their needs!
CMSs are hardly unique in sparking user complaints. All kinds of enterprise software generate dissatisfaction. These problems stem from a common practice: the buyers of enterprise software are not the users of the software.
Do enterprises care about internal users? The field of enterprise UX emerged in response to a common situation: enterprise software is often less usable than consumer software. One explanation for why consumer software is better than enterprise software is that developers are unsure what consumers want so they test and iterate their designs to ensure people are willing to buy it. For enterprise software, the user base is considered a known and given quantity, especially if the enterprise application is being developed internally.
Enterprise software has changed dramatically over the past decade. It was once common for such software to be developed internally (“homegrown”), or else procured and installed on-premises (“off-the-shelf”). Either way, enterprise software was hard to change. Employees were expected to put up and shut up. Now, much enterprise software is SaaS. In principle, it should now be easier for enterprises to switch software, as firms shouldn’t be locked in. Usability should matter more now.
What’s good enough? Benchmarking usability. The most common usability benchmark is the System Usability Scale (SUS), which has been in use for four decades. Many software vendors, such as GitLab use SUS. A SUS survey yields a score from 0-100 that can be broken into “grades” that reveal how good the usability of the software is compared to other software, as this table from GitLab shows.
The SUS can be used to assess any type of software. It measures general usability, rather than the specific usability of a certain category of software. It matters little who has the best medical claims reconciliation software if all software in that category is below average compared to overall norms.
Employees aren’t consumers. It’s not straightforward to apply consumer usability practices to enterprise software. Many user experience assessment approaches, including the SUS to some degree, rely on measuring user preferences. The SUS asks users if they agree with the statement, “I think that I would like to use this product frequently.” Yet employees are required to use certain software — their preferences have no bearing on whether they use the software or not.
The ESUS is readily applicable to assessing CMSs — what in the content strategy discipline is known as the authoring experience, which covers the editorial interface, workflow, analytics, content inventory management, and related end-user tasks. These tasks embody the essential purpose of the software: Can employees get their work done successfully?
ESUS consists of just five questions that cover major CMS issues:
Usefulness – whether the CMS has required functionality and makes it possible to utilize it.
Ease of use – whether the CMS is clear and allows tasks to be completed in a few clicks or steps.
Control – whether the CMS empowers the user.
Cohesion – do the CMS capabilities work together in an integrated manner?
Learnability – can the user make use of the CMS without special training?
The ESUS, shown below, is elegantly simple.
ESUS Items
1
2
3
4
5
How useful is this CMS to you?
Not at all useful
Slightly useful
Somewhat useful
Mostly useful
Very useful
How easy or hard was this CMS to use for you?
Very Hard
Hard
Neutral
Easy
Very Easy
How confident were you when using this CMS?
Not at all confident
Slightly confident
Somewhat confident
Mostly confident
Very confident
How well do the functions work together or do not work together in this CMS?
Does not work together at all
Does not work well together
Neutral
Works well together
Works very well together
How easy or hard was it to get started with this CMS?
Very Hard
Hard
Neutral
Easy
Very Easy
Microsoft’s proposed Enterprise System Usability Scale (ESUS) applied to CMS evaluation by employees
How enterprises might use ESUS
The ESUS questionnaire provides quantitive feedback on the suitability of various CMSs, which can be compared.
Benchmark your current state. Enterprises should survey employees about their current CMSs. Benchmark current levels of satisfaction and compare different vendors. Most large enterprises use CMSs from more than one vendor.
Benchmark your desired state. It is also possible to use ESUS for pilot implementations — not vendor demos, but a realistic if limited implementation that reflects the company’s actual situation.
Measure and compare the strengths and weaknesses of different classes of CMSs and understand common tradeoffs. The more separate usability dimensions a vendor tries to maximize, the harder it gets. Much like the iron triangle of project management (the choice of only two priorities among scope, time, and budget), software products also face common tradeoffs. For example, a feature-robust CMS such as AEM can be a difficult-to-learn CMS. Is that tradeoff a given? The ESUS can tell us, using data from real users.
CMSs will vary in their usefulness. Some will have limited functionality, while others will be stuffed with so much functionality that usefulness is compromised. Does what’s out of the box match what users expect? It’s easy to misjudge this. Some vendors overprioritize “simplicity” and deliver a stymied product. Other vendors overemphasize “everythingness” – pretending to be a Swiss Army knife that does everything, if poorly.
CMS difficulty is…difficult to get right. But it matters. Not everyone finds the same things difficult. Developers will find some tasks less onerous than non-developers, for example. But everyone seems to agree when things are easy to do. That’s why consumer software is popular — rigorous user testing has de-bugged its problems, and everyone, no matter their tolerance for nuisance, benefits.
CMSs often fail to give users control — at some point. What’s interesting to look at is where the CMS falls down. Maybe the user feels in control when doing something simple and granular, but is overwhelmed when doing something involving many items at once or a complex task. Conversely, some CMSs are better at batch or exception tasks but impose a rigid process on everyone even to do basic tasks.
Simple CMSs may be coherent, but complex ones often aren’t. Every CMS will be compared to a word processor, which seems simple because it deals with one author at a time. It’s an unfair comparison; it ignores the many other tasks that CMSs support, such as analytics and workflow. But too many CMSs are pointlessly complex. They are mashups of functionality, the shotgun marriage of corporate divisions that don’t collaborate, separate products that were acquired and packaged as a suite, or collections of unrelated products patched together to provide missing functionality.
CMSs vary in their learnability. Some are so complicated that firms hire specialists just to manage the product. Other products require online “academies” to learn them — and possibly certifications to prove your diligence. Still others seem indistinguishable from everyday software we know already until one needs to do some that’s not every day.
Comparing CMSs quantitatively
Over the years, the CMS industry has splintered into more categories with shifting names. It’s become hard to compare CMSs because all want to seem special in their own way. Many categories have become meaningless and obscure what matters.
Remove the qualification “of.” Plenty of sites will claim to be arbiters of what’s best. Analyst firms create “Best of” lists of CMSs based on various criteria. What gets lost in this sorting and filtering is the sense that maybe everyone interested in content management wants many of the same things.
Some analysts focus on the vendor’s projection (positioning) as innovative or market-leading — qualities hard to define and compare. Some other sites rank vendors based on customer surveys, which can reflect whether the customer is in their honeymoon phase or has been incentivized to respond. While these resources can provide some useful information, they fail to provide feedback on things of interest to everyone, such as:
Comparison of CMSs from vendors from different CMS categories
Comparison of the usability of various CMSs
The ESUS can cut through the curation ring fence of “Best of” lists. It’s not beholden to arbitrary categories for classifying content management systems that can prevent comparison between them.
Aim for unfiltered comparison. Imagine if CMS users could get a direct answer to the question, Which CMS has better usability, overall: Adobe Experience Manager, Contentful, Wix, Drupal, WordPress, or Webflow? After all, all these products manage content. Let’s start here, with how well they do the basics.
Many folks would object that it’s an unfair question, like comparing apples with oranges. I believe those objections devalue the importance of usability. Every CMS user deserves good usability. And there’s no evidence that CMS users have different standards of usability — 40 years of SUS results tell us otherwise. Users all want the same experience — even when they want different functional details.
For many years, the people designing, managing, and delivering user experiences have pursued the LEGO ideal – making experiences modular.
Content teams have aimed to make content modular so that it can be assembled in multiple ways. UI design teams have worked to make user interfaces modular so they can be assembled in different ways as well.
More recently, vendors have embraced the LEGO ideal. The IT research firm Gartner labeled this modular approach as “composable” and now scores of SaaS firms endorse composability as the most desirable approach for building user experiences.
The LEGO ideal has become a defining North Star for many digital teams.
The appeal of LEGO is easy to fathom. LEGO is familiar to almost everyone.
Though LEGO was not the first construction kit toy that allowed parts to be connected in multiple ways, it has by far been the most successful. LEGO is now the world’s largest toymaker.
But LEGO’s appeal stems from more than its popularity or the nostalgia of adults for pleasant childhood memories. LEGO teaches lessons about managing systems – though those lessons are often not well understood.
What LEGO figured out: Clutch Power
What’s been the secret to LEGO’s success? Why has LEGO, more than any other construction toy, achieved sustained global success for decades?
Many people attribute LEGO’s success to the properties of the bricks themselves. The magic comes from how the bricks fit together,
The Washington Post noted in 1983 the importance of “the grip that holds one piece to another. Measurements have to be exact down to minute fractions of an inch, which requires high-precision machinery and closely monitored quality control.”
The ability of the bricks to fit together so well has a name: clutch power.
The fan blog Brick Architect defines clutch power as “Newtons of force to attach or remove the part.”
The Washington Post noted that the bricks’ clutch power translated into “market clutch power”: how solidly the bricks built a grip with consumers.
Clutch power makes bricks more powerful:
Bricks can connect easily – they snap together
Bricks can be disassembled easily by pulling them apart
Bricks are not damaged or deformed through their repeated use
Bricks are infinitely reusable.
Clutch power is an apt metaphor for how brinks connect. Like the clutch in a car that shifts between gears, clutch power allows bricks of different sizes and roles to work together to deliver a bigger experience.
What makes content and design LEGO-like?
Truth be told, most content and design modules don’t snap together like LEGOs. Content and design modules rarely exhibit clutch power.
Even if the original intent was to create a LEGO-like kit of parts, the actual implementation doesn’t deliver a LEGO-like experience. It’s important to move past the pleasing metaphor of LEGOs and explore what makes LEGOs distinctive.
LEGO bricks aren’t for very small children – they are a choking hazard. Similarly, some teams figuratively “choke” when trying to manage many small content and design elements. They are overwhelmed because they aren’t mature enough to manage the details.
Attempts to create modularity in content and design often fall short of the LEGO ideal. They resemble LEGO’s junior sibling, DUPLO, offering simple connections of a limited range of shapes. In addition to generic bricks, DUPLO includes less general pieces such as specialized shapes and figures. It reduces the choking hazard but limits what can be built.
We find examples of DUPLO-like modularity in many UX processes. A small interaction pattern is reused, but it only addresses a very specific user journey such as a form flow. Small UI “molecules” are defined in design systems, but not more complex organisms. Help content gets structured, but not marketing or app content.
The limitation of DUPLO approach is the modularity isn’t flexible. Teams can’t create multiple experiences from the pieces.
When teams can’t create complex experiences out of small pieces, they resort to gluing the pieces together. Pieces of content and design get glued together – their connections are forced, preventing them from being reused easily. The outputs become one-off, single-use designs that can’t be used for multiple purposes.
Some people glue together LEGO bricks, even though doing so is not considered an approved best practice. They create an edifice that is too fragile and too precious to change. Their design is too brittle to take advantage of the intrinsic clutch power of the bricks. They create a single-use design. They use modularity to build a monolith.
Digital teams routinely build monolithic structures from smaller pieces. They create content templates or frontend design frameworks that look and behave a certain way but are difficult to change. They build an IKEA product that can’t be disassembled when you need to move.
So what gives content and design clutch power? What allows pieces to connect and be reconfigured?
The digital equivalent of clutch power is systems interface design – how the interfaces between various systems know of and can interact with each other. It determines whether the modules are created in a way that they are “API-first” so that other systems can use the pieces without having to interpret what’s available.
More concretely, giving content and design modules clutch power involves defining them with models. Models show how pieces can fit together.,
Models define things (resources) and their relationships, highlighting that things have a rich set of potential connections. They can snap together in many ways, not just in one way.
Defining things and their relationships is not easy, which is why the LEGO ideal remains elusive for many digital teams. It requires a combination of analytic and linguistic proficiency. Relationships are of two kinds:
Conceptual relationships that express the properties that things share with each other, which requires the ability to name and classify these properties clearly, at the right granularity (abstraction), to enable connection and comparison with appropriate precision.
Logical relationships that express the constraints and requirements of things and their values, which calls for the ability define what is normal, expected, exceptional, and prohibited from the perspective of multiple actors engaged in an open range of scenarios.
Modeling skills transcend the priorities of UI and content “design”, which focus on creating a product intended to support a single purpose. Modeling skills are more akin to engineering, without being cryptic. Modular pieces must be easy to connect, cognitively and procedurally.
We sometimes find organizations hire content engineers, content architects, information architects, or UI engineers, but most often designers and developers are in charge of implementation. We need more folks focused on creating clutch power.
What LEGO is still learning – and their lessons for digital teams
LEGO created a system that could grow. It expanded by offering new brick shapes that allow a wider range of items to be built.
LEGO has proved remarkably enduring. But that doesn’t mean it doesn’t need to adapt. To maintain market clutch power, LEGO needs to adapt to a changing market. Its past formulas for success can no longer be relied upon.
LEGO’s bricks are made from ABS plastic. ABS plastic gives the bricks their clutch power. But they are also environmentally bad as they are petroleum-based and have a big carbon footprint. As the world’s biggest toymaker, producing billions of plastic bricks, LEGO needs to change its model.
LEGO has tried to change the formula for their bricks. They’ve sought to replace ABS with recycled polyethylene terephthalate (RPET) but found it too soft to provide the needed clutch power. Additives to RPET, which would make it safer and more durable, require too much energy consumption. After intensive research, LEGO is discovering there’s no simple substitute for ABS.
LEGO’s dilemma highlights the importance of creating a system that can adapt to changing priorities. It’s not that clutch power became less important. But it had to fit in with new priorities of reducing carbon emissions.
One option LEGO is looking at is how to enable the “recircling” of bricks. How can bricks in one household, when no longer needed, be re-entered into the economy? LEGO is looking at a “circular business model” for bricks.
A circular model is one that digital teams should look at as well. The aim should not just be how a team can reuse their content and design modules, but also how other parts of their organization can reuse them, and perhaps, how outside parties can use them too. An API-first approach makes recirculation much easier. Better collaboration from vendors would also help.
