I propose evaluating the association and classification of field settings (i.e. area, work plan) for the snow blower (and generally) due to the dynamic nature of…nature, and a user’s ‘jobs to be done’ at the moment.
The current implementation doesn’t adequately factor in nature and it’s seasonality, nor is it adaptive to the user context.
-
New proposed logic model (simplified)
- Area
- Name
- type (mapped, pathway, sidewalk)
- boundary/path
- slope direction(s)
- gradients
- safety margin
- no-go zone
- docking station
- Workplan
- Name
- Module (currently ‘Labels’)
- New: Labels (actual user-defined labels - spring, summer, lake effect, odd/even days)
- Settings
- Area selected 1…n
- pattern
- overlap
- speed
- height
- angle
- work twice
- Area selected 1…n
- Schedule
- Name
- Frequency (Single/recurring)
- Date
- Time
- Workplan(s) included
- return method
- Area
-
Use cases
- For example, I propose ‘auger height’ or ‘work twice’ (as they exist today) should be a workplan setting, not an area setting. A use case would be that for lake effect snow, I would use a workplan with high auger height/ balanced speed on first pass, and low auger height with turbo speed for work twice second pass. These workplan settings might need to be the reverse in order to be successful for a user on the other side of the lake. Separately, light and dryer snow would only get a single low fast pass - so it doesn’t disturb neighbors when it runs multiple times over the course of the day.
- Other settings (i.e. pattern) should be evaluated as well. An area should be defined as a perimeter and corresponding characteristics agnostic to a module (e.g. margin, slope direction, slope gradients, no-go zones), not defining the job to be done (pattern circular with right side throw direction on calm days, pattern parallel with left side throw direction on windy days, work twice on Thursdays for areas 1 + 2 in a parallel pattern, etc).
- I could choose from multiple workplans that matches my ‘job to be done’; for example on a snow day with no school I’d choose a thorough workplan, but on a day where we forgot to get eggs for breakfast and need to run out, I’d select a workplan that’s fast for me to get out quickly. Or, depending on the time of year when snow levels vary, I’d choose… etc.. etc..
-
Legacy mappings
- An area may only ever have 1 work plan (that sets area(s), pattern, direction, height, etc). This is the current implementation of Area, which is very limiting to more dynamic factors or needs.
I can go into more detail with the product team, if desired. This would also be applicable to the other modules, where it appears users are adapting to Yarbo’s implementation of these concepts and settings as they exist in a series of workarounds in order to ‘get the job done’, however this constrains future configurability and scalability, and in order to expand features in the current model the result will be software bloat if these concerns aren’t logically separated.
My post echoes a similar post Work Plan - make it an actual plan while focusing this feedback to be based on the snowblower experience, and adding in JTBD, IA, UX, and other tech experience to help the app product owner (software development definition) justify these changes. It is January now, and I am also surprised this hasn’t gotten more attention since it was brought up last summer. Changing this would allow greater flexibility and adaptation to the myriad use cases while Yarbo is refining the overall product, and create a better path for scaling, maintenance, and upgrades.
