Move.
A UX case study identifying communication and workflow bottlenecks within a robotics startup to improve inter-team coordination.
My Role
- Project Lead
- UX Researcher
- UX Writer
Team
- 1 Researcher (Myself)
Duration
- 2 Months
- (Sep 2022 - Oct 2022)
Tools
- Figma (Prototyping)
- Python (Data Analysis/Scripting)
- Ethnographic Observation
- Interviewing
- Co-Design Workshops
The Challenge: Untangling Robotic Startup Complexity
The lifecycle of building and deploying successful robots is inherently complex, requiring seamless coordination between diverse teams like sales, marketing, software, hardware, and deployment. Miscommunications or misaligned processes between these teams can create significant bottlenecks, hindering progress and efficiency.
This project aimed to identify the critical bottlenecks within a robotics startup's workflow. Where does communication break down? How do differing team processes clash? And ultimately, how can these issues be addressed to streamline the robot development lifecycle?
My Approach: Researcher as Engineer
To gain deep, authentic insights, I adopted the role of a "Researcher as an Engineer." I immersed myself in the startup's daily activities, leveraging my engineering background to participate directly within the software, hardware, and deployment teams.
This ethnographic approach was supplemented by targeted stakeholder interviews (particularly with leadership) and collaborative co-design sessions with employees from various teams. The goal was to uncover core problems from multiple perspectives and collaboratively explore potential solutions.
TL;DR: Visual Summary
.png)
.png)
Identifying Stakeholders

Through initial analysis and conversations, we identified 5 major stakeholder groups influencing the robot lifecycle within the startup:
- Sales and Marketing
- Software Engineering
- Hardware Engineering
- Leadership
- Deployment Team
Understanding the unique perspectives, responsibilities, and pain points of each group was crucial for identifying systemic issues.
Research Methodology
Given the generative nature of the project (identifying unknown problems), we employed qualitative UX research methods:
- Ethnography: Immersive observation and participation within teams to understand workflows, tools, and informal communication patterns in their natural context.
- Stakeholder Interviews: Semi-structured interviews, primarily with leadership, to understand strategic perspectives, perceived challenges, and information needs.
- Co-Design / Participatory Design: Collaborative sketching sessions (Quick 4s) with employees to rapidly brainstorm solutions addressing their most pressing pain points.
Research Findings: Uncovering Bottlenecks
Ethnography: Insights from the Trenches
"I have no clue what the sales team promised the client for this robot, and I do not care. I am just going to write basic code and fix it later."
- Software Engineer during ethnographic observation
By working alongside engineers and deployment staff, I observed daily activities and engaged in informal conversations. This revealed several recurring friction points:
- Information Silos: Critical information about client requirements, robot configurations, or software updates often failed to flow effectively between teams (e.g., Sales to Software, Software to Deployment).
- Lack of Centralized Reference: Teams lacked a single, reliable source of truth for the status, specifications, and history of each individual robot being built or deployed.
- Inconsistent Protocols: Standard Operating Procedures (SOPs) were either not well-documented, not consistently followed, or not known across relevant teams.
- Domain Expertise Gaps: Assumptions about technical skills created issues, particularly during deployment where teams encountered unfamiliar software or hardware procedures under client pressure.
Stakeholder Interviews: Leadership Perspective
"Yeah, I will need to talk with the sales team to understand what they are selling... and the software team to see what features they have at this point..."
- Manager describing information gathering process
Interviews with leadership focused on their awareness of team-level issues, their view of robot performance, customer insights, and inter-team communication effectiveness. Key themes included:
- Centralized Information Flow Challenges: Leadership often acted as manual information hubs, highlighting inefficiencies in direct team-to-team communication.
- Need for Actionable Aggregation: Difficulty in getting aggregated data on robot performance or SOP adherence hindered strategic decision-making and resource allocation.
- Limited Insight into SOP Efficacy: Lack of visibility into whether established procedures were being followed effectively or needed revision.
Co-Design Activities: Employee-Driven Solutions
"I can't send ROS commands, I don't get it... it has to be simple. Something like this..."
- Deployment team member during co-design sketching
Using a rapid sketching technique ("Quick 4s"), we asked employees to draw simple interface screens that would most help their daily work. This exercise quickly surfaced priorities:

Interpretations from these sketches included:
- Desire for Simplicity: Employees prioritized minimal interaction complexity, especially for tasks performed under pressure (like deployment).
- Need for Simplified Technical Interfaces: Abstracting complex technical commands (like ROS) into user-friendly interfaces was a common theme.
- Demand for Data Aggregation (Leadership): Leadership sketches focused on dashboards and summaries for better oversight of robot performance and status.
- Maximum Information, Minimum Effort: A universal desire for quick access to relevant information without navigating complex systems.
Design Suggestions & Prototypes
While the primary goal was research and bottleneck identification, the insights directly informed potential solutions. Based on the findings, I developed low-fidelity prototypes illustrating concepts for a centralized information hub and simplified task interfaces. These aimed to address the core issues of communication silos, lack of central reference, and overly complex technical interactions.

These prototypes served as tangible starting points for the startup to consider for future internal tool development, focusing on improving cross-functional communication and workflow efficiency.