I've got over 16 years of game development experience creating art and writing tools for artists, and have recently been training technical artists to fulfill the growing demand for people who can fill the growing divide between programmers and artists. While doing this I found had to explain the insights and practices that I had spent the last 15 years developing. Some of this had to do with coding techniques and tools architecture, but I found the most of the coaching I was doing was around communication.
An enormous amount of time in tool development can be spent solving either the wrong problem, or as I have found through hard personal experience, problems that don't even need to be solved. What I ended up sharing with the technical artists was the thought process I went through evaluating all the tools requests being made and how I went about resolving them. And that is what I'm going to share here.
What's the problem here
Superficially this is trivial, the artists request a feature change or a new tool and it yours job to make it for them. The artists know what the problem is, they are using the tools on a daily basis and know better than you what problems they are having. The artists will also know if the solution is satisfactory. What they don't always know is how to get from where they are to where they need to be. If they did know how to do this they would most likely do it themselves and not even bother a technical artist.
So the first thing you need to understand is, what is the problem that the artist think this tool will solve. If you don't understand this how can you deliver a tool that will solve the problem. While this may appear stupid obvious I have been guilty of failing to do this step in the past and solving the wrong problem.
Secondly you need to understand what they think the solution will look like and how they intend to use it. This is a potentially big place to screw up. As the Technical Artist/Tool Programmer you why you can and can't do somethings, to the artists they don't know why and usually aren't interested in why, but they know what they want. Understanding what they think the solution will look like will help guide your technical solution to match their need.
The third thing which is easily over looked is how this fits inside the over all art content production. It's not enough to understand what tool they want and how they want it to work, you need to understand how this tool fits in with their production practices and the other tools that they are using. your tool rarely exists in a vacuum and it needs to work with the existing production practices.
Knowing the answers to these three things is absolutely critical before you start developing your solution.
