UX Designers advocate for the user. They need to understand their needs and goals and tailor an experience to their needs. But the content is also important. It is the material that causes a user to visit. Without understanding the content's structure and properties, we are unable to fit it for our users' needs. Does the text come as one block, does it have a headline, sub-line, body with paragraphs? How long is the video? What is the aspect ratio of the image?

Understanding the content is key

There is often an underlying back-end that dictates the rules. Mapping and understanding this structure is vital when choosing UI patterns and designing an application. An object-oriented mindset is vital to help build the content inventory. It gives an approach to designing a UI around the content.

An object-oriented mindset

In the early days of the internet, we created websites and applications from the content up. Every new website rendered a new design challenge. The introduction of mobile applications caused a need for systematic design. So, in 2014, Google introduced Material Design and enabled designers to focus on user problems instead of creating patterns. But it caused designers to rely too heavily on copying patterns instead of trying to understand the content. Before we reference design systems, we need to understand what makes our content unique. Failing to do this can lead to a broken experience.

The problem with standardization

Our users come to our applications because of the content. The content allows us to connect with our users and engage them in experiences.  This necessitates us to know how our content behaves. We need to understand how flexible it is and notice when it will break. An object-oriented approach can help to understand and structure the content.<ol><li>Start with a content inventory.</li><li>Then investigate the individual elements.</li><li>Finally, list the different instantiations of the content objects.</li></ol>

The content is our material

<ul><li>Identify the primary content objects used in your application.</li><li>List their content elements. Start with core content elements and metadata, then map the nested objects.</li><li>List all the CTAs the users will need to work with the object.</li></ul>

The content inventory

When you have your inventory, look at each content element's attributes. The image, video, headline, or body copy have specific properties, constraints, and requirements.<ul><li>Origin: Where is the content coming from? Is it hardcoded, coming from a database, user-generated or curated?</li><li>Appearance: What is the general character count of a headline, teaser or body copy? What are the sizes and default aspect ratios of images or videos?</li><li>Relationships: How do those elements relate to one another?</li><li>Hierarchy: Are all related elements equal?</li><li>Versions & state: Is the content changing or static?</li></ul>

The content study

Once you know the content pieces and their constraints, it's time to see how they work together. Content objects can appear in many places and in different shapes,  for example, displayed as a detail page or a listed item on an overview page or shown as a teaser. Identify and detail the required instances and check their relationships. Then list the content elements for each occasion.

The object instantiations

The correct pattern should fit the user and content requirements. It will respect the content needs and help users use the content to reach their goals. When we know the different instantiations of each object and the requirements and constraints of its content, it should narrow the possibilities to a few patterns. From there, we look at our options from a user's perspective to select the best pattern.

Choose the right UI pattern for each instance

<figure><img alt="Design for your content, as you do for your users! — cover image" src="https://miro.medium.com/max/500/1*Cs7EVXksPTLRQGULkDDHY" width="785" height="393"></figure>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: “<a href="https://www.smashingmagazine.com/2021/04/content-fundamental-part-web-design-process/" rel="noopener ugc nofollow" dir="ltr">Why Content Is Such A Fundamental Part Of The Web Design Process</a>”, 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.<figure><img alt="" src="https://miro.medium.com/max/500/1*hiAzq9xJ9nUktM7cFWbin" width="680" height="383"></figure>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: “<a href="https://alistapart.com/article/ooux-a-foundation-for-interaction-design/" rel="noopener ugc nofollow" dir="ltr">OOUX: A Foundation for Interaction Design</a>”, outlines how an object-oriented mindset helps to understand your content. And in return, build a strong foundation for your design.<h1 data-selectable-paragraph="">Problem with standardization</h1>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 <a href="https://bradfrost.com/blog/post/atomic-web-design/" rel="noopener ugc nofollow" dir="ltr">Atomic Design</a> offered new ways to define and structure our work. There was a need for systematic designs. And when Google released <a href="https://material.io/design" rel="noopener ugc nofollow" dir="ltr">Material Design</a> 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?<BLOCKQUOTE>We don’t spend much time with the content. At best, this makes the design interchangeable. At worst, this creates a broken experience.</BLOCKQUOTE>In theory, nothing! But, in reality, it feels like we went too far. Christian Beck asks his article “<a href="https://modus.medium.com/suburban-tract-housing-and-the-death-of-craftsmanship-a-critique-of-digital-design-systems-34c0fc1e106f" rel="noopener" dir="ltr">Design Systems Create Bad Designers</a>”, 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 “<a href="https://www.nngroup.com/articles/risks-imitating-designs/" rel="noopener ugc nofollow" dir="ltr">The Risks of Imitating Designs (Even from Successful Companies)</a>”, 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.<h1 data-selectable-paragraph="">The content is our material</h1>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.<a href="http://www.daevasdesign.com/bauhaus-truth-materials-central-principle/" rel="noopener ugc nofollow" dir="ltr">The Bauhaus</a> was one of the most influential design schools of the early 20th century. Material studies were at the core of its <a href="https://www.bauhaus.de/en/das_bauhaus/45_unterricht/" rel="noopener ugc nofollow" dir="ltr">curriculum</a>. <a href="https://en.wikipedia.org/wiki/Walter_Gropius" rel="noopener ugc nofollow" dir="ltr">Walter Gropius (the founder)</a> 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.<BLOCKQUOTE>The content is our material. The back-end is our factory.</BLOCKQUOTE>The same applies to digital products. If we come back to the article from Matt, the <a href="https://www.smashingmagazine.com/2021/04/content-fundamental-part-web-design-process/#the-difference-between-design-and-content" rel="noopener ugc nofollow" dir="ltr">content is our material</a>, 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.<h1 data-selectable-paragraph="">A content-first approach</h1>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. <a href="https://www.rewiredux.com/ooux" rel="noopener ugc nofollow" dir="ltr">ORCA (Objects, Relationships, Call-to-Action, Attributes)</a>, 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.<figure><img alt="OOUX — content inventory (map all required objects and list their core contents, metadata, related objects and actions)" src="https://miro.medium.com/max/500/1*Mz5MxmL7gZkQfFhkO_V_eQ.png" width="680" height="383"></figure><h2 data-selectable-paragraph="">1. The content inventory</h2>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.<figure><img alt="OOUX — content study (investigate each element of the object)" src="https://miro.medium.com/max/500/1*epK_DWNu91TFWMv0PNwwSg.png" width="680" height="383"></figure><h2 data-selectable-paragraph="">2. The content study</h2>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:<UL><LI>Origin: Where is the content coming from? Is it hardcoded? Does it come from a database? Is it user-generated or curated?</LI><LI>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?</LI><LI>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.</LI><LI>Hierarchy: Are all related elements equal, or do some have a parent-child relationship?</LI><LI>Versions &amp; state: Is the content changing over time, or will it stay static?</LI></UL><figure><img alt="OOUX — instantiations (list all the different ways the object will be shown in the UI)" src="https://miro.medium.com/max/500/1*RCFdQczxt465hQCSXBVSZw.png" width="680" height="383"></figure><h2 data-selectable-paragraph="">3. The object instantiations</h2>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.<figure><img alt="OOUX — pattern selection (use your knowledge to find the most suitable pattern or model for your object)" src="https://miro.medium.com/max/500/1*Noc8E4EvbcLeFn3Sh70ayQ.png" width="680" height="383"></figure><h2 data-selectable-paragraph="">4. Select the correct pattern</h2>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.<h1 data-selectable-paragraph="">Summary</h1>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.<BLOCKQUOTE>Content is our material. The UI is our tool to bend the content to our users’ needs.</BLOCKQUOTE>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.If you want to know more about the general mindset behind OOUX, check out my other article: “<a rel="noopener" href="https://uxdesign.cc/stop-thinking-about-flows-start-thinking-about-objects-16143c1b8b1f" dir="ltr">Stop thinking about flows, start thinking about objects</a>”

Using an object-oriented approach can help UX designers better understand their content and shape it to suit their users’ needs.

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…

Stashed ideas

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 t he year, I came across an article that echoed some of my late thought. It was titled: “<a href="https://www.smashingmagazine.com/2021/04/content-fundamental-part-web-design-process/">Why Content Is Such A Fundamental Part Of The Web Design Process </a>”, 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: “<a href="https://alistapart.com/article/ooux-a-foundation-for-interaction-design/">OOUX: A Foundation for Interaction Design </a>”, outlines how an object-oriented mindset helps to understand your content. And in return, build a strong foundation for your design.

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 <a href="https://bradfrost.com/blog/post/atomic-web-design/">Atomic Design </a>offered new ways to define and structure our work. There was a need for systematic designs. And when Google released <a href="https://material.io/design">Material Design </a>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 “<a href="https://modus.medium.com/suburban-tract-housing-and-the-death-of-craftsmanship-a-critique-of-digital-design-systems-34c0fc1e106f">Design Systems Create Bad Designers </a>”, 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 “<a href="https://www.nngroup.com/articles/risks-imitating-designs/">The Risks of Imitating Designs (Even from Successful Companies) </a>”, 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 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.

<a href="http://www.daevasdesign.com/bauhaus-truth-materials-central-principle/">The Bauhaus </a>was one of the most influential design schools of the early 20th century. Material studies were at the core of its <a href="https://www.bauhaus.de/en/das_bauhaus/45_unterricht/">curriculum </a>. <a href="https://en.wikipedia.org/wiki/Walter_Gropius">Walter Gropius (the founder) </a>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 <a href="https://www.smashingmagazine.com/2021/04/content-fundamental-part-web-design-process/#the-difference-between-design-and-content">content is our material </a>, 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.

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. <a href="https://www.rewiredux.com/ooux">ORCA (Objects, Relationships, Call-to-Action, Attributes) </a>, 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.

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.

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:

<ul><li>Origin: Where is the content coming from? Is it hardcoded? Does it come from a database? Is it user-generated or curated? </li><li>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? </li><li>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. </li><li>Hierarchy: Are all related elements equal, or do some have a parent-child relationship? </li><li>Versions & state: Is the content changing over time, or will it stay static? </li> </ul>

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.

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.

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.

If you want to know more about the general mindset behind OOUX, check out my other article: “<a href="https://uxdesign.cc/stop-thinking-about-flows-start-thinking-about-objects-16143c1b8b1f">Stop thinking about flows, start thinking about objects </a>”

Bite-sized knowledge
to upgrade
your career

Design for your content, as you do for your users

Understanding the content is key

An object-oriented mindset

The problem with standardization

The content is our material

The content inventory

The content study

The object instantiations

Choose the right UI pattern for each instance

IDEAS ABOUT

MORE LIKE THIS

15 Inspirational UX Design Quotes

10 Things You Need to Know About UX and UI design - Wiredelta

The ‘Design Review’ Between Designers and Developers

It's time to

READ

LIKE

A PRO!

Bite-sized knowledgeto upgradeyour career

Design for your content, as you do for your users

Understanding the content is key

An object-oriented mindset

The problem with standardization

The content is our material

The content inventory

The content study

The object instantiations

Choose the right UI pattern for each instance

IDEAS ABOUT

MORE LIKE THIS

15 Inspirational UX Design Quotes

10 Things You Need to Know About UX and UI design - Wiredelta

The ‘Design Review’ Between Designers and Developers

It's time to

READ

LIKE

A PRO!

Bite-sized knowledge
to upgrade
your career