Maya - USD Payloads
USD Payloads Summary: USD Payloads provide a method similar to "lazy loading", though the specific data is explicitly requested on demand. Users have massive scene files that may not be needed until render time and can avoid paying the cost while working on ancillary scenes.
Universal Scene Description (USD) was created by Pixar to manage their ever-growing eco system of tool-specific applications. Rather than use lossy file conversion to move between apps, USD allows for a single file type to be used to build complex worlds. USD Payloads were created to allow on-demand loading of CPU demanding content.
My Role
Basic UX/UI Design
For this project, I was stepping into an entirely different team, on a product (Maya) which I had never worked. Our subject matter experts had presented a hypothesis from Charter (focus) group discussion with major film studios (Pixar, Disney, etc.) . There were political and time constraints blocking direct user research (IDI's, Contextual Inquiry, etc.). The design ask presented was simple:
Primary Research Goals
-
Understand the existing API capability
Primary Interaction Design Goals
-
Designing for the complexity of the fully composed state vs the authored state
Challenge
The user need and expectations of Payloads were presented to me in a base hypothesis. The challenge was to present an experience that manages Payloads both in the authored and composed states. Technical Directors and Artists have different goals for this UI and need to be satisfied with the resulting capability.
USD's major value, and challenge, is the composition of multiple layers into whatever scene or shot in which you're working. A user has the option to make edits at any "point in time" throughout the composition, while viewing the final composed state. Users needed the ability to author, view and edit Payloads via front end UI.
My Process
Empathize
User Interviews
Time and resources did not allow for IDI's on this project. If I had a nickel for every time. . .
Stakeholder Interviews
Individual stakeholder interviews were held using Kim Goodwin's methodology from Designing for the Digital Age. Stakeholders included:
-
Subject Matter Expert (Game Development Technical Director)
-
Development Architect
-
UX Design
-
UX Leadership
Key Insights:
The most important takeaway was the realization that the capability of the payload technology itself was widely misunderstood. Lacking in the hypothesis was the workflow correlation between USD Payloads and USD References. It was discovered during these discussions that Payloads and References use different syntax and, although the design needs to accommodate both, there needs to be separate UI containers for both.
From the UX Design and Leadership discussions, it was made clear that true Usability Testing time and resources would not be available for this project. As such, I integrated various usability inspection methods (e.g. pluralistic walkthrough, consistency inspection, etc.) early and often at all stages of the prototype reviews.
Participatory Design
Internal USD experts and Charter customers from major film studios added early insight into the wants, needs and expectations. This happened in several iterations through Wireframing and Concept Testing clickable prototypes. This process immediately reduced the perceived project scope dramatically as view/edit/author of Payloads was deemed the primary need. Integration of the composition, at the point in time which the payload was authored, was uncovered as an important limitation of the API by the Dev Architect. An early lo-fi mockup of the workflow exposed and eliminated hours of design and development time.
Competitive Analysis
USD is a fairly new technology, so its existence in other DCC's is not yet widespread. As a result, the competition on this project was Pixar itself. The USD API documentation is extensive, so I spent several days learning basic Python syntax and testing the complete offering of Payload functionality.
Failing Forward
Key areas where I failed and what I learned:
-
Python Development! I took it upon myself to learn basic Python syntax in order to build my own USD compositions. While I had no expectations of becoming an expert, I got way too involved in specifics that weren't necessary for the task. Thankfully a fellow Maya USD designer helped me recognize this before I was too far down the rabbit hole. An old Agile mantra was my key learning here: Just in time. Just enough.
Define
Personas
Extensive personas for Maya artists and TD's existed prior to this project. Given the potential industry possibilities (Games, VFX, etc.), these personas are quite detailed.
In order to focus on the user goals as presented in the hypothesis, I simplified the existing personas drastically and modified the high level data into project-specific details.
Wireframing
Using Axure, I sketched some very high level ideas for the Participatory Design stage. Using the information gathered during that phase, I put an updated sketch-level concept together to showcase customer needs and potential solutions to the problems. I met with the agile team first to review these concepts for Maya compatibility and technical feasibility.
Note: Autodesk Maya is approaching 25 years of maturity with hundreds of thousands of users worldwide.
Key Insights:
-
Reloading a dirty Layer isn't difficult, but pinging to check for modified files wasn't efficient. Since updated files are loaded on Open, this was deemed an acceptable limitation.
-
There is a technical difference between "Clear" and "Remove", requiring more investigation on labeling, flow and even evangelism. A perfect example of when icons alone don't work.
-
The potential need to show incoming (composed) information alongside authored information was reviewed. A technical spike on the topic proved this to be unreasonable (a.k.a. technically impossible) at this point.
Concept Testing
With the Wireframe learnings in hand, I began to create basic click-level mock-ups in Axure. Not prototypes (yet), but enough interactivity to highlight some of the aforementioned challenges.
Key Insights:
-
Major studios BLOCK the usage of various tools from their artists in USD. They structure their pipelines in a way that the artists "don't care" if it's USD or Maya data.
-
Changing from a traditional to an Explicit ListOp order is not common enough to add front-end UI functionality. It remains scriptable for the advanced use case.
Journey Map
Many of my projects result in the creation of one/many journey maps. This project did not. For an example, please see the Angling With Friends journey map.
Ideate
Generating Creative Ideas
Not much was done for true "ideation" for this project. You can't always do EVERYTHING!
-
Statement Starter: "How Might We...show users the composed results, while allowing active view/edit of the authored data?"
-
This was not some grand, organized operation! :) It was a fly-by-the-seat-of-my-pants exercise that spawned, nay, erupted from an early sketch. We went back and forth, round and round, in order to come to the conclusion that it's a difficult problem to solve! A much larger design concept that had been previously moved aside, was brought forth as the solution. My design counterpart was THRILLED that this conversation happened as she had previously been unsuccessful in convincing the team that this idea was necessary.
-
-
Other methods I use, but did not in this project:
-
Affinity Clustering, Creative Matrix, Round Robin, etc. Because the process isn't linear, many other items could fall into this category at any time.
-
Prototype
Low-fi Clickable
This project was destined to be heavy on prototypes, working through concepts with development, PM's, etc. I created several rounds of prototypes as I solved different sets of problems. These always (always, always) start as "sketchy" to promote the idea that it's not finished.
At this stage I introduced simple (but effective) workflow elements in clickable form (drop down menus, tab behavior, etc.).
Key Insights:
-
Complications of USD's Explicit Lists
-
USD Technical Limitations of Composition
-
Target Prims were brought to light - I had no idea they existed!
Design Review
Many, many design review sessions happened during this project. These broke out into two main categories - technical and design. The design team reviews included Interaction/Content/Visual designers, focusing on product consistency, best practices, etc. A heuristic review was done in the loosest terms - I asked a designer who had never done one to run through the process with small, but tangible results! Technical reviews included everyone, most notably the dev architect.
Technical
These reviews happened with another designer present, but for the benefit of recognizing any concerns from the agile team. The goals were to tease out technical limitations to my initial solution proposals to various problem statements. This routinely included concept-testing, not necessarily targeting workflows. Workflow questions were asked and uncovered, but it wasn't the goal.
Design Team
The goals, as laid out prior to a design critique, are different with the design teams. For this project, because USD projects are happening both in Maya and 3DS Max, designers from both Max and Maya were invited to provide insights. Representatives from IxD, CxD and VxD were also present for multiple sessions.
Key Insights:
-
Existing table designs in Maya were probably not worth following, even those created within the past few releases. In short, the most recently designed tables were dev-driven designs with no level of testing. This, of course, brings up the age-old question for a 25 year old product - Consistency Vs. Progress. I proposed documenting the differences to retro-fit the changes to (at least) the most recent table implementation. It was agreed upon that, even without usability testing, the UX process would provide enough of an edge to this new design to disregard the existing table design, providing we update the other UI.
-
Mocking up and working through a tree structure, rather than a sub-divided table, helped eliminate this option. This type of structure already exists in Maya, so it had to be explored, but proved unusable.
-
Not all table workflows required toasts, and/or micro-interactions to validate a user action
Med/High Fidelity Prototypes
As various design review iterations were completed, new insights were incorporated into the designs. With each review, I incorporated usability inspection elements (in attempt) to refine usability while moving forward with the design. As these iterations happened, the design slowly morphed from a sketchy, basic concept to "near" complete and refined.
Test
Moderated Usability Test
Time and resources did not allow for proper usability testing on this project. Between the nickels gained from the IDI section and here. . .
Usability Interview
Yes, I recognize that this is NOT a real thing. :)
This is typically an in-line process that I use when unable to perform proper testing. As I do concept testing, design reviews, etc., I am often asked questions about functionality. When presented with the opportunity, I try to gain usability insights, no matter how small. In the simplest of examples, it might go something like this:
Stakeholder: "What happens if you click the plus button?"
Me: "What would you expect to happen?"
Stakeholder: "How do I set the target prim?"
Me: "If I weren't here, what would you try?"
This is simply a way for me to gather insights on the fly. If it's an issue where I have major questions, I'll move to a Mural board and create a timed feedback window where people can add their own insights without group dynamics taking over.
Revisions
This is a highly iterative process and revisions were made early, often, and more throughout the process. Of course, this means that "My Process", as laid out via image above, is NOT linear!
Implement
Visual Design hand-off
A full review of the prototype was handed off to the visual designer to begin the beautification process. Multiple reviews happened to clarify, modify and accept the design.
Story Writing
On this project, I wrote the user stories. This isn't always the case, but the only choice is to roll with it! Stories were broken down using Bill Wake's INVEST method, allowing each to stand on its own if implemented in the documented order.