Confuence Page Information Architecture
Context: Process Automation and Delivery team uses Confluence as an enterprise tool to empower team communication, foster collaboration and maintain documentation
Currently serving close to 100 employees, after 5 years of self-organized usage, hundreds of pages and sub-sections created by multiple departments and project teams, the page tree has rendered itself with decreasing usability, leading to increased lost time for the PAD team
Timeframe: May 2022 – Sep 2022
Problem Statement: How might we improve the navigation of internal workspace page to optimize developer efficiency for information management?
Ideal State: As a program management team, we got together to first discuss and define what our end goal was
Understanding User Needs and Pain Points: I conducted a series of interviews with representatives from each department to understand how they are currently using Confluence page, and what are the biggest pain points.
Research Results
What’s Working Well?
- Confluence is a more user-friendly tool for external stakeholders (outside of development team), especially for documentation purposes
- MACROs allow data to be pulled into Confluence
What are the Biggest Pain Points?
- Confluence page is currently hard to navigate (since names can be updated easily, it makes it harder to navigate without having someone to walk through them)
- Dysregulation
- No clear idea of who owns each page and management of each section
- Once “onboarded” the pages in practice are self-governing
- Not the most user-friendly tool for documentation, e.g. it does not provide real-time collaboration, but it does provide sufficient traceability
- Redundancies
- Most tracking functionalities have been migrated to JIRA
- Duplication and redundant documentation is observed for development team
- Additional tools can be explored to push design specifications
What would Users like to see more of?
- PI (Planning Interval) information
- Demonstration Information
- How-to pages or guidelines in a more organized format
- Onboarding information
- Lessons Learned
- Capacity Management
Design Explorations
I proposed three options of restructuring of tree structure, due to NDA I am unable to show the designs. The improvement committee came together to debate and converge on one logical design we wanted to take forward in the redesign effort.
Validation Methodology
How?
Card Sorting is an information architecture design technique. Participants sort through information (presented as notecards) that makes it most easily accessible and findable for them
Closed Card Sorting: Participants are asked to place specific themed page into a category that has been pre-defined
Tooling: The free version of Optimal Sort was selected as the tool as it provided an easy to use interface to achieve desired testing outcome
Why Card Sorting?
Understand optimal information organization structure that makes sense to the organization
Understand the topics should be included in each section
Optimize information presented so that it is usable, getting feedback directly from our end users
Who?
10 Participants were recruited to from various departments:
- UIUX
- Architecture
- Product Management
- Agilist
- Release Management
- Quality
- Leadership
- Infrastructure and release
Two Tasks answering Two Questions
Cardsorting Results
Task 1: Locate the Functional Specs
- 80% success rate
- Took on average less than 28.1s
- Ease of use scored an average of 6/10
Task 2: Locate Team Roster
- 75% success rate
- Took an average of 53.2s
- Ease of use was scored at average of 4/10
What did you liked about the proposed reorganization?
- Logical, structured
- Easier to find (specifically for PFS)
- SAFe aligned
- More controls and standardization than the current state (was previously self-organized by departments)
Overall, I thought the updated taxonomy was easy to use (from 1 – 7)
What did you disliked about the proposed reorganization?
- Some tasks are still difficult to find – especially pertaining to Task 2
- May not be as easy for a novel user who do not have basic terminology, recommendation to include proper documentation for pathfinding
- Solutions / Portfolio / PDP and its relationship to specific Agile Release Trains are still ambiguous
- “PFS” as a final specification should not be in Confluence page
- May be difficult to manage due to reorganization
If you can change on thing, what would it be? Why?
- Including “Solution” and “Portfolio” level as a form of “resource”
- Ensure initiative will be cleaning up archived data points so only relevant information is accessible in the new structure
- Tips and tricks to use confluence for a novel user
- Introduction of a “WIP” space vs “Project space” to avoid WIP documents cluttering space and resulting in duplicated versions of the same topic
- May not be as easy for a novel user who do not have basic terminology, recommendation to include proper documentation for pathfinding
Conclusion
General consensus across received across departments that the proposed structure improves overall usability (SEQ = 5.5) , and additionally confirmed in free-form survey that the redesign is more logical, standardized, and SAFe aligned.
Although most participants successfully completed the task, many successes were indirect, suggesting room for improvements in the following areas:
- Depth of content page trees for Agile Team information (”too many clicks”) – as reflected in Ways of Working for each Agile Team
- Separating a project space for work-in-progress documentations, and final project space to house final documents
- Clean-up of archived data points, remove unnecessary pages to reduce information overload
Concerns expressed around on ease of use for a novel user – suggesting to emphasize on optimizing the onboarding experiences for new team members, for example:
- Making “how-to” pages more accessible
- Include “Tips and tricks” to heal novel users
After sharing results of the feedback with the improvement committee, we revised the information architecture of proposed structure. The redesign is currently still a work in progress, but the feedback indicated that we were moving in the right direction. As next steps, we plan to implement a small section of redesign section by section, eventually revamping the entire tree structure of the Confluence page so that it is more usable.