Enterprise Automation Platform

UX / Product Design case study

Simplifying a Complex Enterprise Automation Platform

A complex enterprise platform had grown into a powerful but difficult-to-understand product. It supported automation, discovery, migration, application packaging, alerts, smoke testing, support workflows, endpoint management and application publishing — but the overall experience was becoming hard to explain, navigate and scale.

My role was to help clarify the product logic, identify the main workflows, reduce interface complexity and create a clearer UX foundation for product design, UI structure and future development.

Project type

Enterprise software / internal automation platform

Industry

Enterprise IT, automation, endpoint management, application delivery

My role

UX strategy, product design, information architecture, workflow mapping, interface structure

Focus

Complex workflows, product structure, user roles, dense interfaces, UX clarity

Output

Problem framing, workflow maps, product structure, UI direction, wireframes, UX recommendations

Status

Anonymised case study based on enterprise product work

The challenge

The product had become highly capable, but difficult to understand.

Over time, it had grown into a broad enterprise platform that could support many different technical and operational tasks: automation, migration, discovery, app packaging, alerts, smoke testing, support processes, ticket-related workflows, endpoint management and application publishing.

The issue was not a lack of functionality. The issue was that too much functionality lived inside one broad product experience without a clear enough structure for different users, teams and workflows.

Users needed to understand:

What is this area for?
Which workflow should I use?
Who owns this task?
What action should happen next?
What information needs attention?
What is automated, manual or pending?

The product could “do everything”, but that also made it harder to explain what it was really for, who it served and how different parts of the system connected.

Context and constraints

This was not a simple interface redesign. The product operated in a complex enterprise environment with technical users, operational teams and business stakeholders all needing different things from the system.
The platform had to support:

Large enterprise clients
Complex IT environments
Technical and non-technical stakeholders
Automation-heavy workflows
Data-intensive interfaces
Multiple product modules
Different levels of user understanding
Legacy logic and existing product decisions

A key constraint was that the interface needed to expose powerful functionality without making users feel lost inside the system.

The product also had to remain useful for expert users who needed speed, density and control, while becoming clearer for stakeholders who needed to understand what the platform did and where specific workflows belonged.

My role

I worked on the UX and product structure of the platform, focusing on how to make a complex monolithic product easier to understand, navigate and explain.
My work included:

Analysing the product’s existing structure
Identifying overlapping workflows and unclear areas
Mapping user tasks and product modules
Clarifying the relationship between features, teams and outcomes
Restructuring interface logic around clearer workflows
Supporting product and UI direction
Creating UX artefacts that helped explain the product internally

The goal was not only to improve screens, but to create a clearer product model that could support design, development, sales conversations and future product decisions.

What made the problem complex

The complexity came from the product trying to serve too many purposes through one broad interface.

It supported different kinds of work:

Discovery
Automation
Migration
Application packaging
Alerts and notifications
Support workflows
Ticket-related tasks
Smoke testing
Endpoint management
Application publishing

Each of these areas had its own logic, terminology, users, data and expected outcomes. But from a UX perspective, they were not clearly separated enough.
This created several problems:

Each of these areas had its own logic, terminology, users, data and expected outcomes. But from a UX perspective, they were not clearly separated enough.
This created several problems:

The product was powerful, but its structure made that power feel heavier than it needed to be.

UX approach

I approached the problem by separating the product’s capabilities from the user’s actual tasks.
The work focused on understanding:

What are users trying to achieve?
Which workflows belong together?
Which areas are operational, strategic or administrative?
Where does the product need to provide status, guidance or control?
Which tasks require expert density, and which require simpler explanation?
How can the product be described without overwhelming users?

The process moved through several layers:

1. Problem framing
2. Product capability mapping
3. Workflow and task mapping
4. Information architecture
5. Interface structure
6. Wireframe direction
7. UX recommendations

The key was to move from:
A product organised around everything it can do
towards:
A product organised around what users need to understand and complete

Key artefacts

I approached the problem by separating the product’s capabilities from the user’s actual tasks.
The work focused on understanding:

What are users trying to achieve?
Which workflows belong together?
Which areas are operational, strategic or administrative?
Where does the product need to provide status, guidance or control?
Which tasks require expert density, and which require simpler explanation?
How can the product be described without overwhelming users?

The process moved through several layers:

1. Problem framing
2. Product capability mapping
3. Workflow and task mapping
4. Information architecture
5. Interface structure
6. Wireframe direction
7. UX recommendations

The key was to move from:
A product organised around everything it can do
towards:
A product organised around what users need to understand and complete

Problem framing

The first step was to clarify the actual UX problem.

The brief could easily have been interpreted as “make the interface cleaner” or “redesign the UI”. But the deeper issue was structural: the product’s capabilities were not organised around clear user intent.

The problem framing helped separate symptoms from causes.

Symptom:  
The interface felt complicated and difficult to explain.

Underlying issue:  
The product combined multiple workflows, user roles and technical concepts without a clear enough experience model.

UX direction:  
Clarify product areas, workflows and user intent before redesigning individual screens.

Why it mattered

Without this step, the project could have become a cosmetic redesign of a still-confusing product.

The problem framing made it clear that visual improvements alone would not solve the experience. The product needed a clearer structure before UI design could be effective.

Product capability map

The product had many capabilities, but they needed to be understood as part of a system.

A capability map helped identify what the platform actually did, where features overlapped, and which areas belonged together from a user and business perspective.

Sample categories

Discovery / Automation / Migration / Application Packaging / Monitoring and alerts / Testing and validation / Support and ticket workflows / Endpoint management / Application publishing / Administration

Why it mattered

This made the product easier to discuss with stakeholders. Instead of treating the platform as one large monolith, the team could start seeing it as a set of related but distinct product areas.

It also helped reveal which areas should be primary workflows, which should be supporting functions, and which needed clearer naming or separation.

Workflow mapping

Once the capabilities were clearer, the next step was to map key workflows.

The goal was to understand how users moved through the system, where tasks began, what information they needed, and what happened next.
This included workflows such as:

Discovering assets or applications / Preparing automation tasks / Packaging or publishing applications / Reviewing alerts / Running validation or smoke tests / Managing endpoints / Following up on support or ticket-related activity

Why it mattered

Workflow mapping helped identify where the product was asking users to make decisions without enough context.
It also showed where different workflows shared similar patterns, such as:

Role and task clarification

The product served multiple types of users and stakeholders.
Not everyone needed the same level of detail, control or explanation. Some users needed operational speed. Others needed visibility, reporting or confidence that a process was working correctly.
The UX work helped separate different user needs:

Expert users needing efficient access to technical actionsOperational users needing status, queues and next stepsStakeholders needing overview, progress and confidenceSupport-related users needing traceability and issue contextAdministrators needing configuration and control

Why it mattered

This helped avoid designing one interface mode for everyone.

Instead, the product experience could better support different levels of detail: high-level overview, workflow management, detailed technical action and administrative control.

Information architecture

The information architecture work focused on how the product should be organised so users could understand where they were and what each area was for.
The aim was to move away from a structure based mainly on product history or technical grouping, and towards a structure based on user tasks and product purpose.
Possible structure directions included:

OverviewDiscoveryAutomationApplicationsTesting & ValidationEndpointsAlertsSupportAdministration

The exact naming would depend on the final product strategy, but the UX direction was clear: each area needed a more defined purpose.

Why it mattered

A clearer IA made the product easier to navigate, easier to explain and easier to scale.
It also created a stronger foundation for UI design, because screens could be designed around more coherent product areas rather than isolated features.

Interface structure and wireframes

Wireframes were used to explore how complex information could be shown without overwhelming users.
The focus was on structure rather than visual polish:

How should users scan dense information?Where should status be visible?Which actions need to be primary?How should alerts or exceptions be handled?Where does the user need guidance?How should technical detail be revealed?

The interface needed to support both overview and action.
A typical screen structure might include:

Context/header areaStatus summaryPrimary workflow actionsData table or queueFilters and searchDetail panelAlerts or exceptionsSecondary actions

Why it mattered

The wireframes helped translate product structure into usable interface patterns.

They also helped reveal which UI components needed to become reusable across the product, such as tables, status indicators, filters, action panels, alerts and workflow controls.

UX recommendations

The UX work produced practical recommendations for how to move the product forward.
Key recommendations included:

Clarify product areas around user workflows rather than technical accumulationSeparate overview, workflow execution and administration more clearlyCreate consistent patterns for status, alerts, validation and completionUse progressive disclosure for technical detailMake ownership and next actions more visibleReduce the number of competing actions on dense screensIdentify reusable components for tables, filters, status indicators and workflow actionsCreate language that explains the product more clearly to users and stakeholders

Why it mattered

The recommendations gave the team a practical way to improve the product without treating every screen as a separate design problem.

They also helped connect UX decisions to product strategy, interface design and development planning.

Main UX decisions

1. Organise around workflows, not just features

The product had many features, but users did not experience the product as a feature list. They experienced it as work they needed to complete.

The UX direction was to group and present functionality around workflows such as discovery, automation, validation, publishing and support.

Why

Users should not need to understand the full internal logic of the product before they can start using it.

2. Separate overview from execution

One interface cannot effectively serve every level of detail at the same time.
The product needed clearer separation between:

high-level status
workflow management
detailed technical action
administrative configuration

Why

This makes the product easier to scan, easier to explain and easier to use across different user types.

3. Make status and next actions more visible

In automation-heavy products, users need confidence that the system is doing what they expect.
Status, progress, exceptions and next actions needed to be more prominent and consistent.

Why

Users should not have to search through dense technical information to understand whether something is pending, running, failed, blocked or complete.

4. Use progressive disclosure for technical complexity

The product needed to support expert users without overwhelming everyone else.

The UX direction was to show essential information first, with deeper technical detail available when needed.

Why

This supports both speed and clarity. Expert users can still access depth, but less experienced users are not forced to process everything at once.

5. Identify reusable interface patterns

Many workflows shared similar UI needs:

high-level status
workflow management
detailed technical action
administrative configuration

These patterns needed to become more consistent across the product.

Why

Reusable patterns reduce cognitive load for users and reduce design/development effort for the team.

Outcome / impact

The UX work helped turn a broad, monolithic product into a clearer set of product areas, workflows and interface patterns.
The result was not only a cleaner interface direction, but a stronger product foundation:

Clearer product structure
Better understanding of key workflows
More visible user tasks and decision points
Improved basis for navigation and UI design
Reusable patterns identified for design system work
A clearer way to explain the product internally and externally
Better alignment between UX, product and development thinking

The work made complexity more visible, structured and manageable.

Instead of treating the product as one large interface problem, the team could start addressing it as a set of connected product experience challenges.

What this project shows

This project shows how I approach UX and product design when the main problem is not just visual design, but product complexity.
The value came from understanding the system, mapping workflows, clarifying user intent and creating a structure that could support better interface design and future development.
It reflects the type of work I often do: helping teams turn complicated requirements, technical logic and fragmented product areas into clearer digital experiences.

Some details have been anonymised and simplified to protect confidential product and business information. The case study focuses on the UX approach, product structure and design decisions rather than proprietary implementation details.