> Sketch solution(s). Throw away sketch. Tests. Final solution. I think it's worth pointing out that this has been my interpretation of the general approach th

> Sketch solution(s). Throw away sketch. Tests. Final solution. I think it's worth pointing out that this has been my interpretation of the general approach that XP originally took many years ago. If you know the general design that your story should take, you do a test first approach using your knowledge of what you are doing as a guide. However, if you don't have a good idea of the best approach to take, you "spike" a solution, throw away the code and then use test first to develop the "final" solution (hard to say "final solution" in XP, so I hope people understand what I'm saying here -- the solution that will be refactored over time as opposed to the solution that will be rewritten ;-) ). As the sibling thread pointed out, though, "test first" in the TDD sense is an iterative process and usually you write a test, satisfy it, write another test, etc, etc. You wouldn't want to write all your tests up front because it would constrain your design too much -- and then it wouldn't be "test driven", even if it is good ;-). I find it especially interesting that you use the word "sketch", which is exactly the same word I use. For me the activity is based around trying to get my head around the basic composition in the design. But like you say, if you are unsure about the UX workflow, just banging out some code and looking at it can make you realise, "That work flow is just not going to cut it because it doesn't use/generate the information I need".