2

At the local level, the system admin can add add/remove/modify users and user groups. At the same time, we have an internet based user management system. The device is registered to the cloud account, allowing users from that account to log in. This allows cloud admin users to manage users/roles centrally for several devices at once.

Here comes the problem: We're trying to encourage people to administer users/roles exclusively from the cloud, but need to keep local user management available for customers that don't want to use it. Local user management has to co-exist with cloud user management on the same devices. Cloud administrators have full access to local user management on all devices, but not vice-versa. Local accounts can't migrate between devices at this time as well.

So finally, the question: How do I visualize this mess so that I can communicate to customers that editing local users only affects users on that device, and not cloud users that have access to that same device? There's so much room for confusion when describing this system.

  • To clarify you have two separate user account lists. One per device local and one global? Any conflicts between these sets? – Jason A. Nov 11 '14 at 20:41
  • No conflict between the two. In the ideal scenario, the only account on any local machine is the default admin account. However, there will be use cases in which customers switch to cloud account management after originally using local account management. I imagine this will be were the most confusion will be. – dmacfour Nov 11 '14 at 21:52
  • I think the last sentence in this question sums up why it's not getting attention. You've described a very complex situation, and tucked the question away at the end. Your title also reflects that you have more of a mess than a question. That said, this problem has a solution, and as someone who'll be working on building a proprietary authentication app at some point in the next couple of years, I'm interested in helping you work it out. But before I, or anyone else, stands a chance of suggesting something that works, I think you need to put some more work into the question... – dennislees Nov 12 '14 at 1:20
  • For starters, your title should be an engaging question; How can I show, How should I differentiate, etc. If you can't condense your problem into a relatively short question, it's more proof that you need to clarify the problem before seeking an answer. My personal approach to this would be to draw as simple a system map as possible. The diagram will serve as a thinking tool, and can be used to better demonstrate concepts like "local level", and "cloud admin". – dennislees Nov 12 '14 at 1:31
  • By showing the relationships, and restrictions, between elements, you make it possible to start answering questions around who has access to what, and for what reason. That's going to be your jumping off point for ideating on the UI. You can also use the diagram to add a little more context than you've provided, e.g. what kind of users, accessing what kind of app? Of course, this advice means that you've got more work before you get to the bottom of this, but hey, simple is hard ; ) – dennislees Nov 12 '14 at 1:37
1

Your immediate issue is a branding/PR problem. Your customers come in two flavors, but the ones you're looking to communicate with are "cloud admin" users (whether these are concurrently "system admin" users is irrelevant at the moment).

First things, you need two discrete schemas to associate accounts with. The cloud admin needs to internalize these schemas to the point that they become jargon. Cloud and Device, somehow branded, need to be consistently used in reference to the two so that the user associates those names with their respective things.

Cloud accounts are cloud accounts, Device accounts etc. It's even better if you can come up with different names for account based on the device -- what we're trying to do here is put as much distance perceptually between the two to encourage perception of functional differentiation.

So, you have

  1. Cloud accounts
  2. Device profiles

Next step is management UI/UX, yes? Since only "cloud admins" can manage both, we're looking at a management interface for the cloud admins. A few things encourage cognitive differentiation -- beyond the different names, logically separate them in different pages.

  1. Cloud-based identity management tool
    1. Page: cloud accounts
    2. Page: device profiles

Page: cloud accounts is user-account-centric -- you're looking up users and modifying their various settings.

Page: device profiles is device-centric -- you're looking up a device and modifying profiles' properties on that device.

Linking between the two must be explicit based on a well-understood shared property. In Page: cloud accounts, the "Devices associated with this account" panel might give you a list of devices, any of which will deep-link to the Page: device profiles view for that device. Likewise, "Accounts this device is assigned to" will deep-link you to the Page: cloud accounts view for that account.

1

Four things need to happen for users to migrate to cloud user management

  1. User needs to see and understand the overall system
  2. User must believe in benefits in cloud user management (notably this includes (a) belief that it is secure, and that (b) working off line won't be impacted
  3. Painless and clear migration path
  4. "Nudge" to both remind, educate and motivate

I understand question is mainly addressing point (1) above, which is key, but probably not in itself quite enough.

The key UX heuristics to apply to this design is probably Match between system and the real world, Visibility of system status and Recognition rather than recall.

Which would give us a single UI that reveals both systems together and their relation ship.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

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.