Technical debt and bugs are issues nearly any development team are intimately familiar with. But how many of those teams prioritize user experience (UX) debt and accessibility alongside tech debt and bugs? Would most even view these design concepts as critical pieces of app development?

At Dealerware, our Design and Engineering teams, in cooperation with many other parts of the organization, have elevated UX debt and accessibility to the same level of importance as their more commonly-known cousins, tech debt and bugs.

In a presentation to the User Experience Professionals Association (UXPA) at their UXPA Boston conference, Dealerware Director of Design, Todd Zazelenchuk, along with Product Designer Patrick Drake, explained how they went about bringing constant monitoring of UX debt and accessibility issues into Dealerware’s agile development workflows.

The first step was understanding the problem: UX debt, like technical debt, is the cost of having to rework a user experience solution later so you can employ a faster, easier-to-implement solution today. Accessibility refers to the characteristics of a product that allow it to be effectively used by your intended audience, regardless of their potential differences in abilities. 

Addressing these issues requires team dedication, skill, empathy and experience. For the presenters, the last piece presented the most challenge – UX debt and accessibility are too often sidenotes in development processes, overshadowed by more deeply technical concerns.

A picture of Dealerware product designer Patrick Drake, who says "by designing inherently accessible products, you're designing inherently usable products."

Working with an accessibility auditing vendor provided the team with access to experience and knowledge that would help the rest of the organization view accessibility and UX debt as critical categories of work – a major goal in the Design team’s effort.

Though working with a vendor may not be every team’s choice, careful vetting helped our team find a partner who met a few key criteria – testing was not just automated, but done manually by people with differing accessibility needs. Audits could be requested on the schedule our team wanted, and the vendor provided easy-to-understand reports and ratings of different pieces of the product so that the severity of issues could be easily communicated to the rest of the organization.

With this framework in place, the Design team got buy-in from Engineering and other teams to add UX and accessibility issues to existing development workflows. Like our scrum teams were already doing with feature development and bug fixes, the combined team started to document UX and accessibility issues and work together to walk them through kanban boards that moved solutions from the research stages to “Design Done,” at which point they’d enter the Engineering backlog for buildout.

A chart showing how Design workflows would lead into Engineering workflows. Design begins by identifying UX or accessibility issues, then tracking progress on fixes in a kanban board. Once a solution design is agreed upon and finished, it moves into the engineering backlog to be developed and later deployed into a live app.

Simple, right? Maybe, but often the most difficult parts of process change are getting buy-in and maintaining commitment to the change. This is another area where a long-term vendor relationship helped the team ensure their commitment, but what about commitment from the wider development team, or the whole organization?

What came next in the team’s plan is still talked about here at Dealerware as one of the most powerful meetings anyone has attended. Commitment requires empathy and personal attachment to an issue. To foster this, the team gave a presentation during a company all-hands in which several employees bravely shared personal experiences that give them different accessibility needs.

Drake revealed that he’s a colorblind designer, and demonstrated the toolset he uses to check his work. He also educated the company on how common colorblindness is  — affecting 1 in 12 men and 1 in 200 women. He pointed out that hundreds of Dealerware users are likely to be colorblind, so his experience and its impact on his work help us deliver more usable tools for our customers.

Another employee shared how Stargardt macular degeneration requires them to rely more on peripheral than central vision, which makes large-font text and screen readers an important part of their ability to use apps. During their UXPA Boston presentation, Zazelenchuk and Drake shared that this person’s experience helped them identify an experience-breaking issue with extra-large text sizes, and also contributed to a company-wide effort to write or revise alt text for screen readers.

A color vision deficiency test
Having any trouble seeing numbers among the colored dots? It may be worth talking to an opthalmologist or having an eye exam.

Finally, a third employee helped the rest of the company understand accessibility in a broader sense by sharing their experience with central auditory processing disorder, which limits their ability to take in and process sound. As Drake told the UXPA Boston audience, we often think of web accessibility in visual terms, but this person’s experiences helped Dealerware teams to also consider the auditory and cognitive elements of product design that might make a user experience more difficult.

For many in the company, making accessibility and UX issues personal cemented the commitment that the Design team was looking for. As a part of their initiative, the team tied UX debt and accessibility to their annual Objectives and Key Results, and by the end of the third quarter had made significant progress toward their stretch goals: increasing Dealerware’s accessibility compliance score and integrating UX debt reduction into our agile workflow. 

Want to join our team? Find all of our open positions here, or learn a little more about our company, mission, values and commitment to our employees on BuiltInAustin.