Open in app

Sign in

Write

Sign in

Content Design and UI Mapping

Gather, manage, publish and “display” content independently on any UI

Wolfram Nagel
11 min readDec 11, 2016

When you want to gather, manage and publish content and display it independently on any target channel you need a system that supports “Content and UI Mapping”.

Content and user interfaces can be planned and assembled structured and modularly in a similar manner — comparable to bricks in a building block system. Content basically runs through three steps until it reaches its recipient: Gathering, management and output. A mapping has to occure at the intersections of these three steps.

Here’s my approach and the status quo of my thoughts on this challenge. I’m always open for feedback. :-)

Correlation and systematic mapping of Content and UI

Accompanying and summarizing slides on the topic:

Holistic approach on Content UI Mapping: Gather, manage, publish and display content independently on any user interface according to the building block system.

Multiscreen

We live in a Multiscreen-World. Everything needs to work across devices. This requires a holistic strategy. I wrote a book on that topic. This is the starting point on my thoughts and led to the following concept.

From »Multiscreen UX Design« (www.msxbook.com/enbook, ISBN: 978–0128027295)

Digital contents can appear everywhere today. It is just a fact that we use digital services daily on a wide array of devices and media. Information flows into all channels. In order to create a uniform user experience, a continuous flow of information is required.

Basic parameters, methods and strategies for multiscreen-projects are explained in detail in my book „Multiscreen UX Design“, in a summarizing article, and in a little article series. (You can use the code COMP315 for 30% off on the book.)

Next Generation Information Experience
In 2014 I presented some thoughts on „Next Generation Information Experience“ at Usability Professionals Conference in Munich. In the future, and already now, digital information and services must be able to be obtained from a wide array of sources on various devices, in a wide array of media, for multiple screens and output channels. It’s important how content is created to prepare the best possible quality of information that will be consumed by recipients on any imaginable touchpoint.

The content editors lay the base for content that can and will appear everywhere. They must be able to concentrate on the creation of content. Try to optimize the UX for them and support their work as much as possible.

You need one single point where every content arrives, can be managed and be delivered from. A centralized content hub for content channeling and aggregation will help to tackle these challenges! Try to offer and implement custom interfaces and/or gateways (API). If it’s possible allow editors to use their preferred system. Use interfaces to gather, aggregate, and manage content as well as to deliver content to each channel that is important for your (potential) target group.

After my talk at UP2014 which focused on the “content manager experience” I started thinking and researching about how content and user interfaces should be designed, built, managed and brought together to be as channel-independent as possible (and as it turned out during my research I was not the only one tackling that interesting challenge).

Module-based approach

A modular approach helps to develop platform-independent content and user interfaces which can then be put together in a way that correspond with the user’s needs and the context of use.

There are several concepts and strategies that are based on a modular approach with single “bricks”. With Content Design, Content Modeling, and Atomic Design (or “UI modeling” in other words) individual bricks are assembled according to the building block principle similarly to LEGO. Other approaches (among others) I found during my research on that topic are object-oriented programming, object-oriented UX, or the Content and Display Patterns.

Foremost one important aspect: If content is built upon the building block principle each brick (of content) can be outputted as independent as possible whereever you want.

Five-stage building block principle: Contents and user interface can be developed in a
modularly structured manner, comparable to the building blocks of the LEGO building
block system. The fifth stage (concrete shape) occurs with the recipient. There’s a correlation
between content and user interface. (source: Nagel, 2015b)

Generic five-stage building block principle

The individual (atomic) elements and/or building blocks build on one another and can be flexibly assembled to form a type (a concrete instance of a type is an object). Each type or object can be developed with five stages — from the smallest possible element to the generic template and the real, unique object (individual instance).

The terms from the atomic design chemistry metaphor can be replaced by generally valid generic terms:

  • atom = brick / element
  • molecule = small brick group / component or module
  • organism = large brick group (group of groups) / segment or area
  • template or type (generic)
  • instance or object (concrete)

Content and UI Mapping

Three-step content flow

There are three parts in a content’s (work) flow. It has to be created (written and structured). It has to be managed (by adding meta data, defining workflows and rules, and setting it up). And it has to be delivered to any kind of target channel or viewport where it is viewed and received by the (end) user.

You can create, collect, and output contents — wherever and with whatever you would like. At the two intersections of these three steps content and UI have to be mapped. Firstly content must fit to the defined content structure, and secondly the structured content bricks must fit to the output bricks in the target channel. A central hub in the middle of these three steps serves as interface between in- and output.

The Three-Step Content Hub (principle): 1) Collecting and authoring 2) combining and managing 3) outputting and distributing to various channels. The content hub in the middle plays a central and important role in the content flow. Content will be aggregated, mapped to a predefined structure (if there are different input channels), organized and prepared for flexible output in the content hub (see also the content mapping example at the beginning of this chapter).

Inspired by LEGO

If you create contents, user interfaces, and processes based on brick-like, modular building block patterns, you will be largely independent of future developments.

If you have (for example) a bunch of unsorted LEGO bricks (comparable to a lot of content and UI elements on a website, for example) you can (and should) first sort them to get an overview. Make an inventory of all the bricks that are available and shall be used to build any LEGO model. You can build different cars out of the same elements, if you combine them in a different manner. That’s the same what you can do and must think about with your content (and your user interface). Different elements can and will be shown and differently used and combined on various channels and touchpoints. A systematic and structured approach helps to tackle that challenge.

Let me quote Brad Frost.

Rather than diving headfirst into constructing the final work, you can take the time to take stock of the available pieces and organize them in such a way that they become more useful. […] By taking the time to organize the parts, you can now create the whole in a more realistic, deliberate, and efficient manner.

Systematic and structured approach: Make an inventory of all the bricks that are available (LEGO, content, UI, whatever). You can then easily build different types out of the same brick pool.

Semantically similar contents should be variably utilizable in various media, channels, and devices. This applies to the smartphone, tablet, desktop, TV, and smartwatch as well as for contents on your own website, in Google search results, in the RSS feed, on Instagram or Facebook, or any other content presentation.

Content structure mapping

An information management system must support the work of content creators and should be able to serve as a hub for all contents. The collection and/or creation of the content seldom occurs via a uniform system. It would be best if authors could use their customary creation system and the collected contents could be consolidated, merged, and brought to the defined structure via corresponding (application programming) interfaces and a kind of content structure mapping in the content hub based on the content model. By so doing, it would be possible to collect contents based on and according to the structure of the content model and the content type with any system and via any input-channel (e.g., via e-mail, Evernote, a Tweet, a Facebook post, or another system), to edit and update it in the content hub, and to flexibly transmit and publish it again to any desired channel.

Thus, it would be possible — via a “simple” e-mail — to collect the content elements (of a news article, for example) of author/creator, creation date, title, brief description (short text), main text contents (long text), photos or media elements (as attachment), and other meta-information, for example via hashtags, a kind of markup or other defined characters in the e-mail text as the Todo app Todoist does. The gathered contents could then be edited, optimized, and supplemented in the central hub.

Content structure mapping: Content elements can be generated via variable input channels (each channel quasi serves as CMS) and then be mapped according to the underlying structure of the content type (for example a news article). In the “long text” semantic structuring (e.g. H1, bold, quote, listing, etc.) is adopted.
Content structure mapping: The individual content bricks of the content type are mapped to the UI bricks in the target system. The UI template has to offer the UI bricks, otherwise some content bricks can possibly not be outputted in certain target systems.

Content providers are confronted with the problem that they should be able to consistently publish contents in many channels. Information should be able to be displayed everywhere. The requirements for this are a central and, insofar as this is possible, user-friendly hub for contents (e.g., content management system [CMS]), a central system for the definition of UI elements (e.g., style guide or UI pattern library), and corresponding rules (workflows) regarding when which contents will be displayed in which combination on which device and how.

UI Mapping

The following example will show how the individual bricks of the content type “event” can be mapped to different shapes of a “teaser” UI component in the target system (here: a website with desktop-like presentation). The teaser in the example is simplified and consists of four different text bricks, an image and metadata. (It’s the same for any other target UI component as with the teaser example.)

Screenshot of a website (target system website, viewport “desktop”) with different teaser variations (large, medium, small).
Same content and different presentation: The three teaser variants extracted and isolated from the website with the individual UI bricks (except the image all exemplary available information is outputted textually).
The generic teaser variants schematized without content with the individual content bricks. The small teaser shows most information in this case and uses all exemplary content bricks of the content type “events”.

Summarized: One content type can be displayed in various shapes when the generic structure basically fits to the the generic UI structure. The UI components have just to be able to display or output the relevant bricks of the content type. The other way round it’s the same. Different content types can be displayed similarly (see following example).

Different content and same presentation: The basically different content types “event” and “article” are structurally different, but generically identical. Thus the bricks of both content types can be mapped to a generic teaser component that can display these bricks. In short: Different content types can be displayed identically. Which also means that different UI types can be served by content bricks from the same content type (see above).

Content Modeling according to the building block principle

Based on the aforementioned ideas, we at SETU GmbH have developed a concept for such a “content management hub” that will be integrated into our SETU 3.0 release. With it content management apps can be realized for various thematic focuses (units).

The content architect has predominantly free rein with the structuring of the data bodies. The software offers a large library of predefined (and extendable) form and output elements (bricks) and supports iterating elements within a data model (including more complex structures such as text with an image) as well as relationships and kinds of relationships to other elements. It offers functions for the creation and management of language- and market-specific contents such as heredity and workflow support. Existing platforms can be supplemented with freely definable workflows in customer communication.

Moreover, rule-based and connected and related and individually personalizable context-based contents can be supplied. Context relevance can be recognized and utilized via rules and meta-information. Personalized contents dependent on, among others, the log-in, user profile and user type, Internet speed, device, output medium, channel, etc. The structured information that has been supplied can be integrated into as many platforms, target UIs and channels as desired.

SETU Software: Content Modeling Software suitable for the building block principle. The moodscreen shows an impression of the user interface of a demo use case of the SETU 3.0 release.

Outlook

A visual presentation of content can be standard body copy (text), a list, a table, chart, infographic, or an interactive application. All these types of output have to be considered when mapping content to a UI. But a user interface is not only visual. You can input, output and interact with content and interfaces also via speech, haptically, or with text only, for example. Don’t forget the Internet of Things.

That in the future information can be coherently outputted on any imaginable channel, you must also consider the Internet of Things and all other shapes of interfaces when thinking about UI libraries, styleguides, content models and the mapping of content to any UI. This is a challenging and very interesting task for content and UI designers in the future and anyone else that has to deal with content and user interfaces in general.

I’m quite curious and excited to participate in and make my contribution to that challenge. And I’m open for any discussion or question on the topic.

If you liked this article, please ❤️ it so others stumble upon it as well! Thank you! You might also read some of my other articles.

If you want to have the presented approach more visually, just check out the summary slides on slideshare. There’s also an extended slide version available.

Any questions? Feel free to send me an e-mail.

Note: This is a summarizing translated article of two other articles that I initially published in German: Content Design und UI Architektur für Multiscreen-Projekte and Content und UI Mapping

Sources

About the author

Wolfram Nagel is a UX Designer, UI Architect, and Concept Developer. As Senior User Experience Designer at TeamViewer he is responsible for conception and design in close collaboration with product owners, product managers, front-end and back-end developers.

Previously he worked as Head of UX for SETU GmbH (a German software engineering company) with main responsibility in the areas of multiscreen, user experience, content design, UI architecture, and visual design. He gives talkes to these topics and is author of the book “Multiscreen UX Design”.

Design
Content Strategy
UI Design
UX Design
Content Management

--

--

Wolfram Nagel

Written by Wolfram Nagel

539 Followers

UX Designer (@TeamViewer), UI Architect, JTBD Practitioner, Author of “Multiscreen UX Design”, Initiator of the “Design Methods Finder”. I love my 👪 and ⚽️🚵📸

Help

Status

About

Careers

Blog

Privacy

Terms

Text to speech

Teams