TL;DR: The onboarding process was fragmented, mirroring the multi-layered organizational structure, and system access had a host of varying requirements due to some being legacy systems. Sometimes new staff started without having had accounts created for them, not realizing they needed training to access certain systems needed for their job, or with confusion about which credentials to use for which system. I created a previously nonexistent listing of all systems used by multiple organization units across the department, and included information on access, training requirements, and links to information on accessing and using those systems.
Development and Alumni Relations is a department that cuts across Johns Hopkins University & Medicine, which, in addition to being a very large organization, has many layers—central, institutional (University, Medicine), campus/office location, and school or division levels. Thus system access and training often had many layers as well.
When new Development and Alumni Relations (DAR) staff started, as I did in September 2016, the following were common issues that came in as questions for Technical Training or tickets to Customer Support:
- Occasionally, new hires did not have all of the appropriate employee accounts set up for them before they arrived.
- Both managers and new hires were unsure of what system access was available to all employees, which types of access required training, and what those training requirements were.
- There were a few older systems that were not able to be put on Single Sign On, which required maintaining separate credentials and often caused confusion.
- New hires in offices without any peers in the same role often did not realize there was a system they should have been using for particular tasks because no one told them.
There were other efforts in progress to streamline the onboarding process and improve coordination, but there was no single list of the systems that a new DAR staff member might need. Similar to the onboarding plan, information architecture and usability would be key.
My thought process was as follows:
- People can’t ask for what they don’t know exists.
- Too much currently depends on a manager or the particular Customer Support agent knowing what types of access a new employee will need based on a.) recall, and b.) their individual institutional knowledge.
- New hires and managers need to be able to see a single list that includes:
- A description of what the system is used for, so they can determine if it’s needed
- Access information (URL, type of login credentials, whether access must be requested or is given to all employees, whether access has other restrictions such as training or organizational unit)
- Training or other learning resources
- Customer support contact information, since different customer support teams handled different systems
- We do not want to overwhelm people with information, so an online format would be handy so we can list names and logos, then viewers can expand to view more information about that system as needed.
Using Confluence, where I was already building out a self-help knowledge base, I created a page that listed the systems most commonly used by DAR staff that were used by multiple development offices and offered at a department-wide, division-wide, or enterprise level. Specifically excluded were systems used by individual offices and niche systems, such as those used by HR or IT.
For each system, I displayed the system name, logo (or a screenshot of the main GUI screen), and link (if applicable), and a one sentence description of the system. Users were able to expand the area beneath each system listing for more information, including access, training, customer support/technical assistance.
Here is what the Frequently Used Tools List would look like when first navigating to the page:
Here is a closeup of what the list looks like when sections are expanded.
Tools + Methods
- Information architecture