4 ms·

This is a great article and it covers almost all the bases. The only thing I'd add is a discussion of UI refactoring. Over time, creeping featurism tends to tak

by mrshoe 17y ago

This is a great article and it covers almost all the bases. The only thing I'd add is a discussion of UI refactoring. Over time, creeping featurism tends to take over. Your users will request every possible feature and your marketing department will want to add more check marks to your product's column in the feature matrix. As this article points out, you have to be the bad guy and Just Say No most of the time. However, when a large subset of your users request a certain feature, the best response is often to refactor your design. Don't just add the feature. Figure out why they're requesting it. In other words, figure out why the current design is lacking. At that point you can come up with a new design which lets your users accomplish what they're trying to do. User interfaces age like code bases in this way. If you keep adding to them, they get really ugly really quickly. If you instead take the time to refactor them, they can remain beautiful while becoming more capable.

gnoupi 17y ago
Fully true, but how many times you will be able to justify that refactoring to the ones who asked ? Most of times, all they want in a "fast, small new important feature to put in a new menu item". It's hard to make them realize that because you add new features, most of times the dynamic of the UI has to be rethought. And it ends usually in an application with countless menus and modes even for these menus. So redesign is important, but how do you justify to your marketing (or head programmer) that they have to "pay" for a redesign of what they "paid" already months ago, just for one feature ?
- megaduck 17y ago
  Refactoring doesn't have to be massive. Perhaps you can get by with a subtle tweak, so long as it's well thought out. Alternatively, if adding a feature demands a massive refactor, then it might be a warning signal that you've got some fundamental issues with your UI. In that case, it might be worth it to spend the time re-examining the core design of your app. You also might refuse to support that feature. Being able to say "no" is an important skill, both as a designer and a developer. Leaving stuff out is often as important as putting it in.

by mrshoe 17y ago

gnoupi 17y ago

Fully true, but how many times you will be able to justify that refactoring to the ones who asked ? Most of times, all they want in a "fast, small new important feature to put in a new menu item". It's hard to make them realize that because you add new features, most of times the dynamic of the UI has to be rethought. And it ends usually in an application with countless menus and modes even for these menus. So redesign is important, but how do you justify to your marketing (or head programmer) that they have to "pay" for a redesign of what they "paid" already months ago, just for one feature ?

megaduck 17y ago
Refactoring doesn't have to be massive. Perhaps you can get by with a subtle tweak, so long as it's well thought out. Alternatively, if adding a feature demands a massive refactor, then it might be a warning signal that you've got some fundamental issues with your UI. In that case, it might be worth it to spend the time re-examining the core design of your app. You also might refuse to support that feature. Being able to say "no" is an important skill, both as a designer and a developer. Leaving stuff out is often as important as putting it in.