Project Description
Inheriting the company Confluence instance, a WYSIWYG wiki tool by Atlassian, it was my responsibility to start building a centralized repository for company resources. This included documentation spaces for each software suite, support spaces with client details, and team spaces with lookups and specific materials. After the design was complete, I began a “roadshow” to demonstrate using spaces and how each team can maintain its own content to benefit coworkers and customers.
Learning Outcomes
- Be attentive to the documentation and resource needs for each team, software tool, and specific use cases
- Analyze and respond to a variety of needs and situations
- Understand and apply major theories behind the profession
- Utilize Confluence to create and deliver content
Reflection
No matter what industry or workplace, from Apple to Zynga, you find yourself in, accessing information crucial to your job or goals is essential to be successful. If documentation isn’t easily accessible, employees can run into issues where they send outdated documentation rather than current materials to customers. No one wants the wrong information going to internal, let alone external, resources.
As a technical writer, my goals were to identify my audience’s needs and address them. This meant working with every team within the company to gather requirements and identify key pain points within their processes. Understanding everyone’s needs, I created Lucid Chart diagrams of each team’s resources, types of documentation and information they owned, and any other conditions other groups could solve (information-wise). Once I saw how the content each team produces and how each team’s needs related, I could start solutioning.
So going in, I had my head in the info-design-game. I was ready for any information problem to hit me so I could dice it UP. Little did I know that the issue wasn’t just organizing content and improving its accessibility; I needed to find ways to convince individuals in the company that these spaces would address their needs. Persuading individuals outright on something isn’t really my style. I can feel the charisma checks fail as I keep trying, but my strength lies in collaboration.
Creating spaces for specific teams and intentionalities (such as a support wiki for customer issues, internal road mapping, project-specific, etc.) was the foundation for the new organization methodology. With each type of space, I would create a tester to tweak and play with until I felt it was “right” (ready for a general review). To quote Lee Clark Jones, “the file cabinet has a sex life.” After I had the core created for each type of space, it was off to tailor it - duplicate and tweak (rename, resituate and build), and repeat.
By involving teams (primarily the leads) when completing important functions within a space, I could keep their attention on my work while providing more opportunities for them to take ownership. I designed the Confluence site to have team spaces for group use, communal spaces to look up or share information, and other spaces to address specific projects or unique use cases. This project completed its intended goal to help improve communication within the organization, improving communication with customers. This process taught me how important it was to obtain user “buy-in” and make them feel they have a stake in the process. By consistently meeting with each team to verify that designs addressed their needs, I delivered solutions that gave people time to work on other priorities.