The Problem with User Stories
Back when I was running a consultancy, I was a big fan of user stories as a method for gathering requirements. Having left the consulting world, though, it's become really clear to me that stories are the wrong approach.
Why consultants like stories
With a freshly inked contract, the client typically wants to begin work immediately. If you're smart, you've sold them on the value of good design. But, they probably haven't engaged a designer just yet. So, starting the requirements gathering process by story carding is a great way to get the ball rolling.
In fact, an iteration or two worth of story cards are a really great thing to put in a proposal. They demonstrate to the client that you have listened to them during your initial meetings. A reiteration of the requirements proves that you're (at least basically) on the same page.
The problem
The thing is: applications are not collections of words. They engage us in completely different ways than reading story cards.
Words mean different things to different people. Even meticulously written user stories that follow a standard form leave plenty of room for interpretation. That's why, even with your carefully crafted stories, it still takes several tries to get it right with the designer.
The design process exposes all the holes in your requirements. You discover missing, irrelevant, or grossly mis-estimated stories. With something to look at, everybody sees the application far more clearly. In fact, this is the first time they actually see the application at all.
Now that the stakeholders have seen the designs, the inevitable rounds of changes begin. A good design process should yield important refinements to the product. Which means that by the end of it, the stories are even less relevant.
The solution
Start with UI.
User interface assets (xhtml / css — not photoshop documents) leave very little to the imagination. They are as close as you can get to a working application without actually implementing it.
A good designer (and supporting team) will gather requirements and incorporate feedback throughout the process. All the while, the project stakeholders will be able to actually point and click at the interface, even if it's not completely functional.
So, for application development, the designer belongs on the team rather than as an external resource. They should play a central role in bridging the gap between stakeholders' brains and the development team.
The reality is that designers play that role either way. It is during the design process that the requirements become truly understood. So, come to terms with that, and save everybody a lot of time and money.
