Why You Should Stop Using the Go Button for Search

by on 09/20/10 at 4:03 pm

Many websites offer users a search bar to make it easy for to find content without browsing. This saves users time and effort. But it doesn’t do that when the search bar uses the ‘Go’ button for search. This creates a noisy, unnecessary mess that does more harm than good. There is a simple and clean way to do search that’ll make searching for content faster and easier.

Why You Should Stop Using the Go Button for Search

By using a ‘Search’ instead of a ‘Go’ button, you remove the need for other labels. The ‘Go’ button doesn’t describe the user’s action clear enough, so it needs an extra ‘Search’ label. This clutters the search bar and makes it harder for users to process.

Also, the word “search” has more characters in it than the word “go”, which makes the button bigger and easier for users to click. Another advantage to using a ‘Search’ button is that it makes the search bar narrower. This allows you to place it in the top right corner without interfering with site content or logins.

When you include unnecessary elements in your search bar, it makes doing a search that much slower. Not only that, but having more elements decreases aesthetic appeal. It’s best to seek the simple approach that not only looks appealing, but enables users to find what they’re looking for fast.


Why You Should Stop Using the Go Button for Search Why You Should Stop Using the Go Button for Search

Author and editor-in-chief of UX Movement. Loves great web experiences and fights for the user.

59 Responses to “Why You Should Stop Using the Go Button for Search”

  1. Alex

    Sep 20th, 2010

    Why not just get ride of the button altogether?

    Just hit enter and the search will happen.

    • anthony

      Sep 21st, 2010

      There are potential usability issues with that, but that mostly depends on your users. If you have a tech and web savvy user base they’ll understand that hitting enter enables search, but not all users do. So, if you have a site with a range of different types of users then its best to include a button.

      • Aurélien

        Sep 21st, 2010

        Why doesn’t UXMovement have a “search” button next to it’s search field then ?

      • Sunny K

        Sep 21st, 2010

        I agree with Anthony. Many users don’t know that enter works instead of the click..

      • Umanka

        Sep 21st, 2010

        I agree that there should be some kind of visual clue next to the input field which shows the submit affordance. (btw this site does not have any button next to the search field)

      • panaghia

        Oct 2nd, 2010

        “Potential” is the right word: it would be interesting to test a kindly feature (no search button) giving a placeholder text like “type and press enter” or a google-like instant search

    • Florent V.

      Sep 21st, 2010

      Not all users with access to a keyboard know that you can hit Enter to submit a form.
      Not all users have access to a keyboard (smartphone, tablet computer, etc.).

    • B

      Sep 21st, 2010

      Yep, leave nothing to chance in the UX realm. I’d like to see some testing data on this but these are well made points. While “GO” is compact and common, “Search” better conveys the intented function. Thanks for sharing.

  2. Matthew

    Sep 20th, 2010

    What about a search icon (magnifying glass)? Then it’s language independent.

  3. Yofat

    Sep 21st, 2010

    Great tip. I have actually been looking around for tips or tutorials detailing how to create a custom simple search engine for a website. The google ‘custom search’ add on is very convenient, but is very generic. Would you be able to point me in any directions :) ?

    • Aidan

      Sep 24th, 2010

      Apache Solr is a popular open-source, free choice for a site search engine. It offers a simple RESTful API and good performance. However, it doesn’t have the best documentation. Here’s a link:

      http://lucene.apache.org/solr/

  4. Dave

    Sep 21st, 2010

    How about pre populating the search field with an indicator ie What are you looking for?

  5. jDesai

    Sep 21st, 2010

    Well, if one is making a site for advanced computer users, the button is not needed at all. People can rather hit enter. To target a wider audience however, the ‘Search’ button is the best option.

  6. Kawika

    Sep 21st, 2010

    You make a good point! It makes sense to label the button with what it does.

  7. Fuzzybug

    Sep 21st, 2010

    Any plans to do that with UX Movement? I see you have no visible submit button at all? Also from a technical point of view the label should still be present just positioned off the screen to satisfy accessibility requirements and ux for all users. May be also some place holder text in the input field box wouldn’t go a miss that disappears when the field it’s focused upon.

  8. xonic

    Sep 21st, 2010

    Seems reasonable. The only thing I’m wondering about is what happens with the text field label element. Since Accessibility guidelines require every text field to have a label right in front as far as I know, I’d like to know if you just hide it via CSS or maybe do something else? Or maybe you could provide a code snippet? That’d be great! Thanks

    • Stomme poes

      Oct 28th, 2010

      @xonic
      For screen readers, at least, you can use a title attribute on the input itself. One place where titles tend to always be read out is in forms.

      For the sighted, the button doubles as a label.

      But, there’s still linear-browser-users who won’t get the title and run into the input before the button… so because those cases exist I’d possibly still have a label, pulled off-screen with CSS. Even in Lynx I don’t need the label, and even a screen magnifier user is likely to see the button at the same time as the input field.

      You can match the Accessibility Guidelines with pre-filled prompt text in the input, but that has two issues: either you’re adding it with Javascript, which the user may not have, or you have it there and maybe remove it on-focus, which again means more work backspacing for users without Javascript. HTML5 has a “placeholder” attribute but that’s a ways off in cross-browser cross-UA implementation.

  9. Nico Amon

    Sep 21st, 2010

    I am agree with this.. Shouldn’t use anymore

  10. Juho Vepsäläinen

    Sep 21st, 2010

    Good point!

    I guess the modern way is to implement a nice ajaxy solution that eliminates “search” button altogether. I can see this won’t work without JS but if you don’t have JS related constraints imposed on your design, why not.

    • Stomme poes

      Oct 28th, 2010

      @Juho then it had better be one truly amazing web application… and as big and as popular as the broken sites people put up with like Facebook and ebay. Search is a fundamental function on websites who offer it… meaning you are taking away something important from those scriptless users.

      Have a search form, let the JS remove it and replace with ajaxy stronger-than-dirt-ness. Everyone happy. : )

  11. AnthonyTerrell

    Sep 21st, 2010

    I totally agree with both @Alex and @Anthony. I personally would love to just get rid of the search/go button. Make some place holder text in the input box that says such.

    But then I have to stop and ask myself, “Will anyone, like my mother, be able to know that enter means search?”

    But I think I might be willing to get rid of the button, personally. :D

    Nice article!

  12. Antoine Guédès

    Sep 21st, 2010

    Really great post. I feel a bit frustrated; wondering why I didn’t think about it before. Thanks for sharing! ;)

  13. Zeke Franco

    Sep 21st, 2010

    I agree that buttons/submit inputs with the text “go” are small and not very descriptive. But every form input should have a label in the HTML for accessibility reasons.

    Non-sighted user prefer the label element because it reads the label to them in relation to the field first.

    For example without a label:
    User presses tab and is now focused on input.
    Screenreader states “input”
    Because there is no label user doesn’t know what the input is for so the user presses tab again
    Screenreader states “Button, search”
    User now has to press shift + tab to return to input now that they know what it is for.

    With a label element and proper use of the for attribute:
    User presses tab and is now focused on input.
    Screenreader states “Label, Search”
    User presses enter, and now there cursor is in the search field.

    Label elements should almost always be used. But I do think we can do away with go as the call to action.

    Note: Often I will use jQuery to take the text from the label and insert it into the value attribute of the input so that the interface is less cluttered and display the label off screen so it’s still available for non-sighted users. HTML5 has have some nice solutions for this, placeholder attribute.

  14. ehsanul

    Sep 21st, 2010

    I was considering “Go” for a non-search button. Specifically, the button submits a URL from the user which will result in a list of web pages related to the given URL. I could use something more descriptive, like “Find Related Web Pages”, but that’s too long. “Find Related” is also clunky. So I thought putting a 1-line description of what the button will do above, and just using “Go” as the button text would be good in this case. What do you think?

    • Stomme poes

      Oct 28th, 2010

      Awesome, esp if you keep the text outside the form (so screen readers in Forms Mode catch it as well). This is a good idea for any non-trivial form really: all instructions and necessary info come before the form and remain outside it. Then, GO is obviously a Submit button (heck, Submit would still be better for the reasons listed above in the article… more clickable area, has more meaning to more users) and needs little further explanation.

  15. Florent Gosselin

    Sep 21st, 2010

    Simple and nice post. It’s like the “Click here” button issue :)

  16. Lasha Krikheli

    Sep 21st, 2010

    99.9% of all computer users I’ve met just hit “Enter” after typing something in a field. I am a supporter of getting rid of the “Go” and/or “Search” button altogether.

    I recently worked on a project where the search box contained a nice magnifying glass image to the side, with the text “search” pre-populated in the field. You’re not gonna find anyone who doesn’t instinctively hit “Enter” when searching… unless it’s their very first time using a computer, which in that case, he/she would require a guide next to them.

  17. Iza Bartosiewicz

    Sep 21st, 2010

    Please remember that what you refer to as an ‘an ugly and noisy mess’ is one of the requirements for accessible and universal design:

    WCAG 2.0 H44: Using label elements to associate text labels with form controls (HTML) http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H44.html

    However, skipping the label may indeed be a preferred solution in some cases, but that should be determined on a case by case basis rather than saying that we ‘should stop using’ it. :-)
    Form controls that don’t have labels will need title attribute so that the form control is not left without an identifying label:

    H65: Using the title attribute to identify form controls when the label element cannot be used (HTML) http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H65.html

    The JavaScript jump menus and what @Alex suggested are not recommended for the same reason.

  18. Ygam Retuta

    Sep 21st, 2010

    better explicit than implicit as they say, especially when a great percentage of users aren’t tech savvy

  19. hm2k

    Sep 21st, 2010

    Often “Go” fits in places that “Search” will not.

    It’s sometimes a toss up between a shorter text area or having the button say “Go” instead of the action.

    Whatever is more important will win.

  20. Chris

    Sep 21st, 2010

    I think this is a matter of personal preference more than anything. Also, the amount of code added for the “wrong (in your opinion)” way of performing the search box is negligible which renders your “unnec­es­sary ele­ments to a design the result is always a decline in user effi­ciency and an increase in the like­li­hood of poten­tial prob­lems” emphasis moot.

    Just my 2 cents…

  21. Bart Grootveld

    Sep 21st, 2010

    Pretty simple, yet very effective! Nice article :)

  22. In my opinion, the Search button is more applicable. Moreover, the word Search makes more sense.

  23. matchstic

    Sep 21st, 2010

    Thanks for the post :)

    It’s ironic that this website does not have a search button.

  24. yohann

    Sep 21st, 2010

    I absolutely agree with this post. As a basis, always tell your users the meaning of actions. “Submit”, “Ok”, “Validate” is to be banned instead always use “Send”, “Search”, “Publish” or “Leave comment”.

    It is part of semantic web.

  25. jdirt

    Sep 21st, 2010

    Well, the reason for a go button is . . . two characters!!!!

    • Brett Lutchman

      Sep 21st, 2010

      jdirt,
      I’m not sure that 2 characters is a reason to use the term “Go”.
      “Go where”?
      Look at the author’s 2nd point regarding “Go”, it “makes a smaller click target”.
      Not only is “Go” not big enough to click on, it’s a term that is not relevant to the user’s interactive conversation with the system.

      There are no rules to design- only logical and intuitive best practices on a project by project basis.

  26. tuckinteractiv

    Sep 21st, 2010

    Thank you for pointing this out! Using “GO” has always annoyed me. Even using submit seems arbitrary. I prefer the mag glass approach, but in truth, you should try to cater to the majority.

  27. Brett Lutchman

    Sep 21st, 2010

    A very logical approach.
    I never did like “Go” as it is a term that is completely out of context.
    In my designs, I personally use the term “Find” to initiate a search process (along with a filter drop down menu as you have in your above pic).
    Upon landing on the search results page, I use the term “Sort” to narrow down the “findings” if there is exhaustive findings.
    Good short and right to the point article.

  28. Chas Grundy

    Sep 21st, 2010

    There are a lot of articles out there about this subject and it’s not always clear whether a UX recommendation is based on research, data, testing, or just intuition. Is this article based on research/testing?

    I ask because companies who are known for usability testing often come to different conclusions. Amazon uses “Go.” Wikipedia, Sun Microsystems, and Microsoft both use a magnifying glass.

  29. Paul Nolte

    Sep 21st, 2010

    My company uses an arrow button (i.e., ->) instead of a ‘go’ or ‘search’ button. I believe that it was chosen because it’s not language dependent. I think conventions are needed for web sites that serve international audiences. Thoughts?

    • anthony

      Sep 21st, 2010

      An arrow icon to me is pretty much the same as Go. If you want to use an icon that best represents Search use the magnifying glass icon.

      Thanks to the windows and mac operating systems, the icon has already been established as a design convention.

  30. [...] article from UX Movement, which came out yesterday (which is, I admit, perfect timing for our discussion), is a great [...]

  31. Tom

    Sep 22nd, 2010

    I think the point about the “can’t use the Go button without a search label” also apllies to the Search button as it should be added for accessibility and your document won’t validate. The main reason in my opinion would be clickable area.
    With regards to the button stating ‘Go’ I feel this is perfectly acceptable, but not ideal. Again, for accessibility you could use alt text of “search” on the button.

  32. jeffrey

    Sep 23rd, 2010

    unless it’s a search box on a map ;-)

  33. Dimitris

    Sep 24th, 2010

    Much too long discussion for such a simple thing. Web developers get obsessed with stupid things, like accessibility, code purity, blah blah … Does google have a label next to their search box? No. Did apple cared much about accessibility when they designed iphone? No. Will that mindset help you get rich? Probably Not.

  34. Mark Lamb

    Sep 24th, 2010

    Jakob Nielsen’s user research findings recommend using a button labelled “Search” for keyword search, but not for parametric search.

    http://www.useit.com/alertbox/20050509.html

  35. Matthew

    Sep 27th, 2010

    From an accessibility perspective, the Search box needs to at least have a title that indicates what it is for. If you have a bare input element, without the visual context (i.e placement in the header), a screen reader user might not know what the box is for, until the button is passed. I use “Search Text” for the title.

  36. poker spielen

    Sep 29th, 2010

    ha, I will test my thought, your post give me some good ideas, it’s truly amazing, thanks.

    - Murk

  37. Esta Schachsieck

    Oct 28th, 2010

    Interesting article and one which should be more widely known about in my view. Your level of detail is good and the clarity of writing is excellent. I have bookmarked it for you so that others will be able to see what you have to say.

  38. orangeguru

    Oct 28th, 2010

    This discussion is so 2005 …

    Who needs ANY submit button when you have AJAX real time feedback?

    And you can label the search box by putting a spyglass or similar background in the entry field.

  39. Nick Freear

    Oct 30th, 2010

    Hi
    expanding on what others have said, a label on the left (for RTL languages) is important for screen magnifier accessibility. Users start at the top left of the page and move right.

    HTML5 placeholder type=search should also be considered.
    Nick

  40. Steve

    Dec 8th, 2010

    We’ve just rolled out a similar concept on http://www.mendeley.com/ but using just a magnifying glass instead of the word “search”. Only been live a day, but looking forward to seeing how search frequency is effected by the changes :)

  41. Graham Armfield

    Dec 8th, 2010

    As a web developer and accessibility consultant who is “obsessed with stu­pid things, like acces­si­bil­ity…” I would agree that the input needs either a 1) label (hidden if you want) or 2) a title attribute. And a Search button too. These combined will make your Search facility usable by the widest audience. And if your site is any size at all the search facility is potentially one of the most useful navigation features.

    Sure you can change things around with javascript if it’s available but many screenreaders have a real problem with AJAX functionality so relying on that alone may cause your site to become unusable by some people.

  42. web designer

    Mar 22nd, 2011

    Agree with Justin – why not get rid of the button altogether and just hit ‘enter’ – which most users do anyhow?

  43. Björn

    Mar 29th, 2011

    Very good overview and argumentation. Changes could be so simple!

  44. EJelome

    Aug 21st, 2011

    There are problems with other suggestions here:

    Using AJAX:
    The problem on being dependent on JavaScript is that when the user’s device doesn’t support JS or has been intentionally turned off, then the Search itself will be of no use.

    ‘Just Hit Enter’ approach:
    Problem is that users ‘expect’ a button when submitting an input in any kinds of forms (be it search, registration, login, etc.). You’ll just be giving a Usability barrier. Even technical people themselves often doesn’t realize that hitting the Enter button would submit their inputs, how much more for non-technical ones?

    ‘Usability/Accessibility is stupid?’
    If you are a User-centric developer, then the things that will help your users to easily access and accomplish tasks on your applications can never be stupid, be it be ‘simple’ or not.

  45. MasterDesign

    Jan 24th, 2012

    ok, ok! that’s not a news… but you have a newer post that says that the best thing to do is having your search button right aligned. That’s confusing… On your site you don’t even have a search button! so what after all is the best option?

Leave a Comment