Flywheels distill complicated sets of business processes down to the most critical inflection points, enhancing stakeholder focus.
A business flywheel is an alternative to the more traditional “funnel” that graphically portrayed processes must follow to get and keep customers.
- The center of the flywheel is the business process the flywheel is describing.
- Each of the boxes around the flywheel is an “inflection point.”
If any of the infection points break or degrade, the flywheel positive feedback loop derails.
Stakeholders need to focus on activities supporting the flywheel, prioritizing elements that keep the inflection points from breaking.
If you take the Amazon sales model flywheel above and adapt it to the accessibility world, it looks like this.
Let’s dive deeper into each of these individual inflection points and how they connect, starting with better accessibility compliance.
Better accessibility compliance
Beginning activities that influence better accessibility compliance include:
- Establishing a public accessibility statement citing a particular standard your organization intends to meet.
- The ability for customers to quickly tell you when you haven’t met that standard.
- starting a training program so everyone involved with the software (designers, developers, QA) understand the requirements for the chosen standard.
More advanced better accessibility compliance activities include:
- An established process for resolving customer complaints.
- An accessibility champions programs, so accessibility knowledge is embedded in all parts of the organization, not just the accessibility team.
- Automated tests that can be integrated as early as possible in the software development lifecycle, so efforts can focus on manual assistive technology-based tests that can’t be executed manually.
When you improve your accessibility compliance, that leads to the next flywheel inflection point: more disabled customers.
More disabled customers
My employer did not announce when it released its first accessible product. No fanfare or press releases. We only had a small amount of accessibility “defects resolved” information buried in the release notes. Within 48 hours, we had our first bug report from our first screen reader user.
People who don’t work in accessibility were appalled while I was doing a happy dance. Why?
No release ever has perfect accessibility.
Bug reports mean 1) the user with a disability made it far enough into the product to find an issue, and; 2) was asking us to fix the bug so they could continue using the product.
To me, that was a victory. What happens after disabled users start using your products? They are going to log bug and feature requests. Which means you have to support them. That leads to the next flywheel inflection point, which is More Accessibility Focus.
More accessibility focus
Once disabled customers make themselves known, the people who look at the numbers will take them seriously as a group whose concerns must be addressed.
Focus transforms accessibility from a feature frequently treated as disposable to make a release date to something that requires attention and care throughout the software development life cycle.
More accessibility focus can take the form of:
- Creation of a disability-specific support channel
- Changes in orientation and training ensure new individuals have the appropriate level of training, so they will be less likely to break accessibility that others have accomplished.
- User research focusing on the usability needs of customers with disabilities.
- Accessibility maturity improves across the entire organization, including things like including accessibility/disability in:
- Job descriptions
- Performance reviews
- Procurement policies
- Social media
- Reasonable accommodations
- JEDI (Justice, Equity, Diversity, and Inclusion) initiatives
- Employee Resource Groups
Organizations that have achieved critical mass in employees understanding accessibility, have disabled customers, and having prioritized accessibility in development initiatives leads to the next inflection point on the accessibility flywheel, which is more accessibility features.
More accessibility features
If you build it, they will continue to come. Having the entire organization understand accessibility will naturally result in more accessibility-related features being proposed and implemented.
- Discussions with disabled users performed in the “more accessibility focus” infection point will lead to feature requests.
- Any new features being proposed will be looked at through an accessibility lens. For example, a cool “drag and drop” function might be proposed. Stakeholders will now have the accessibility maturity to know that they must include a keyboard-navigable equivalent for the product to stay accessible. Keeping the product accessible so the flywheel doesn’t derail should be important to the organization.
- Procuring more accessible products and making HR, orientation, and training accessible to employees with disabilities will result in hiring more employees with disabilities. These employees will also point out areas where accessibility can be improved.
The activities associated with improved accessibility focus lead to better accessibility operational practices.
Better accessibility operational practices
How do you get better at something? Experience, otherwise known as practice, practice, practice. The more accessibility efforts performed, the better and more efficient the organization’s accessibility operational practices should become. Here are some examples.
- You’ve got more employees with disabilities, but giving them reasonable accommodations is a hassle? Create a centralized budget and a catalog of pre-approved accommodations that people can order for themselves. Streamline the process by automatically approving anything under $100 or not always demanding medical documentation.
- You’ve got everyone trained and testing, but accessibility bugs are uncovered too late in the release cycle? Integrate your automated tests into your CI/CD pipeline so you can reject check-ins that break accessibility tests that were previously passing.
This inflection point leads back to better accessibility compliance, which is where we started. If the organization has completed the beginning “better accessibility compliance” activities, the next time through the flywheel, take on the activities I identified as advanced.
Where should my organization begin?
This is the question I hear most often. In a flywheel, hypothetically you should be able to begin at any of the inflection points as long as you make sure that progress does not get interrupted as you travel from one inflection point to the next.
I generally recommend starting with “better accessibility compliance” because I feel it is the easiest point from which to start the flywheel spinning. It is difficult, for example, to improve accessibility maturity across the organization when you don’t know who or where your disabled customers are, or don’t have an accessibility statement. Many of the items listed in the “better accessibility compliance” inflection point are fairly straightforward to implement and entirely in the hands of the organization. Being able to find employees or customers with disabilities have outside influences that may make accomplishing those efforts easier or harder.