Redeveloping the Intranet site for West and moving it to a new platform was the biggest project I worked on at West. It took about two years to complete and pushed me to step outside my comfort zone and learn new areas of web development.
One of the big reasons for this project was to make website updates more efficient. At the time, there was no content management system. All site updates were made on the backend, which could only be made by people with a lot of HTML experience. An employee from the application development team then had to assist with moving the updating files to the live server. There was a lot of mundane work being done by highly skilled employees who could be making better use of their time.
My plan was to move the site to a content management system where users with no coding knowledge could make the majority of the content changes. Then we would implement an automated workflow. This would notify a site editor of the changes and require them to approve before moving the change to the live site.
Auditing the Old Site
The first step I took in this project was to map out the current Intranet site and get a better idea at how it’s structured. The site was very disorganized from years of new owners moving pages around as well as a couple attempts at redesigning the site. Using an online site mapping tool, I added the major site pages in the structure that it currently sat. I also kept a record of all pages on a spreadsheet to keep track of everything.
The pages weren’t the only thing I had to audit, though. I also created a spreadsheet, along with links, to all the documents that are linked in the site. Altogether, there were close to 200.
Choosing a Platform
We decided to use WordPress as our platform because of its flexibility and ease of use. It is the most widely used platform with a large open source developer community. I also had the most experience with this platform and felt confident working in the backend environment.
Navigation
The navigation on the old site was complicated. Multiple links were repeated in different places on the same page adding to the chaos. My solution was creating five buckets in the main menu where the links would be split up. The departments are all stored under one bucket with a more in-depth menu while the other four were basic dropdowns. This solution came to me after seeing how the agency that designed the external west.com organized their menu.
Security and Workflows
One of the big improvements I wanted to make to this was a more efficient, automated workflow and better access control. We didn’t want too many people with admin access but we also didn’t want to the admins’ time to be tied up approving everything. I worked with a team to create a system that consisted of tiers of approvers where the approval required depended on how big the change to the website was. Editors would be in charge of approving content changes and Admins would approve of new pages or functionality changes. Very large changes would need to be approved by multiple admins and the departments that the changes would affect.
Mockups
I wanted this site to be similar to our company’s external site but tailored to our employees’ needs. Using a wireframes/mockup tool called Adobe XD, I began drawing up the page templates. Instead of throwing everything on the home page at the top, I made it more hierarchical, putting the less important links at the bottom and inviting the user to scroll down. I also changed the submenus to be horizontal instead of vertical to give more room to the page content.
Templates
Following the mockups, I had designed, I created several page templates for different types of pages. It was important to have a template that was flexible, bending to the needs of each department. With that in mind, my team met with several departments to find out what they would like to have on their pages. We received some valuable feedback and offered suggestions when they weren’t sure what they needed.
Theme Customization and Plugins
One of the disadvantages of using WordPress is that not all of its 3rd party plugins/themes are compatible with each other. Everything needed to be researched first to prevent wasting money. It was also important not to have too many plugins as it could potentially slow down the site. Many of the functions in the site I ended up coding myself to reduce unnecessary server requests.
Transferring and Updating Content
While we met with departments to discuss what kind of functionality they needed, we also asked them if there were any radical changes that they were making structurally. Some departments were consolidating, which meant changes to our site structure. We also gave departments a deadline to get us any updated content. If no changes were received, we would copy over the content from the old Intranet site. We did this primarily to save us from doing unnecessary work and once new content came in we updated it on the new site.
Active Directory
The biggest challenge of this project was setting up the Active Directory feed. This had been set up on the old site using C# on a .NET framework. At the time, I didn’t have much knowledge of how an Active Directory works so I did a lot of research. I also asked our application development team how our company’s directory worked. The company had a very complex system; the result from years of acquiring companies and not completely merging those directories with ours. There were multiple directories and they were not synced up. Luckily, there was a development team working on this but their project would not be completed until much later than our launch date.
Launch
Because of the magnitude of this project and all the variables I couldn’t account for, I decided to launch the site in two phases. The first launch was of our company news site, The Wire. I chose this because it was separate enough to be a stand-alone site and the content in it wasn’t as vitally important as something like Human Resources. This could also help us grow excitement around The Wire and the new Intranet site.
Many employees at the company worked on computers with dated software so there was concern that the site might not work well on some older browsers. We went through multiple browser compatibility tests beforehand but there are so many variables in play, that it’s impossible to account for everything.
We launched the site on a Monday so there would be plenty of developers available to assist. The launch went very well and no issues were reported. This calmed a lot of fears about browser compatibility. We continued working on the main Intranet site and preparing for the big launch.