When we first drew up plans to build this chat application, we looked hard at the natural boundaries that existed within the organization. It felt important to take advantage of the knowledge that we had internally to improve the chat experience. We were confident that we could apply internal knowledge to facilitate communication. There are always hurdles to communication, so where can we remove them?
Preconfigured, right out of the box
The first thing we looked at was presence and relationship management. Within the organization, people naturally talk more often with a certain set of other people. These groupings generally follow some fairly were obvious borders, so we chose three of the more prominent natural groupings to start: Departments, Roles, and Territories. Each person who logs into the chat app would have a roster pre-filled with groups of people people with whom they shared a Department, a Role, or a Territory.
Trying a little too hard
It didn't take long to discover that we had gotten it wrong. The biggest offender was the Territory grouping. In several areas, this worked perfectly: territories that had small field offices always could see their local coworkers' presence with no fuss. But for our largest group of users, working out of the headquarters in Philadelphia, the territory group held over 500 names. Not only was this unruly to look at, it was slow to load.
The second place we found we got it wrong were the per-group rooms we created. It made sense that, for example, all call center agents working a particular queue should have a shared conference room. This was easy to do as they all shared a common Role. But what about their managers, who obviously should be included? They come from a different role. We also found we couldn't do it on Department because that was too coarse; that would end up putting the entire call center into a single room.
What were we doing here again?
So we took a step back and asked ourselves, "what problem are we trying to solve?" There were two key answers:
- Users should easily communicate with certain groups by default, so that when a new person joins the company he doesn't spend an entire day adding people to his buddy list
- These groupings need to be dynamic enough to deal with employee turnover, but not so fixed as to be inflexible and prevent communication among the groups we are attempting to serve
Lessons Learned
In the end, we determined that we had not sufficiently counted on self-organization. That is, most of the users already know who they want to talk to. The best thing we can do for them is give them the tools to communicate, and then get out of their way.
We weren't entirely off base at the beginning, but we did need a better model. Now that we have basic chat working, and several user-managed rooms, we're revisiting the idea of pre-built groups. This time we're making them more flexible. Rooms can be created by describing the kinds of people who should be included. Using the call center example described above, we can now create a room that includes the "Confirmation Queue" role plus the "Confirmation Queue Manager" role. We can combine these groupings any way we need to get the right mix of people. And of course, any outsider can be invited by a room member.
As we continue to develop the application and test these ideas, we continue to learn.
The post Throngs at the Gates: Dealing with a large user population appeared first on Mojo Lingo.