I have an application called "Redmine-Bugtracker" with the matrix below. This permission matrix allows users to add permitted status-steps on an issue depending on the current-status of it.

So you see on the left side, in the first column of the each row belong to Gegenwärtiger Status --aka current-status. There are all the steps an issue can be in the form of.

In all the columns for the right side under Neue Berechtigungen --aka new-permissions, you see all the steps you can do if the current-status is the one in the leftmost column.

Now what happened is, my colleagues added a new status step as Auftrag unklar --aka assignment/task unclear. So as to mark a ticket where it is unclear what you should do, when the PMs leave you in the unclear what has to be done.

Now what happened is, they set permissions on the row of "Auftrag unklar", thinking it would unlock the issue-status in the tracker. Instead, what the crosses in the pink row defined, is which status-steps are possible when the current-status is "Auftrag unklar". What they would have needed to be doing, is set the crosses in the red-marked column instead.

I was wondering, what is wrong with this UI design, and more to the point, how on earth could this be done better, so as to be less confusing?

How to take some cognitive-load off the user?

I mean, if the programmers can't understand such a matrix, then how could an average user do it?

I'm asking because we have a similar workflow in our application, where the user should do exactly the same as in this example. Configuring (=allowing or disallowing) some status-steps depending on the current-status of some entity.

Bad Matrix UI

  • I would expect that "Auftrag unclear" is only available from status "Neu" or "In Bearbeitung". And that any other status is available from "Auftrag unclear" (except "Neu" and "In Bearbeitung" maybe). So am I right that in the column "Auftrag unclear" rows "Neu" and "In Bearbeitung" should be checked and in the columns "Neu" and "In Bearbeitung" the row "Auftrag unclear" should be unchecked?
    – jazZRo
    Commented Sep 21, 2022 at 9:14
  • Sorry, maybe it's my poor German skills, but why are you using a matrix where actions intersect with other related actions? For example, if I check the intersection between "Edit" and "clarification" or "removed", what should happen? This doesn't make any sense to me. Again, maybe it's my bad German, but I think the problem is that you're overcomplicating things, which is why programmers can't understand it.
    – Devin
    Commented Sep 21, 2022 at 18:53

4 Answers 4


I'm very curious about how others will answer this, and certain there will be better answers. I'm inclined to assume that:

  • Your users are not going to be working in this matrix frequently; it's set-and-forget until processes change or another feature is introduced; and
  • Unless you are specifically designing this for an office manager or other less-technical persona, your users probably are the more technical and savvy ones in their org.

So I'm thinking you don't need a whole UI redesign here. A matrix that shows all of the possibilities on one grid is a more user-friendly pattern than a workflow builder or a bunch of dropdowns.

What I'm thinking is that you probably should try to guess some good defaults for that "Auftrag unklar" (aka assignment/task unclear) step. At what step do tasks typically become so clear that users wouldn't mark something as unclear in the next step? Everything up until that point can be checked by default. It doesn't seem risky or harmful to accidentally introduce this option into steps that don't need it, they can easily be unchecked.

User research would likely be helpful for figuring that out.


If I understand correctly, the matrix specifies what statuses can transition to what other statuses. The rows on the left represent the “old” status, while the columns represent the “new” status. When users are tasked to specify what old statuses can transition into Auftrag unklar (i.e., to fill a column), they instead specify what new statuses Auftrag unklar can transition into (fill a row).

I suspect the problem is that the row labels catch user’s attention before the column labels due to them simply being a vertical list, and my impression is that, at least with this design, the eye tends to be drawn down a vertical list more easily than across a horizontal one. When tasked to set transitions that Auftrag unklar can come from, users thus see Auftrag unklar first in the row labels and work from there. They either don’t notice or don’t recognize the implications of the Neue Berechtigungen label far to the right, outside of their initial glance. I suspect if you tasked users to set the statuses Auftrag unklar can transition into, users would still start with the Auftrag unklar row (correctly, this time).

As for solutions:

  1. If the task is almost always to set the old statuses that can transition into a given status, rather than the new statuses a given status can transition into, then go with the flow and swap your columns and rows.

  2. You can try to make the column labels more prominent so the eye is at least equally likely to follow horizontally as vertically (e.g., use bold font, color, or reverse polarity).

  3. “Current Status” (Gegenwärter Status) sounds ambiguous. It could be the current status after transitioning from an old status, or the current status about to transition to new status. If users don’t notice the “New Status” label, they may assume wrongly. Try changing the label for the rows to “Old Status” to clearly contrast with new status.

  4. While you’re at it, align the “New Status” (Neue Berechtigungen) to the left so users see simultaneously how both columns and rows are labeled: Neue Berechtigungen to left of grouping graphic for columns

  5. Consider including some sort of graphic representation of to-from to make it more apparent how to set old-new transitions, maybe involving arrows: Arrows direct from each row label to each column label

  6. If none of that works, then consider a separate UI for setting the transitions for just a single status to remove any ambiguity of what is before or after, rather than a matrix for all at once (although this would be not nearly as elegant as a single combined visual representation that your matrix provides): Before statuses to left of "Auftrag unklar," after statuses to the right


How would I know what the columns and the rows mean without your explanation?

I would assume that it would help to have "axis-labels" for this matrix: enter image description here

Now this is obviously just an ugly example, but you get my point.

Or simply add an info text that shows a little pop-up on hover/click with a short explanation:
enter image description here


I would suggest playing around with jobs to be done. First of all, determine the frequency of the user having to change values on the horizontal and vertical.

Then maybe play around with some visual differentiation and some kind of preparing the user for the activity he wants to do, such removing cognitive load as: I have added a new status-step "Auftrag unklar". Now I need to do two things. Unlock the issue-status in the tracker


Set which status-steps are possible when the current-status is "Auftrag unklar"

Giving the user the ability to do both things at once might cause the error you described.

Out of the top of my head, I would think of an interaction like in the image.

  • Where the user lands in this view. ( The view could also be read-only. )
  • User has the option to edit either Gegenwartiger Status OR Neue Berestingungen.
  • When user selects what he wants to edit, he gets a highlight on the basis of either rows or columns.

enter image description here

These are suggestions on a minimal understanding of your case. User research would help a lot.

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.