Team Dynamic

The RVA team had a constant sense of urgency driven by tight deadlines and a lean workforce. We used a rapid-paced, agile approach, and strategically broke down projects into manageable phases. Our primary focus was on Phase 0 (P0), where we focused on the minimum viable product (MVP), containing only essential features for agents' usability. This agile framework allowed us to streamline our workflow, with design and engineering swiftly executing tasks in sprints.

After joining the team and adapting to the new processes, I worked on enhancing the relationships on the team. I promoted stronger collaboration, communication, and efficiency by organizing team-building exercises, encouraging open communication, and focusing on clear and concise language when conversing with team members. Our team grew out of tense discussions and adopted a more efficient communication style, holding calm conversations even when times were stressful.

Onboarding to RVA

When I first transitioned to the RVA team, there wasn't much of an onboarding process for new team members. While coming up to speed and piecing information together, I created a new onboarding process document in Figma (shown below on the left) breaking down everything I used to understand the team. I then used this to bring my direct report up to speed only a month after I joined. This effort cut onboarding new team members' time in half and was also useful for other teams to gain insight into how our team functioned.

Figma Templates & Design System

In addition to improving the onboarding process, I also enhanced our team organization. I joined RVA four months after the previous and only designer had been laid off, and due to this, had no one to guide me through their Figma Files. Unfortunately, the files I inherited were bare bones, lacking any key dates, description, or useful information, making the files unusable. This was a turning point where I truly understood the importance of clear and extensive documentation.

In turn, I made it my mission to create structured Figma templates (pictured below) that anyone could dive into and understand the design intentions at each step of the process. In the new project template, the first page gives an overview of project information at a glance, and subsequent pages break down each step of our process from requirements, exploratory research, engineering sync notes, brainstorming, concept testing, and final handoff. This template kept our design handoffs consistent as well, making it quicker and easier for engineering to digest each new feature. Key dates, points of contact, decisions made, open questions, risks and more are now well documented throughout all our project documents.

No design system or reusable components had been built before I joined the team. This made it challenging to jump right in and get started with the rapid pace of the team. I wasted no time in kickstarting the creation of a design system (pictured on the right above) for the RVA team, meticulously constructing a suite of complex components. Working closely with the front-end engineers, I made sure the new components were built as intended and removed inconsistencies I found in the design. The Figma components allowed designers to produce screens and prototypes in half the time, making instance swap easy with the flip of a toggle. The engineers also benefitted from the well documented usage of components and their states, and the ability to see all parts of system at a glance.

By creating templates for our design process in Figma and a comprehensive design system, I streamlined our workflows and ensured clarity through detailed documentation. As our team grew, we were able to stay efficient, consistent and organized.

Hybrid Working

Since we had offices worldwide, our team spent the majority of our time together virtually. We used various remote tools and often prioritized asynchronous communication. This meant we employed strong skills at refining content and clearly explaining our needs and questions to other team members. We often collaborated in Google Docs, Miro boards, and Figma files, leaving comments, questions, and critiques.

We collaborated across timezones with team members working out of Boston, LA, Singapore, Pittsburgh, and Chicago. The time difference ranged from 1-3 hours to 12 hours. A few times a year, we would visit Las Vegas, the center of all operations, for in-person research sessions, hands on learning, and to sync face to face.

Our designers and researchers mostly worked out of the Boston office, so we would get together in person for team whiteboarding sessions. At one point, my direct report was located in LA while I remained in Boston. I leveraged our 3-hour time difference to delegate project tasks between myself and my direct report, enabling collaborative asynchronous work and gaining additional hours of productivity each day for our shared projects. As a result, we were able to expedite project turnaround times.

Additional Process Improvements

Design Needs Checklist

One issue we encountered when I first joined the team was a misunderstanding of project requirements and expectations from PM to research and design. The misunderstanding was due to requirements being written for both engineering and design with no clear differentiation. To solve this, I set up an initial meeting at the start of each project with the product owner to read through the requirements together, gain a shared understanding, and specifically list out the expectations from design at each phase of the project. I called this the "design needs checklist." Design was then able to use this checklist as a reference throughout the project. This new process improvement resolved previously missed requirements for all future engagements.

Feasibility Checks

Another problem we continuously faced on RVA was running into feasibility issues. In the beginning, we kept finding ourselves learning of the constraints after we had already handed off our designs. This would prolong the project, lead to design rework, and postpone engineering’s start on the effort. To solve this problem, I implemented feasibility checks at multiple steps of our process. After the product team synced on the requirements and understood the project, we would meet with engineering to ask our open questions and give them a rough idea of potential solutions. Engineering was able to inform us what was possible, or workarounds we could make. We also had a second feasibility check right after concept testing and before we finalized the designs. This reduced rework on the design side and gave engineering a sense of what to expect with the final handoff. The second feasibility check closer to handoff allowed us to incorporate feedback and requests from engineering, making it a full team collaborative process.

Thanks for Reading!

Working at Motional has been such a rewarding experience. If you'd like to learn more about my role, my process, or want to work together - send me a message below!

Or check out these articles from Motional's website:
A Path Forward: Using AI to Improve Remote Vehicle Assistance for AVs
Smart Choices: How Robotaxis Partner with Remote Vehicle Operators to Work Through Tricky Spots Safely