Orange DAM

Orange DAM is an enterprise platform for managing digital assets: images, videos, documents, and other files.

The product helps large companies organize content, quickly find the files they need, and publish them. The platform is used by clients such as Google, Bank of America, Blizzard, Apple, AMD, and Instacart.

I worked on Orange DAM interfaces from 2024 to 2026 as a UX/UI designer, and later took over the product design and ownership of Site Builder — a tool for creating branded portals.

Process of work:

Site Builder

DAM stands for Digital Asset Management. It is a complex platform for large corporations that works like a file library. Companies use it to store images, videos, documents, presentations, and other digital assets.

Unlike a regular cloud drive, DAM is not just a place to put files into folders. It helps manage them: search, sort, assign access rights, keep versions up to date, and use materials in workflows.

But storing files is not enough. They also need to be shown to people: employees, partners, clients, and so on. For example, a company may need a brand portal, an online guideline, a product hub, or simply a corporate website. Usually this means hiring developers, launching a separate CMS on hosting, and maintaining the materials manually.

That is why Site Builder was created — a product within the Orange DAM ecosystem that lets users create branded portals directly from the file library. A client can choose a template or build pages with an easy-to-use editor, add text, blocks, and media files from the library, configure access rights, and launch a site without writing a single line of code.

Site Builder only looks similar to website builders like Wix or Webflow on the surface. The difference is that it is tightly connected to the file library. Users do not need to upload files again or manually track versions. They simply take the materials they need from a huge library, build a portal from them, and publish it. If files, access rights, or collections change in the library, the portal updates them automatically.

A site in Site Builder is built from ready-made blocks. The user clicks the Add block button and chooses what to add to the page. The platform includes dozens of blocks: headings, text, images, videos, galleries, carousels, and much more. Blocks are flexible to configure and support templates.

Each block is edited directly on the page. When the user hovers over it, a control panel appears: the block can be moved, configured, copied, or deleted. Opening the settings brings up a separate window with the parameters for that specific block.

For example, Carousel is a slider for images and videos. It can be filled manually with individual slides or connected to a folder in the library, so the content is automatically pulled from DAM and stays synchronized.

Another example is Gallery. It is a card-based block for collections of images, files, products, pages, or any other materials from DAM. Each card can have an image, a title, a description, and an action on click.

Cards can be filled in two ways. The first one is automatic: the gallery takes data from selected files and pulls titles, descriptions, and previews from their metadata. The second one is manual: the user builds each card from nested blocks, adding text, buttons, images, or other elements.

In addition to simple blocks like images, buttons, or text, Site Builder supports nested blocks.

For example, the Columns block lets the user split a page into several cells, and each cell can contain other blocks: a heading, text, image, gallery, button, or something else. The structure can go even deeper — for example, the user can add columns inside columns.

Working with this kind of structure can be tricky, so it needed its own navigation logic. The user can click on the needed area and gradually move inside the structure: first selecting the entire Columns block, then a specific cell, and then a block inside that cell.

To move one level up, the user can press Escape. Nested blocks also get border highlights with different levels of brightness.

Columns are the most complex block in Site Builder. They work almost like a flex grid in CSS. The user can control the minimum and maximum width of cells, spacing, and behavior when there is not enough space. All this flexibility is available without writing markup or code.

On a wide screen, cells can stretch to the full width of the container, wrap around their content, or take a percentage-based width. On a narrow screen, the same columns automatically stack vertically. The builder also allows individual cells to be configured manually — for example, one column can have a fixed width.

Overflow behavior was also designed separately. If the content does not fit, the block can either wrap cells onto a new row or keep them in one line and enable scrolling.

Settings and behavior were designed separately for every block in Site Builder. Each block solved its own task and was very different from the others, so a universal set of settings would not work.

The first task was to create a separate part of the design system for complex forms.

In most interfaces, forms are built vertically: first the label, then the field. This works well for simple forms and questionnaires, but for complex forms with dozens of options it takes up too much space and turns settings into an endless scroll.

For Site Builder, a different structure was proposed: labels on the left, fields on the right. This is a classic approach for interfaces with many parameters, used by Apple since the early days of interface design. It helps use screen space more efficiently and makes it easier to find the needed option.

This was especially important for complex blocks like galleries and columns, where users need to control content, styles, behavior, responsiveness, hover effects, and translations. As a result, settings windows became compact without feeling cramped. Forms got a consistent structure that was clear for both users and developers.

Site Builder supports responsive layouts.

The editor includes a view switcher. The user can build a page in desktop mode, then switch to tablet or mobile to see how it will look on smaller screens. Each block is designed with responsiveness in mind and transforms into a mobile version according to predefined rules.

Site Builder supports multilingual sites. Users can add as many languages as they need and create, for example, English, French, or German versions of the same portal without building a separate site from scratch.

The main content is edited directly on the page: the user switches to the needed language and changes headings, text, and descriptions right in the editor. If the text is part of an image, the file can simply be replaced in the block settings.

System labels are translated separately — in the Translate tab inside the block settings. This includes things like button text, search field placeholders, and other interface labels.

Individual blocks or entire pages can also be hidden in a specific language version. For example, if a section is needed only for the US market but not for Europe, it can be hidden for the selected language.

Spaces & Pages

Another major part of the work was redesigning the file manager interface and introducing spaces.

The file manager is the main screen of the product, where users search for files every day, switch between sections, filter assets, and work with large content libraries.

The goal was not to reinvent the file manager from scratch, but to make it more modern and easier to use in everyday work. The main changes focused on readability, visual hierarchy, asset cards, navigation, filters, the control panel, and overall interface density.

Previously, dozens of screens like this were called Workspaces, but despite the name, they were essentially regular pages.

They all existed on the same level: file library pages, project documents, service sections, planner screens, and so on were all placed in one long list. Navigation felt like searching for the right page among dozens or even hundreds of similar pages.

Workspaces were rethought as Pages, and a new level was added above them — Spaces. Now pages are grouped by purpose: one space for files, another for video projects, another for a site, and so on.

Each space has its own settings: name, URL, access rights, appearance, navigation, and so on. A space works not just as a folder for pages, but as a separate work area. It can be configured for a specific scenario, such as a brand portal or a file library.

Inside a space, there can be two types of pages: standard and custom.

Standard pages are used for DAM work areas, such as file libraries, projects, tasks, and so on. They can have access rights, sidebars, filters, browser behavior, and other parameters configured for a specific scenario.

Custom pages are site pages. Since they are built with Site Builder, they have fewer system settings.

Design system

The old design system had become outdated and could no longer support the scale of the product. It had basic components — buttons, fields, checkboxes, radio buttons — but lacked a clear overall logic. The colors were too bright and often clashed with each other, making the interface feel noisy.

Inconsistency was an even bigger problem. Similar components could have different sizes, spacing, corner radii, and states. Some were built carefully, while others existed as separate variants without a clear system behind them. Designers had to figure out every time which component to use and how it should behave in the actual interface.

A full component matrix was created for buttons, covering all main variants: a regular button, a button with an icon on the left or right, and an icon-only button. The component was designed in different sizes and several visual types — primary, secondary, outline, and destructive.

States were worked out separately: default, hover, active, disabled, loading, and focus. This helped remove the inconsistency that existed in the old system.

Checkboxes and radio buttons also needed to be cleaned up. In the old system, they looked like a set of similar but not fully connected elements, so a proper matrix was created for them: default, hover, pressed, disabled, focus, and error.

I will not go into other basic components like text fields. The folder tree component is much more interesting.

For DAM, it is one of the most important components. The tree should not be just a list of folders, but a full navigation system: it needs to show hierarchy, the active item, expanded and collapsed states, hover, disabled, focus, the selected folder, and different depth levels.

A state matrix was also created for the Tree view component. It was necessary to define spacing for different levels, the behavior of expand arrows, folder icons, selected item highlighting, and many other details.

A separate system of form fields was also created. The product has many settings dialogs where users need to manage dozens of parameters on a single screen.

For this task, a horizontal layout was used: label on the left, field on the right. This prevented forms from stretching too far down, unlike in Material Design, which made screen space more efficient and helped users find the needed option faster.

This approach worked especially well in Site Builder and Spaces, where almost every block or page had its own settings window.

Other improvements

Accessibility of published sites was considered separately. Site Builder creates sites that automatically support navigation for people with disabilities.

For each block, focus states, tab order, ARIA fields, and ARIA roles were described. The pages meet WCAG 2.1 requirements and the European EN 301 549 standard. Pseudocode for each block was handed over to developers.

Tab order was also designed for nested components.

For example, in a carousel, each slide can be more than just an image — it can be a small structure of its own, with a heading, text, button, link, or other interactive elements inside. So it was necessary to describe how a user enters this kind of block with the keyboard and how they move through the elements inside it.

In the case of a carousel, focus first lands on the block itself. Then the user can move into the active slide, tab through the buttons and links inside it, return to the carousel controls, and move to the next slide.

Finally, a set of personas was created for Site Builder. This helped make it clear that the product was not used by one abstract “site editor,” but by several different roles: a brand lead, a designer, a content manager, and a technical architect.

Each role had its own goals and pain points. For example, the brand team wanted to preserve visual consistency, the designer needed control over templates and style, the content manager needed to update pages quickly without the risk of breaking everything, and the architect needed to make sure Site Builder did not break access rights, CDN logic, or the DAM architecture.

These personas helped evaluate design decisions: whether there was enough flexibility for the editor, enough control for the designer, and enough security for an enterprise product.