In everything I do, I try to keep the goal in mind. Focusing on the outcome now comes quite naturally to me, but I’ve noticed that what I now take for granted, others seem completely oblivious to. And this goal-oriented thinking is applicable to most undertakings.
- When you’re reading a (non-fiction) book, focus on what you want to learn and retain from it, don’t just flip through pages mindlessly. Reading a book isn’t a goal in and of itself, but a means to acquire knowledge and competence;
- When you’re designing new software, think “this is how the solution should behave and look like”, and NEVER “this is what I can do with my current skill level”;
- When you’re designing a user interface, think about what makes most sense for the user (depending on their knowledge/competence levels, the context they’re in, etc.), don’t simply implement the interface that maps best to your code base (saving yourself work).
This takes willpower, since it requires an additional effort investment (including possibly acquiring new skills). My (admitedtly simplified) theory on software complexity is that it depends more or less linearly on features (quantity and size/scope). But with a given application complexity, I believe code base complexity is proportional to ease of use for the end user. Put another way, the simpler your code base the more trouble your users will have using the application.
Naturally, this doesn’t mean that spaghetti code will magically produce a self-evident interface. Rather, it implies that in order to provide a streamlined interface that is as easy for end users as possible, you’ll need to shift complexity away from the user and into your code: provide conditional tool tips, don’t show unnecessary info or controls, etc.
The simple fact of the matter is that we currently have better tools to manage software complexity than we do to manage the infinite skills levels and backgrounds your users may have: refactoring and tests will be your closest friends along with UI testing.