I'm working in a startup and we're building a web based application. Not all our features have been implemented yet but we want a way to tell the user that they'll be there one day.
Our current approach is to leave the buttons or links that fire the action and just display a message like "Dear beta user this functionality is not implemented yet."
Is it too confusing for users? What is the best approach to tease them?
Quite simply don't do this. False expectations are the biggest source of a disappointing experience. It commits you to features that you may not be able/want to produce, users will assume very short timescales for this functionality to be in action, and it also highlights your apps weaknesses leading users to look for these elsewhere with your competitors.
If you absolutely have to add teasers, make sure that it is clear at the beginning of the path that the feature is not implemented. There is nothing more annoying than putting in some effort to start a process only to have the rug pulled out from under you.
People often want to put some form of "under construction" messages in their UI, because when you're making something new you're enthusiastic about its potential and want to communicate that enthusiasm to your users. But if you think about this from the user's point of view (which is the basis of good UX), it's not a good idea.
Highlighting new features within the UI can be helpful and rewarding; highlighting features that you don't yet have is a distraction at best, and at worst it tells users to just come back later when the application is finished. Plus, you're making yourself a hostage to fortune-- these "under construction" messages have a habit of sticking around far longer than planned, which can make a project look abandoned.
Basically, the best way to show users the features you have planned is to implement them. If this is a beta, you can deploy features before they're 100% polished-- but 0% is premature.
What you describe is reminiscent of the popular "lean startup" idea of building a skeletal app or website which is known as an MVP - minimal viable product - and seeing who tries to use which features (including the 'sign up for paid account' feature) before you build them. You could potentially use this to your advantage to, say, figure out which features to light up first (those that have the most clicks). This is not a user-centered approach, so it depends on your goals. Since you are posting in a UX forum, perhaps you care a lot about UX and maybe prioritize that higher than optimizing other aspects of your business at the expense of puzzled (or frustrated) users.
As an example of an established company that does this, consider cable TV. My cable company gives me the privilege of wading through all existing channels - even those I don't subscribe to. So when I navigate to one I don't subscribed to, I waste a little time and get treated to a "buzz off or pay us more money" message. Doesn't make me any more productive, doesn't make me want more channels, and doesn't make me happy. More to the point, it continually makes me think about getting rid of cable because they clearly will take my money, but will not spend/invest any of it to improve MY time and enjoyment and productivity. (Thanks Verizon!)
I know your app is not like cable TV in that your features are "coming soon" (and are maybe for everyone, unlike cable TV pricing tiers), but unless you can turn the "coming soon" from wasting users' time and being annoying into being fun and leading users to anticipate excitedly, I'd be careful.
If you can't decide, try a usability test and observe the reactions.
During the beta phase only, how about a pop-up which says "We're thinking of implementing this because..." along with vote-up/down buttons? That way you are able to gauge the interest in a feature as well as making your beta users feel engaged in the product development. It might also help to break the feeling of entitlement which a "Coming soon..." message would create.
As long as the site is in "real beta" (as opposed to eternal beta): Grey out the links / give them a distinct color, and provide a mouseover that says "We are working on it!"
I agree with the other replies that you should not wake false expectations.
OTOH, advertising your current spec could greatly improve beta feedback, both by reducing the the "without a big big button to globurgate the fudibii, we'll never buy" and enabling early "the globurgate button should be on the main screen".
I recently found the GalCiv III Alpha handling this very well: a splash screen explaining the alpha state when starting the game, and planned features already advertised, with obvious feedback that this will be here, but isn't yet.
This might not be a good idea to tease users, but as long as users are aware they are using a non-final version, this can be an important reassuring factor. Important (not for the core functionality of the application, but for the workflow of the user) features may still be unimplemented, but showing them already tells the user that they have been thought of and even if the program cannot currently be used conveniently for what they have in mind, it is worth the effort coming back later to check again.
However, you need to keep in mind that if you fail to deliver any of the thusly announced features, this will fall back very badly to you. In that respect, it is hardly any different than announcements about features for the final version outside of your application, e.g. on your product website.
In conjunction with such in-application announcements, it may be worthwhile to frequently release new beta versions. Especially if we are talking about non-trivial features, those probably deserve a beta phase of their own and should not just appear out of thin air when the final release is ready.
I think it might depend on your user audience as well. If they are early adopters or say Kickstarter supporters in a closed beta, it might be a good idea to use a process similar to this in certain places to indicate where development is progressing. I wouldn't do it too far in advance however because of the possibility that you might portray a feature as something that will never arrive if you do it too early.
If we're talking about a public beta, I don't think including messages like this or buttons that don't function into the application is a bad practice when it comes to UX. It will only frustrate and confuse users who may not have an vested interest in your project. This could harm future sales.
There's also an argument if you should be adding major features to a beta application though. Beta is normally a testing period for the final product. After the beta period it is released. If you are still adding major features, maybe you're still in the alpha stage of your product.
I'd say it depends on why you're doing it.
Adding a way to access a feature you haven't yet built isn't a great experience for a user who tries to access it but it can give you some really valuable feedback about whether people will actually use it if you track how often people click it.
It is sometimes better to discomfort a few users for a week or two than it is to spend big bucks implementing a feature few people actually use.
thats a nice idea, but don't overdo it because it might be frustrating to the user to see a lot of controls that are disabled.
added to that message you could link the user to a page that shows off the features coming up in the next release.
First thing that comes to mind: those annoying buttons that, when you click on it, it tries to sell you a "gold" membership (or similar) in a free app with ads.
At least grey them out/don't do anything when clicked on. Best: just don't include them! If you want to tell users you are working on a feature, a blog post may be better. Most people don't really care about such things; the ones that would care might look at the blog post. If you're afraid it won't be seen, try a little message in the corner. I wouldn't have a non-intrusive message in the corner for the first few times they visit the page. Make sure it's easy to dismiss and goes away after a bit in case they don't notice they can remove it so users aren't annoyed.
If you want to put the buttons in there just to figure out layout, I'd just add them and comment them out in the HTML. If that would mess up the margins/padding, chances are you could improve your code. ;)
