Community Discussion · Policy

The ban didn't kill tech, it removed the 'default options' in interaction design

Pixel PerfectionistPixel PerfectionistJul 312026/07/31 64 views

I noticed an interesting detail: Unitree Technology states in its prospectus that "subsequent developed products face risks of being unable to sell in the US," but the wording specifically emphasizes that "existing main products are unaffected." To a designer, this sentence essentially means: "The robot interface you see now can still be used in the US, but the interaction logic for next-generation products might need to be redesigned."

The FCC placing "advanced robotic equipment produced outside the US" on a controlled list sounds like trade policy, but at the product level, it directly impacts the "factory settings" of user experience. Robots are not smartphones; they don't have the flexibility of post-launch upgrades via an App Store. Once hardware certification and communication modules are finalized, redesigning them later incurs extremely high costs. The FCC's cut doesn't sever the technical route, but rather the "default options" in the product design process.

The "Compliance" Cost of Design Systems is Higher Than Imagined

Those who build design systems know that the "defaults" of a component library determine 80% of visual consistency. Applied to robot products, the communication module is that "default." The US market has very strict certifications for radio frequency emitting devices; FCC Part 15 rules specify parameters for radiation limits, frequency bands, and power. If Unitree Technology wants to design a "US version" for new robots, selecting the communication module alone requires changes.

// The "compliance" variable in a design system, usually hidden in environment configuration
// This is simplified pseudocode representing interaction strategies for different markets
const marketConfig = {
  US: {
    wifiChannel: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11], // FCC restricts to 11 channels
    maxTxPower: 30, // dBm
    brand: 'Unitree',
    safetyTimeout: 3000, // ms
  },
  EU: {
    wifiChannel: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13],
    maxTxPower: 20,
    brand: 'Unitree',
    safetyTimeout: 2000,
  },
  CN: {
    wifiChannel: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13],
    maxTxPower: 20,
    brand: 'Unitree',
    safetyTimeout: 1000,
  }
}

In this variable table, each field corresponds to hardware design, firmware development, and UI feedback logic. For example, "safetyTimeout" is the time the robot waits for user operation after an emergency stop; the US's 3000ms is twice as long as China's because the FCC has stricter confirmation requirements for safe communication. The UI must reflect this waiting state; progress bar animations, sound prompts, and visual feedback all need adaptation.

So the ban essentially opens another "maintenance branch" for the design system. Product managers might think it's just changing a module, but designers have to revise copy, animation durations, and error prompts for all interaction states. Worse, if future US market versions share code with global versions, conditional judgments must be made at compile time, doubling code complexity.

The Challenge of "Localizing" Interaction Flows Goes Beyond Translation

Robots are unlike phones; their interaction flows are continuous and physical. For example, the action of "one-click start" might connect directly to a mobile app and begin movement in the Chinese market; but in the US, because the FCC requires devices to confirm channel idleness before emission, a step of "scan and wait 1 second" must be inserted into the startup flow. If this step isn't done well, users will feel the robot reacts half a beat slow.

  • Visual feedback: The start button must change to a "scanning" state, with a 1-second looping animation; it can't be a pure loading spinner—it must tell the user "I am checking the network environment."
  • Audio feedback: There cannot be continuous buzzing sounds because the FCC has requirements for emission noise, so prompt tones must be short "beeps."
  • Haptic feedback: If the robot has physical buttons, the vibration mode upon pressing must also change; the US market typically requires longer vibration durations (200ms vs 100ms in China).

These details seem small individually, but stacked together, they create a perception of "verbosity" for users. What I fear most when building design systems is this kind of "localization difference"—unlike text translation which can be replaced with one click, it requires redrawing flowcharts and redoing prototype tests. If Unitree Technology really wants to enter the US market, they need a dedicated designer internally responsible for "compliant interactions," monitoring every rule change in FCC versions.

Don't even get me started on the after-sales experience. If a user accidentally takes the robot out of the US and uses it in Canada or Mexico, it might trigger cross-border penalties from the FCC. At this point, the UI needs a hidden entry for "region switching," but for compliance, users cannot switch arbitrarily. How to resolve this contradiction? The smartest solution I've seen is: automatically detect GPS on first boot and lock the region, then solidify all interaction copy and communication modes, preventing manual changes by users. This effectively welds "product design" and "compliance design" together.

Where is the "Safe Zone" for Visual Language?

Visual designers hate one thing most: "Create a design set first, then modify it for compliance." The FCC has no direct restrictions on product appearance, but there are indirect impacts. For instance, the color and blinking frequency of indicator lights on the robot must avoid certain aviation frequency bands per FCC regulations, so RGB values cannot be chosen randomly. Additionally, antenna placement affects the signal radiation pattern, which in turn influences the shell's shape.

I guess Unitree Technology's current products lean towards a "mecha style," with sharp angles and strong tech vibes. But if selling to the US, antenna positions must consider FCC requirements for SAR (Specific Absorption Rate), so the shell cannot have overly sharp metal decorations...

Original link: https://www.ithome.com/0/983/962.htm

0 replies

?
Ctrl + Enter to reply
No replies yet — be the first to share your thoughts