One of the most frequent tasks on many intranets is finding people within the company. Providing an effective way to search people is thus a key goal in designing intranets. This goal becomes even more important for an organization like Emirates, a leading international airline, which has over 35,000 employees with over 140 nationalities and where more people are likely to use this feature more frequently.
Our intranet provides many applications that have a people finder feature to help staff find each other. The goal in using this feature varies depending on the application and situation. For example, people may want to find a staff to book a meeting or add them to a project team. Whatever the goal, a simple text input field and a Find button are enough to provide the sought-after results. But again and again I have heard complaints about not being able to effectively find colleagues using this feature.
The effectiveness of the People Finder feature is challenged in the following ways:
- People misspell names of staff they are searching. (e.g., ‘Vivek’ is spelled as ‘Vevek’; with over 140 different nationalities this is bound to happen.)
- Names stored in the database are not in proper format. (e.g., ‘Vivek Deshmukh’ is stored as ‘Vivek D.’)
- People are known by completely different names than the one stored in the database. (e.g., In some cultures women change their names after marriage.)
Figure 1: A typical example of not finding a person in staff directory
How can you design a better People Finder application than the one that so often says “Staff not found!”?
Building on users efforts
One idea is to look at what users do with the problem at hand and how they solve it, and then use their efforts to build the application. For our People Finder application we can do this by having a “Did you mean …” feature, which gives alternative name suggestions to users. These suggestions are not built by pre-defined logic but are based on the collective input of users.
In our department, when colleagues don’t find someone on a People Finder application, they try various strategies. These include:
- trying different spellings,
- asking another colleague for the persons correct name and spelling,
- calling the person directly (if they have their phone number), and
- checking previous emails to get the exact spelling.
Whatever activity they choose, they make sure that they have the right information to type in the People Finder text box. We need to make use of this effort (i.e., making an error and then fixing it) from the users to build our application. The following conceptual model is my attempt at designing such a system.
Building the application
There are five essential components to this concept:
- Build a relation table to store incorrect entries. In other words, store search queries which produced no results.
- Determine if the user has found the right person.
- Build a relation between the previous incorrect entries with the last correct entry determined in step 2.
- Check the strength of relation by observing patterns across all users.
- Present strong patterns as a “Did you mean …” feature on the search results page.
Let’s look at each step in detail.
STEP 1: Build a relation table to store incorrect entries.
To explain the concept, let’s take the scenario in which a user Sally wants to organize a meeting with Timothy Campbell using People Finder but cannot find him because Timothy Campbell is stored as Tim C. in the application database. (See Figure 1 above.) Let us store this incorrect entry Timothy Campbell in a database table called “Relation Database Table for Sally” (See Figure 2).
Figure 2: Incorrect entry inserted in the Relation table for Sally
STEP 2: Determine if the user has found the right person.
Next, let us say Sally tries a few more names in the People Finder text box, which generate no results. We store all of these incorrect entries in the Relation table. After a few failed attempts, Sally asks her colleague how to find Timothy Campbell in the address book. She is told his name appears in the address book as Tim C. Sally types the name ‘Tim C.’ and gets a result with Tim C.’s details. Sally adds Tim C. to the meeting list. It is this action of Sally clicking the Add button that allows us to identify a correct entry for the Relation table. (See Figure 3.)
Figure 3: Sally now types Tim Campbell’s name as it appears in the database.
STEP 3: Build a relation between the previous incorrect entries with the correct entry.
We then build a relation between the previous incorrect entries with the first following correct entry (i.e., Tim C.) and add it to another table called ‘Alias’ for the staff Tim C. Think of the Alias table as a ‘People also know Tim C. as …’ list. Note that the basis for saying that there exists a relation between the incorrect entries and the correct entry is the real life observation that people do what they must to find the correct name to type in the search text box. Of course you may get mismatches but this will be taken care of in the next steps.
Figure 4: Tim C. is related with the previously typed names
Figure 5: Alias table for Tim C.
STEP 4: Check the strength of relation by observing patterns across all users.
Next we identify the most common aliases used for finding Tim C. We do this by looking at the Alias table for Tim C. Those aliases that appear frequently are strong candidates to be displayed with a “Did you mean …” feature. In our example Timothy Campbell and Tim Campbell show a good pattern across different users as aliases for Tim C., so we conclude that when people search for Tim Campbell they mean Tim C.
Figure 6: Alias table shows that lot of people type Timothy Campbell or Tim Campbell to find Tim C.
STEP 5: Present common patterns as “Did you mean …” feature on the search results page.
The last step is to present the most common pattern to the users as a “Did you mean …” feature. In our example when -users search Timothy Campbell we present them with Tim C. as a “Did you mean …” feature. We can show additional information like the department, title or a photo of Tim Campbell so that the user can confirm that it’s the person he is looking for.
Figure 7: Implementation of the “Did you mean …” feature
Making the system efficient
The secret to making our system more efficient is eliminating -irrelevant relations. Consider this question: Should you build a relation between an incorrect entry which was entered at 08.30 and the next correct entry entered at 09.20? Probably not! It is very unlikely that the user will search for the same person after a gap of 50 minutes. A time frame of 20 minutes may be more realistic.
Advice on how to go about building such a system
- Build a business case
Building such a system will take time and resources. You will need to present an argument to management why this is important and perhaps make a business case for the effort. Don’t forget to include key stakeholders like Human Resources while presenting the business case. Here are some key points:- Users will save valuable time while searching other staff.
- Colleagues will not be disturbed – their time will be saved.
- Companies will save on phone bills and employee time.
- Systems become robust over time without additional work from users or a massive data cleaning effort.
- Collaborate and co-ordinate with different IT teams who build applications
Pepare a list of all applications that use the People Finder feature. Collaborate with the IT teams who are responsible to build these applications and work out a plan to implement the “Did you mean …” feature on the current applications. This task becomes easier if you have a centralized IT team. - Prioritize applications for implementation
Our system becomes robust when many users use the system. Start implementing the feature on the “Frequently used by many” type of applications first. These applications will give maximum value in shortest amount of time.
The risks
There is a risk that few users can work together to build a strong pattern of, say, “Jerk” with Rob Stevenson, thus manipulating the system. This can be kept in check by doing two things. If your company is like ours (formal and very particular about its image) you can:
- Keep pattern strength high especially if the suggestions to users are going to be automatic without human intervention.
- In addition to high pattern strength you can include a manual check done by HR admin who can authorize or investigate each strong pattern. To do this you will need to provide an admin interface to HR where they can monitor and dig deeper in to strong aliases.
Going forward
Just as users learn a new system by using it, possibly by making mistakes on the way, a system can also be ”trained" to learn from the users by continuously “listening” to users inputs, while helping users along the way. Though some development effort and technical know-how is required, more intelligent people-finding features on company intranets are essential. There is a long-term payoff, and companies will be saving a great deal in terms of employee time and costs.
