If someone opens my videoconferencing product 98% of the time it's they've got a scheduled call to join within the next 20 seconds. They're not going to be late for their meeting so they can read my release notes.
If someone opens my PDF viewer, 99.9% chance they want to view the PDF they just opened. Very rare someone opens the PDF reader because they're just having a look around to see if there are any interesting new features.
If someone opens my virtual whiteboard product, 95% chance they're in some sort of sprint review meeting and they want to write some virtual post-it notes right now. A tour isn't what they need.
If someone opens the ticket management product, or the expense report filing product, or the music playing product... you get the picture.
But they are so common, i don't know who designs them and makes me feel like 5yo.
You gotta understand, people will use the product you made, in a way that makes sense to them, not according to your devised "one way". And that's fine because it allows user to own his workflow using your product.
I like the "checklist" and "load sample data" approach better.
This is primary reason perhaps why my apps are growing fast.
Often these are the product managers building follow-on features that don't get the usage they want. Users aren't using them, but monthly usage is the currency of so much PM work that they have to try to draw attention to it.
Don't get in my face when I'm trying to get task done. Ain't nobody got time for that!
You've got to think and care deeply about what you're creating while at the same time understanding it's of approximately zero interest to those who you're building for outside certain key moments of interaction. Try to just nail those as much as possible and beyond that, get out of the way.
I think this is the core of good design, that things make sense, are nice, and well explained to the point they are even fun to discover and explore when you care to go looking for them. If you don't care to, they're invisible and out of your way.
Guided tour does have its place where the product is a workflow, a platform offering, has bunch of features and you want to introduce the feature to them.
If you are paying 10-25k USD per year, you expect some onboarding specialist who gives instructions on integrating ACH and payroll systems etc. It is very common for non-technical folk to hop on a onboarding call.
People often try to automate that as it is expensive, but i think people prefer that human touch esp. when you are paying alot of money.
While they do make the point about introducing new features, they don’t address how to make an interrupt-driven announcement successful with existing users.
Has anyone seen a good way to make ongoing update announcements
Because their goal metric is number of tasks closed/features delivered (and this counts as one), not customers satisfied.
Plus, social parroting - a misconception that if it's popular and everyone does it it "can't be wrong".
Whose idea was it to show me a “what’s new” popup of all the jira tickets they closed in the last sprint?
What’s new? Nothing is new. It works just like it used to. Just take my money and leave me alone, please.
Every time I start on a new job, I have to click through Slack's, Github's and many other dev tools' stupid guided tours for the hundredth time
Incremental games do an amazing job at this (things like Universal Paperclips, A Dark Room, etc); parts of the game are revealed to you as you need them and it's often a fun surprise. I don't think the same thing is directly applicable to productivity apps, but I wonder if something could be taken from the pattern.
This is timely -- I'm coding an app at the moment and had the fleeting thought that "hey I should do a new user onboarding tour thingy" and then remembered that in general I skip them, so I havne't made one :)
On the other hand, I think it's interesting to compare the dislike in these comments (and elsewhere) to "RTFM" culture. What's the primary difference? That you can read the manual or use the product at your discretion? e.g. `ls` doesn't forcefully open the man page when you run it for the first time?
(I'm aware of the goomba fallacy and that these are likely two different groups of people - I still think it's interesting!)
First thing I do in a new app or new web service is click all the stuff, try and get a lay of the land and understand the UI metaphors. It's much harder to do if there is a twee, condescending guided tour "hyuck hey there champ didja know the gear icon that says Settings next to it is where you can change some settings?" stopping me from doing that, and names hidden behind hover popovers and crappy monochrome SVGs of....shapes to serve as icons.
I am very unlikely to need every part of every tool, app, or service I use. I need to do one thing with it right away, and I need to find my way there and experiment to see how it works. I don't give a shit if I can have it waft my farts if I'm trying to compress a gif or something, the fart-wafter button just needs to be clear so at a time when I go "huh what does this do" I can figure it out non-destructively to see if I'm interested. If you need a big popup saying "We just added the Fart-Wafter! Want to know how to find it?", you've failed, utterly.
The other side though is sometimes even more important it's what this thing does as a high-level introduction so you can understand all the things you're supposed to be able to do depending on the software this is some sometimes not obvious and that explanation can be really helpful to understand all the things you're supposed to be able to do and thus plan to use all those features.
Plus, there's no way I'm going to remember whatever the tour tells me by that time anyway. To actually learn the product you need experience to lock in what the manual says
1) Push vs pull. As you identified, ls doesn't stop you from doing the thing you wanted to push the man page on you when you don't need/want it. ls just does the thing you ask. man also just does the thing you ask. The product tour is a sign that the developer doesn't understand consent and is trying to get the user to do what the developer wants, not what the user wants.
2) It's infantilizing. The product tour assumes the user doesn't know what they want, and doesn't know how to RTFM to learn how to do the thing they want to do. It treats the user as having no agency.
2.5) It's a tacit admission that TFM sucks and R-ing it isn't a productive use of your time.
In the US engineers don't get that ring and they implement product tours.
Popups are a great way to get your content ignored.
Imagine you walked into a convenience store and the owner was like "Hey you need to take the tour first!"
I can't think of a single time I've looked at a product tour and thought "well, I'm really glad they told me that, I never would have figured that out.
What the product tour I think often misses is that people don't want to learn your entire tool at one time.
They came to do one thing, that one thing needs to be brain dead simple.
Over time, you can show people what else they can do. But a product tour isn't the way to do that.
I think progressive UIs where you expose more and more to the user over time is the way to go.
If you're thinking "but I have so many features and capabilities this person needs" you probably haven't identified what the one thing people are paying you for is.
Just a couple examples offhand..
Discord (constant tooltips covering the screen to harass me to try "Nitro", or some new AI BS I am never going to even remotely consider trying)
Miro ("Sign in with Google" modal in the top right, "CANVAS 26" conference signup site stripe covering the top of the screen, frequent "What's new" modal covering the entire app, "How likely are you to recommend this product or service to a friend or co-worker?" net promoter score survey covering the bottom of the screen, which makes zero sense whatsoever as an enterprise user)
JIRA ("Try dark theme" tooltip covering the top right of the page)
Figma ("Reconnect with Community" tooltip covering some content on the left)
Too bad I didn't get to work there for long but I loved their stance that everybody should personally make safety the first priority, not just because the company requires you to do so but because your safety really is your priority.
So yes, this was before 2014 but I still think these kind of "training" and feedback should be a two way street, not a series of next I have to press to get the software to shut up.
They'll be reintroduced under a new name in a decade or two with endless self-congratulation. Same as physical car controls.
Here's a solution off the top of my head: have a dedicate "info" button at the OS level. Holding the button disables normal interaction, highlights all inspectable elements, and allows you to click on each one for a description. Like "inspect element" in the browser.
This is a really cool idea. Agreed! Wish something like this actually existed.
I've got a task to accomplish, I wasn't just sitting around with nothing to do.
Imagine you get in your car to drive to work, and the dashboard displays a pop-up that tries to show you the latest feature. No!
after that its determining how people to digest info, some like docs (me), others want to sit thru a video, others NEED a person to guide them in person, some like tooltips, checklists, etc.
i'm not saying you need to litter your app with this stuff, but i don't think there is some magical UX pattern that always works.
The best UX is using obvious and standard design, plus a searchable menu / command palette.
And the other reason is because most users probably have day jobs and need to get something done.
but this time, make apps actually respect it :)
Or better: tie it to an OS-level screen-reader AI that explains what's what's on the spot.
Why most ads on Youtube gets get skipped
etc etc
Atlassian is particularly enraging, especially if you're dealing with setting up "new" accounts. I've worked with your shitware for a decade now, I know how it works, DO NOT FORCE ME TO MAKE TEN CLICKS TO GET RID OF A FUCKING INTRO.
Rather, invest your time into a good, logical UI and, most importantly, good AND CURRENT documentation.