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?

  • The Nintendo 3DS had just this thing when they released it in March 2011 with an Internet Browser icon in its OS, but tapping on the icon merely said that the browser would be shipped at a later date (it was shipped with the 2nd OS update in June 2011 IIRC) Commented Jul 9, 2014 at 16:08
  • 1
    It seems like a good idea to announce upcoming features to users, but to put the announcements in one place (e.g. a Coming Soon page with a bulleted list of what's on deck) rather than making it unclear in the UI which things are not actually features yet.
    – asfallows
    Commented Jul 10, 2014 at 17:51
  • 2
    I really personally hate this. Please don't do it. If there's no feature - there should be no reference to that thing of imagination. Commented Jul 11, 2014 at 8:52

10 Answers 10


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.

  • 5
    I agree with James, this is a very poor idea, leave the link off and if you must tell users of something coming soon do so in a blog or news post. Commented Jul 8, 2014 at 10:18
  • 9
    Agree. IMHO the only acceptable reason for "teasing" users is if's about an existing feature that requires special privileges (registered/paid account).
    – msp
    Commented Jul 8, 2014 at 15:06
  • 2
    @msparer Yes, and even then, it feels disappointing if you have to try to use a feature to find out you can use it - possibly showing a full page advertisement for the paid version instead... Commented Jul 8, 2014 at 19:19
  • 2
    This classic article (from the co-founder of StackExchange itself) also provides some insights into the minds of nonprogrammers when it comes to UI vs features. A good read in any case!
    – jmiserez
    Commented Jul 9, 2014 at 1:00
  • @msparer: I personally would feel much more annoyed by being "teased" about an existing feature that requires special privileges than about a non-existing, but planned feature as long as that's in a beta (or otherwise explicitly non-final) version. Commented Jul 9, 2014 at 5:45

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.

  • In some organizations, if the user is outside the organization and unsupervised then it's by definition not an alpha. Even if it's a really half-assed beta, any external release is beyond the alpha-testing stage. That said, the use of the terms "alpha" and "beta" is pretty idiosyncratic. I don't think you can really assume anything about the meaning of either term other than, "we know it has at least some problems". Commented Jul 11, 2014 at 9:00

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.

  • 1
    By the time you have showed it to users and basically said "coming right up!", you can't realistically decide to pull that feature. You've promised it to your users, so even if only a few users actually try to use it, those users will be really disappointed if it just completely disappears.
    – user
    Commented Jul 9, 2014 at 13:04
  • Depends how many users you're disappointing I'd say. If I'd got a feature planned that I think 40% of my users will like but only 1% actually clicked the link, I'd rather disappoint that 1% than spend money developing the feature. Might not be great UX but is still a valuable feedback tool.
    – Ben
    Commented Jul 9, 2014 at 13:17
  • You could also develop a first revision of the future, and see how many use it. That way, you can also see how many keep using the feature. That too can provide very valuable feedback.
    – user
    Commented Jul 9, 2014 at 13:29

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. ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.