Defining STRUTT ev¹
How might we define a mobility product around what people actually need, when the company started from technology rather than a customer?
The company began with technology rather than a customer. We had a capable sensing and algorithm stack and a long list of things it could do, but no reliable picture of who would use a powered mobility device, what they actually cared about, or why. Product definition was being argued from intuition, and the arguments could not be settled because nobody had the evidence.
I led the user research, designing the study, running the interviews and home visits, and synthesising the findings into the definition work. I worked directly with the design director and reported to the CEO. Later in the same phase I built a Grasshopper tool that let the team see real sensor coverage instead of estimating it from overlapping geometry.
Research goal
01 Who our users are
02 How they actually live
03 Whether our assumptions hold
Research process
We recruited online for remote interviews, which let us reach people across different ages and countries. We also recruited locally, so we had people we could meet in person, observe, and test prototypes with.
Research outcomes
We completed more than 10 stages of online interviews with more than a hundred participants, and dozens of site visits in person.
- The experienced user. Over sixty, ambulatory but able to walk less than a hundred metres, with moderate mobility loss and prior experience of a powered mobility device.
- The first time buyer. Over fifty, with mild to moderate mobility loss. Able to walk, but slowed by balance problems or declining stamina. Typically using a walker or rollator, and considering a powered device for the first time.
- The family buyer. Aged roughly forty to fifty, buying for a family member so that person can rely less on others and be independent again.
Making sensor coverage visible with
Rhino & Grasshopper
While the user and product definition work was running, the R&D team was debating where the LiDAR sensors should sit and how many were needed. It was not only a question of technical blind spots. Coverage also depends on the size of the person in the chair, how they sit, where they put their things, and how they transfer in and out. At the time the team was working from hand drawn illustrations and overlapping 3D models, because there was no accurate or quick way to check what a given arrangement would actually see.
I wrote a Grasshopper program for LiDAR field of view inspection. The algorithm and design team could move each sensor, change its orientation, adjust the beam angle, and drop different human models into the chair. The program calculated the blocked field of view in real time and sliced it by height, so coverage could be read separately at ground level, at desk level and at head level.
It helped the team agree on the sensor placement, and it gave design and engineering something concrete to work against. A proposal could be checked against a real body in the chair in seconds, so form decisions and sensing performance could be discussed together rather than separately.