I am facing sort of a mental block while redesigning a new UI at my Job. The previous UI was not user friendly and we received a lot of feedback to make it better. Now, finally after 2 years our team has decided to revisit the UI and make it better.

I mocked out a few proposals but all were heavily influenced by our existing UI and so I never showed them to my team. I am stuck and cannot think past the existing UI design we have. I feel like I am not getting anywhere and cant come up with anything new.

So any suggestion or advice would be helpful.

Problem: I am trying to create a UI that allows users to map nodes (define mapping). I have x number of source buckets each containing more than 1 node. And then I have 1 target bucket that also has more than 1 node. The goal is to map nodes in target bucket to nodes in source bucket.

For example,

Source Buckets: A = {'node1','node2','node3'} B = {'node4','node5'}

Target Buckets: C = {'node6','node7','node8','node9'}

Mapping (that user should be able to define):

C::node6 -> A::node2

C::node7 -> B::node5

C::node8 -> B::node4

C::node9 -> A::node1

Note how all the nodes of Bucket C are eventually mapped to some node form source buckets.

enter image description here

I am not sure, what would a nice and simple way to allow users to define this mapping?

I do not want to talk about current design much but just that we are using tables to display this mapping in the UI. The buttons that a user presses to define individual mappings are outside of tables.

Any better way to define and visualize these mappings? Any resource I can look at?

  • 1
    Welcome to UXSE. Have you been able to talk to any of your users about their pain points? Can you watch 5 of them work with the system and see where they're struggling? Do you have any recording videos such as with systems like Hotjar? Research is a good place to start a redesign.
    – Izquierdo
    Jul 26 at 14:55
  • Hi Izquierdo, Thanks for your reply. Yes I have a list of pain points from the users. We did that study and found a lot of negatives in our existing design and things that users found hard to interact with. The major pain points have to do with the fact that we are using trees to represent buckets and tables to represent the mappings. Pain point: 1) Focal point of UI seems to be the mappings table but the actual UI elements that a user interacts with is the bucket tree. 2) Table entries are hard to read when node and bucket names are long. (Existing UI is not scalable)
    – user148638
    Jul 26 at 15:17
  • I'm finding it quite difficult to visualise what you're describing - Is there a chance you could add some anonymised screen grabs or wireframes? Jul 26 at 15:22
  • Yeah I am adding a rough sketch of some of the UI elements I mentioned here. As I said, buckets are represented in form of trees in bottom. All the user interaction happens in the bottom half.
    – user148638
    Jul 26 at 16:03
  • The buckets are flat, right? If so, a tree seems very vertically inefficient for displaying them. Also, is there a good reason source/target are switched above? Jul 26 at 17:33

When you find yourself stuck on one design, strip the task down to its essentials as defined by your user research. In this case, it seems you need to support:

  • Users specify a Target C node.

  • User specify a Source A or B node to go with it.

  • Display the resulting Source-Target relation.

Surely there are many designs to accomplish each step and combine them. How many can you imagine?

Personal Design Iterations

To find the best design for your particular case, consider what has to be true about the task (or users or work environment) for a given design to work best. In many cases, you won’t know the answer, but it becomes a question to ask your users.

For example, in your design, I noticed that Source and Target nodes remain in the Source and Target panes even after being paired. What benefit does that have for the user? Does seeing paired nodes in these panes help the user find the remaining nodes? Or are there other actions the user does on those nodes individually after they’re paired? What are the downsides? Do users lose track of what nodes are already paired? Is it difficult to tell when they’ve paired all targets? Do paired nodes just plain get in the way after a while, forcing a lot of scrolling up and down?

So what if the UI was like this:


After each pairing, the two nodes disappear from the Source and Target panes. Now users can tell what’s left, if anything.

What else is implied by the design? As you mentioned, the user is focused on the Source and Target panes –they hardly need to look at the Connection pane. Is that what goes into making Connections, just select this node and that node, or do users need to see the developing Connections to know what to do next? You mention that the “focal point of UI seems to be the mappings table (connections pane).” So what design would put more attention there? What if you combine the Target and Connections panes:

enter image description here

What would make such a combined design work best? Do users tend to go through the Targets in order assigning Sources one after another? If not, then this design could make it hard for the user to realize when all Targets are connected –they have to scroll up and down to see if there are any Targets left with blank Sources.

Do users in fact tend to go through the Source nodes one after the other in order (maybe first A then B)? Then maybe you should combine the Source pane with the Connections. But does there tend to be a lot of Sources that never get a Target? Would they then tend to distract the user or clutter the display when the user is inspecting Connections?

You have Source nodes divided into A and B buckets. What does that say about the task? Do users think, “I need an A for this Target. I think it should be… yes.. Node 2.” Or do users often think “I need Node 2 for this Target, which, if I remember right, is in Bucket A.” If the latter, then maybe you don’t want separate buckets for A and B, and instead just need one Source pane sorted by Node name. Or maybe it should be a Source Table with Bucket as an attribute. Users can sort the table on either Node name or Bucket depending on what they need to find.

enter image description here

Users need to select a Target, then a Source, then select Add. Three clicks. That prompts the question, is there anything a user can do to a Source other than add it to a connection? If not, why not make the Add implicit? Once the user selects a Source, it pops up to the current Target node, cutting clicks by 50%.


Why a pane listing Sources? Do users have a rough idea of the Bucket and name of the Source they want, so by scrolling down they’ll recognize it? Or do you need to show additional attributes (table columns) of each source to provide enough information for users to sort, recognize, and select the right one? Or are there just too dang many Sources to put in a pane –too much scrolling around. Should you have a Source Search feature instead?

Or is it more like the opposite –users generally know exactly which Source node they need –maybe its name is even given on another screen. So maybe Source should be an attribute of the Target, which the user selects with a dropdown/ combo box that supports type-ahead:

enter image description here

The user can copy and paste the Source node name into the combo box, and they’re done.

Design to Ask Questions. Answer Questions to Design

In all probability none of the drawings above are right for you. However, it demonstrates that you can look at each feature of a design and recognized what it implies about the task. That will cue you towards questions to ask yourself or the user, and thereby alternatives that fit the task better.

No design is perfect, but once you have a basic design that’s best for the task, you can mitigate any disadvantages it has. For example, maybe it’s best to combine Connections and Targets, but include a graphic or field indicating if any Targets remain unpaired and make it easy to find them. Maybe you can’t eliminate the Add button, but you can support expert shortcuts like double-clicking or drag-and-dropping a Source to pair it.


If you are willing to sacrifice some efficiency and accessibility you could try a node based UI. Connecting nodes with drag and drop can be fun and visually rewarding, but only if the number of nodes are small.

connecting nodes with drag and drop

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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