Re-Entry Resource Hub
A web-based hub of helpful agencies, forms, and general living resources to aid incarcerated persons in their transition back into society
MISSION - Redesign a resource discovery experience to better help incarcerated persons with accessible needs gain access to valuable resources to aid in their process in re-entering society
TIMEFRAME - March 2022 - September 2022
CLIENT - A major state department of corrections and rehabilitation
ROLE - Product designer / product manager consultant, collaborating with a junior client product manager and developers
SITUATION
Our consultancy staffed a project with a major state department of corrections and rehabilitation to modernize their legacy tool (a hub of re-entry resources for incarcerated persons, or IPs for short, hosted at specific kiosks) into a web application that can be accessed by IPs anywhere they have a networked device. I joined the project part-way through the lifespan to backfill for the designer / product manager rolling off, and my responsibility is to support the team in finishing the MVP and launching the pilot.
At that time, a good portion of the vision and experience of the digital discovery hub app had been mapped out, but a huge risk to a successful launch was that the app needed to be accessible. The goal posts were fuzzy: our stakeholder understood that accessibility (or a11y) was a requirement because they did not want to get sued, but they had no idea how to determine compliance nor what the compliance rules were. Fortunately, in early scoping for this project, the team flagged a11y as a priority, and a11y development was adopted in some part by the engineers (e.g. when the initial forms and pages were built, our engineers knew how to use the correct semantic markup for page elements and labelled inputs appropriately), and knowledge has been shared with dev pairing and strict code reviews. However, this was done largely as a “style” of our engineering, and a11y work tasks (with rigorous acceptance criteria and code tests) had not been added and prioritized in the backlog.
Furthermore, we only had a superficial understanding of the accessible needs of our users from the initial rounds of product exploration. We learned from our subject matter experts (SMEs) on our prison population that many of those re-entering society were very limited in their exposure to digital experiences, and many had reading levels akin to elementary school students. This was enough for us to start building empathy for our users, but it was not sufficient as concrete pain points that we could solve and measure our success.
TASK
Thus, my to-do list on various fronts emerged:
- For client stakeholder, we would help them find this invisible line in the sand for a11y and define success metrics for how we know we have successfully crossed it
- For product research and management, we would plan and execute ways to test a11y with users and translate our learnings into engineering stories that we would prioritize
- For design, we would update the current styles and components to be accessible, and we would establish guidelines for the team to integrate a11y in future features
- For myself, while all of the work was happening, I would brush up on my own knowledge about a11y so that I can be the advocate on the team to influence teammates and stakeholders on the value and importance of a11y design
ACTION
With help from stakeholders, I identified an a11y SME in our client team organization who had helped test other in-house applications for a11y compliance in the past, and I led a conversation among leadership, SME, and legal to clarify the a11y requirement and success metrics. It turned out that even as a state agency, we had to be compliant with Section 508 of the federal U.S. Rehabilitation Act for digital a11y. In practice, this meant conformance with the Web Content Accessibility Guidelines (WCAG) 2.1, with the AA-level (the middle amongst three) as the goal. In order to know how conforming we were (and would be going forward), our SME successfully pushed our stakeholders to adopt an external a11y audit. But that posed an interesting challenge with our iterative process of development: our team was pushing to production every week with iterative features and improvements, but it wouldn’t make sense to conduct a11y audits on a weekly basis. After discussions, we decided on a plan to try out: do an audit ASAP, and then time future audits around major releases - it would give us some clarity now and accountability along the way, and it had legal weight as a “good faith argument” should we get into trouble.
Our a11y SME recommended an external audit org (that incidentally was a venture employing incarcerated individuals as trained analysts), and we opted for an initial audit by sending them key flows of the application to review. While we waited for the results, the SME, our engineers who were more savvy about a11y, and myself collaborated to review the application as it stood - using tools like Figma/web plugins and voice-over apps to simulate a screen reader - and identify general and blatant a11y violations (e.g. insufficient color contrast between button bg color and text, functional graphics without alt-texts, text sizes too small). I then worked with our junior client product manager to write those changes into user stories/chores so that we could begin committing them to code, start writing unit tests for them, and eventually build automated scans as part of our release pipeline. Our Labs engineers adopted strict code review and knowledge documentation so that the more junior client engineers could learn and have material to refer back to later. I also updated our style guides / proto-design system to bake in those updates so that accessible components could become part of design best-practice.
It wasn’t sufficient that we did our own assessment of a11y without learning from our users, so I included a11y testing as part of our regular user validation engagement. We enlisted help from our stakeholders to identify a range of IPs who had prior demonstrated some form of disability. In preparing for those user interviews, I set one of our desired outcomes to be to understand the specific a11y need our IPs had in completing the core flow of the app, and I prepped my co-conspirator PM to help look for those needs and take notes. These sessions were eye-opening. We confirmed that our IPs had low reading literacy, between 4th and 6th grade level for many of them (as our SME suspected), because some of the words we used in our body copy did not make sense to them. We discovered from our officers that some IPs have been incarcerated for so long that they had barely used any computer or digital devices in decades (e.g. one interviewee didn’t grasp the concept of password requirement, and another asked for help typing a capital letter on the keyboard).
Our learnings here led me to redesign some parts of the application to prioritize a11y. Tasks like rewriting the body copy of our whole application were easy to do, but some of the other features required a bit more refinement. I iterated on the password set up flow to make it very transparent what the rules were and how well they were being met - with redundancies built in so that it was both textual and visual. One of our key findings that was not as apparent to us but that was shared by the officers accompanying the IPs during their tests was that re-entry could be an extremely overwhelming experience, and that our IPs could easily get overwhelmed trying to prepare for that while juggling the mountain of paperwork and checklists. Thus, I made it a point to prioritize cognitive a11y so that we could help reduce the cognitive load that our users had to bear while using the app. That translated to simplifying pages so that it was easy to stay oriented, making text hierarchy extra clear, or using graphical icons to accompany selectable options. With help from the balanced team, we also re-examined many assumptions that we had taken for granted as digital-natives (such as recognizing that there might be more options hidden behind a “dropdown” or a “hamburger” menu) and tried to find designs (such as a flattened out top nav menu) that were more universal.
RESULT
The several discussions I facilitated among our stakeholders and a11y SME led to a consensus plan that gave every party involved something that they wanted: client leadership wanted a Sept pilot launch timeline as the success story to tell, our a11y SME wanted a fully audited and remediated application, and legal wanted as little risk of being sued as possible. Thus, I worked with my client product manager to make some tough decisions in ruthlessly prioritizing product features so that we can work in the most valuable a11y remediation work, with our initial as well as ongoing periodic audits scheduled to demonstrate a strong good-faith legal argument - all while still meeting the original intended launch date in Sept.
Our initial audit came back with some nice surprises! First of all, it was a lot cheaper and faster than we expected, which gave our stakeholders more confidence that they can continue funding ongoing audit efforts. In our iterative design process, a product is never fully finished, because there is always room for improvement and ways that it should evolve with changing workflows and circumstances in reality. That means that there would always be room for it to fall out of compliance with a11y. Getting our stakeholders to see a feasible timeline and budget for doing continual a11y audits this time would encourage them to consider this for future application development efforts, and that way we would have more accessible tools out in the world. Plus, this project helped us build a relationship with our audit vendor.
Secondly, our audit found much fewer violations than we had feared! This was largely thanks to the engineers laying down a strong a11y foundation from day one. The fact that we had fewer issues to fix, and that some of those issues were features we knew to be less impactful to address for our specific group of users (e.g. skip links for repeated elements), allowed for us to sacrifice fewer capabilities in prioritization. For example, we were able to develop a robust password assistance tooltip to explain why a particular chosen password might not be sufficient for the security requirement of our app, and we redesigned the user registration process using a stepper to make the experience more guided.
These experiments in new design patterns received affirming feedback from our IP users as well as stakeholders in early usability tests, which gave us the confidence that we were heading in the right direction. The rework did bring some frustration to client engineers because it meant that they had to redo features that they had worked on much earlier, but our user research gave us actual stories of how our IPs might or might not be able to use the app to find re-entry resources, and that convinced them to be on board with the a11y effort. It also helped that the rework exposed several a11y issues with the front-end library that we were using, and those were good learning moments for our engineers to carry onto future projects.
Many thanks to teammates and delivery leads from Tanzu Labs and our client organization