When building tools for developers and data scientist to iterate (any tool used in an iterative creative process like writing code, building ML models, etc.), I

When building tools for developers and data scientist to iterate (any tool used in an iterative creative process like writing code, building ML models, etc.), I have similar breakdowns. This might be a build process (i.e., Makefiles and such). Or processing large amounts of data for analysis, simulation, model training, etc. 4+ hours: At most one iteration per work day. Because of the wait times, users will try to fit as many changes into each iteration as possible. Users just want to find something that works because trying alternatives can cost days, making results less optimal. Users will typically run jobs over night so they can work on the next iteration all day. 1 - 3 hours: 1 - 3 iterations per day. Users will do some exploration on the most important components. Context switching is a large cost because they have to do something else while it's running. 10 - 60 minutes: Still limited to a handful of iterations per day, largely because users don't want to do more context switches than that in a day. The run will finish sooner, but user won't be ready to switch back. Especially true later in the day as people get tired. 30 seconds - 10 minutes: Context switches can be simpler because they can be small tasks like catching up on email. Exploring different options is starting to pay real benefit here. < 30 seconds: Context switches are now minimized, keeping the user in flow. Feels more like interactive exploration rather than idea -> do something else -> remember idea -> evaluate. Users will try lots of different options, often yielding much more optimal results. Doing a bunch of work to get things from 5 hours to 4 hours is not of much use. Getting things from 10 minutes to 10 seconds greatly multiplies the value that others can create.