Why does finding the right asset often take longer than creating it?
JioDAM is Jio's internal digital asset management platform for organizing, enriching, discovering and managing digital content across teams. When I joined the project, it was an established enterprise product with defined workflows, screens and edge cases.
My role was to modernize assigned product surfaces within Jio Design System while preserving the established product model. The work involved translating a large existing experience into a shared enterprise system, then making targeted interaction improvements where the scope allowed.
Role
Product Designer
Product
Jio Digital Asset Management (JioDAM)
Project type
Enterprise Product Modernization
Primary focus
JDS Modernization + Targeted UX Improvements
Scope
150+ screens · 9+ modules
Team
Product · Design · Engineering · Core Design
Key areas
Asset Details
Discovery
Metadata
Access
Queue's
AI-assisted experiences
Face Finder
Merger
Transcripts
Org. Admin
Overview
An existing product at enterprise scale
JioDAM was already serving an established asset-management environment when the modernization began. The product had existing navigation, workflows, metadata structures, permissions and operational states that users and teams already depended on.
By June 2026, the documented environment represented approximately 60.6 TB of data, 1.1 million assets, 11 departments and 320 users. These figures describe the product environment I was designing within, not impact generated by the redesign.
The assignment was modernization, not reinvention
The immediate objective was to bring the existing product into Jio Design System (JDS) while maintaining the UX context that already existed. That meant understanding which patterns needed to be preserved, which could be improved, and which requirements exposed gaps in the shared system.
My contribution sat within that boundary. I owned assigned surfaces including Asset Details, Tags, Renditions, Search Results, Queue implementation, Profile interaction, AI-derived information and specialized workflows such as Face Finder + Merger and Transcripts.
That distinction shaped how I approached the work
I was not starting with a blank canvas or treating every existing interaction as a problem to solve. I had to understand the product that was already there, locate the decisions that were actually mine to make, and translate those decisions into a system that could work across a much larger enterprise product.
That became the central design challenge: modernize what needed to change without destabilizing what already worked.
WHAT CHANGED
A large product moved into a shared enterprise language
The modernization brought JioDAM into Jio's enterprise design language without replacing its established product model. I translated existing interfaces into JDS, made targeted improvements where the product warranted them, and accounted for dependencies across metadata, discovery, permissions, AI and infrastructure. The result was a more consistent product foundation while deeper workflow changes remained outside the scope of the sprint.
PRODUCT FOUNDATION
A common language across the product
I translated the existing JioDAM interface into JDS using approved components, tokens, typography and interaction patterns. The challenge was not applying a library mechanically, but preserving the existing UX context while bringing different product surfaces into the same enterprise language.
PRODUCT EXPERIENCE
Targeted improvements where change mattered
Modernization did not mean leaving the existing experience untouched. Where the sprint allowed meaningful UX changes, I focused on specific product surfaces such as Asset Details, supporting information architecture and interaction patterns around dense asset workflows.
SYSTEM THINKING
Design decisions connected across product layers
JioDAM's interface could not be separated from the systems behind it. Metadata affected discovery, validation affected metadata quality, AI depended on infrastructure, and permissions shaped available capabilities. I used those relationships to understand where an interface change could actually solve the problem.
PRODUCT DIRECTION
A stronger foundation for the next phase
The sprint established a more coherent JDS-aligned foundation for JioDAM. It also made the remaining product gaps clearer: deeper workflow improvements, AI capabilities, design-system extensions and infrastructure-dependent work could be separated from what needed to be solved in the current modernization.
THE PRODUCT PROBLEM
The problem was not storing assets. It was making them usable.
As the volume of digital content grew, assets were spread across local machines, physical drives, internal folders and external storage. The organization had the content, but retrieving and reusing it depended heavily on where it lived, what information existed around it, and who could access it.
A documented internal example made this concrete. During a marketing discussion, the team needed an existing asset from a roughly 20 TB physical drive. The drive contained accumulated folders and inconsistent organization, and locating the required asset took approximately two days. The asset was not missing. The system around it made retrieval difficult.
That changed how I framed the product problem. Finding an asset was only the first step. Once found, a user still needed enough context to understand what it was, enough information to distinguish it from similar or outdated versions, and the right access to actually use it.
JioDAM had to connect discovery, context, trust and control around the asset so that finding something was not the end of the task, but the beginning of being able to use it.
MY ROLE
Modernizing an existing product within defined boundaries
JioDAM already had its product model, flows, screens and edge cases. My role was to modernize the assigned product surface within Jio Design System while keeping that established UX context intact. I worked with Product, Design and Engineering to translate the existing experience, identify where I could make meaningful interaction improvements, and stay within the system, technical and delivery constraints around the product.
What I owned
Asset Details
Tags
Global Search Results
Queue implementation
Profile interaction
AI-derived Information
Face Finder + Merger
Trascripts
DAM Website
Who I worked with
Product Managers
Design Team
Core Design
Engineering
NMACC Users
Product & Design Reviews
What I couldn't decide alone
New JDS Components
AI Infrastructure
Product Priority
Existing UX Scope
My responsibility was not to change everything I could see. It was to understand what I could change, what required alignment, and where a local design decision would create consequences elsewhere.
DESIGN WORK
Five product areas where the system needed design judgment
The modernization touched a broad product surface, but I did not treat every screen as an independent redesign. I focused on areas where information density, discovery, access, system consistency or workflow state created meaningful design decisions.
01. ASSET DETAILS
Keeping the asset primary in a dense information workspace
Asset Details had to expose metadata, tags, AI-derived information and other supporting context without competing with the asset itself. The asset occupied roughly 60% of the workspace, so I introduced a compact vertical navigation for Details, Tags and Renditions to keep supporting information accessible without continuously consuming the primary viewing area.
02. DISCOVERY
Search depended on the information around the asset
JioDAM's search experience extended beyond filenames. Users could search across metadata, tags, descriptions, events, locations, transcripts and asset IDs, with filtering, image reverse search and Face Finder adding further discovery paths. That made search quality dependent on the information being captured and enriched upstream.
03. ACCESS
Permissions changed what the product could show and do
JioDAM's permission model extended beyond simple view access. Roles could govern management functions, collections, product features and AI capabilities, meaning access rules could influence navigation, visibility and available actions.
04. JDS TRANSLATION
Modernizing the interface without rewriting the product
JioDAM already had established workflows and edge cases. I mapped those existing patterns into JDS rather than treating the migration as a visual reset. Where an approved JDS component existed, I used it. Where the system did not cover a requirement, I documented the gap, used a temporary solution where appropriate, or escalated it through Core Design governance.
05. SPECIALIZED WORKFLOWS
Some workflows needed explicit state, not generic interaction patterns
Face Finder + Merger and Transcripts exposed a different class of problem. The interface had to represent relationships and states that could not be reduced to a simple search or content panel. Face Finder required detection, cluster selection, merge requests, approval or rejection and consolidation. Transcripts needed the generated content to remain connected to speakers, timestamps and the underlying media.
For the Transcription Portal, I had already explored AI-assisted transcription as a persistent workspace. That experience informed how I thought about generated transcripts as something users need to review and understand in context, rather than simply accept as output.
KEY DECISIONS
The hard part was knowing what should change
JioDAM did not need a new product model. It needed a more coherent one. Most of my decisions came from working between an established workflow, Jio Design System, technical constraints and new product requirements. The important question was not whether I could redesign something, but whether changing it would improve the product without destabilizing what already worked.
Preserve what already worked
DECISION
I kept the established workflow intact while translating its interface into Jio Design System.
WHY
The product already had defined flows, edge cases and user expectations. The sprint was primarily about modernization and JDS migration, so a cleaner alternative was not enough reason to replace the underlying workflow.
CONSEQUENCE
The result was less local interaction freedom, but a more consistent enterprise product foundation.
Keep the asset in control
DECISION
I kept the asset as the primary workspace and moved supporting information into a compact vertical navigation.
WHY
Metadata, tags and other context needed to remain accessible, but continuously expanding them would reduce the space available for the asset itself.
CONSEQUENCE
Details, Tags and Renditions became accessible without permanently taking over the viewing area.
Treat discovery as a system
DECISION
I treated search as the visible layer of a larger discovery system.
WHY
JioDAM's search depended on metadata, tags, descriptions, events, locations, transcripts, asset IDs and AI-derived information. Improving the search field alone could not solve gaps created elsewhere in the system.
CONSEQUENCE
The search experience had to be designed with its upstream information sources in mind, even when those sources sat outside my immediate interface.
Make access part of the product model
DECISION
I treated roles, groups and permissions as product behaviour rather than administrative settings.
WHY
Access could determine what a user could see, manage, download or use, including product and AI capabilities. That made permission architecture relevant to the experience itself.
CONSEQUENCE
The interface had to accommodate different capability sets rather than assume one universal product experience.
Design for state, not just interaction
DECISION
I modelled the underlying state before deciding how the interaction should behave.
WHY
Face Finder involved detection, cluster selection, merge requests, approval, rejection and consolidation. Transcripts involved generated content that needed to remain connected to speakers, timestamps and source media.
CONSEQUENCE
The interaction became more explicit, but users had a clearer understanding of what had happened, what required action and what the system would do next.
REFLECTION
I became more deliberate about where a design problem actually lives
JioDAM changed how I approach enterprise product design. I entered the project thinking primarily about interfaces, but the work repeatedly pushed me beyond the screen. Search led back to metadata and enrichment. Permissions shaped what the interface could expose. AI capabilities depended on infrastructure. JDS determined not only how things looked, but what patterns could be introduced and how gaps were handled.
I came away with a stronger habit: before changing an interface, understand the system around it and identify the layer where the problem actually exists.
1.
Restraint is part of design
Modernizing an existing product taught me that making something different is not the same as making it better. I became more deliberate about distinguishing between a genuine product problem and an opportunity to redesign. Sometimes the right contribution was to preserve an established workflow and improve the system around it.
2.
Systems need room to evolve
Working within JDS changed how I think about design systems. They provide consistency and governance, but real products eventually expose requirements that a shared system does not cover perfectly. The designer's responsibility is not always to solve that gap locally. Sometimes it is to recognize the gap, work within the constraint and help the system evolve.
3.
Start with the system, then design the interface
The biggest shift was learning to trace visible problems beyond the screen. A search problem could originate in metadata. Metadata could depend on validation. AI could depend on infrastructure. Access could change the available experience. The interface was often only the point where those dependencies became visible.
