Patrick Ly — Portfolio

I'm a product designer based in the Greater Vancouver Area with 7+ years of experience, specialised in building tools that help professionals work more efficiently across complex workflows.

At Meta, I led end-to-end design of capture and creation tooling for Horizon Worlds across desktop, VR, and mobile, shipping features used by thousands of creators. At Visier, I built enterprise design systems and file management patterns for HR analytics software used by large organisations.

I care about deeply understanding user workflows, simplifying complexity, and shipping products that drive measurable outcomes while working closely with product and engineering partners throughout.

In my free time, you can catch me playing League of Legends, revisiting handheld Nintendo games, and staying active playing basketball and badminton with friends.

Currently open to new opportunities.

Meta

Advanced capture tools 🎥

Redesigned a professional capture tool suite for Horizon Worlds, a user-generated gaming platform with millions of monthly active users. The tool enables third-party creators to produce high-quality promotional content directly from the desktop editor, and is now shipped and used by 1,000+ creators.

Role

Lead Product Designer

Partners

Product Design, Product Management, Engineering, Content Design

Timeline

3 months

Year

2025

Context

Horizon Worlds is a user-generated gaming platform on VR and mobile, similar to Roblox. Creators, both in-house at Meta and independent developers, build worlds using a desktop editor akin to a simplified Unity. Their typical workflow is develop, test, publish, and promote.

Current 3rd party world creator workflow

Problem

The challenge is promotion: the creation workflow was fragmented across platforms, forcing third-party creators to context-switch between tools to capture and share their work. This is analogous to enterprise users who must leave their primary application to complete a core workflow, a pattern that consistently drives drop-off and reduces output quality.

Goal

The goal is to streamline world promotion for all creators by consolidating the entire workflow into a single desktop platform, enabling faster, more professional capture.

Understanding core actions

To better understand users' mental models, I gathered insights from internal creators and identified three core actions: controlling the camera, recording footage, and adjusting camera speed.

Understanding pain points

I gathered feedback from internal creators and identified two key pain points: the tool was buried in internal settings, making it hard to access, and it relied on external software due to the lack of integrated recording, adding unnecessary friction to workflows. These two pain points directly shaped the solution: a consolidated entry point within the desktop editor, and an integrated recording function that eliminated the need for external software.

Improved entry point access

Before, the tool was buried in internal settings on the desktop simulated VR experience, making it tedious to access and start using.

After, the tool is accessible directly in the desktop editor, allowing creators to seamlessly move from publishing to capturing promotional content.

Restructured IA + updated UI

To address the lack of integrated recording and better align with core actions, I restructured the IA to prioritize primary tasks and updated the UI to match the desktop editor. This streamlined common actions and improved workflow efficiency.

Key decisions + trade-offs

After multiple iterations, I narrowed the solution to two options:

Option 1 treated capture as a widget integrated into development and testing workflows. The risk was mixing mental models, potentially distracting users from capture and promotion tasks.

Option 2 treated capture as a focused workflow, allowing creators to concentrate on capturing and promoting their worlds. While it required some upfront education, it better separated workflows by stage.

I recommended Option 2. This decision required alignment across product management, engineering, and content design, navigating scope constraints and ensuring the education layer was feasible within the timeline.

Results

Within three months, the tool was built, launched, and adopted by 1,000+ creators. By consolidating the workflow into a single platform, creators no longer needed to switch between desktop and VR/mobile to promote their worlds, reducing friction in a previously multi-step process.

next project: drone camera 📷 →

Meta

Drone camera 📷

Expanded the Horizon Worlds camera with a new drone mode, enabling users to capture unique gameplay angles. Driven by user research, validated through playtesting, and launched after a two-week experiment, the feature drove a 24.6% increase in video captures and a 6.5% lift in time spent.

Role

Lead Product Designer

Partners

Product Management, Engineering, Content Design, Product Design Prototyper, Data Science, Research

Timeline

4 months

Year

2023

Problem

The current in-world camera is great at capturing selfies and staging shots, but can be cumbersome and difficult when capturing gameplay moments.

Understanding user needs

Our UX researcher ran a survey with Horizon Worlds users on preferred camera points of view. A strong majority (40%) indicated interest in a drone-style camera for gameplay capture, directly validating the need for a new mode and giving the team a clear north star for the design direction.

Preferred Camera PoV Type survey results

Competitive auditing

I audited drone-related features across physical and digital products to understand the design space. VRChat's drone camera prioritises advanced manual control but does little to simplify gameplay capture. Pixy by Snapchat takes the opposite approach: pre-defined flight paths that let users capture content hands-free. The Pixy model aligned more closely with our users' pain points and informed the direction I pursued.

Solution

Entry point + education

I added an indicator on the primary camera entry point to help educate users about the new drone mode. After the user clicks on the camera entry point, by default it would open up the selfie camera, and a secondary indicator will show where to access the new drone feature.

Minimize gameplay disruption

Since the main focus of this feature is to capture gameplay in the drone angle, it's important that the camera is not disrupting the user's gameplay. I decided to place the camera at the top right corner of the user's peripheral vision with a smaller preview, so that they can see what is being previewed without disrupting users from playing the game.

Drone camera minimize gameplay disruption - drone view

Clear bystander awareness

It's important that we account for other users in the same instance of the world, and ensure that they are aware of recording happening near them for privacy and integrity reasons. I decided to integrate a recording icon on the user's nametag (along with the other status icons) for bystander awareness. I also worked with a design prototyper to integrate a 3D model of the drone object, providing awareness of where the recording is happening spatially.

Bystander awareness - nametag without recording icon

Bystander awareness - nametag with recording icon

Playtesting + iterating

After working with engineering to implement the designs to specification, our team went through multiple rounds of playtesting and iterating to improve the overall experience. One thing we noticed during playtesting was that during recording, the drone camera UI was still distracting during gameplay, even though it was placed in their peripheral vision.

I decided to tweak the experience so that the entire UI (asides from the stop record button) faded out while recording was happening, and reappeared on hover of the UI area. This helped the user focus entirely on playing the game.

Results

After running a 2 week experiment, the drone camera drove a 24.6% increase in video captures and a 6.5% lift in time spent. As a result, we decided to launch the feature publicly.

This project reinforced the value of pairing quantitative research (survey data) with qualitative iteration (playtesting rounds) before committing to a launch decision. The research-to-experiment pipeline compressed decision-making and reduced the risk of shipping a feature that did not land with users.

next project: file management system 📂 →

Visier

File management system 📂

Redesigned the file management system in Visier People, an enterprise HR analytics platform. The existing experience made it difficult for HR analysts to navigate, find, and delegate documents: key workflows in day-to-day analytics work. The redesign improved discoverability and was subsequently adopted across multiple surfaces of the product.

Role

Product Designer

Timeline

2 months

Year

2018

Problem

Before this project, the user experience for file management was difficult to navigate and lacked the core functionality of common file management systems such as Google Drive and Dropbox. The experience of creating, reading, updating, and deleting documents was inconsistent, difficult to access, and tedious to scan.

Research + audit

Before diving into user experience and interaction design, I analyzed the commonalities between existing file management systems and email clients. Examples I've looked at include: Google Drive, Gmail, Dropbox, and Jira by Atlassian. I identified common user interface and interaction patterns between each application to see how it might fit within our current design system, and made sure I understood the design decisions made.

Explorations

After auditing existing file management systems, I created multiple iterations on Sketch to explore different visual and interaction options and prepared them for design feedback sessions.

Peer feedback

An important aspect of this project was getting feedback from other designers when there wasn't a clear-cut choice for a particular iteration. An example was when I had to choose between two approaches for a multi selection pattern: an adapted version of Dropbox's pattern versus Google Drive's pattern. Dropbox uses a checkbox layout for multi selection, while Google Drive uses the standard desktop file manager metaphor for multi selection ('shift' key multi-select).

After our feedback session weighing out the pros and cons of each approach, I came to a conclusion that Dropbox's pattern better aligned with our application, since Google Drive's pattern is heavily dependent on a custom right click menu that allows the desktop file manager metaphor to work effectively. Our application currently doesn't support a custom right-click menu, so Dropbox's pattern better aligned within the scope of the project.

Optimizing navigation

A common pattern across file management systems is using tabs or sections to help users navigate by ownership type. I chose tabs over a dropdown because the number of options was small enough to display all at once, reducing cognitive load and keeping primary navigation always visible.

Revealing meaningful information

The previous experience surfaced only document titles, making it difficult for analysts to scan and identify the right document quickly. Based on patterns from Google Drive and Dropbox, I added subtitles, last-modified dates, and owner names, giving analysts the context they need to act without opening each document.

Surfacing file management functionality

Several key actions available inside individual documents were absent from the document list view, creating inconsistency across surfaces. I brought these actions inline at the list level, ensuring analysts could act on documents from wherever they encountered them.

$File management functionality$

Results

The updated design layout for file management was adapted and scaled across various surfaces of the product.

Reflection

Looking back, I would have prioritised user research with actual HR analysts earlier rather than relying primarily on competitive analysis. I would also want to validate the redesign through usability testing before shipping, rather than relying on internal design feedback alone.

next project: ui library 📖 →

Visier

UI library 📖

Built a Sketch UI component library for Visier's design team to address growing inconsistency across the product's visual design and interaction states. The goal was to standardise components, reduce duplicated work, and give designers a single source of truth that could scale with the product.

Role

Product Designer

Timeline

4 months

Year

2018

Problem

Visier's design team lacked a set of consistent components to share and use. Our team was progressively migrating from using Illustrator to Sketch as our primary design software, and a consistent set of UI components was needed for Sketch. As Visier grows as a company, a UI component library was crucial to ensure designers work with the latest iteration of components.

Research + exploration

When I was first involved with this ongoing project, it was at an early stage where it was relatively new to everyone on the team. This gave me the opportunity to start from ground up, meaning it was important to look into existing design systems and UI libraries established by other companies (such as Shopify Polaris, IBM's Carbon Design System, and Google's Material Design) and to see how their components are structured; in particular the Sketch UI components. Apart from researching other companies' UI libraries, I looked into the best practices for using Sketch and making a UI library.

Structure of components

It was important to have a baseline structure for our UI components before executing the details; this ensures that the designers on our team can easily locate the components and that they are consistently and logically grouped together. One of the biggest challenges I had to overcome is not being fully aware of all of the complex UI components that exist in our product. Apart from being assigned certain components to be built in Sketch, I actively explored the current build of our product to make sure I have a relatively better understanding of all the components that exists, how they relate to each other, and how I can group them together.

Execution

When I executed each individual UI component, I thought of how to make it easy for designers to use each one. It was a challenge to find the right balance between modular and preset components; if a component was too flexible, users would have trouble figuring out whether or not a component can be used in a certain section of our product. If a component was too fixed into a preset state, users would find it limiting when it comes to configuring a component to their needs.

Peer feedback + user testing

What helped me progress through my work was the feedback I received from my supervisor and peers as well as the informal user testing sessions from various individuals on my design team. The feedback I received either helped relieve doubts I had on design decisions I made or helped provide insight as to how to approach building out a specific component. For example, when I wasn't sure whether or not the hover states of two different components should be the same, I brought up the question to my supervisor. We had a discussion about it, and resolved that they should follow the same pattern.

Building templates

To make the UI library easier to use for the designers on our team, I made a Sketch file specifically for templates. Ideally, this would give our team a one-stop-shop to pull any layout they need to communicate their user workflows or concepts. This means designers do not have to spend time worrying about the layout and the spacing between each component.

Maintaining + editing components

Apart from making the Sketch UI library easy to use for our design team, it was important to make sure it was easy to make changes and edits to the components. The approach was simple: build each component from ground up; this way, the base components could be easily edited and reflected into the combined component.

For example, a search bar is made up of several base components: a container with several states (default, hover, and focused), text (placeholder and input), two icons (search and close), and a blinking cursor. The components were made into symbols then combined into a new symbol (the search bar), meaning all edits would be made through the base components. This is useful when considering the different variations of the search bar; if the search icon needed to be updated, only the base component for the icon would need to be edited in order for it to reflect into the different variations.

Maintaining and editing UI components in Sketch

Results

The UI library was fully integrated into our design team's workflows to execute design work more efficiently.

Reflection

In retrospect, I would have pushed for a token-based foundation from the start rather than building components in isolation. A component library without strong token conventions tends to drift over time as the product scales. This became clearer in the years after, as design systems thinking matured across the industry.

next project: advanced capture tools 🎥 →