We, as UX Designers, are the primary advocate for the user. Therefore, understanding their needs and goals is fundamental to our work. Being able to emphasize with them enables us to tailor an experience to their needs. Yet, in my experience, the content is of equal importance. It is the material our applications are made of. It’s the reason why users visit. Without a thorough understanding of its structure and properties, we can’t tailor the content to our users’ needs.

At the beginning of the year, I came across an article that echoed some of my late thought. It was titled: “Why Content Is Such A Fundamental Part Of The Web Design Process”, written by Matt Saunders. In his article, Matt states that as UI designers the content is our material. And that it could be disastrous to only use real content late in our process. I wholeheartedly agree. However, in his article, he identifies the non-existence of the content as the root cause. Especially early in the process, when the story is still shaping up.

For web design, this might be true. But for many applications, the content, or at least its structure, is defined via the back-end or other system. However, I notice a very similar behavior in product design. We neglect the content too. In my opinion, the issue is more profound. We, as designers, lost our drive to dig into the content.

As product designers, we spend a tremendous amount of time with our users. At the beginning of a project, we send surveys or do interviews. Then, once the first concepts are done, we re-engage with users and validate. And, before our designs get developed, we run usability tests. We make sure users are involved at every stage of the process. Yet when it comes to our content, we eventually define the type (text, image, video, or audio) and determine its superficial hierarch.

I have been designing websites and applications for almost 20 years. In my experience, understanding the content is key. As Matt stated, it is our material. For me, UI design is the process of bending the content to our users’ needs. We need to know our material’s abilities, dependencies, and requirements. The UI works at the intersection between your content’s abilities and users' needs.

To be specific, when I talk about the content, I don’t mean the words of a text or the subject of an image. I am not talking about the tone of voice or the story to be conveyed. Instead, I refer to the content as a structural object with its elements and their properties. For example, does this text come as one block, or is it further nuanced via separate elements like a headline, sub-line, and body copy with paragraphs? How long is the video? Is it related to an author? And what is the aspect ratio of the image(landscape or portrait)? How granular are the data points for a chart?

As I mentioned above, usually, there is an underlying back-end, an API, or some other system that dictates the rules. Mapping and understanding this structure is key when selecting UI patterns and designing an application. Applying an object-oriented mindset helps to build the content inventory. It provides an approach to investigate the individual part and craft a UI around the content. Object-oriented thinking is nothing new, but it has come back into the spotlight thanks to Sophia V Prater. Her initial article: “OOUX: A Foundation for Interaction Design”, outlines how an object-oriented mindset helps to understand your content. And in return, build a strong foundation for your design.

Problem with standardization

In the early days of the internet, content was king. We crafted websites and applications from the content up. There were only a handful of established patterns. Every new website was a new design challenge. We reinvented the wheel over and over. It was a playful time, but it came at the cost of huge usability issues.

With the introduction of mobile applications, there was a strong push for standardization. The new viewports created new challenges for consistency and coherence. In 2010, Brad Frost’s Atomic Design offered new ways to define and structure our work. There was a need for systematic designs. And when Google released Material Design in 2014, it ushered in the age of design systems. The reuse of UI patterns enabled designers to focus on user problems in opposite to crafting patterns. It reduced the learning curve for users. And last but not least, the standardization reduced development effort. So what is the problem with this development?

We don’t spend much time with the content. At best, this makes the design interchangeable. At worst, this creates a broken experience.

In theory, nothing! But, in reality, it feels like we went too far. Christian Beck asks his article “Design Systems Create Bad Designers”, why designers should even bother to learn design principles if they are baked into the design system. I would expand on this and ask: Why should a designer make an effort to understand the content if it is just about copying a pattern from somewhere else.

It seems that we rely too much on tech giants for our inspiration. In her article “The Risks of Imitating Designs (Even from Successful Companies)”, Kathryn Whitenton lists excellent examples where this might not have been the best idea. In addition, it seems like we copy patterns from other successful applications without questioning the context. Before we reference external design systems, we need to know what makes our content unique. We need to understand how our content differs. It is impossible to select the correct pattern without a good understanding of our material. Skipping this step results at best in a blend and exchangeable design. At worst, this leads to a broken experience where the UI does not fit the content. In both cases, we miss the chance to create something unique, something that has a justification for existing.

The content is our material

The content is the reason why users come to our applications. It enables us to connect with our users and engage them in experiences. Screen design, and therefore, UX and UI design originated from graphic design. Thus, our mindset and design approaches are modeled based on that discipline. We still arrange elements on a 2D plane. To adjust for the interactivity of our medium, we add a 3D dimension and place those screens in a flow. Yet, today’s UX and UI design is much closer to another design discipline: industrial design.

The Bauhaus was one of the most influential design schools of the early 20th century. Material studies were at the core of its curriculum. Walter Gropius (the founder) believed that designers should use materials in the most honest way possible. To do so, they need to understand the strengths and weaknesses of the used materials.

To design a metal frame chair, you need to know how metal works. You need to know how thick it should be to carry the required weight. Understand how you bend it to get it into the desired shape? Experiment with how to finish it to achieve the desired look and feel? If you aim to mass-produce the chair, you need to go even further. You will need to understand how factories work. How many steps are needed to produce the chair? Which steps might be complicated or risk the quality. What makes the assembly expensive or cheap? Without this knowledge, you can design beautiful chairs, but no one will be able to sit on them.

The content is our material. The back-end is our factory.

The same applies to digital products. If we come back to the article from Matt, the content is our material, and we need to understand the content the same way the students at the Bauhaus had to. We need to know how our content behaves. Understand how flexible it is. And experiment to know when it will break. Otherwise, you won’t be able to shape your content to your users’ needs.

A content-first approach

So how do you get to know your content? And which aspects of the content will impact the UI model and patterns? As I mentioned above, an object-oriented approach helps to structure the content. Instead of focusing on user flows, OOUX focuses on the content. It attempts to capture the user experience via distinct but relatable content objects and their elements. ORCA (Objects, Relationships, Call-to-Action, Attributes), introduced by Sophia V Prater, offers a great step-by-step process to capturing those entities (Have a look at the video down on the page).

Spending time studying and understanding your content will help you select more appropriate UI models and patterns. Also, it will lead to more relatable conceptual models, better usability, and a better user experience. To better understand an application’s content, I look at three main aspects. I start with a content inventory. Then investigate the individual elements. And last but not least list the different instantiations of the content objects.

1. The content inventory

To avoid surprises further down in the design process, you’ll need a content overview. You need to know all content elements and understand how they relate.

Start by identifying the primary content objects used throughout your application. Once identified, you go one level deeper and list their content elements. Start with the core content elements and metadata. Once those are identified, map the nested objects. Lastly, you list all the actions (CTA — call to actions) the users will need to work with the object.

2. The content study

Once you have your inventory, it is time to inspect each content element's attributes. Every image, video, headline, or body copy has its specific properties, constraints, and requirements. Keep in mind that those attributes depend on the context and the back-end.

Here are some aspects I usually look into:

• Origin: Where is the content coming from? Is it hardcoded? Does it come from a database? Is it user-generated or curated?
• Appearance: What is the typical character count of a headline, a teaser, or body copy? What are the sizes and default aspect ratios of an image or video? Compared to the most common or the default, what is the variance you need to deal with? How often will those extremes occur?
• Relationships: How do those elements relate to each other? Do they have a one-to-one relationship or one too many? Are there dependencies between one element and another? For example, a teaser could be an excerpt from the body copy.
• Hierarchy: Are all related elements equal, or do some have a parent-child relationship?
• Versions & state: Is the content changing over time, or will it stay static?

3. The object instantiations

Now that we know the content pieces and their constraints, let’s look at how they will play in concert. Content objects usually appear in many places and different shapes within the application. For example, an object can be displayed as a detail page. It can be shown as a list item on an overview page. Or, it could be shown as a teaser or related content card.

Identify and detail the required instances. Check its relationships and/or if the object is nested in other objects. There might be more, but those will give you a good idea. Once you know where an object is shown in the application, list the content elements for each occasion. Ideally, you follow the content element prioritization of each object.

4. Select the correct pattern

Last but not least, we use all this knowledge to select the right UI pattern for each instance. The chosen pattern should fit the user and content requirements. The ideal UI pattern negotiates between the users’ needs and the content’s abilities. It respects the content needs and enables users to navigate and use the content to reach their goals.

We know the different instantiations of each object. And we know the requirements and constraints of its content. All this knowledge should enable us to narrow the possibilities to a handful of patterns. This is where the users come back into the picture. Looking at our options through a users’ lens should enable us to determine the best pattern. Ideally, patterns used for different instantiations of the same objects should feel coherent. For example, a teaser card should not feel too different from the detail page it links to.

Summary

As I stated in the introduction, we, as designers, need to get more serious about the content and its structure. The content is our material. The UI is our tool to bend the content to our users’ needs. If we don’t know our materials constraints, it might break. If we don’t know its advantages, we will never make it shine. Users are essential, but the content too. Our UI needs to mediate between the users’ needs and the content’s capabilities.

Content is our material. The UI is our tool to bend the content to our users’ needs.

The next time you design a new application, take your time and immerse yourself in the content. Consider using an OOUX approach to structure your content. Inspect the individual content elements. Identify the required instances and choose the pattern based on the content abilities and the users’ needs. Don’t just copy a UI model or pattern from another app, but use your knowledge to pick the right one. Tailor the UI to contents and users’ needs. As a consequence, your content will shine and connect with your users.

Clapp, if you like the article, follow me for more thoughts about OOUX. In my next article, I will dive deeper into OOUX and outline how an object-oriented UX approach helps to look beyond established patterns and tailored applications to their content.