

Ask HN: Should your UX contain 'greyed-out' features? - jdavid

In any given startup you move fast, really fast and sometimes you want to develop good user habits early.  For features that are coming soon, very soon is it a good idea to show a link to them that is 'grey-ed' out?<p>In one sense this lends it's ear back to the under construction signs of the web in the 80s, but a more modern approach would allow you to get early feedback on what users like and don't like about features you are working on now.<p>So I put it out to HN, how do you feel about using disabled buttons, or UX to get early feed back on features that are actually under construction?<p>Are there any clear examples of this being a Win or a Fail on the teams trying it?<p>Does it depend on your customer?  What types of customers might this be a win for and which one's might find it frustrating?
======
destraynor
If you're going to gray out something in the UI (and there are reasons why you
might), here's a few things to remember.

1\. Your users won't know why it's greyed out. Is it currently disabled? Is it
not available yet? Have I broken something? Is it paid only? Is it launched?

Resolve this by explaining why it is grayed out on hover.

Anecdote: We all remember trying to click "Make Table" in Microsoft word only
to find it was grayed out for some obscure reason (Scroll lock was on or
something). Telling a user they can't do something but not explaining why is a
shit experience.

2\. Track clicks to it or hovers on it, it's a good indication of how much
action it'll get, in my experience. If no one is going near the feature, then
chances are it's either not worth building, or it's positioned in the wrong
place on the screen.

3\. Consider bringing it to a splash page where you post a teaser of whats to
come and ask your users what job they're trying to do when they click "Merge
Users" or "Share Reports" or whatever. Just to make sure you're delivering the
right value.

Hope that helps.

Des

(Obligatory: Use Intercom (<http://intercom.io>) to understand user behaviour
and talk to them, this helps avoid a lot of second guessing)

------
will_brown
I have recently read a lot of blogs on this exact issue. After all the points
of view and insight, what I would suggest is show a link to your new feature,
but make it an active link do not grey it out. The key with the active link,
you can measure how many of your users actually click the link and would be
interested in your new feature without having actually spending the
time/money/effort creating it. However, as you mentioned the draw back is by
activating the link to a feature that is not there you will have to post an
under construction page or the mm/dd/yyyy the feature will go live.

------
rekisu
I think it really depends on how engaged your users are with your product and
who you're targeting.

If you have a customer base that is really into your product and the page is
question is aimed at current users, then offering information about an
upcoming feature will be something that's engaging to them.

Conversely you expect the page to help you acquire new customers then it will
just serve as a type of "excess" information.

------
generalseven
Two answers:

\- Theoretical discussions about UX are often meaningless. Create wireframes
and UX test them.

\- Look in UX pattern databases to help you decide what to test. Sometimes
your design choices will have previous significance to your users that are
different from what you intended.

------
lalania
Sounds like a good idea to me.

Tripadvisor does something similar: [http://techcrunch.com/2011/12/22/founder-
stories-tripadvisor...](http://techcrunch.com/2011/12/22/founder-stories-
tripadvisors-kaufer-discusses-the-logic-behind-running-404-tests/)

~~~
jdavid
It seems that data is a core element of the 404-test/ 404-link-test approach.
Would you ever do it without data? to teach a user about a future feature?

------
petervandijck
No.

Because you may change your mind about that feature before you launch it.
UNLESS you're doing a test to measure how many people click on this feature
before building it, but that's a different story altogether.

~~~
jdavid
so data is a requirement for you too?

teaching a user about a pattern is not a good enough reason?

~~~
petervandijck
No because you're just teaching them something doesn't work (yet).

------
zacwitte
As with most things I don't think there is a black or white answer to this. I
think it's OK to have some features that are unavailable if tastefully done,
but it will make your product have an unfinished look to it.

~~~
jdavid
what requirements would you have to implement a grey-ed out feature?

------
SamMorris
It's a real commitment to a feature you haven't made with little reward. The
only reason to do it is if customers are asking for it. If they aren't, you
promise a feature and then it doesn't go in for whatever reason, this sucks.

If you've got a good customer base and you want to let them know you're
working on stuff. I like Freeagent's approach. <http://depot.freeagent.com/>

------
blackant
Meta-question: should Ask HN questions (the primary piece of content on the
page) be greyed out?

~~~
djbrowning
That's always bugged me and I never understood why they're greyed. The
original comment is very important in the context of the discussion below.

------
erictarn
We use greyed out buttons in two ways: 1\. To gather data around interest in
the feature. After clicking tell your user "thanks for the vote you just cast
for this feature, we will notify you when its ready." 2\. To indicate paid
account only features

------
lowglow
Why put in anything that doesn't work? That's bad UX practice in my
experience. It offers no immediate functionality and just serves to confuse
the user.

~~~
jdavid
My gut reaction agrees, but I have seen times, especially at 'telly' where we
were able to do a quick test and prove that users were interested in a
feature.

However in that case we were both watching data and only running the test for
a few hours.

I'm wondering when there are best practices to do this, and maybe when not to
do it.

