I am working on a web application for Branch Managers at an investment bank to assign accounts that are without Financial Advisers for whatever reason. Some reasons are the Financial Adviser has resigned or the client doesn't like them, etc. Branch Managers will have the ability to view accounts that need assigning and view available Financial Advisers. Many accounts can be assigned to only one Financial Adviser.

My application is being developed in Ext and I see through their demos that users can drag and drop items. This seems like a clunky way to assign accounts to new financial advisers, especially since assignments could easily be made in error (choosing the wrong individual). Users will be able to back out if they made a mistake, but this doesn't seem like the best solution. I once worked on a ticketing system that had this ability to drag and drop additional items onto an open ticket and it became very messy.

Do any other types of patterns come to mind for anyone?

  • are you looking at a single 'active' account and assigning an adviser to that account, or are you looking at a list of accounts and a list of advisers and reorganizing relationships between accounts and advisers? Aug 15, 2011 at 16:19
  • I'm looking at a list of accounts and a list of available advisers. The user will see things about the accounts, like worth. They will also see things about the advisers, like how much money they already manage. Based upon this discovery they will assign accounts to a new adviser. So yes, reorganizing the relationships between the two.
    – Eileen
    Aug 15, 2011 at 16:26
  • How many advisers do they have? 20, 30, hundreds. There could be different options depending on the expected number of advisers.
    – Emil
    Aug 15, 2011 at 19:26

2 Answers 2


This seems like a requirement for a possible 3 step process where details can be seen permanently and easily checked at each stage - and before final assignment.

Essentially, you are building a relationship via a couple of steps which require some examination of the items between which the relationship is to be made. A drag/drop motion seems wrong because it is a separate event to both the examination of the account and the examination of the advisers.

So perhaps it might be better to build the relationship as you go, and then confirm the relationship once you are sure.

step 1: choose the account. This is displayed somewhere in some confirmation area that shows the relationship you plan to build. You can see the selected account. Chances are you don't want to change the account after selection, but if you did it just updates in the confirmation area.

step 2: choose the adviser. The adviser is displayed next to the account in the confirmation area. Perhaps you are likely to change the adviser if you find one more suitable than the one you already selected, in which case clicking another adviser updates the one in the confirmation area.

step 3: once you are confident you have the right adviser, you click apply in the confirmation area.

As a visual guide to what I mean, see the very quick mock up below.

enter image description here

  • The brilliant thing here is that Eileen already had the solution (in her comment) once she wrote it out in plain English. I love situations where that works.
    – Rahul
    Aug 15, 2011 at 17:32
  • Yes! Thank you Roger. I was uncomfortable with dragging and dropping as a metaphor for picking a new assignment and had been thinking about a side by side type of widget. You are right, this application is about setting up relationships.
    – Eileen
    Aug 15, 2011 at 22:02

I take from your question that the user might be modifying several account-manager relationships together -- give this account to that manager, but if so we should move this other one from him to this other manager, and so on.

If that's correct, then your interface is fundamentally about relationships. One way to represent relationships is with lines connecting other UI elements.

Consider a UI where accounts and managers are displayed (boxes? icons? you decide), with the display including key information (account value, total managed money for managers). Current relationships can be shown as lines (say, black) connecting these. You can use a different line color (say, red) to highlight the ones that need to be changed. A user can see at a glance that, say, these five red lines indicate changes to be made; when he drags one end of the line to a different node the line changes to some third state (say, blue dashed) to indicate "pending", and the values update with some changed rendering to also indicate the "pending" nature (blue text, boxed, or something like that). The user can move things around as much as he wants, always seeing a snapshot of what things would look like if he kept this. When he's ready, he can commit (button, keystroke, some other gesture of your choosing).

If your system permits customers to request new managers because they don't like their current ones, you should probably keep track of that so a later change doesn't send an account back to an unwanted manager. This means your UI has to handle the case where an assignment is not permitted. (You might have other rejection criteria too, like limits on the amount of money a manager can manage.) A basic way to handle that would be to not permit the drop of the line-end (with some suitable message). A slicker way to do it, if you can spare the computing power, would be, when a line is being moved, to "gray out" invalid targets.

This approach works if you are working with a fairly small number of managers and accounts. (You don't need to show all accounts, only the ones you might change. But you do need to show all available managers.) If you want to work with 500 accounts and 75 managers this approach won't work; you'll either need to narrow the focus somehow (managing fewer at a time) or use a less visual interface (like a per-account drop-down menu to set the manager, which isn't very good for topsight).

  • Thanks Monica. I really appreciate your feedback. Your response reminds me of an Flex app I worked on yrs ago that would build a network topology by dragging connecting lines. Pretty cool. With this system customers will not be allowed to request on their own and due to legal and licensing issues, Managers won't be allowed to assign friends without a better reason. There will have to be an engine behind all this to resolve such issues so that mistakes can't be made. I did think about icons and colors for the status column that will appear. Thanks again.
    – Eileen
    Aug 15, 2011 at 22:15

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.