I have a mode button in menu of zoom tools on a desktop application. With the button you can change the mode of the cursor between select, zoom in, zoom out, and pan.

When you hold the button down, a small pop-up menu lets you choose between the options. This is similar to Adobe Photoshop or similar programs: left click give you the tool and hold-down or right-click gives you the neighboring options.

So the thing is I want to build in what could be called "feed-forward". Since you are always in a mode anyway, I want to show which other options are available. When you are in select-mode the button shows a zoom-button. When you are in any other mode the button show an arrow cursor for select mode. Zoom and Select are the most common modes.

enter image description here enter image description here

Test users are confused that they are not shown the mode they are currently IN, but the mode they can change TO. Feedforward instead of feedback.

So the question is: Should I do as users expect (killing my darling), or should I implement the more usable idea which would give the user fewer mouse clicks in daily operation.

enter image description here

  • I think (being kinda new here) that the correct way to rush a question would be to add a bounty to it, not add "urgent" in the title Commented Nov 29, 2013 at 9:29
  • Marking posts as 'Urgent' isn't really appropriate to Stack Exchange posts. UX.StackExchange (and all sites in the Stack Exchange group) are repositories of useful questions and answers, not an instant support service. Think 'Wikipedia' and not 'Support Forum' as that's a more appropriate analogy. You're welcome to add a bounty to your question in a few days when it becomes eligible for one (although you'd need some extra rep to actually offer as a bounty).
    – JonW
    Commented Nov 29, 2013 at 10:05
  • Thank you. I was not aware on the bounty system. I will do so in the future
    – martinnova
    Commented Nov 29, 2013 at 10:19
  • I have decided that magnus' answer answers my situation well. Biplav does too, but I cannot choose two correct answers I guees. Sorry for being a newb.
    – martinnova
    Commented Nov 29, 2013 at 10:24

2 Answers 2


As a general rule i definitly advice you to "kill your darling" when it's not working as intended in user tests. Remember, you're not designing this UI for yourself, you're designing it for your users

However, it would help if you show a screenshot of how the interface looks, maybe there are other problems causing the users to not understand the buttons behavior. To me it feels like the quick mockup below shouldn't be hard for users to understand:


download bmml source – Wireframes created with Balsamiq Mockups

Edit (due to screenshots being uploaded): Yes, I think you should show the state you're in. It's good that you're trying to find new ways that will decrease the number of clicks, but since this solution failed the user tests you should change it to showing the current state. I think that would solve your usability problem


In the time crunch scenario, with User testing going against your darling, i would advice you to fallback to more reliable feedback approach, and rethink the feedforward approach for future release.

I like your concept of feedforward, and makes sense. But without seeing the actual UI I am not sure how we can communicate to the user. You need to work there.

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.