Fleet management for robotic mowers and connected tools

The Challenge

STIHL connected is the web application behind professional robotic-mower fleets. A landscaping business does not own one mower. It owns dozens, spread across client sites, each with its own schedule, boundary configuration and failure modes.

Managing fifty devices cannot be fifty times the work of managing one, and that is the whole design problem. The naive version of this product is a list of devices with a detail page behind each, which works beautifully in a demo with three mowers and collapses at thirty.

The second constraint was the field. These users are outdoors, often on a phone, often with one hand, and often at the moment when something has already gone wrong.

Key Decisions

1. 01

   Made the default view answer “what needs me today”

   Considered

   A device list as the landing screen, which is what almost every fleet product opens with.

   Chose

   An exceptions-first view, where healthy devices are deliberately quiet and only the ones needing attention surface.

   Professionals do not sit and monitor. They check in, find the exceptions, act, and leave. An interface optimised for browsing a device list is optimised for the wrong task.

2. 02

   Treated bulk actions as the main path, not a power-user mode

   Considered

   Bulk editing as a secondary mode behind a menu, with single-device actions as the primary flow.

   Chose

   Selecting many devices and applying one configuration as the main flow the interface is built around.

   If the core job is operating a fleet, then the fleet-level action is the core interaction. Burying it turns the product into a device list with extra steps.

3. 03

   Gave every device state one vocabulary across every surface

   Considered

   Letting the list, the map, the detail view and the notifications each describe status in whatever way suited that screen.

   Chose

   One word, one colour and one icon per state, identical everywhere it appears.

   Inconsistent status language is where trust in a fleet tool quietly dies. If a device is “offline” in one place and “not reachable” in another, the user starts wondering whether those are two different problems.

4. 04

   Specified the data layer with engineering instead of handing over mockups

   Considered

   Designing the tables and charts with plausible sample data and letting the engineering team infer the model behind them.

   Chose

   Defining every column, aggregate and chart together with engineering as part of the design work.

   A chart is a claim about what the data can do. Making that claim without checking it is how a design becomes unbuildable after it has been approved.

The Solution

The application designed from ideation through to launch: concept development, low and high fidelity prototyping, and UI design, together with the data model behind every table and chart.

Delivered as concept documentation, a data-layer specification and production-ready UI.

The Results

Shipped to production and running at connected.stihl.com. The application manages fleets rather than devices: live status across every mower, bulk actions, and mowing configuration applied to a whole site in one pass.