Visual Asset Management System

- A centralized database to store and manage large 3D assets.  

final design

Problem & Introduction

Visual Asset Management System (VAMS) is a centralized database to store and manage large sets of refinery/equipment reality capturing, metrology, and 3D model data to enable the digital twin initiative.

What is VAMS?

Project Impact:

  • ~$200k cost savings per refinery by reducing duplicate projects

  • Designed the uploading process that increased data uploading speed by ~43%.

  • Decreased system data caching time by ~77% by reorganizing and reducing the metadata schema.

  • Designed a role-based access system to cater to different data access tiers for better asset management.

Responsibilities:

Throughout my internship, I worked on 3 core functions of VAMS: project creation and file uploading process, role-based access for data and system operation, and metadata-driven searching and filtering. This case study will focus on project creation and the file uploading process. 

Team – I worked with internal stakeholders and a 3rd party development team 

My Role – UX designer /researcher 

Project length – 3 months 

Tool – Mural, Adobe XD, pen and paper 

Visual design guide – Company’s internal standard design system

“We often have five computers uploading data to our drive semutesouly for the entire day after the scanning project is done. One failed file could set us back in hours”

“It’s not like uploading a few files to your Google Drive”

- 3rd Party Vendors

  • Interviews with 3rd-party vendors responsible for large-scale reality capture

  • Workflow observation of post-scan upload practices

  • Discussions with the engineering team to validate technical constraints

What I did

  • Massive data volumes: Vendors uploaded hundreds of gigabytes per project, often running multi-machine parallel uploads.

  • Location metadata critical: Each scan needed to be tied to an exact asset location on a map (not just text) to support digital twin models.

  • File type classification required: Engineers depended on assets being separated by file type to successfully assemble 3D models.

Key Insights

  • Slow upload times – Existing software processed and uploaded files simultaneously, doubling upload duration. Recommendation: decouple processing from upload.

  • No file skipping – If one file failed (e.g., file 99), the system restarted from the beginning. Requirement: resume from point of failure.

  • Poor error visibility – Failed uploads were unmarked, forcing users to manually sift through hundreds of files. Requirement: clear error notifications.

  • Inefficient folder management – Uploads began immediately, so misfiled uploads required moving files later — which took as long as re-uploading. Requirement: allow staging or faster file moves after upload.

Pain points & Requirement

Artifact

Simplified User Workflow

User Interview Report

“We will need to align with external software development team before providing solutions”

- Product Manager

My process began with competitive analysis and early sketches. Around this time, the team decided to use a pre-existing database, so I partnered with the external software team to ensure my design solutions complemented their product. Once all teams are aligned, I started sketching solutions.

  • Competitive Analysis - Reviewed 10 asset/database platforms (3D, GIS, enterprise storage) to understand how they handle very large uploads, location metadata, and file-type organization.

  • Created a user story map that connected user pain points to system functions to align priorities before sketching.

  • Sketched multiple flows/wireframes against the story map to validate approaches quickly.

  • Facilitated reviews with stakeholders and the external software team to confirm feasibility.

What I did

  • Upload progress & recovery: Clear progress UI, resumable uploads, and the ability to skip/retry failed files instead of restarting.

  • Error visibility: Inline, persistent flags for failed items with scoped retry actions.

  • Staging before commit: A pre-upload staging area so users can confirm destination folders and avoid expensive moves.

  • File-type classification: Guided selection and guardrails to ensure correct file-type buckets for downstream 3D assembly.

  • Location tagging: Map-based picker with visible boundaries to increase accuracy (text only is insufficient).

  • API handoff: One-click send to approved visualization tools; no heavy in-app rendering.

Key Design Outcome

Artifacts

Competitive Analysis Summary

User Story Map V.1

Illustrated wireframes 1

Illustrated wireframes 2

Illustrated wireframes 3

Illustrated wireframes 4

Our project was expanding fast. Midway through, metrology scan engineers were asked to bring their workflows into VAMS. To ensure their needs were represented, I added interviews and ran the first usability tests with vendors and engineers, broadening the project’s perspective.

“From Reality Capture to Metrology: Broadening the Scope of VAMS”

  • Interviewed two metrology engineers to understand how they use scan data differently from reality-capture teams.

  • Usability Testing: Evaluated a range of core flows with vendors and engineers — including project creation, file categorization, reviewing uploads, error recovery, and navigation patterns.

What I did

  • Projects often include multiple scan types, but the system only allows one type per project.

  • Engineers needed different metadata fields for metrology vs. reality-capture scan.s

  • Some scans are used standalone, not tied to projects

  • Users found file buckets confusing and inconsistent with how they organize their data

  • Breadcrumb navigation was preferred because it aligned with familiar mental models

Key Findings

  • Allowed multiple scan types (modalities) within a single project

  • Displayed only relevant metadata fields based on scan type

  • Added support for standalone assets not tied to projects

  • Replaced buckets with an optional dropdown to reduce confusion

  • Adopted breadcrumb navigation for a more familiar browsing experience

Design Iterations

Artifacts

Usability Testing Report 1

User Story Map V.2

Wireframe Iteration 1

Wireframe Iteration 2

“When the Project Got Bigger: Metadata & 3D Models”

As Sprint 2 wrapped up, two new demands reshaped the project: the data team wanted VAMS to integrate with the company’s internal database (bringing in 70+ metadata fields), and 3D model engineers joined, eager to use VAMS for their digital twin workflows.

Suddenly, VAMS needed to scale—handling massive models, strict folder hierarchies, and more complex metadata—without overwhelming users.

What I did

  • Card Sorting: With 5 cross-discipline users to prioritize and simplify the metadata fields.

  • Contextual Inquiry: Reviewed naming conventions and past interviews to see how people really organized their files.

  • Usability Tests: With 3D model engineers to uncover pain points and stress-test the scalability of my designs..

  • Less is more: Engineers only needed a handful of metadata fields, and many were redundant. Saving & reusing field combinations was critical.

  • Hidden relationships: Fields like site → country → region were already connected. By only surfacing “site name” to users, I could speed up uploads and reduce caching time.

  • The 3D model reality:

    • Transfers often failed with multi-terabyte models.

    • Parts were updated every 2–3 weeks, making re-uploads painful.

    • Folder hierarchy wasn’t optional — one misplaced folder could break the entire model.

Key Findings

  • Simplified metadata: Reduced visible fields, pushed redundant ones to the backend.

  • Reintroduced file tree: Breadcrumbs alone weren’t enough for 3D engineers; hierarchy had to be visible.

  • Planted seeds for the future:

    • A workflow for pre-selecting “update files” so the system automatically places new versions correctly.

    • A user history map so engineers could jump back to recent folders without endless drilling

Design Decisions

Artifacts

Usability Testing Report 2

Wireframe Iteration 3

Prototype

New Project Flow

  • Start by selecting the project location on the map

  • Draw a bounding box to mark the exact scan area

  • Attach the appropriate scan types (modalities) to each file

  • Hidden metadata fields stay in the background, keeping the system fast and focused

Engineers can now manage files independently, without attaching them to a project.

Two ways to review uploaded files

  • Breadcrumb navigation – simple, click-through path for quick scanning

  • File tree – full folder hierarchy for complex scans like 3D models

Additional features:

  • Clear upload progress

  • Easy file location and re-upload of failed files

Learnings & Reflections

I walked into this project thinking file upload would be simple. The deeper I researched and tested, the more I realized it was one of the most complex and critical parts of the system. Every new user group revealed fresh needs, and every round of testing reshaped my designs.

Looking back, I’d do a few things differently:

  • Involve all user types earlier

  • Think about the system as a whole instead of isolated features

  • Create stronger feedback loops with engineering so design and backend constraints inform each other from the start

Other Projects