Striving for Quality
Building effective and resilient software is hard. Building software that is a joy to use is even harder. Software developers and their teams manage a number of goals and often struggle with meeting them, whether it's business goals, making deadline/budget, finding the right talent, avoiding technical debt, etc.
All of those goals are important, but none of them trump creating usable software. Being usable is simply the lowest bar. Any lower and the product will simply fail. Does your app annoy people? Do users have to trudge through mud to do even the simplest of tasks? Questions like this can lead us to great reward, if we would only spend the time it takes to resolve the problems uncovered.
Developers seem to have a blind-spot and a particular endurance for clunky experiences. We understand what it took to make. Even a few mis-steps can lead us down a path where our app becomes frustrating to even look at. And while we can have sympathy towards others who build software, we cannot expect this of our users. They deserve better and shouldn't be burdened with our struggle. We've got to be better than that. Especially for developers just getting into the field, we have to give them principles to uphold and an image to strive for. We have to show them what it takes and what it really means to do development well.
True quality can only be achieved by deep understanding and collaboration with our colleagues outside of development, but we need to control how we work and be firm with our principles. This is what it takes to create truly gratifying software.
Introducing Technically UX
To help developers strive towards this goal, I'm starting a newsletter, Technically UX. We will be discussing what it takes to build better usable software and introduce a new topic called technical UX. Technical UX is a whole class of problems that fall under developers' responsibility that range from foundational issues like poorly performing architecture, all the way up to final polish issues like optimizing animations. It's part of what separates the good developers from the great and often part of the reason why we fail at making usable experiences.