Designing a Knowledge Sharing Platform at Atom
By: Anthony Conta
Tags: Knowledge, UX, User Experience, Design, Edtech

Sharing Knowledge About Knowledge Sharing

Photo by Janko Ferlič on Unsplash

Maintaining project documentation is challenging for many organizations. From wikis, to specific folder structures, to where files are stored, there is a real problem with keeping track of the content that goes into building products. When you’re focused on shipping a product, there isn’t always the time to make sure the decisions you make on a daily basis are written down in a neat, organized way for someone else to follow. As a result, when people want to reference those decisions, the “why” and the “how” behind building a product can be lost.

At Atom, we haven’t found the perfect solution to this problem (yet). However, we’re very passionate about learning and providing knowledge, not just with our users, but also with ourselves. We’re constantly experimenting and iterating how we approach knowledge sharing, and have decided to experiment with a system that allows us to keep our knowledge in a centralized, company wide space.

The vision for this system is simple to describe — create a place to keep information, so that employees can share and access knowledge more easily. However, that problem grows increasingly complex as one begins to delve deeper into its true meaning:

How do we motivate employees to change their workflow and contribute to a knowledge base?

What type of information is important for them to share?

How can others sift through all of that shared knowledge to access the most important information to them?

Photo by bonneval sebastien on Unsplash

As I began to explore systems to address this problem, I realized that our approach would be perfect for the UX process. We want a solution to people’s problems that considers their pain points, motivations, behaviors, and uses cases, but that also balance’s Atom’s objectives and constraints. By framing the problem in this way, I was able to apply the lens of user experience design and work towards a solution.

Defining the Problem

In order to design the right thing, I needed to start by defining the problem better. “A platform that shares knowledge” is a bit vague, so I needed more concrete details to focus my scope.

I heard a lot of different wants and needs from the team for what the solution needed to capture, which included:

Any reports, prototypes, or other documents associated with a project

Projects that have been just kicked off, are in progress, or are completed

The team members for each project (so people can reach out to them)

The values of each team within Atom and the department as a whole

Quarterly objectives and key results for Atom

Links to JIRA boards and sprint planning, for each team within Atom

Release notes for updates to projects

Privacy (accessible to employees only)

Additionally, we wanted to capture multiple use cases:

Find the documents for the projects my team is working on

Learn more about projects I know about, but don’t directly work on

Learn about new projects I’ve never heard of, but want to learn more about

And we had to accommodate different levels and verticals of knowledge, considering:

Project proximity: different users will have a different understanding of project specifics (direct team member in Atom, indirect team members in Atom, any employee across Kaplan)

Domain expertise: various users will seek out, digest, and understand information differently (developer, designer, product owner, stakeholder, CTO, CEO, etc.)

We already have several tools that solve these issues, but we didn’t have a single, unified place that brought all the knowledge together for everyone across the organization to view easily. We didn’t need another tool; we needed to use the resources we had to bring everything together in one spot.

Given the wide range of users, use cases, and information to present, we needed something scalable, customizable, and easy for anyone to contribute to and maintain.

Researching Solutions

Photo by Noble Mitchell on Unsplash

With a greater grasp of the problem I was solving for, I turned to research platforms and structures we could adopt at Atom.

WordPress Plugins

There are a variety of different WordPress plugins that are cheap, effective, and easy to use. These plugins would allow us to sort and store a lot of information, but at the expense of a well designed interface, automatic updates, and custom integrations that were necessary to solve our problems.

Examples: Knowledge Base, Documentor, WeDocs

Wikis

A second approach was to explore the idea of a wiki, which would be a great place to organize information sequentially and by project. Additionally, wikis are low cost options that can scale easily across projects. However, the drawbacks are that they require someone to enter all the information manually, require a good deal of initial setup, and they too are limiting from an interface and integration perspective.

Examples: XWiki, ReadTheDocs, DokuWiki

Project Organization Tool

Another approach was to use a project management tool that lives on its own server and is highly customizable. However, this option costs a lot of money (sometimes tens of thousands of dollars). These tools would enable us to stay organized automatically, but at too great of a cost for our team to afford.

Examples: Confluence, Sharepoint

Custom Website

Finally, since we had a custom problem that we wanted to solve for, we could build our own solution based on common website editors like Squarespace or Wix. This option would let us organize information the way we wanted to visually, define our own branding, and link out to documents or folders the way we wanted to. However, it too would require some setup and structuring.

Examples: Squarespace, Wix, Google Sites

Prototyping a Solution

Weighing all of our options, I decided to prioritize a solution based on:

Cheap to set up / maintain

Quick to install

Easy to contribute to

Integrates with JIRA / Google Docs for automatically synching content

Out of all the options available, a custom website built with Google Sites was the best solution for our team.

$Free.99

Google Sites are free to create and maintain, provided you have a Gmail account (which is also free).

Easy to Use Interface

A sample of Google Sites’ interface. The options on the right, such as text boxes, Drive links, and layouts make adding and structuring content easy and responsive. Courtesy of Google Sites.

Google’s editor is very simple to use, and while the micro interactions on the site have a learning curve to make managing content more efficient, any person on the team will be able to contribute to the page depending on how we set up our permissions.

Permissions Based Interactions

Courtesy of Google Sites.

We have the ability to easily restrict access to viewing and editing the site, meaning we can establish contributors, viewers, and unauthorized access easily across Atom, Kaplan and general internet access.

Integrates with Google Drive

A sample portion of a project page. Courtesy of Google Sites.

You can link directly to specific files, or even folders, which means as people add content to a spreadsheet or presentations to a folder, that information will update automatically on the website. No grooming required.

A sample structure for how we use Google Slides to share information at Kaplan. Courtesy of Google Sites.

I can’t understate the importance of the Google Drive synching — by setting up templates within Drive, you can customize the look and feel of a Google Site with your own branding and information structure, while using the same documents your team uses to get work done. It’s a win-win.

Integrates with embeds

Courtesy of Google Sites.

If you’d like a more custom integration, such as JIRA, you can embed a link to that site and see it on the website easily. Updates made in JIRA will update on the site as well.

Global Search

Courtesy of Google Sites.

Google Sites also come with a global search feature, allowing them to find any component of a project on the website.

How can this solve the problem of sharing knowledge?

One thing was very clear in our research – every system has its own set of flaws. Some are too difficult to use, or are too cost prohibitive, or require a lot of grooming. The best part about a Google Site approach, for our team, is that it easily fits into our current workflow (which is to store documentation on Google Drive and goals through JIRA) and allows us to build a database of knowledge automatically through linking to the site. By working with the habits and motivations of our team, the site builds itself, provided a project leader sets up their page at the start of a project and grooms the site periodically. To enable project leaders the best way possible, we also created templates for good web page structure and Google Drive organization, which lets us homogenize our presentation and our process.

What’s next for the Google Site?

Photo by felipe lopez on Unsplash

Building a framework for documentation can only go so far – it requires people to use the system, and for that system to evolve over time as the needs of the team change. Overall, we’ve created a framework that allows people to easily track, organize, and share their documentation across Atom. The next step is for us to use this system, provide feedback about it, and for us to iterate on it further. I’ve already been surprised with how people at Atom have started to integrate it into their workflow, and seeing the energy they devote to it is breathtaking. People at Atom are very passionate about sharing knowledge, and I’m excited to keep learning from them.