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. Leadership knew something was wrong but couldn't pinpoint where.
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.
Research Methodology
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.
Ethnographic Embedding
4 weeks working alongside Sales, Engineering, Hardware, Deployment, and Leadership teams. Participated in stand-ups, client calls, robot testing, and deployment visits.
Stakeholder Interviews
15 semi-structured interviews with team leads, individual contributors, and leadership to understand strategic perspectives and pain points.
Co-Design Workshops
3 sessions using "Quick 4s" sketching method where employees rapidly ideate solutions in 4-minute sessions—generating employee-driven ideas.
Process Documentation
Created visual workflow diagrams showing information flow (or lack thereof) across teams, revealing gaps formal interviews missed.
Estimated Impact
Based on documented incidents, the recommendations could transform deployment efficiency.
Key Findings: Five Critical Bottlenecks
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.
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.
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.
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.
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.
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 and client commitments were made without real-time data.
The CEO 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.
.png)
Visual summary highlighting key problems and solution concepts from the research.
Solution Concepts
Based on research findings and co-design workshop outputs, I developed concepts addressing the five core bottlenecks. These weren't just my ideas—they emerged from employees' own sketches and pain points.
Centralized Robot Hub
A single platform where every robot "lives" digitally. Sales can add client requirements, Engineering can update configurations, Deployment can log installation notes—everyone sees complete robot history in real-time.
Simplified Deployment Interface
Replace complex command-line ROS interfaces with visual, button-based controls. "Run Diagnostics" button executes complicated sequences behind the scenes. No programming required.
Leadership Dashboard
Executive-facing view showing fleet health, deployment queues, team capacity, and bottleneck alerts. Real-time data for resource allocation and client commitment decisions.
Conceptual prototypes developed by designers exploring solutions for improved information access and simplified workflows.
Research Insights & Learnings
What Worked Well
Ethnographic Immersion
Being embedded as an engineer wasn't just a research method—it was essential. During formal interviews, employees gave polished descriptions. But working alongside them during a deployment emergency, I saw real behaviors: circumvented processes, who they actually called for help, what they said when leadership wasn't listening.
Co-Design Workshops
The "Quick 4s" sketching method 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.
Multi-Stakeholder Perspective
Understanding all five teams prevented classic mistakes: solving one group's problems while creating new ones for another. A comprehensive documentation system would solve Engineering's needs but add 30 minutes to each deployment.
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.
Key Learnings
- Startup chaos is systemic, not personal: Most failures stemmed from missing infrastructure—not individual negligence. Teams weren't lazy; they were working around systems that didn't support their workflows.
- Simple solutions win: Teams consistently chose simplicity over feature-richness. "I don't care if it has 20 features if it takes 5 seconds longer than doing it the old way."
- Visual communication accelerates alignment: When a Sales manager said "transparency," I thought he meant financial numbers. His sketch showed robot configuration visibility. Without the visual, we would have designed the wrong solution.
- Process documentation must capture informal wisdom: The biggest knowledge gaps weren't in documentation—they were in the undocumented workarounds experienced employees had developed.
Recommendations
Quick Implementation
- Standardized communication templates: Documentation templates for common handoffs (Sales-to-Engineering briefs, Engineering-to-Deployment configurations)
- Weekly cross-team sync meetings: 30-minute meetings where each team shares updates that impact others
- Shared "Robot Status" Slack channel: Centralized channel for real-time robot updates visible to everyone
- Documentation audit: Update SOPs based on actual workflows observed
Phase 1 Implementation
- Centralized Robot Hub MVP: Simple shared workspace (Notion, Airtable) where robot information lives
- Deployment mobile app prototype: Simplified diagnostic interface starting with top 5 most-used ROS commands
- Automated alert system: Alerts when critical information changes
Full Implementation
- 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 across teams
Skills & Methods Demonstrated
Ethnographic Research, Stakeholder Interviews, Co-Design Workshops, Contextual Inquiry, Process Mapping
Qualitative Analysis, Thematic Synthesis, Systems Thinking, Bottleneck Identification
Prototyping, Figma, UX Writing, Information Architecture, Workflow Design
Robotics Domain, Cross-Functional Collaboration, Startup Operations, Technical Translation