What is a Stretch Program?
Hootsuite has something called a Stretch Program. This program provides opportunities for employees to “stretch” into other departments and learn new skills. Employees spend 20% of their time working with the new team on real problems. I applied to the program and was granted a research project to work on with the Product Design team.
Overview
What was this project about?
Hootsuite documents accessibility guidelines and learning resources in Confluence. Over time, this resource has accumulated extraneous and duplicate information and became difficult for users to sift through to find the needed information.
My mission was to research and understand how our organization learns about accessibility and uses Confluence to aid in accessibility efforts. 
Results from this project will guide the next part which is to reorganize the information architecture and content of the page to provide more value to our users.

The goal
➜ Conduct research on accessibility learning and Confluence usage.
➜ Will guide the reorganization of the Accessibility page in Confluence.
My mission was to conduct research on how our organization learns about accessibility and uses resources to aid in accessibility efforts.

Why is this important?
I wanted to provide a single resource that will help enable designers, developers, and product managers to understand accessibility and build accessible products. As it stands, the current implementation can use some improvements to bring more value to our team.
By providing our teams with the right tools and resources, they will ultimately be able to provide a better overall user experience to our customers. 
If we improve the experience for those who are differently-abled, it will improve the experience of everyone who uses the product.
Process
How did I go about it?
First I wanted to find out how to shape my project goals.
I wanted to understand how stakeholders want to use the current tools we have to teach, inform and align the organization on building accessible products. In the context of this project, the stakeholders are those who initiated this project and brought this project to life. This team is made up of design and product management.
I started by leading a kickoff to get insight into what we currently know about the state of accessibility learning, what we want to learn from this study, and if successful, what this will help drive.
Project kickoff insights
Read my medium article to learn more about how my project kickoff went and the lessons I learned from it. 
Continue reading to see what insights I learned.

What we know
I learned from the kickoff is that there is a lack of confidence on how to get started and on how to actually implement these guidelines. Teams are muddling through at different speeds with no way to ensure consistency across portfolios.

What we want to know
I've established that the stakeholders would like to know:
➜ Are teams making use of the internal resource provided?
➜ What their experience has been using said resource?
➜ Are they using other external resources? If so, what are they and why?

What will this drive?
If this project is successful, this would help unify our approach to our accessibility strategy, and help ensure product compliance and consistency.
Defining my research goals
After the kickoff, I set out to create a research plan with the following objectives.
Objectives
➜ Understand how teams learn about and document accessibility
➜ Find out what kind of external resources are being used and why
➜ Their experience with the current resource both with the accessibility section and the overall tool

Hypothesis
❓ Teams want a single source of truth to learn about accessibility
❓ The current implementation is unorganized and makes it difficult to find needed information
❓ Duplicate information is created because the current implementation is not known or difficult to use
❓ Teams are not aware of this resource

Key questions
1. What resources are used when learning about web accessibility?
2. What do workflows look like when building or designing accessible features?
3. What are participants' experiences with the current implementation?
4. Have they ever used the current implementation?
Who did I talk to?
I wanted a good mixture of all positions and portfolios, so I recruited: 3 designers, 4 developers and 3 product managers of all seniority levels across 9 different portfolios.
These participants were chosen under the advisement of my PM - these are employees who are working closest to our accessibility efforts or are the accessibility champions of their teams.
Findings and Insights
After speaking with participants, I synthesized my findings and grouped them into the following common themes. 
Themes 
Visibility and awareness
I learned that there was an awareness issue around Confluence, 3/10 participants were unaware that the Confluence page existed until the day of the interview. This led to participants creating new content and guidelines for their teams which resulted in repeated content. 
Participants are accessing other resources before coming to Confluence, either because it’s not part of their workflow or they’re just not aware of it. They seem to lean toward internet searches, searching the company google drive, or asking other team members because it’s quicker to get answers.
Confluence usage
Confluence does not seem to be a part of workflows that are not related to the development team because it is simply not used by those respective teams. 
Confluence is a place to learn the basics. Once that is achieved, participants find their own way to implement learnings.
Usability
Participants feel that there is too much content in Confluence and that it’s difficult to find information that they need - causing them to use other resources. I also found this is why participants tend to bookmark certain tools or resources linked in Confluence so that they wouldn’t have to come back to look for it.
I’ve received feedback that while the resources are there, the way it is presented feels disorganized and can be overwhelming, especially for those who are new to the subject.
Confidence
We have a basic understanding of how accessibility works and why it’s important. But there aren’t any instructions as to how Hootsuite does it. How do we apply these guidelines to Hootsuite products? What’s the Hootsuite way?
Because of this, participants are feeling like they’re left to their own devices and end up figuring out their own solutions that ultimately impact product consistency.
With accessibility, we want an experience that is consistent across the product. We do not want the same component to behave differently across different product areas.
Hypotheses
I'm happy to say that my hypotheses were all proven correct. 

✓ Teams want a single source of truth to learn about accessibility
✓ The current implementation is unorganized and makes it difficult to find needed information
✓ Duplicate information is created because the current implementation is not known or difficult to use
✓ Teams are not aware of this resource
Next Steps and Recommendations
Recommendation #1
Consider organizing information in a way that allows access to feel effortless. Almost mindless.
When information can be found effortlessly, users will naturally come back to use the resource, because they know they will find what they’re looking for. Once the resource is available, we need to make the information easy to access and digest.
There are a lot of great resources out there already on accessibility, guidelines and success criteria. We can build on these existing foundations rather than start from scratch. We don't need to reinvent the wheel. We can show teams where to go to learn the foundations of accessibility.
What we need to provide on our end is how we should implement these learnings on Hootsuite products.

Recommendation #2 
Consider having a team to manage and monitor new and old content.
As an organization, we’ve gotten to a point where we have a good basic understanding of accessibility. There’s no longer a need for everyone to add more general information into Confluence. 
We need information on how to implement these guidelines.
This new information will need an owner, or a team of owners to manage or monitor content. Confluence can no longer simply be a “dumping ground” for information.

Recommendation #3
Consider creating guidelines on how to implement rather than general information.
We need to bring confidence to our teams by providing standardized Hootsuite rules on accessibility. We need to align teams on how this road should be built by providing standardized guidelines. 
This will help increase confidence, thus allowing teams to work more efficiently by guiding them all in one consistent direction.
What's next?
I will continue this project by moving into the next phase, which is to work with the User Education team to learn more about content strategy so I can organize the content better.
Once I've defined a strategy, I will then put my new knowledge to use by reorganizing the information architecture of the Confluence page.
Learnings
This project was an amazing learning experience. I got to experience the entire process, from project kickoff to interviews to data synthesis and had to opportunity to present my findings and contribute to a bigger project.
From this project, I'm able to take my experience and learnings into the next step. While I definitely don't know everything yet, I now have a good idea of how to get started and how to troubleshoot if I ever get stuck. 
It also never hurts to ask your colleagues to quickly have a once over your work - that feedback is invaluable especially when you're learning. 

Take a look at my other projects!

Back to Top