UX of home-cooked software

I’ve been recently thinking quite a lot about the development and design of user experiences for home-cooked software. If you’re not familiar with the term, it refers to non-commercial software that’s built to solve the problem of the developer and maybe a small private group of users. You can read more about it from the link above.

When I build software for myself, I can make a lot of shortcuts when it comes to user experience and user documentation. I know how to use my tools so I can save time and effort in skipping the parts that I know how to use.

On the other hand, I also like to share my code and my projects so anyone else can either use them or take the code and learn from it or develop something for themselves. And when I do that, I start thinking about the responsibility of building good user experiences. Sometimes that work benefits myself as the user as well but often it’s just polishing something for other people. And in this case, if “other people” use these specific tools, it’s completely by accident and not as a targeted audience.

I know I don’t have to do any of that work but something inside me keeps nagging if I don’t.

Maybe it stems from my background as a junior athlete: when you do sloppy in practice, you do sloppy in competition. You want to always maintain certain level of execution to reach the proper level in situations where it matters; in this case when building real production grade software.

Maybe it stems from insecurity towards other people’s opinions. “What if someone comments on my bad UX?” This is also related to the idea that what if someone looks at these projects when I’m applying for jobs and makes judgements based on them.

I work very iteratively when I do software development and when I build tools purely for myself, as soon as it functions and helps me save time or achieve my goals, my motivation to polish and do minor improvements drops drastically because I know 100% of the users are already satisfied with it. And yet, the self-critic keeps yelling at me to get back and fix small inconveniences and polish the work.

I’ve been working on my own Stardew Valley Mod Manager and I want to publish it one day but once I reached the point that I can manage my mods with it, I’m willing to put up with some slowness and quirky workflows because I know them and I know how to work around them. It’s in no way in a shape where I’d feel comfortable giving to another person to use so it needs big refactorings and improvements but at the same time it has already solved my problems. So all development from now onwards would be about making it more polished so I’d feel more comfortable showing it to others.

One thing I do often focus a lot on my own projects is the technical/admin user documentation. I have a bunch of tools I’ve built that I use either once a month or once every three months. Since I can’t remember what I need to do with each, I’ve built command line utilities and written extensive documentation to make sure I don’t have to remember things by heart.