Some thoughts on tool dev


Some recent issues I’ve run into lately have sparked some thoughts on tool dev:

Firstly, when you’re developing tools for many people on different teams you need to get input from all the teams and individuals. Some tool concepts and functionality may work for a larger group, but may cripple the smaller group’s workflow. For generalized tools that are one off tools you may need to say that the smaller group has to fall to the way side and just continue using the ‘majority rules’ mentality. However, if the new tool is intrusive, changing normal functionality of the software, you HAVE to cater to all groups. You also should (read have) to make it an opt-in process.

Recent activities by Facebook and Google regarding new features and security settings illustrate the point well but particularly Facebook. If you change or add a privacy setting you should have it act as it did before while giving the users an option to activate it or allow it. Its fairly obvious why Facebook does this as their business on selling ads is based on sharing your data. Many people go and disable it automatically while others oblivious to the change carry on and unknowingly share their data. Not good and not legal in my eyes.

This is a practice you should stay away from. If you say, build a tool that overrides the default key mapping for the application and force it on people and disabling their existing ones, it’s going to be a pretty invasive and opaque to the end users. This should not be the case. While you could add an option to disable this to solve the problem, it is still opaque to the users and takes effort to find out how to do so. Like-wise, the function to do this needs to be as global as possible. Don’t make users go through tons of settings to disable all the changes.

Make 1 toggle to turn it on. Leave it off by default and educate people on the benefits of turning it on and how it may affect their workflow. Your users, leads, TD’s, and all will love you for it silently.