Identity Management is an important part of any Learning Management System. Creating, finding & managing users is an everyday task our users need to accomplish.
A major problem users, of an identity management system, encounter is finding an individual user, or groups of users. In larger systems, many user can have identical names, and it can be difficult to distinguish which user one is trying to identify.
Design example flows, layouts, and a simple UI for the following:
What criteria is best practice when searching for, and finding specific users? How might you represent this on screen?
Viewing returned results of users, especially large numbers of results, can be a cumbersome task. How might an administrator locate, or identify, a specific user from a large group of returned results? This should be represented with 2 unique views.
When a specific user is located, how might the users profile be represented on screen, and allow and administrator to perform routine tasks, such as resetting of passwords, moving a user between groups, and modify standard user details (name, age, gender, ethnicity, etc.).
Identity is a very dynamic concept that involves volatile variables. Those are categorized as follow:
Identity management must help:
The best way is searching by email address because is unique, while other characteristics (full name, birth date, acquisitions etc.) may be identical to other users' characteristics. Anyway, not even email is bulletproof because a user can create multiple accounts and change the email addresses between accounts. Because the search engine is looking also over the past emails within the same user account, confusion might happen.
However, the real challenge is when we don't know the email address but just a few details. I build this mock-up based on those scenarios listed bellow because trying to find and solve them all is impossible in such short notice and without feedback from Help and Support staff members. Identity management is one of the vastest ecosystems that can break or build an amazing customer support and has a significant impact on marketing
C = Client
O = Operator
M = Marketer
C: - Hello, I’m Christina Modigliani and I bought 2 days ago a book called Poppy field stories.
Operator’s search: “Christina Modigliani + item: Poppy field stories”
If the return results are more than one, the operator is asking either for email for a quick visual identification on the list or is checking the date under the search field.
M - There is this guy that bought 2 books last week and he said that weren’t delivered yet. Can you please check this one for me?
O: - Can you tell me were those books were supposed to be delivered?
M: - Manchester or London, don’t know for sure.
Operator can search for
“gender: male + items: 2 + last week + pending delivery + London or Manchester”
if it’s not enough, M may continue offering informations
M: - He said is not the first time he bought from us.
C: - Hi, I’m Clara, we spoke yesterday.
Operator can search for “Clara” and under search field, at “help and support activity” chooses “yesterday”.
C: - Hi, someone I know bought a book and I want just about the same for my son but I cannot remind exactly the book.
O: - Can you tell me your friend’s name?
C: - Carol.
O: - Does she has a girl or a boy? What age?
C: - Boy. He’s 7.
O: - What was the book about?
C: - About pirates.
Operator can search for
“Carol + age: 7 + pirates” (because every item has its own tags) or
“Carol + age: 7 + category: adventure” or if this is still not enough can ask for delivery address
“Carol + age: 7 + category: adventure + Bristol”
if the results are too many, Operator can continue asking for acquisition date etc.
Operator will not disclose information in terms of “Indeed, Carol Smith bought “The Amazing Pirates” and “Castles of the world” on January 15 … etc.” but based on the info Client provides can say “The only options we have based on your information are this and this.”
7 = age recommended item
adventure = category item
Daniel, Ireland, adventure
From a user experience perspective it is easier to just type for items in the search field while the system is picking up the entry type, such as:
• Daniel is a user's name rather than a book title;
• Ireland most likely is a location, not a family name or part of a book subtitle;
• adventure is assumed to be a category, not part of a item title.
This type of interaction is more convenient than just hunt for sliders, check-boxes, fields and radio buttons, no matter how well positioned are or how good are learned by the user (Operator).
When we just type, we are engaged in a mechanical and thinking flow. The word "flow" is important, because is about low energy level.
When we look for buttons, check-boxes, sliders and so on, this flow is interrupted by a visual load. Also, the mechanical load is increasing by positioning the mouse cursor, click, type again, slide etc.
Because this type of learning and adaptation is hard to accomplish inside a search engine, we can add a little compromise to it, by specifying the entry type.
name: Daniel, location: Ireland, category: adventure
Q: How can the Operator learn this syntax: "name:", "location:", "category:"?
A: From field labels.
The Operator can still user first type of syntax but in the second type, the level of disambiguation is increased.
At the same time, the syntax learning process is increased by the auto-complete: writing "cat", will result in "category:" for example.
Also, the syntax should be flexible and closer to the speaking language such as: "cat:" is the same as "category". "Place" should be the same for "location", typing for "name:" should take into consideration "first name:" and / or "last name" etc.
Of course, the email format is easy to recognize and doesn't need a label specification.
The goal is that the Operator to leave the search field as rare as possible. And when he has to, the most used items and options should be above the fold (so the Operator doesn't need to scroll for them.)
+46 705 090702
The syntax can look like this
label1: <string>, label2: <string> but also
<string> :label1, <string> :label2
Why is this important? Because when Operators are receiving a search request, the short term memory (or Working Memory - WM) shouldn't interfere with the cognitive load of "what type of entry is this". After you can set the WM free you can think about what type of label should apply, otherwise the Operator might end up asking repeatedly about the entry.
The logic operator between searches separated by commas is AND. So the search engine is returning all the users having both characteristics, not at least one.
Search criteria can be saved and, in this case, we can have dynamic groups of users. Those saved searches can be seen as dynamic folders.
At the other end we have the classic concept of folders. Users can be added manually to some specific folders, unlike saved searches (or dynamic folders), where if users meet certain conditions, they can move in and out of different dynamic folders.
The great thing in using dynamic folders is that we can see how different kind of users are relating to each-other and more importantly, at marketing level there can be build meaningful correlations. Those correlations lead to predictions which lead to actions in user retention, acquisitions etc. For instance, at least one acquisition may transform people in brand ambassadors or their behaviour is unchanged?
ex. Daniel Goldman
Feb 23 - Apr 23 2015
last session 2 weeks ago • 03.22.2015 at 22:03
registered 2 years ago • 02.21.2012
Add to group folder
Easy to Deal with
Create a New Group
View list by:
A - Z (alphabetically)
078 562 499
067 667 989
000 344 565
000 007 891
022 784 555
Last Login Session
23.03.15 at 23:16
17.04.15 at 10:44
28.03.15 at 17:02
02.02.15 at 12:49
17.04.15 at 12:08
age recommendation - ascending
age recommendation - descending
login session - latest on top
registration date - latest on top
registration date - oldest on top
total spent - descending