Greg Toroosian sits down with HelloRobo founder Shakir Dzheyranov to talk Design, Trust, and the Human Side of Automation.

There is always a quiet assumption baked into a lot of robotic companies: if the hardware works, the product works. Get the sensors calibrated, get the arm moving, get the navigation stack tuned, and the rest will sort itself out. It is a reasonable assumption if you come from an engineering background. It is also, according to Shakir Dzheyranov, one of the most expensive mistakes a robotics company could make.

Shakir is the founder and CEO of HelloRobo, a product design studio built specifically for robotics and automation companies. In this episode of Machine Minds, Samson Rose founder Greg Toroosian and Shakir had a conversation that goes well beyond the usual “robots are the future” talking points. It is a grounded, practical look at what actually happens when a piece of hardware meets a human operator on a warehouse floor, in a hospital hallway, or on a construction site. Spoiler alert: the hardware is rarely the reason things go wrong.

If you are a founder or an operator in the robotics, AI, or hard tech space, stick around for the end of Episode 119 of Machine Minds, because Greg’s job at Samson Rose might be exactly the resource your team needs right now.

From Nike to Robotics: An Unlikely Path Into Hard Tech

Shakir’s background is not what you would expect from someone now designing interfaces for autonomous fleets. He started in visual arts and motion design, eventually landing product leadership roles at major consumer brands, Nike included. It was a world built around aesthetics, storytelling, and brand consistency.

At some point, Shakir made a deliberate pivot away from traditional design and marketing and into product design. The appeal was simple: product design let him tie every decision directly to something measurable, a real user problem, a business outcome, a number that moved because the design choice was made. That pull toward accountability and impact eventually led him somewhere he did not expect, which is robotics.

What he found in robotics was a massive gap. Robotics companies were pouring enormous resources into mechanical engineering, perception systems, and controls, while the actual interfaces that operators used to run these machines were often an afterthought. Dashboards that looked like they were built in an afternoon. Fleet management tools with no clear information hierarchy. Onboarding flows that assumed every operator already understood the underlying technology. Shakir saw an opportunity to bring design rigor to a field that badly needed it, and HelloRobo was born.

Why UX in Robotics Doesn’t Play By Software’s Rules

One of the most interesting threads in the conversation is Shakir’s explanation of why robotics UX cannot simply borrow patterns from consumer software. In a typical SaaS product, decades of design convention already exist. Users know what a dropdown menu does. They know what a green checkmark means. Robotics does not have that kind of luxury.

Shakir explains that when you are designing an interface for fleet management or human-machine collaboration, you are often building the pattern from scratch, not adapting an existing one. There is no fifteen-year-old convention for how an operator should be alerted that a robot has paused for a safety event versus a mechanical fault. There is no established best practice for how much autonomy status to expose to a warehouse worker who has thirty seconds to make a decision. These are safety-critical environments, and getting the designs wrong does not mean a frustrated user. It can mean a costly mistake or a genuine safety incident.

This is part of why HelloRobo decided to narrow its focus exclusively to robotics and automation rather than staying a generalist design shop. Specialization forced the team to actually solve these unsolved problems instead of reaching for templates that do not apply.

Building Credibility Before There Was a Business

Greg and Shakir also talked about the early days of HelloRobo, and it is a useful lesson for any founder trying to break into a technical niche without an existing network. Before commercial traction came, Shakir contributed to Open Robotics, the organization behind widely used tools in the robotics community. That contribution was not a marketing play or ploy, but it was a way to genuinely add value to the ecosystem while building real credibility with the engineers and founders who would eventually become clients.

It is a reminder that in deeply technical industries, trust is earned through demonstrated understanding, not through a polished pitch deck. Robotics founders can smell a design agency that has never actually sat with an operator or read a safety spec. Shakir’s early involvement in the open source robotics community gave HelloRobo a credibility that no amount of paid advertising could buy.

Lessons From the Field: Designing with Bedrock Robotics

The conversation gets particularly specific when Shakir walks through his experience working with Bedrock Robotics. Rather than adapting existing interaction patterns from adjacent industries, the HelloRobo team had to build new ones from the ground up, shaped by direct conversations with the people who would actually operate the machines every day.

Shakir is candid that the instinct to copy what already exists, borrowing a pattern from a warehouse management system or a fleet tracking app, is often the wrong move. The people running these operations have specific mental models, specific pressures, and specific moments where clarity matters more than polish. Talking directly to operators, rather than relying on secondhand assumptions from a spec sheet, consistently beat any shortcut the team tried.

What HelloRobo Looks for in a Designer

For anyone hiring in this space, Shakir shares a refreshingly concrete framework. HelloRobo looks for three traits above all else: strong product thinking, visual clarity, and the ability to embrace chaos.

That last trait might be the most telling. Robotics is not a stable, well-documented environment. Specs change mid-project, hardware constraints shift, and a feature that made sense in the office turns out to be unusable once it hits a dusty, loud, high-pressure warehouse. Designers who need a tidy, predictable process tend to struggle at HelloRobo. The ones who thrive are comfortable making good decisions with incomplete information, then adjusting fast once real-world feedback comes in.

Shakir talks about keeping design teams grounded in business metrics rather than aesthetics for their own sake. It is easy for a design team to fall in love with a beautiful interface that never actually gets adopted, but at HelloRobo, their measure of success is not how a product looks in a portfolio; instead, it is whether operators actually use it, trust it, and get faster at their jobs because of it.

MVPs, Vision Products, and What “Market Ready” Actually Means

One of the more useful distinctions Shakir draws is between three very different kinds of products: the minimum viable product, the overbuilt vision concept, and what he calls market-ready software. These terms mean these:

MVP: characterized as something teams often chase but which HelloRobo treats with some skepticism. These are called "flashy MVPs," implying MVPs can become an excuse to ship something thin or demo-oriented rather than genuinely useful.
Overbuilt "vision" products: the opposite failure mode. These are over-designed, aspirational concepts that look great but aren't grounded in what operators actually need day to day.
"Market-ready software": Shakir's own term, positioned as the goal in between. These interfaces that can "actually ship, scale, and be adopted by operators in the real world," i.e., tested against real operational use rather than either investor-demo minimalism or unshippable ambition.

MVPs are often too thin to actually earn operator trust. Vision concepts, on the other hand, tend to be flashy demo pieces that look great in a fundraising deck but were never designed to survive contact with a real operating environment. Market-ready software sits in between. It is built with enough depth to genuinely function in the field, without the bloat of features nobody asked for. Getting that balance right, Shakir argues, is one of the most underrated skills in robotics product development.

He also points out a persistent blind spot across the industry: onboarding and education. Robotics companies spend enormous effort on the core technology and comparatively little on helping a brand-new operator actually understand how to use it confidently on day one. That gap is exactly the kind of problem HelloRobo has built its practice around solving.

Culture, Growth, and What’s Next

This episode also touches on the softer side of building a company. Shakir talks about building culture inside a creative, distributed team, and about HelloRobo’s decision to open its first physical office in New York. He shares founder lessons on taking risks, staying playful even under pressure, and learning to let go of tightly controlling every outcome, something that does not come naturally to most design leaders.

Looking ahead, Shakir is most excited about where robotics intersects with mobility and prosthetics, technologies that do not just automate tasks but genuinely extend human capability. It is a fitting note to end on, tying the entire conversation back to the theme that runs through everything HelloRobo does: robotics only works when it is designed around the people who use it.

The Bigger Picture: Why This Conversation Matters

What makes this episode worth your time is not just the tactical advice, although there is plenty of that. It is the reminder that the hardest problems in robotics are not always mechanical. They are human. Trust, clarity, and usability are not soft add-ons to a robotics product. They are the difference between a machine that gets adopted and one that gets pushed into a corner of the warehouse after week one.

That is a theme Greg Toroosian returns to often on Machine Minds, and it is not a coincidence. Outside of hosting the podcast, Greg is the founder of Samson Rose, a retained search firm built specifically for the robotics, AI, and hard tech world. Having spent years inside the industry talking to founders, operators, and engineers, Greg has a rare vantage point on what separates companies that scale well from ones that stall out, and a lot of it comes down to the people they hire.

If you are building a robotics or automation company and thinking about your next key hire, whether it is a head of talent, a product design lead, or a founding engineer, Samson Rose is worth a conversation. The firm has spent years focused exclusively on this niche, which means less time explaining your industry to a recruiter and more time actually finding the right person.

Deepen Your Understanding of Human-Centered Robotics

Explore more from Machine Minds and Samson Rose:

Listen to the Full Episode: Catch the complete conversation, Designing the Human Side of Robotics with Shakir Dzheyranov, on Apple Podcasts or Spotify.
Explore HelloRobo’s Work: Visit the official HelloRobo website to see how the team approaches product design for robotics and automation.
Connect with the Speaker: Follow Shakir Dzheyranov’s perspective on design, robotics, and building market-ready products by connecting with him on LinkedIn.
Connect with the Host: Learn more about Greg Toroosian’s work in robotics talent strategy and follow the Machine Minds podcast by connecting with him on LinkedIn.
Build Your Team: If your robotics, AI, or hard tech company is hiring, explore how Samson Rose can help you find the right talent to scale.

Why Robots Fail Long Before They Ever Reach the Warehouse Floor