Quick heads up

I recently fixed some behind-the-scenes email settings to improve deliverability. If Model Thinking has been landing in spam or you’ve missed recent issues, please mark this as “not spam” and add model-thinking@tripleoakenterprises.com to your contacts. You can browse all past issues anytime at newsletter.collinscontent.com.

Issue 31

The user abstraction pattern

I was leading a large content management (CMS) implementation with dozens of stakeholders—some eager and others … not so much—from several teams. Part of the project was moving a large content set to a new subdomain on a new site with a modernized user interface.

Before we got deep into the work, I led an effort to establish some design principles that we could use to fall back on when we got mired in opinions or just too many details. One of those principles was something along the lines of “Champion the user.”

I was part of the Design org. Many of my stakeholders were too. That principle sounded obvious. It felt unassailable, but I eventually recognized that “champion the user” wasn’t as clear-cut as I thought.

As the project progressed there were murmurings and insinuations that my work wasn’t user-focused. It didn’t feel good, and I’ve struggled to wrap my head around everything in the years since then.

What is a user anyway?

One realization I had was that we were talking about different users. Indeed, I’ve thought for years that the project had different types of users, even though I struggled to communicate it.

Many of the stakeholders were thinking of the end users of the website we were working on. Valid.

But most of those stakeholders were going to be users of the system I was building—that my job performance metrics were based on. Also valid.

So, who is a user?

Tiers of users?

No, not tears of users. Tiers.

I started to realize that both the website end users and my stakeholders could be considered users, but obviously they weren’t the same. So I began to think about types of users, and the first thing that came to mind was primary users (my stakeholders: the content authors, editors, software developers, and UX designers) and secondary users (end users).

I was thinking of primary and secondary in the sense of when they acted as users.

Obviously that naming didn’t sit well with me because it implies a hierarchy or comparison between the groups that I didn’t intend. End users don’t matter less or more than the content authors working in the CMS.

A dawning realization

Especially now that we have headless CMSes powering experiences in multiple channels, secondary users—end users—are distanced from the CMS.

They are distanced—abstracted, if you will—not because they matter less, but because they don’t interact solely with the outputs of systems-level work. This work is one part of a larger experience they encounter.

Some of my stakeholders were equating “user-focused” with “end-user adjacent.” The problem wasn’t that I didn’t care about users. The problem was that we didn’t understand how user-centered thinking works when some users are more abstracted than others.

I think that the broader industry hasn’t figured it out either, and we need to. If we don’t serve the initial users well, the end users downstream suffer too.

As abstraction increases, so too does responsibility to create a strong foundation. Otherwise, the designers of the larger experience may be—to use an American idiom—putting lipstick on a pig.

Towards different naming

Now I’m thinking about this as the User Abstraction Pattern. Within the pattern, I’m shifting from primary users to direct users and from secondary users to downstream consumers.

Direct users are a low abstraction and downstream consumers are a high abstraction. And like many nuanced things, this abstraction pattern is a continuum, even within the two groups.

Within direct users, an author is less abstracted than a designer. Within downstream consumers, a person browsing a website is less abstracted than a large language model that consumes the content.

But this pattern doesn’t just happen in content management systems. It also occurs in design systems, data platforms, and in artificial intelligence (AI) systems.

I’ve also considered other terminology for the two groups, and I wonder about shifting the terminology for different audiences.

• System users / Experience users
• System operators / System beneficiaries

How to stay user focused, in spite of abstraction

Systems teams still need to know the end users, but they likely need to know them via proxy. Personas, jobs-to-be-done (JTBD), and analytics might be those proxies. Designers or product managers on the cross-functional team might be those proxies.

Without these proxies in place, outsiders have more reason to say the systems team isn’t user focused.

Continuing refinement

The problem with “champion the user” was that it was too constrained. I didn’t have the language to broaden the view for myself or my stakeholders.

Now I’ve got the user abstraction pattern and its emerging language. Arguably, everyone in product development in the technology sector and even everyone in a service business is doing what they do for users. Being user-focused isn’t just in the domain of product designers. It’s everyone’s role, but we need to realize that some roles are more abstracted from users than others. That’s OK.

Have you felt this tension of working deep in systems and needing to be user focused?

I’d love to hear your thoughts, so if you got this in your inbox, hit reply and send me a message. If you’re reading online, send an email to model-thinking@tripleoakenterprises.com.

Real World Content Modeling: A Field Guide to CMS Features and Architecture by Deane Barker

Welcome to the 4 new subscribers who joined us since the last issue of Model Thinking.