4 ms·

I was a bit sceptical when I read the title, but the author raises a good point about calcifying users into suboptimal ux decisions. Wofkflow breaking UI chang

I was a bit sceptical when I read the title, but the author raises a good point about calcifying users into suboptimal ux decisions. Wofkflow breaking UI changes are always hard and there's always someone whose use case [you're breaking](https://xkcd.com/1172 https://xkcd.com/1172). Then again, you can't please everyone and it might hurt to stick with older decisions. Onboarding itself is extremely valuable. No application is so self explanatory that everyone gets it without a guide. When should you onboard then? I'd say when you're sure that you're not doing any major changes within the next few months. All UIs can and should be iterated upon and it helps if you have a timeline on when you're upgrading which views and components and it'll help you decide when to launch the initial onboarsing process.

jimktrains2 7y ago
> Onboarding itself is extremely valuable. As a user, I find them extremely annoying. They stop me from achieving what I want to achieve and I try to get rid of them as quickly as possible. I also find them as the hallmark of a bad UI -- if you have to tell me how to use your product, then it's not well designed.
- dotancohen 7y ago
  > if you have to tell me how to use your > product, then it's not well designed. VIM users, licensed drivers, and pilots would disagree. Powerful tools require training. If you're pushing an app that I'm already familiar with before I've ever used it, then you are obviously not innovating.
  - jimktrains2 7y ago
    Perhaps we're talking past each other? To me "training" is different from "onboarding". "Onboarding" is something that happens quickly and right at the start -- OP links to blogs about building those screens that block the whole UI and point out some buttons. It's something that isn't meant to be all-encompassing. It's something to point out things you wouldn't expect. (That last bit is why I dislike them so much.) "Training" is something that isn't expected to be fast often continuous from the start. It's meant to be fairly encompassing, as in you should be pretty well versed in something once it's finished -- not an expert, but some experience and understanding of the whole. Training is meant to include things that aren't obvious/you wouldn't expect (e.g. steer into a skid), but is (and I would argue primarily) about building a foundation for the UI and for further training and learning. Training also includes practice. Yes, vim has a learning curve and breaks what has become the current UI paradigm. However, I'd argue that unless you're just using vim occasionally, you need to be "trained" on it, not "onboarded". That "training" starts with getting the user to understand the UI paradigm, which isn't expected to be quick. By the end of vimtutor, for instance, the modal paradigm and the ability to chain commands together should be clear and practiced. Driver's licenses take at least 6 months and both a written and practicle test to get initially. Commercial licenses require training from accredited institutions. There is no expectation that this will happen quickly. Driver's training includes practice study (e.g. driving with a licensed person present). Driver's training also included a study of the UI (e.g. signs of similar styling convey similar information, for example green is an information highway sign, white, tall rectangle is a speed limit, and yellow is important such as exit only lane) which is partially tested in the written exam. Ditto for powerful tools, you're not expected to be told "this unmarked button does this" and be left to your own devices. These aren't things you could ever "onboard" someone to do. They require actual training. > If you're pushing an app that I'm already familiar with before I've ever used it, then you are obviously not innovating. That's very judgemental -- innovation doesn't mean confusing the user. Did Google's original/classic UI mean that it wasn't innovative? There are applications that I would argue require "training", even if of an informal type. This doesn't mean that someone couldn't poke around in the application and get something done, but they probably won't be able to exploit the application to its fullest. Two example: GIS tools (i.e. require knowledge _about_ GIS, _about_ projects, _about_ UI and spatial concepts) and Video/Photo editing software (i.e. channels, color spaces, types of transforms, &c). Again, you can open QGIS and GIMP and do something meaningful on your first time, but that doesn't mean you won't feel lost or that it'll be easy.
  - chillfox 7y ago
    As VIM user, a licensed driver, and a pilot, I would like to point out that there’s a huge difference in risk of death and injury between those. Learning vim can be done quite safely by trial and error, then googling for how to do specific things when interested. The other two, not so much. So unless you’re product has a risk of death or severe injury then I will agree that it shouldn’t need training. About planes. Unlike cars, they don’t have a standard cockpit layout which leads to lots of bad design In my opinion.

jimktrains2 7y ago

> Onboarding itself is extremely valuable. As a user, I find them extremely annoying. They stop me from achieving what I want to achieve and I try to get rid of them as quickly as possible. I also find them as the hallmark of a bad UI -- if you have to tell me how to use your product, then it's not well designed.

dotancohen 7y ago
> if you have to tell me how to use your > product, then it's not well designed. VIM users, licensed drivers, and pilots would disagree. Powerful tools require training. If you're pushing an app that I'm already familiar with before I've ever used it, then you are obviously not innovating.
- jimktrains2 7y ago
  Perhaps we're talking past each other? To me "training" is different from "onboarding". "Onboarding" is something that happens quickly and right at the start -- OP links to blogs about building those screens that block the whole UI and point out some buttons. It's something that isn't meant to be all-encompassing. It's something to point out things you wouldn't expect. (That last bit is why I dislike them so much.) "Training" is something that isn't expected to be fast often continuous from the start. It's meant to be fairly encompassing, as in you should be pretty well versed in something once it's finished -- not an expert, but some experience and understanding of the whole. Training is meant to include things that aren't obvious/you wouldn't expect (e.g. steer into a skid), but is (and I would argue primarily) about building a foundation for the UI and for further training and learning. Training also includes practice. Yes, vim has a learning curve and breaks what has become the current UI paradigm. However, I'd argue that unless you're just using vim occasionally, you need to be "trained" on it, not "onboarded". That "training" starts with getting the user to understand the UI paradigm, which isn't expected to be quick. By the end of vimtutor, for instance, the modal paradigm and the ability to chain commands together should be clear and practiced. Driver's licenses take at least 6 months and both a written and practicle test to get initially. Commercial licenses require training from accredited institutions. There is no expectation that this will happen quickly. Driver's training includes practice study (e.g. driving with a licensed person present). Driver's training also included a study of the UI (e.g. signs of similar styling convey similar information, for example green is an information highway sign, white, tall rectangle is a speed limit, and yellow is important such as exit only lane) which is partially tested in the written exam. Ditto for powerful tools, you're not expected to be told "this unmarked button does this" and be left to your own devices. These aren't things you could ever "onboard" someone to do. They require actual training. > If you're pushing an app that I'm already familiar with before I've ever used it, then you are obviously not innovating. That's very judgemental -- innovation doesn't mean confusing the user. Did Google's original/classic UI mean that it wasn't innovative? There are applications that I would argue require "training", even if of an informal type. This doesn't mean that someone couldn't poke around in the application and get something done, but they probably won't be able to exploit the application to its fullest. Two example: GIS tools (i.e. require knowledge _about_ GIS, _about_ projects, _about_ UI and spatial concepts) and Video/Photo editing software (i.e. channels, color spaces, types of transforms, &c). Again, you can open QGIS and GIMP and do something meaningful on your first time, but that doesn't mean you won't feel lost or that it'll be easy.
- chillfox 7y ago
  As VIM user, a licensed driver, and a pilot, I would like to point out that there’s a huge difference in risk of death and injury between those. Learning vim can be done quite safely by trial and error, then googling for how to do specific things when interested. The other two, not so much. So unless you’re product has a risk of death or severe injury then I will agree that it shouldn’t need training. About planes. Unlike cars, they don’t have a standard cockpit layout which leads to lots of bad design In my opinion.