Hacker News new | ask | show | jobs
by jafl5272 5855 days ago
Users work in an infinite number of different ways, and they way they worked before they use your app is probably forced by whatever crap they are currently using.

No matter what you do, you end up forcing a lot of people to learn to work the way the app wants them to. The best you can hope for is to build an app where, once it's explained, most users first go "Oh, ok, that makes sense." and then actually remember it later. If you're really good, the users will even say, "Wow! That's much better than the app I used before."

2 comments

This assumes a one-to-one relationship between pieces of software and workflows, which is absolutely incorrect. Just because you design a piece of software to be used in a certain workflow does not mean that that workflow will work for everyone; software which allows users to configure it to fit their individualized problems and processes is infinitely more valuable than software that tells the user "it's my way or the highway."
Then I have an infinitely valuable compiler and empty file to sell you.
Arguably, if you work a different way than the majority of users of a product, you'd be better served by a different product.
Usually, a product which doesn't exist.
Ok, sure, you have to draw a line somewhere. Point conceded. But the position taken by the parent article seems to be pretty close to "don't make a damn thing configurable" and that is a position I think is flat wrong - for many classes of software.

Then again, my interest is more in complex, multi-user, enterprise systems, where you are likely to have more varying forces at work (integration with other systems, needs of different classes of users, etc.) than something like, say, a TODO app for ones iPhone.

I have yet to see a highly complex piece of enterprise software that people actually liked to use. Honestly, I think the current state of enterprise throw everything and the kitchen sink at the problem software just demonstrates the downsides of a complex and highly configurable system. If you don’t know what people will be using it for then you can’t build a streamlined system.

  I have yet to see a highly complex piece of enterprise 
  software that people actually liked to use. Honestly, I 
  think the current state of enterprise throw everything 
  and the kitchen sink at the problem software just 
  demonstrates the downsides of a complex and highly 
  configurable system. If you don’t know what people will 
  be using it for then you can’t build a streamlined system.
True, true. And that's why I find articles like the parent useful, because they do serve to remind use that we should strive for simplicity... That is, while I may largely disagree with what seems to be the "logical conclusion" of the article, I don't disagree that things should be, as they say, "as simple as possible, but no simpler." And since I am working on some "complex, enterprise software" - and being aware of how notorious this kind of stuff is for NOT being friendly and easy to use - I feel drawn to try and break that trend by making things that are both powerful and flexible, but without being confusing and difficult. It's a difficult balance to strike, and I don't claim to have all the answers, but at least acknowledging the problem and having that as a goal is a start, I think.