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:
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.
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:
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.
