Welcome to the next edition of my Design Strategy blog series. Today, I’m sharing a client story with the hope that y’all will focus on thinking about WHY you should do things differently so that your program can rapidly mature and scale quickly. I will once again skip the “how-to” article formula and dry laundry lists of tactical “do this/don’t do that” mechanics. On to the story…
The Problem
This client came to us to do an assessment of their digital property. “Of course,” we said, “we’d be happy to help!”
Their website had a heap of issues. It’s important to know that that’s okay. Focusing on the positive side of this, the client now clearly understands where they are and what needs to be done.
Heck. This scenario is actually better than okay–it’s fantastic! Why? Because we are working with a client that’s now eager to roll up their sleeves not just to remediate, but also to dig around to find and fix the root cause. In other words, they’ll focus on fixing what went wrong and put energy into understanding what can be done to make sure it doesn’t happen again. This focus will help their organization quickly scale and mature.
From this point, let’s look at how this played out. We’ll examine the root causes and their associated learning opportunities.
Are There Themes in These Findings?
As I started to wade through this client’s assessment results, I noticed some key themes. In this case, more than half … HALF!!! … of the issues were related to Name/Role/Value. Like a lightning bolt, it came to me— “Let’s start here!” OK, maybe not a lightning bolt…but an obvious place to get significant progress, quickly.
Name/Role/Value
Let’s align on some specifics from Web Content Accessibility Guideline (WCAG) Success Criteria 4.1.2… [Read this like one of those TV commercial spokespersons that read those dry bits at the end very, very quickly.]
States and properties are attributes used to convey essential information about an element to screen readers and other assistive technologies. Some roles require certain state and property information – such as the checked/unchecked state of a checkbox. This code needs to be valid in order for a screen reader to convey the information to a user. Every user interface control must have a role along with any applicable states and properties so that screen reader users know how to interact with the control. Developers must add the relevant role(s) and any applicable states and properties as well as expected swipe interactions.
Let’s explain this better with an example. Say we want the user to opt out of newsletter subscriptions (rather than opting in) when they complete a form. So, we design a user experience where the “Sign-up For Newsletter” checkbox is pre-selected; the choice has already been made for the user. The user has to unselect this before submission if they do not want to sign up for a newsletter. The annotation in the wireframe must detail for the developer that the checkbox should be checked “on” as part of their build so that it appears checked on page load. This annotation also informs the tester to ensure that the checkbox is checked on page load as part of their testing process. They, of course, will also test that it can be selected (off and on) and test that it can be submitted properly in the unselected state.
The ‘A-Ha!’ Moment Followed by Contemplations and Insights
Let’s look at the final sentence of that blurb a little more slowly:
Developers must add the relevant role(s) and any applicable states and properties as well as expected swipe interactions.
As I contemplate this statement, I begin to wonder how the developers would know they need to add the roles, states, and properties. More importantly, I wonder where the values have been documented and what they are defined to be.
With even a little industry experience under our belts, we know that if something is not defined and documented, developers sometimes move forward with their own definitions. And yes, sometimes they push back saying they do not have all the information they need to code efficiently. Not every developer just makes stuff up to move the code downstream.
Further contemplation makes me think about the journey analyst (some companies call this business analyst or agile story coach.) What expectations does this client have on their JA? Did they realize this information is missing as they wrote the Jira story or captured the requirements. Are they empowered to push back on the designer to define it. Does the client define a RACI to this level of detail?
This leads us to some insights:
- Informed teams have established roles that define who is responsible for which task. In this case, the user experience designer should be specifying these details in their wireframe annotations and design leaders should be ensuring that these details are present and appropriate prior to Design Review. For those with component libraries, this information should be clearly defined in the component’s supporting documentation.
- Successful organizations have checks and balances: Everyone in the work stream double checks the work from the previous step in the process. If anything is not meeting standards or is out of spec, the work is returned to the step in which the error occurred for repair. This is possible in large part because everyone in the team understands everyone’s roles and responsibilities. This knowledge allows them to immediately know the right person to correct the problem. This is not only more efficient, it helps to ensure the whole team’s success while building stronger teams.
- NOTE: Want to see this in action? Watch your favorite big chain coffee store’s team in action the next time you’re waiting for a delicious coffee beverage. Everyone understands each position’s contribution and the importance of proactively chipping in to keep the whole thing moving along effectively.
- Team members must be empowered and encouraged to speak up in the moment. When they see something is missing or not quite right, they speak up. They understand the savings in time and effort if problems are rectified as soon as possible. In this case, the issue could have been prevented by the Design Leader or an Accessibility Subject Matter Expert (SME) during the design phase. It could have been caught by the journey analyst in their effort to ensure that the developer has all the information they need to successfully code. The developer could have pushed back to inform everyone earlier in the stream that this information was missing. The tester could have caught this issue when they were working on their test script and reviewed the wireframes. There were several opportunities for this issue to be prevented from moving into production.
- Mature accessibility testing should have been able to identify this issue prior to production where it would be less expensive to repair than an issue found in production.
- The level of risk (and cost, too) is compounded when process failures are considered in addition to the WCAG violation.
What Could We Do with These Insights?
There is a lot of “meat” here to generate improvements, efficiencies, and strong methodologies. Work efficiently, but also take time to employee design thinking tactics to understand your issues and possible solutions. (In the end, this actually improves efficiency.) Plan strategically to sequence process changes and adjustments so that they are both measured (for ease of adoption by your teams) and prioritized (to bring your organization the most value at the earliest opportunity.)
Some considerations:
- Use trends in your data to tackle your issues based on quantity, ease of repair, or ability to repair.
- Build role matrixes to ensure that all the needed bits are identified and assigned to a role. In this case, Role/Name/Value should be documented by a user experience designer. The Design leader should have the assignment to ensure its presence and accuracy.
- Ensure that all team members understand the contributions–and the importance of those contributions–for the roles and activities that precede them. Ensure they understand the importance of their contributions to those that follow them in the process.
- Empower your team members to understand the value of taking a moment to fix something when it’s in front of them as compared to the effort and cost if those issues come back sometime later as tickets or defects.
- Help your teams to understand the value of cross-checking work and that pointing out flaws or issues is a good thing. Complaints are a gift if they happen early enough. (There are any number of books on the subject of complaints as a good data resource; I encourage you to look these up later..)
- Ensure that your SDLC processes are analyzing and testing accessibility at each stage of the process and often within the various stages.
- Use agile retrospectives to examine defect trends and actively work at finding root cause solutions that will ensure no mistakes of that type are made in the future.
- Look for micro-education moments that will help prevent these issues . Create the materials and showcase them in lunch-n-learns, on your accessibility program portal or intranet site, in newsletters, and/or with your learning management tool. In this case, create training for all roles on what Name/Role/Value is, how it should be documented, coding standards, and how it should be tested.
- For those just starting their accessibility program, lean into defect remediation by having your teams focus first on clearing blockers and critical errors. As your sprints or epics proceed, keep adding additional defect levels until all net-new code is free of any accessibility issues. Then have your teams prioritize clearing the accessibility-related technical debt in your product (end-to-end) until testing is showing no issues.
Why I Love This Approach for Solving Design Problems at Scale
Any team and any team member can look at a defect and quickly come up with a long list of potential improvements. But chasing all of the possible options is time-consuming and ineffective. The key is to keep asking questions to get to the root of the problem. (If you recall, we highlighted the Fish Bone technique a few blogs ago.) When a problem is well-defined, it’s easier (and faster) to find the right solution.
Let’s return to the client problem where half their issues were related to Name/Role/Value. I hope you are seeing that I am using this issue as an allegory to help you understand that, as you hash this problem out, you begin to see that the problem goes deeper than role definition. There are team dynamics issues and there’s a cultural problem of allowing poorly-documented wire frames to be built.
Everyone is racing to get this coded and into production. I get it. Trust me, I have been there. But, if you don’t build this well from the start and build the journey so the user doesn’t have issues, you will be back fixing the screens when it doesn’t deliver value to the user or the business.
For me as a strategist and service designer, fixing operational mechanics and process efficiencies is more important to your overall operations than almost anything else. Addressing these can compound the positive benefits that root cause solutions can deliver. Don’t just fix the bug. Learn to fix things in a way that solves problems at scale.
Before we leave, let’s tell you the happy ever after…In the case of this story, the team was able to quickly resolve half of their known issues within a single sprint and they identified who is responsible to initially document Name/Role/Value. They are actively working on team building to ensure everyone feels empowered to point out issues knowing that they actually reduce work in the long run. Well done team!