Was the suite of UI automation (called automation from here on out) stable? So were the tests deterministic? The requirement is if you ran the tests N times in a row you would get the same results N times in a row?
What was the goal automation testing exactly? Testing product overall? Stress testing the product: trying to see how long it could be poked until it crashed. Something else?
How did the automation go about testing? Did the automation drive a build of the product? Or did the automation use a custom test build of the product with the UI decoupled from the rest of the product? What were the benefits or drawbacks of either approach?
Did the automation use internal hooks or accessibility APIs to drive the product or perhaps something else? For the case of internal hooks did they skip the UI elements and simply fire the event handlers or use another approach?
Did the automation only verify the state of the UI or was internal state of the product also verified during the automation?
How long (wallclock time) and about how many steps did a typical test go through?
How did you solve the problem of "waiting"? Any non-trivial program will, at some point, need to wait for something to load from disk or the network or for something to compute. Presumably UI action can invoke this long running operation to happen. How would an automated test get notified of its completion so that the automation could verify the result and/or make forward progress with the test?
How much time was spent maintaining automation once it was in place?
Were the tests and test framework (if you wrote the automation framework yourself) more or less complicated that the feature/product you were trying to test?
Was the automation worth it overall? Was there too much time spent maintaining the tests? Were the tests too difficult to write in the first place?