There were already many good answers here, let me just add my perspective probably just repeating the previous comments.
I am not a Fit expert and I have never used that with "real" customers but I did use something resembling it as I think all of you have. Occasionally I organize a "QA Day" for QA managers and show them various techniques along with Ran Eilam. He is a Fit expert and I am CC-ing him hoping he'll be able to share his experience. During the QA Day I first show them the "evolution of testing"[1] that is basically an introduction to TAP. We build a flow-based test and then re-factor it so that we can move the input and the expected output into external files in some user writable format. (a CSV file). Effectively these are already FIT tables. Then comes Ran and shows the FIT approach from the direction of the tables which is how users see it. What I am trying to say is that if you can re factor your code to have your input and expected output in some data structure, you'll also be able to move it out to an external file. That file can be written by the users. I think chromatic mentioned that you should use FIT for acceptance tests and not for unit tests. May I disagree here. I think every test is a unit test. Just the size of the units is different. For programmers the size of the unit is a function. For the integration engineer (or the programmer when she is doing integration between parts of the code) it might be modules. They call it integration test but that's just bigger units. When the customer test the product we call it acceptance test. In the end I think it does not matter. I can wrap each use-case in a single function (even if that function needs to call external applications) and then we are back in "unit-test mode" where you first write a flow then create an array with input and expected output values and then you can move it to external files. So I think we all use a FIT-like approach when we separate test data from test code. We just did not call that FIT and did not put the data in spreadsheets. Gabor [1] The slides are here: http://www.szabgab.com/talks/qa_in_opensource/slides/tap.xul
