A tangible digital manual created to ensure that multi-disciplinary teams meet accessibility requirements.

All public facing products in the Ontario Government need to meet accessibility criteria. This assessment process is the “Digital First Assessment”. At each stage of the product life cycle, teams need to submit their project charter and plan and meet a panel. This panel is multi-disciplinary and evaluates if they meet all accessibility criteria.

For example: At the beginning of a project- you would submit your team’s breakdown of roles. You would also present the team’s user research plan. At this stage it would be resourceful to get advice and recommendations for success.

​

Within this central division of the OPS, most teams don’t have product team members. Most teams were lead by project managers, business analysts and developers. Due to the common practice of a “waterfall approach” in this area, most teams saw the DFA as a pain point. Each stage of the product life cycle in this evaluation emphasizes an “agile” method.

​

The OPS has a centralized team specific to administer the DFA process, and be a resource to project teams. They are there to answer questions in their drop in sessions and provide feedback to teams. The DFA team is also meant to give advice to teams of best practices for their project situation.

The internal intranet also had a few webpages with each stage’s questions and rubric. Teams need to fill out all information and submit it for review 4 weeks before their evaluation.

• Team’s were unable to receive immediate feedback on their information submitted.
• Team’s weren’t able to locate complimentary information to guide them for their submission
• Team’s would submit an evaluation request right before launching a product. This would result in a “course correct” or “halt” result, requiring teams to backtrack.
• The organization as a whole did not have designated divisional resources to educate
• The DFA team found answering the same questions about the DFA process ineffective

As a consultant in this division who has evaluated on the DFA panel, many project teams would book calls with me. I would get the same requests over and over to explain the DFA process, why it matters and how to go through it. Most teams that came to me had already started their project and skipped a few steps, since they didn’t see the “need”.

​

Breaking up this assessment process in to stages and respective decks. Doing this would help teams approach this as a resource check in point, not an obstacle to avoid.

Each deck needed to include the following information:

• What part of the product life cycle a team is in
• What they needed to have completed in the prior stage
• A timeline proposal of when they need to finish work and submit it to the panel
• A list of external resources to consult if no one had product experience
• A checklist of items to prepare before their submission and evaluation

Here is the “DFA Part 2- Alpha Stage” deck. This is an example of guiding teams during the product lifecycle.

​

This resource was well received by 80% of teams that used it. Most teams found a tangible resource helpful for them to refer to as they went through this process. Especially those first timer teams. Due to the scalability- teams were able to share this with external vendors they hired. When there was a talent shortage- teams used these decks to onboard vendors.

Due to the positive usability of this resource- organic word of mouth got it to the DFA admin team. They reviewed this tool and asked me for the full set of decks to provide teams for initial questions.

A few managers reviewed the tool and also thought it was a resource with merit. They did suggest reducing some of the content in each deck so that it wasn’t so repetitive and easier to scan. I took that into account and noted it for a knowledge transfer for the next designer to complete.

​

I learned the value of creating a tool/resource. Using design principles I learned that effective user experience needs internal focus. Project teams having a pain points overlooked was not ok. Using design principles I was able to contribute to a division as a leader. Applying design principles to a deck is as valuable as it is to any other product. It needs to have merit, add value and always be on the radar for improvement.

​