Question summary: I'm wondering what are some recommended approaches for communicating to the user what will happen once he clicks on an object, in the case that it's not possible to spell out the action on the object itself (i.e. the object is not a classic button).

In the case that the object has a text title, the traditional approach I know is to simply turn the title text into a hyperlink; however, in the case where it's not a traditional website, I feel that the user might not have any idea what will actually happen once it is clicked! (in contrast, for websites the 'browse to a different page' paradigm is very well defined so hyperlinks work well for webpages).

Here is my situation specifically:

  • I have a page with about 20-30 different Measure Indicators, similar to a Google Analytics home page. Each Indicator has a sparkline trend chart, the current value of the measure, and a little up/down arrow indicating the delta (change) from last period.

  • I have two actions that the user needs to do for each Indicator:

    • (1) Be able to expand the indicator to reveal more info (show extra stats for the measure, ratings, etc) - this expansion happens in context and does not take the user to a different page.
    • (2) Select the Indicator and navigate to a different page which is step 2 of the workflow, where the user can Assess and Explore the Indicator further. The 2nd action is the primary action that the user will be taking most frequently.

As I mentioned above, I could just make the Indicator name a hyperlink and simply communicate to the user that it is clickable. However, I want to avoid making users have to click on something without having any idea what will happen (and that they will in fact be taken to a different page, among other things) - this almost feels like asking the user to click on a button which has no label on it!

The key thing I wish to communicate to the user is that by selecting a Indicator they will begin an analysis workflow which will start with 'Assessing' the Indicator in more detail. The control is further complicated by the fact that there is also a secondary 'expand' action on the Indicator as mentioned above.

One obvious solution is to simply put an 'Assess' button beside each object. However, I wish to avoid having 20-30 'Assess' buttons on the page (seeing as I have 20-30 Indicators).

  • Option A: one way to solve this is to simply rely on a tooltip; in other words, the entire indicator area is clickable (indicated by highlighting/outlining the area on mouse-over) and on mouse-over a tooltip appears which reads "Assess Indicator x"

  • Option B: another approach I thought about might be to reveal the "Assess" label on mouse-over, but rather than a tooltip have the label be part of the highlight box, so very similar to the tooltip design, except it's not a floating overlay but a bit more integrated into the Indicator object.

  • Option C: this strikes me as incorrect but I'm mention it for the sake of discussion - stick with the 'Assess' button idea, but only have the button appear on mouse-over. I recall reading that a 'mouse-over, make control visible, then click' interaction is not recommended because the made-visible control might disappear while the user is on his way to move the mouse cursor from the focus 'mouse over' area to the object itself.

Regarding the secondary 'expand indicator' action, I was thinking of simply having a small '+' or 'more info' control beside each Indicator.

Any UX design rules that B or C are breaking? Any recommendations on the best (or better) approach?

For reference, what the application does right now is put an Assess button inside the Indicator expansion, and have the entire Indicator be the expansion click object. Obviously this is wrong seeing as the user has to always first expand the indicator (which is a secondary and sometimes not necessary workflow) in order to get at the Assess button.

  • You've taken your time to write this out thoughtfully and with a lot of detail. Thanks for that. I think you could further improve your question, and chances of getting a useful answer, by adding a mockup of what you have now.
    – Rahul
    May 30, 2011 at 19:52

1 Answer 1



A way to get good affordance and reduce navigation actions is to provide two routes to 'assess'. One route uses a button with good affordance, the other is direct from the sparklines. The combined result is a UI that is discoverable - users will find the assess function - and it is efficient - experienced users will be able to use it with minimal steps.

Illustrating This

Using a pattern, show the Assess button once. The mock-up uses a modified tree to do the master-details (only one level in it), here with the detail for Belgium expanded:

Sparkline Master-Details

Clicking a [+] buttons closes open items and gives more detail on that ONE sparkline item - and as illustrated shows the Assess button. This avoids a proliferation of buttons.

To improve the affordance elsewhere give the sparklines themselves a hover over change in style to indicate they do something if clicked. You can put up a tooltip after a longer than normal 2.5s delay for the hover. Tooltips won't get in the way of experienced users, but will give some new users exploring the interface slowly an extra hint. The tooltip is an optional extra. You've avoided depending on it because casual users can already easily discover a reasonable way to get to 'assess'.

If you want to it would be OK to instead make the indicator names hyperlinks or buttons, and move them a little further from the [+] [-] controls, again using a slow tooltip in much the same way.

A more important aspect than the tooltip is that the 'assess' action be reversible and that it can easily be stopped, especially if it's time consuming - so that it's safe to explore the interface.

Your Answer

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

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