The Process: How We Made It Look Easy
Before pushing pixels, we hammered out a user flow that would take the fewest steps to get from app boot-up to the robot moving, while still keeping it coherent and instinctual.
Decision I: The Calibration Step
Before, calibration started from the Run button, with a pop-up asking whether to use saved calibration points. For safety, Dr. Xu wanted an “in-between” phase between calibration and the robot actually starting, for two reasons. First, the robot has no collision detection, so he worried that field workers new to the product would not think to clear debris from the farm bed or keep other workers out of the robot’s way. Second, he worried that field workers would instinctively try to run the robot without going through boot-up and calibration, which could cause catastrophic hardware failures.
Dr. Xu’s instincts proved right in field testing and interviews. Despite the greyed-out Run button, users S3 and SH‑P03 both tried to press it before boot-up and calibration. To fix this, we made Calibrate its own button and kept Run locked until calibration is done, with subtext under Run telling the user it is not ready to start.
Decision II: Bolder Type = Bigger Screens
This was by far Dr. Xu’s most valuable feedback. After the Figma demo, he prioritized removing some of the sleekness of the UI and making everything (the buttons, the font, the screens) significantly bigger and bolder. He noted that many of the farmers he had collaborated with were elderly and had issues with their vision. Add Florida’s harsh sun, and even people with perfect vision could struggle to use the laptop.
We remedied the bright glare by going bold. Along with typography and buttons, we made our stroke lines thicker and our color contrast starker. For the initial calibration flow, we had pop-up modals that overlaid the home screen. Ryan and I discussed and decided to turn the setup modals into full screens. This bought us a lot more room in the part of the user flow that required the most user engagement, which let us resize all the design components without crowding the screen.
Field testing supported this change. In our first test with the original prototype, battery and time could not be reliably read at 2 meters. Both SH‑P01 and SH‑P03 felt like they had to squint to make out what the home buttons were saying. When taking the laptop indoors, both had an easy time, even from longer distances.
For the second field test, we took the redesigned UI and robot back outside, doing our best to match the weather and glare conditions of our first field test. All participants noted that the new design made it much easier to read and understand. Direct sun glare was still hard, but it could be reduced by tilting the laptop screen slightly downward, away from the reflection of the sun.
The tradeoff: we traded the sleekness of our original design for function, and for people working outside in the Florida sun, that was the right call.
Decision III: Let’s Calibrate!
Dr. Xu wanted the interface to show more. He wanted the user to be able to input the claw height and arm length, and to see that the rangefinder was working properly. For the initial onboarding settings, he wanted the user to enter data about the field, including row spacing, number of rows, row length, bed height, and latitude and longitude. He also asked for a notification pop-up that would alert the user when the strawberry basket was at capacity.
We initially agreed, but soon found that, because of what was available in the MATLAB code, we could only implement some of it. We discussed the limitations with Dr. Xu and agreed that calibration needed only one real value to succeed: the height of the claw relative to the bed, in centimeters. Settings would contain four values: claw height, space between rows, number of rows, and length of row.
Latitude and longitude, bed height, and the basket-full pop-up all had to be cut. Either the hardware could not support them in its current state, or they were out of scope for the timeline.
Decision IV: Say What Broke, Plainly
In the early designs, when a failed check occurred during the boot-up phase, it would reset the booting phase and repeat the error, creating an endless cycle that could only be exited by resetting the browser. For a field worker standing at the robot, a failed check was a dead end.
The first version showed three things: the name of the error, a fault code, and where on the robot it came from. We included a Try Again button in the bottom right corner of the screen so that the user could try the boot-up process again once they fixed the hardware issue.
When we ran a simulated error in the field test, users knew something was wrong, but not how to fix it. S1, S2, S3 and SH‑P03 all mentioned that fault codes were not beneficial for troubleshooting the error, just noise. The only things they needed were what the error was, in plain English, and where on the robot they could find it.
For our initial Figma demo, we had a stylized drawing of the robot with a red circle around where the error was. For our final build we removed it, since it was hard to tell where on the robot the error was from a single 2D image. Plain words beat an unclear picture.
Decision V: Emergency Stop
The very first version we created did not have an emergency stop button or function. The only ways to stop the robot were through the hardware: two switches on top of the robot that turned off the battery. After our June 25 walkthrough with Dr. Xu, we were instructed to add a manual emergency stop function to the interface that would immediately stop the robot. Dr. Xu was concerned about the safety of the users and other workers in a field, and wanted more than one fail-safe method of stopping the robot.
When designing the robot run screen, I made sure that only one element on the screen would be red: the emergency stop button. That way, if something went wrong, no one would have to search for it.
