Create Widget Admin Flow

The challenge

Widgets determine how the company’s player, videos and advertising appear and behave on publisher websites. Creating the wrong configuration can therefore affect content presentation, monetization and the end-user experience.

Despite its importance, the original tool was built as one long configuration form. It exposed many technical fields at once, even when they were irrelevant to the selected widget.

Orientation, player behavior, device support and placement settings were configured through separate controls. Users had to understand how these values affected one another and which combinations were valid.

This made the workflow difficult to learn, slow to complete and vulnerable to configuration errors.

1. Too many fields presented simultaneously.

2. Weak grouping and hierarchy.

3. Related decisions configured separately.

4. No clear distinction between desktop and mobile behavior.

The main problems

• The flow was structured around system fields rather than the user’s configuration task.

• Users had to understand technical dependencies between orientation, placement and player behavior.

• Applicable and non-applicable settings appeared together.

• Desktop and mobile configurations were difficult to distinguish.

• The long form made it hard to understand progress or review decisions.

• Similar widget types could be created through different combinations of fields.

• Invalid or unexpected combinations increased the risk of misconfiguration.

• The interface no longer matched the design principles of the new Admin platform.

• Adding future widget variants would make the existing model even more complex.

Because the tool was used daily by several operational teams, the redesign needed to improve usability without removing the advanced control required for technical configurations.

A single, technically structured form exposed numerous interdependent settings at once.

The design goal

The redesigned experience needed to make widget creation faster and more predictable while still supporting complex operational requirements.

I defined four principles:

1. Start with the intended format—not individual technical properties.

2. Show only settings that apply to the current configuration.

3. Separate desktop and mobile decisions clearly.

4. Create a structure that can scale to future formats and capabilities.

1. Moving from independent settings to predefined formats

The most important change was conceptual rather than visual.

In the original system, users configured orientation and other player properties as separate settings. This required them to understand which combinations created a horizontal player, vertical player or floating experience.

I replaced this with a format-driven model.

Users now begin by selecting one of five predefined widget formats:

• Horizontal Player

• Vertical Player

• Carousel

• Horizontal Floater

• Vertical Floater

Each format represents a validated configuration of the same core player. Its orientation, layout, supported devices, behavior and available settings are defined by the format itself.

Orientation is no longer configured as a separate field. Choosing a Vertical Player, for example, already communicates the intended orientation and determines which options should become available.

This reduces the number of decisions users must make and prevents incompatible configurations from being created.

Orientation and player type were consolidated into one meaningful decision: the widget format.

2. Replacing the long form with a guided flow

The old tool displayed most configuration fields on a single page. Users had no clear indication of where they were in the process or which group of settings they should complete next.

I restructured widget creation into three focused steps:

1. General

2. Desktop

3. Mobile

The General step establishes the widget’s identity and core format. Desktop and Mobile then expose the configuration available for each environment.

This structure reflects how users think about the finished widget: first define what it is, then configure how it should behave in each context.

A visible step indicator maintains orientation throughout the flow, while Back and Next actions allow users to review previous decisions without losing their work.

3. Showing only relevant configuration options

Different widget formats support different capabilities. A setting that is relevant to a horizontal in-article player may not apply to a vertical floater or carousel.

The old form exposed many of these fields together, forcing users to determine which options were applicable.

In the redesigned flow, the selected format controls the configuration that follows. Each step reveals only the settings supported by that format and environment. Non-applicable options are hidden or disabled.

This progressive disclosure reduces visual complexity while preserving advanced controls for the teams that need them.

It also makes the behavior of each format more predictable: users no longer create a widget by assembling a fragile combination of independent settings.

Each format exposes only the settings it supports, reducing irrelevant choices and invalid combinations.

4. Separating desktop and mobile behavior

A widget is one configuration entity, but it may need to behave differently on desktop and mobile.

Previously, device-related settings were mixed into the larger form. This made it difficult to understand whether a setting applied globally or to a particular environment.

I separated Desktop and Mobile into distinct steps while keeping both configurations under one widget.

This creates a clear mental model:

• The widget has one shared identity and format.

• Desktop settings define how it behaves in a desktop environment.

• Mobile settings define the corresponding mobile experience.

• The available options remain consistent with the selected format.

The separation gives users greater control without forcing them to create and maintain separate widgets.

5. Organizing complex settings into understandable sections

Some widget configurations still require detailed controls for player behavior, video selection, placement and monetization.

The goal was therefore not to remove complexity blindly, but to organize it around meaningful decisions.

I grouped related settings into clear sections and established a consistent hierarchy across formats. Primary configuration choices appear first, while dependent and advanced settings appear only when they become relevant.

This makes the form easier to scan and allows experienced users to move quickly without making the interface inaccessible to less frequent users.

Complex controls were retained, but reorganized around the decisions users were actually making.

6. Designing the interface and system together

The previous configuration model was embedded in both the front-end interface and the back-end structure. Introducing predefined formats and device-specific logic therefore required more than rearranging fields.

I worked with the product and engineering teams to define:

• The settings included in each widget format.

• Which values should be inherited from the selected format.

• Which fields should be available for Desktop and Mobile.

• How dependent settings should appear and behave.

• How existing widgets could continue to be edited.

• How the model could support additional formats in the future.

The interface and technical model were redesigned together, creating a shared configuration logic across the front end and back end.

This was essential for preventing the UI from becoming another visual layer over the same underlying complexity.

7. Improving widget management beyond creation

The redesign also addressed the main Widgets page, which serves as the operational hub for several internal teams.

The updated table provides a clearer overview of existing widgets and supports filtering by relevant criteria. Users can find configurations more quickly and understand important widget information without opening every item.

Supporting actions and states were also redesigned, including:

• Duplicating a widget.

• Duplicate-name validation.

• Accessing embed information.

• A/B testing states and restrictions.

• Success and error feedback.

• Editing existing widget configurations.

These changes create a consistent experience across the widget lifecycle—not only during initial creation.

The widget list became a clearer operational hub for finding, reviewing and managing configurations.

Validation and error prevention

Because incorrect widget configurations can affect live placements and monetization, validation needed to prevent errors before they reached production.

The new flow combines several levels of protection:

• Predefined formats remove incompatible combinations.

• Conditional fields prevent users from configuring irrelevant options.

• Required fields are validated within the relevant step.

• Duplicate-name validation prevents conflicting widget identities.

• Restricted actions explain why they are unavailable.

• Success feedback confirms completed actions.

Instead of relying only on error messages at the end, the structure itself reduces the opportunity to create an invalid configuration.

The final outcome

The redesign transformed widget creation from a long collection of technical fields into a guided, format-driven configuration system.

Users can now:

• Start from a clearly defined widget format.

• Understand the type of player they are creating.

• Configure desktop and mobile behavior separately.

• See only the fields relevant to the selected format.

• Move through a clear, three-step process.

• Avoid incompatible orientation and configuration combinations.

• Find and manage existing widgets more efficiently.

• Duplicate and edit configurations with clearer validation.

• Work within a system designed to support future formats.

The project also established a new shared configuration model across the product, front end and back end—creating a more scalable foundation rather than only modernizing the interface.

Before and after

Impact and next steps

The redesign established a clearer and more scalable foundation for one of the company’s most important internal tools. It simplified the configuration model, reduced opportunities for invalid combinations and aligned the interface with the new Admin experience. Because the change required coordinated front-end and back-end reengineering, it also created a consistent source of logic for current and future widget formats.

The intended KPIs are:

• Reduced time to create or update a widget.

• Fewer configuration errors and misconfigurations.

• Fewer support requests related to widget setup.

• Faster validation and troubleshooting by operations, development and QA.

• Reduced effort required to introduce future formats.

Reflection

The main lesson from this project was that simplifying a complex tool does not always mean removing advanced functionality.

The more effective solution was to redesign the underlying model: replacing independent technical settings with meaningful formats, separating device-specific decisions and revealing configuration only when it became relevant.

By treating the information architecture, interaction design and system logic as one problem, the redesign improved the current workflow while creating a stronger foundation for future widget capabilities.