Move: Optimizing Robotics Workflows

When a robotics startup scales from 20 to 80 employees in 18 months, documented processes rarely keep pace. Invento Robotics was deploying robots to enterprise clients while their internal workflows crumbled under the weight of rapid growth. Communication breakdowns between Sales, Engineering, and Deployment teams were costing weeks of productivity and risking client relationships.

This case study documents my role as the first UX researcher at Invento, where I embedded directly within engineering teams to identify systemic workflow bottlenecks and co-design solutions with employees rather than imposing top-down fixes.

The Problem

Imagine this scenario: Sales closes a $200K deal with an enterprise client, promising custom features and specific delivery dates. Engineering receives a brief Slack message with the client's name and a vague feature description. Deployment teams show up on-site without knowing the robot's configuration, software version, or client-specific requirements. The robot fails during demonstration, the client threatens to cancel, and Engineers get called at midnight to fix an undocumented customization.

The root cause? Invento had grown beyond their informal communication channels. Information that once lived in a few people's heads now needed to flow across five teams. When I arrived, they were losing an average of 2-3 days per deployment to preventable communication errors.

Leadership knew something was wrong but couldn't pinpoint where. They needed someone to map the actual workflows, identify the bottlenecks, and propose solutions that teams would actually adopt—not just another process document that gets ignored.

My Approach: Researcher as Engineer

Instead of the traditional approach of conducting interviews from the sidelines, I embedded directly within teams as a "Researcher as Engineer." Given my technical background, I could credibly participate in actual engineering work—debugging robots, writing code, attending stand-ups—while observing genuine behaviors and pain points.

This ethnographic approach revealed what formal interviews would have missed: the informal workarounds teams had developed, the WhatsApp groups where critical information actually lived, and the moments when workflows broke down in real-time.

Research Methodology

Over eight weeks, I conducted ethnographic research by embedding with teams, participatory observation during actual work, and co-design workshops:

• Ethnographic Embedding (4 weeks): Worked alongside Sales, Engineering, Hardware, Deployment, and Leadership teams. Participated in stand-ups, client calls, robot testing, and deployment visits.
• Stakeholder Interviews (15 people): Semi-structured interviews with team leads, individual contributors, and leadership to understand strategic perspectives and pain points.
• Co-Design Workshops (3 sessions): Used "Quick 4s" sketching method where employees rapidly ideate solutions in 4-minute sessions. This generated employee-driven ideas rather than top-down mandates.
• Process Documentation: Created visual workflow diagrams showing information flow (or lack thereof) across teams.

Key Findings: Five Critical Bottlenecks

1. Information Silos Between Teams

In a typical week, I observed this pattern multiple times: Sales would close a deal promising specific features, but Engineering wouldn't learn about these commitments until days later. When Deployment teams arrived on-site, they often discovered the robot had software updates or configuration changes that weren't in their documentation.

Why this mattered: One deployment required 3 engineers to travel back to headquarters to debug an undocumented feature the client expected. The fix took 4 hours, but the round-trip travel cost $2,000 and delayed the client's go-live by a week. I documented 12 similar incidents over the observation period.

What I Heard: "Yeah, I'll need to talk with the sales team to understand what they're selling... and the software team to see what features they have at this point..." — Manager describing typical information gathering

2. No Single Source of Truth

Critical information lived in a fragmented ecosystem: emails, Slack threads, WhatsApp groups, Google Docs, and individual memories. There was no central repository for robot configurations, client requirements, deployment histories, or troubleshooting knowledge.

I shadowed a deployment engineer who spent 40 minutes searching for the correct robot configuration across six different channels before finding the right documentation in a WhatsApp group from two months prior. This wasn't unusual—it was the norm.

3. Inconsistent and Unfollowed SOPs

The company had documented Standard Operating Procedures, but adherence was inconsistent. Teams developed informal workarounds that weren't captured. When experienced employees left, their undocumented processes disappeared with them.

During one deployment, the on-site team skipped three documented steps because "the PDF is outdated, let me just tell you the right way." When I checked, their verbal process contradicted the official SOP in two critical ways. This knowledge lived only in that person's head.

4. Technical Complexity Barriers

Deployment teams needed to send complex ROS (Robot Operating System) commands to troubleshoot robots on-site, but most deployment engineers weren't programmers. They struggled with command-line interfaces during time-sensitive installations, often calling engineers for help with basic diagnostic commands.

What I Heard: "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 a visual interface

During co-design workshops, deployment teams sketched solutions showing simple button interfaces replacing complex commands. One engineer's sketch showed a "Run Diagnostics" button that would execute the complicated ROS sequence behind the scenes.

5. Leadership Visibility Gaps

Leadership had no aggregated visibility into robot fleet status, deployment timelines, or team bottlenecks. They relied on manual check-ins and hallway conversations. Decisions about resource allocation, client commitments, and product priorities were made without real-time data.

When I interviewed a senior manager, he explained they'd recently promised a client a 3-week delivery timeline without knowing the actual deployment queue—it was actually 6 weeks. "We just didn't have that information readily available," he told me.

Solution Concepts: Bridging the Gaps

Based on research findings and co-design workshop outputs, I developed low-fidelity prototypes addressing the five core bottlenecks. These weren't just my ideas—they emerged from employees' own sketches and pain points.

1. Centralized Robot Hub

The Concept: A single platform where every robot "lived" digitally. Sales could add client requirements, Engineering could update configurations, Deployment could log installation notes, and everyone could see the complete robot's history in real-time.

During co-design, a Sales manager sketched what this would look like: "Each robot gets its own page, like a profile. I can see what features it has, what the client wants, and what's different from the standard build. Right now I'm asking Engineering every time."

Key Features:

• Real-time updates visible to all teams
• Version-controlled configuration management
• Chat-like comments for async collaboration
• Timeline showing the robot's full lifecycle
• Integration with existing tools (Slack, email notifications)

2. Simplified Deployment Interface

The Concept: Replace complex command-line ROS interfaces with visual, button-based controls that deployment teams could use on-site without programming knowledge.

This idea came directly from deployment engineers during workshops. One team member showed me his sketch: a mobile app with large, labeled buttons like "Run Diagnostics," "Check Connectivity," and "Reboot System." He explained, "Instead of me typing 15 commands I don't understand, just let me tap this."

Key Features:

• Visual controls replacing CLI commands
• Pre-configured diagnostic workflows
• Error prevention with guided wizards
• Offline capability for installations without WiFi
• One-tap access to engineering support when needed

Estimated Impact: Deployment engineers estimated this would reduce on-site troubleshooting time by 60% and cut calls to engineering support in half.

3. Leadership Dashboard

The Concept: An executive-facing view showing fleet health, deployment queues, team capacity, and bottleneck alerts to enable data-driven decisions.

The CEO told me, "Right now I'm asking managers 'how's it going?' and getting vague answers. I need to see the actual state of our operations." This dashboard would answer questions like: How many robots are in deployment? Which teams are at capacity? Where are we seeing repeated issues?

Key Features:

• Real-time robot fleet status overview
• Deployment queue and timeline visualization
• Team capacity and workload metrics
• Automated bottleneck alerts (e.g., "Hardware team at 90% capacity")
• Historical trends and pattern identification

Research Insights & Learnings

What Worked Well

Ethnographic immersion: Being embedded as an engineer wasn't just a research method—it was essential for gaining authentic insights. During formal interviews, employees gave polished, idealized descriptions. But when I was working alongside them during a deployment emergency, I saw the real behaviors: how they circumvented broken processes, who they actually called for help, and what they said in Slack when leadership wasn't listening.

One particularly revealing moment came when I was debugging a robot alongside an engineer. He spent 20 minutes on a problem before casually mentioning, "Oh, I usually check the beta Slack channel for undocumented fixes." This wasn't in any documentation, and he hadn't mentioned it in our interview. Ethnographic observation captured what interviews missed.

Co-design workshops: The "Quick 4s" sketching method—where participants have 4 minutes to rapidly sketch solution ideas—was transformative. Employees who struggled to articulate problems verbally could suddenly visualize solutions on paper. One deployment engineer who had been quiet during interviews became animated, sketching four different interface concepts. "This is exactly what I need!" he exclaimed.

These employee-generated sketches became the foundation for my prototypes. Rather than imposing solutions, I translated their ideas into designable concepts. This built buy-in—teams saw their own suggestions reflected in the solutions.

Multi-stakeholder perspective: Understanding all five teams prevented classic startup mistakes: solving one group's problems while creating new ones for another. For example, I initially proposed a comprehensive documentation system that would solve Engineering's need for specs. But when I interviewed Deployment, they explained such a system would add 30 minutes to each deployment because they'd need to read through everything. The solution needed to be searchable and filterable by team role.

Key Learnings

Startup chaos is systemic, not personal: Initially, I assumed the communication breakdowns resulted from individual negligence. After observation, I realized most failures stemmed from missing infrastructure—there simply weren't channels for information to flow correctly. Teams weren't lazy or uncooperative; they were working around systems that didn't support their workflows.

Simple solutions win: When I presented early concepts, teams consistently chose simplicity over feature-richness. They wanted minimal clicks, maximum clarity, and predictable outcomes. One engineer told me, "I don't care if it has 20 features if it takes 5 seconds longer than doing it the old way."

Trust enables honesty: Working alongside teams (not just interviewing) built relationships that revealed truths formal processes hid. Employees shared frustrations they wouldn't express to leadership directly: "The CEO thinks we're lazy, but we're spending half our time hunting down information that should be in one place."

Visual communication accelerates alignment: Sketching during co-design clarified needs faster than verbal descriptions. When a Sales manager said "transparency," I thought he meant financial numbers. His sketch showed robot configuration visibility across teams. Without the visual, we would have spent weeks designing the wrong solution.

Process documentation must capture informal wisdom: The biggest knowledge gaps weren't in documentation systems—they were in the undocumented workarounds experienced employees had developed. When employees described their workflows, they often didn't realize they were skipping or modifying official processes. Ethnographic observation caught these informal practices.

Impact & Recommendations

This research provided Invento Robotics with a comprehensive understanding of their workflow bottlenecks and actionable paths forward:

Immediate Wins (No Investment Required)

• Standardized communication templates: Quick-win documentation templates for common information handoffs (e.g., Sales-to-Engineering deal briefs, Engineering-to-Deployment robot configurations)
• Weekly cross-team sync meetings: Structured 30-minute meetings where each team shares updates that impact others
• Shared "Robot Status" Slack channel: Centralized channel where teams post real-time robot updates visible to everyone
• Documentation audit: Identify which SOPs are outdated and update them based on actual workflows I observed

Short-Term Solutions (2-3 Month Implementation)

• Phase 1 of Centralized Robot Hub: Start with a simple shared workspace (notion, Airtable, or similar) where robot information lives. Teams can migrate from current fragmented channels gradually.
• Deployment mobile app prototype: Build MVP simplified diagnostic interface for deployment teams, starting with the top 5 most-used ROS commands
• Automated alert system: Set up simple alerts when critical information changes (e.g., "Robot configuration updated, notifying Sales and Deployment")

Long-Term Vision

• Full Centralized Robot Hub: Custom platform integrating robot lifecycle, team collaboration, and real-time visibility
• Leadership Dashboard: Real-time visibility into fleet status, team capacity, and bottlenecks
• Knowledge management system: Capture and share informal workarounds and undocumented processes across teams

Estimated ROI: Based on documented incidents, the immediate wins alone could save 8-12 hours per week per team in information-hunting time. The short-term solutions could reduce deployment failures by 40-50%.