The dialog box shown below constantly has me clicking the wrong button—despite the fact that I designed it!

The way it works is, the user types some text into the line edit box, and program output is shown in the widget below it (grayed out in this example). The user may want to further processing of the inputs, and so if s/he checks the “Show Transductions” checkbox, the dialog box pictured below will expand and show that additional information below the “Show Transductions” checkbox. This is instantaneous.

The “Generate Debug” button opens a new window with debug output. This operation takes a long time to perform, but it is occasionally necessary.

(These functions are autonomous. Whether chooses the “Show Transductions” option has no effect on whether one would then click the “Generate Debug” button.)

Despite being both the designer and a frequent user of the program, I find myself constantly clicking “Generate Debug” when I mean to click “Show Transductions”. How should I design this dialog box differently to prevent that from happening?

One thought I have is to simply move the button—it can't help that it's at the lower-right corner, where action buttons usually go. I'd also be interested in the computer equivalent of the clear box covering the big red button in the power plant—to prevent accidental clicks—but I can't recall seeing that done in computers. (I would like to avoid clunky confirmation dialog boxes if possible.)

picture showing the dialog box described in the text

  • I'd like to see the complete flow before attempting an answer. However I think you're right in identifying the location of the control as a contributing factor for the accidental interactions. To that I'd like to add that it is also a button as opposed to a checkbox. Buttons tend to communicate 'actionability' more readily than checkboxes, just by how well they are trained in their respective roles. Because mostly, checkboxes are used to configure an action, and much less frequently afford initiating an action. I think your modal might benefit from a redesign, but need to see more first. Dec 6, 2020 at 19:15
  • How does checking the Show transductions "button" (it is a checkbox BTW) effect the user or the process? How does that feature manifest once triggered in this way? Same goes for the Generate Debug, what happens? We are all guessing and it makes a mess of answers.
    – straya
    Dec 9, 2020 at 7:03
  • I've edited the question to add those details.
    – adam.baker
    Dec 9, 2020 at 8:38

6 Answers 6


Full-time Transductions

What if you show the transductions all the time? Don’t make the user click to see transductions. If transductions can be shown instantaneously, then just show them whether the user wants them or not. Make the computer work, not the user.

[[Transductions text box under Parsing box --no check box

If users don’t want to look at the transductions, then they don’t look at them. Even if users only need to see the transductions 30% of the time, it still saves 0.3 clicks per interaction, as well as removing the confusion with Generate Debug.

On the other hand, maybe:

  • The user needs to see the parsing in the context of whatever is behind your window (i.e., the content of the parent window). Expanding to show transductions makes that harder.

  • Some users are confused or distracted by transductions, so it’s best to make it an item of progressive disclosure to insulate certain users.

Visual Weight

If both transductions and debug information should be under progressive disclosure, then the problem you have is that, as a consequence of visual design and layout, the Generate Debug has more visual prominence than Show Transactions.

  • The lower right of a dialog is where users tend to be looking after studying the parsing, and, by habit, the lower right is where users expect the “do this next” control to be (like in a wizard).

  • With its border and shading, a command button appears larger and has more visual contrast to its background than a check box, so it stands out more.

So swap it around. For example, debug can be a lightweight link, which it is, in a way, in the sense that it links to a new window. I’d label it “Debug Info” rather than “Generate Debug” to emphasize this, and make it consistent with what the user wants to do (which is see the debug, not generate it per se). Transductions can be a progressive disclosure button (with the “>>” symbology), which makes its effect on the window more predictable than a check box does.

Debug Info link left, Show Transductions button right

In (Weak) Defense of Confirmation Dialog

Regarding the general problem of preventing accidental activations, the confirmation dialog is indeed the GUI equivalent of physically covered button or switch. It has the advantage over a physical cover that you can provide user with text explaining exactly why the command may be a bad idea. For example, the confirmation could say “Generating debug may take several minutes.”

On the other hand, users almost always think they know what they’re doing (and, believe it or not, they’re usually right about that), so they’ve gotten into the habit of not reading confirmations and going ahead anyway, so all you get with a confirmation dialog is a clunky annoyance.

Safety Covers

If you’re only worried about slip-of-the-mouse accidental clicking (“I meant to click “Insert” but instead I clicked “Nuke”), not misunderstanding the UI (“I thought ‘nuke’ was like ‘warm up the data’”), then a better alternative to a confirmation dialog is to use a single-item menu button:

Nuke menu button with single Nuke All Data menu item

It’s not a conventional use of menu buttons, but it’s faster than confirmation dialogs because there’s less mouse movement and no mental re-orientation to a whole new dialog. So there’s less self-documentation, but also less clunk.


based on what I understand from your question, Show Transductions are commonly used and Generate Debug is the secondary action for this screen. Since there is no 'Ok' button in the design and the Debug Generation is on the bottom right side of the screen users will instinctively click on the button. This is normal user behavior.

To tackle this issue, you can consider rearranging the Show Transductions check box and Generate Debug button.

A suggested rearrangement is to turn the checkbox into a button and put it side by side along with the Generate Debug button. The order of the button depends on the habits of the users. Assuming that this program is running on Windows platform and the primary action is to Shows Tranductions, then the Shows Transductions button will be on the left while the Generate Debug button will be on the right like as follows.

Mock up of how the buttons should look like

The reason for this arrangement is typically on Windows systems, users expect the primary action (Ok) to be on the left of the secondary action (Cancel), such as this example.

Example of Ok and Cancel buttons arrangement

Please give this design a try!


You could simply show a preview with confirmation. Are you sure you want to generate debug ? also the checkmark should be placed where it's logical for the user to use it. Either under the input box or above the button. I am not sure what your interface does to determine the best place for the checkmark but make sure it's logical in it's use.


You say "I would like to avoid clunky confirmation dialog boxes if possible", but that's exactly what programs use in cases of possible accidental misclicks. For example, games show "Are you sure you want to quit?" when pressing the quit button, file explorers show "Are you sure you want to delete this file?" etc.

Programs also show "This may take a while" before a long operation:

enter image description here

Also you might consider designing your program so that the debugging operation can be aborted mid-way.


Remove it.

No, seriously. If I understand you correctly, the user clicks "Show transductions" to see additional information. That will expand the dialog. So why not put the "Generate Debug" button / functionality inside the "Show transductions"?

Then, instead of "Generate Debug", have a simple "OK" button to close the dialog, which is more intuitive.

  • They're distinct functions, independent of one another, so both need to be available to the user.
    – adam.baker
    Dec 6, 2020 at 10:53
  • Call it "more" instead of "Show transductions"? Then have "Generate Debug" and "Show transductions" together. Dec 6, 2020 at 13:03

Here is what I ended up with, incorporating various elements of the feedback I got here:

picture of a revised dialog box

  • “Show transductions” is now a (checkable) button, to make it more clear that it is an action.
  • I switched the order of the buttons so that the lower-cost button is on the right.
  • I made “Generate Debug” a menu button. The user clicks the button, and then selects between two options for debug output, “Parsings Only” or “Include transductions”. This functions as a confirmation of the expensive action.

The last point involves a mild logic tweak. Previously, the user would get debug info for only the parsings if the “Show Transductions” box was unchecked, or debug info for transductions as well if it was checked. That was fine, but this interface is also reasonable, and it gives the user a chance to confirm the action. Depending on one's perspective it is either a hack or a clever combination of requirements. :-)

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.