4 ms·

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 usi

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."

dandelany 16y ago
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."
- nostrademons 16y ago
  Arguably, if you work a different way than the majority of users of a product, you'd be better served by a different product.
  - dandelany 16y ago
    Usually, a product which doesn't exist.
- jodrellblank 16y ago
  Then I have an infinitely valuable compiler and empty file to sell you.
- cherring 16y ago
  Of course opinionated software of this nature will not have a workflow that suits everyone. Wasn't that kind of the point? Some people will love, others will not, and they will use something else. Some people just aren't your customers and that's ok, there is someone else that has an app for them.
mindcrime 16y ago
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.
- Retric 16y ago
  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.
  - mindcrime 16y ago
    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.

dandelany 16y ago

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."

nostrademons 16y ago
Arguably, if you work a different way than the majority of users of a product, you'd be better served by a different product.
- dandelany 16y ago
  Usually, a product which doesn't exist.
jodrellblank 16y ago
Then I have an infinitely valuable compiler and empty file to sell you.
cherring 16y ago
Of course opinionated software of this nature will not have a workflow that suits everyone. Wasn't that kind of the point? Some people will love, others will not, and they will use something else. Some people just aren't your customers and that's ok, there is someone else that has an app for them.

mindcrime 16y ago

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.

Retric 16y ago
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.
- mindcrime 16y ago
  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.