The final empathy area I want to discuss is process and tooling. Who are we doing this for and what tools we’re using to develop
There are three groups of people we should empathize with: Fellow team members, External developers who use our code and the end users of our product.
Our fellow team members are typically the smallest group (some times it’s just us), but they are most affected by the code we write. Because we share the same context it’s easier for us to write code that they can work with easily. If we miss the mark here they will most definitely grill us with feedback and suggestions for improvement. If it’s just us we can certainly make the changes to improve the project.
The final group affected by our code is our end users. These are the people using applications that developers (internal or external) create. This is usually the largest group of people our code will affect, and they probably not developers and doesn’t share many contexts with us. While we may never interact directly with end users, we need to consider how our code can help the integration of features, including – but not limited to – full accessibility and perceived performance.
Tool chains and tools
Another way to make things easier for developers and, eventually, end users is to provide good tooling for the tools you create.
One thing I’ve always loved about tools like NPM, Yeoman, Polymer CLI, Imagemin and other command line tools is that they are very clear in what they do and what they want the user to do to configure the project using the tool. They also give you ways to edit or overwrite the configuration files created in the CLI so you can change the way the tool behaves when it comes to building the application.
Make it as easy as possible for users who are using your tools. Provide documentation and remember that the user of your project may be you in six months and may not remember how you implemented it.