Our Goal

The goal with this project was to implement a more formal knowledge base for the clinic. This knowledge base would primarily have information on platforms that we have assisted clients with previously, including what options exist on each platform for various actions such as deleting or memorializing your account as well as archiving your data or giving access of your account to someone else. There would also be third party tools for platform workarounds as well as internal resources and materials for the clinic members and the class element of the clinic.

The Previous Knowledge Base

At the start of this project, we already had a rudimentary knowledge base in place on Microsoft Loop which contained all the information we’d gathered up until that point. However, this knowledge base was cluttered and disorganized with little structure for where things should go and how things should be added. We also felt that Loop was limited in functionality, with little expandability for templates, public facing knowledge, and AI tools that could make the clinic more efficient.

Knowledge Base Needs

Before we could even look at platforms, we decided that we needed to have a good idea of what exactly we needed from a new knowledge base. We brainstormed policy flows around the core ways that people would be interacting with the knowledge base such as adding and updating platforms to the knowledge base, and we put together a list of essentials for the knowledge base, which can be found to the right. We also shared policy flows with the clinic to see if they felt like natural ways for these processes to occur, and updated them accordingly, noting how these flows would connect to features that we would need from the knowledge base.

We also needed to decide on what the template for platform pages should look like. We couldn’t have an exact template decided on until we had also decided on a platform, but we still wanted to understand what the general structure of the template should look like based on the needs of the clinic. The first template that we had been using thus far for platform pages was originally made as a research tool, so it wasn’t necessarily designed for the clinic as a client focused service. We created two new versions of the template, this time focusing more on what would feel intuitive for workers trying to find information for a particular need quickly, and presented these templates to the class in a focus group format, allowing them to interact with the templates and tell us what worked for them and what didn’t.

Selecting a Platform

With notes on both what policies and a template would generally need to entail, we decided that it was now time to decide on a platform. We put all of the general needs for the knowledge base that we had gathered thus far together, and each of us focused on one of the three platforms that had stuck out in initial research: Slab, Confluence, and Outline. We then each researched our respective platforms with the clinic needs in mind and created a pitch deck to try and sell the rest of the team on the platform we chose.

Then came the hardest part, where we had to decide on what platform actually performed the best in relation to the needs we had set out. We tested each platform rigorously, seeing how particular types of content such as platform pages, clinic logs, and end of life planning looked. We also weighed potential trade offs, such as Slab being simplest but naturally least expandable and Confluence being the most feature heavy but missing a few odd features such as collapsible headings. Ultimately though we felt most intrigued by how many options Confluence has for expandability, as well as being incredibly easy to port over a workspace over to another platform like Outline if needed. It was tough to make the final call on the platform, but we ultimately knew that all three were good options, so it came down to what would give the clinic the most longevity and options.

From there, it came down to the implementation of the knowledge base. We did another iteration of templates, this time exploring Confluence specific features that would be most useful for the knowledge base and experimenting with both single page and multi page templates. Once we got feedback from the class about the effectiveness of the template, we finalized the template and got to work transferring all the knowledge from the Loop knowledge base over to Confluence. Finally, we substantiated policies around terminology as well as adding and updating platforms, and the core knowledge base platform was complete.

Analysis Paralysis

The biggest challenge that we faced in this project was around learning when to continue analyzing and weighing options and when to be decisive. The previous attempt at creating a dedicated knowledge base for the clinic hadn’t been successful because the function and needs of the clinic weren’t considered deeply enough, so we wanted to make sure that we weren’t neglecting that. However, we also didn’t want to drag our feet and get stuck in the process of deciding what kind of template would be best or what platform would most perfectly suit the needs of the clinic.

More than anything else I learned that there isn’t necessarily a hard and fast rule when it comes to this balance between reflection and decision making. It’s something that you constantly need to be mindful of when working on a project, and discovering how to quickly and fluidly adjust our project plan to ensure that we can take the time we need to reflect and discuss choices while keeping the end deliverable in mind was a huge skill that I learned from this process. Even with our delay in making a final decision on what platform to use for the knowledge base, we made sure that we were set up enough that we could still stay on track to have the most important elements of our Confluence knowledge base solidified by the end of the semester.

Another challenge that further complicated this balance was how interdependent certain elements of the process were on each other. You needed to create policies and templates and share them with the clinic to understand what their needs really are and use those to decide on a platform, but you also can’t lock those policies and templates in stone before you decide on a platform as there might be specific features or structures about a platform that end up changing your templates and policies. This ultimately just meant being okay with a constantly iterating process with each of these things, allowing the idea of a template to exist both as a temporary physical thing for testing as well as a concept that might exist in the same form by the time more things have been solidified. This project ultimately made me much more confident in existing in an ambiguous environment and trusting that the process that we have already outlined will lead to that final concrete deliverable.

The final deliverable for this project ended up being what we’d hoped for, a fully implemented knowledge base for the clinic using Confluence. We were able to implement policies for using the knowledge base as well as a platform template that is easy to duplicate, modify, and transverse. More than anything, this knowledge base has given the clinic base structure that is strong enough for future growth, as we hope in future semesters students will explore features like AI automation for tasks, public facing knowledge, and many other features that we barely got a chance to scratch the surface of.

Ultimately, this project aimed to be a good foundation for the future of the clinic, providing a fundamental knowledge base system that will easily be able to continue to be expanded and iterated upon by future members of the clinic. We hope that our careful and deliberate decision making with this project has led to the success of this goal, allowing the clinic to continue to innovate with its infrastructure and continue to provide efficient and personal support to its clients.