Identify contact for workflow improvements.
Pre-load your contact with expectations for gathering information. Let the contact know you want to help them but will need specific information related to their needs.
Identify users. You will want one contact but Ideally you can get feedback from more than one source. Ask your contact who else might have useful information. You are probably developing workflow improvements for more than one user so it is important to get feedback from more than one user.
Keep an open mind about what are valid workflow improvements. Just because you are told your users need "A,B,C" they may be unaware that "D,E,F" would be more beneficial. What they need the most may not be something you can provide but it is still valuable information you need to pass on and follow-up on.
Sometimes users can not identify where they need workflow improvements. So you need to describe the type of stuff you are interested in:
Pain points
Time consuming tasks
Redundant tasks
Tasks that require multiple button pushes
Task that require user to go back and forth to different software a lot
Parts of your workflow that make you unhappy
“If you had a magic wand what would you fix about you workflows”
Sit down at the user's desk and have them show you what their workflows are. Sometimes you can see things they can not.
After you have an idea about what problems exist organize them in an informal doc, bullet points are fine here. Have a meeting with some of your users based on your doc. Say this (your doc) is my understanding of your needs. During the meeting confirm your assumptions about workflow improvements and prioritize options for improvements.
Write down your findings from the meeting and send it off to your contact and other stakeholders. Make sure you understand each need and its priority. You may have to iterate here a couple times to make sure your assumptions are correct.
Once you are sure you understand your users needs are sit down and organize each need into possible solutions. Each solution is the beginning of a possible TDD.
Outline what each solution is (again bullet point are fine):
What is the problem
Why is it a problem
How much time does it take (this will translates into $ for producers and executive types)
What are the possible solutions (there may not be a lot of solutions)
What is the cost (time) of each solution
What is the effectiveness of each solution
What is the complexity of each solution, how many systems will it touch? Will you need engineer support…
What is the outcome of each solution
Show the outline of each solution to stakeholders and use it to make a decision about what work you need to do.
Write a TDD based on what solution is chosen. Keep in mind you will be making a lot of assumptions. Try to add steps for success or failure in the doc. “In order for me to be successful in this task i will need to do A, B and C. If it turns out i cannot do B i will have to fallback to D which will take more time..”
Shop TDD around and get feedback on it
All of the above is to establish a good definition of what you are doing and to set expectations for users and management.