“As Designed” is a useless bug closure status — especially for people with disabilities

Just because it was designed that way, doesn’t mean it was a good idea.

As someone who started off in software testing over 30 years ago, and then transitioned into accessibility, I’ve seen some crazy bug closure statuses.

Won’t Fix — An acknowledgment that what was reported WAS a defect but isn’t significant enough to get handled. Usage in a sentence: I “won’t fixed” all the bugs we didn’t have time for in this sprint.

BSE — Blame Someone Else, an acknowledgment that the issue reported WAS a defect but the fix is not in the control of the group it was assigned to. This status generally refers to integrated third-party code as the source of the problem. Usage in a sentence: I know I have ten open bugs, but eight of them are BSE, so I only have to fix two.

and the bug status I am ranting about today “As Designed.”

“As Designed” implies that the user has reported something as being wrong, but it’s working exactly the way the designers and developers intended. “As Designed” is slightly different than “Not a bug.” “Not a Bug” bugs contain issues that won’t be fixed for many reasons, including root causes such as configuration problems, unsupported environments, or some other reason causing the reported behavior.

“As Designed” is the world’s worst bug status for the following reasons:

1. “As Designed” completely discounts the user’s lived experience.
2. “As Designed” is a low EQ answer that insults the user’s intelligence, making them less likely to take the time to report future issues.
3. “As Designed” typically equates to “I (the designer) don’t care about what you (the user) needs, I know what you need, and I gave it to you.” That message ultimately erodes what trust and respect exist between the user and the organization.
4. For people with disabilities reporting accessibility/usability issues, “As designed” goes even a little bit further than #3 — it means “your needs are not a consideration,” “it’s OK to discriminate against you,” and “you don’t matter.” Considering the slogan for the campaign for the passage of the ADA was “nothing about us, without us, is for us,” this is effectively a digital slap in the face.

All of the above is exacerbated when “As Designed” is the final ticket status when the developer never has a conversation with the user after receiving the ticket. Too often, developers say without thinking, “that is what I intended, end of discussion,” and don’t stop to consider the other end of the equation — the user. Given that the U in UX is for User, and the C in CX is for Customer, this seems shortsighted at best. Designers and Developers will never have the exact POV of the user. They are also unlikely to have the same assistive technology needs as a user with a disability. The bottom line is, the only way to get the users’ POV is to TALK TO THE USERS !!! Fortunately, that is something VMware does well at through a program called Design Studio. Some of the reviews are individual sessions, some are group sessions. Last year we had 1100 participants in various sessions at VMworld Design Studio.

When writing code, the designers/developers are in control. Once the code is released, all the control that was in their hands is gone. Product users are guaranteed to use your software in ways that were NEVER intended by designers. In the legal field, we call this “foreseeable misuse.” To create the best customer experience, developers need to give up control over the product they built and give some of that control over to users in the form of accepting feedback and implementing modifications.

Here are some better actions to take with user-filed tickets where your initial instinct is “this is what we intended.”

1. Ask the user for more details about why they felt this behavior was buggy. Understanding user expectations goes a long way to being able to give them what they want.
2. Ask the user to describe a method that would make the behavior more intuitive.
3. Talk to the user about the impact the issue is having on their product satisfaction — sure it might only be one extra click, but if that is something the user needs to do 300 X per day, that’s going to make them mighty unhappy.

---

Too often, bugs are viewed by developers, project managers, and product powers as “Us vs. Them.” People interpret having a bug assigned to them far too personally. Taking a collaborative approach that is working WITH the user to figure out why they thought the experience was buggy is the vastly more mature approach.

Users, you can get in on this as well.

• Ask for a more detailed explanation for why it was “as designed.”
• Ask who is prioritizing feature requests and speak with them.
• Include a “victim impact statement” when you file a ticket. Don’t just say what the problem is but why you are asking for it to be fixed.