This discussion is locked.
You cannot post a reply to this discussion. If you have a question start a new discussion

When Bias in Product Design Means Life or Death

I've just read this fantastic post on the importance of considering diversity in product design and wanted to share it here:

https://www.linkedin.com/pulse/when-bias-product-design-means-life-death-carol-reiley


I won't copy everything over, but here are just a couple of the points made that I found particularly concerning:


"In the 1960s, the vehicular test crash protocol called for testing with dummies modeled after the average male with its height, weight, and stature falling in the 50th percentile. This meant seatbelts were designed to be safe for men and, for years, we sold cars that were largely unsafe for women, especially pregnant women. Consequently, female drivers are 47% more likely to be seriously injured in a car crash."


"Microsoft’s vision system was reported to fail to recognize darker skinned people. Today, one of the most prominent applications of computer vision is self-driving cars, which rely on these systems to recognize and make sense of the world around them. If these systems don’t recognize people of every race as human, there will be serious safety implications."


"White men viewing a crowd with 17% women perceived it to be 50–50, and when it was 33% women, they perceived it to be majority women. A simple overestimation like this illustrates how difficult it can be to see the world from another’s perspective."
Parents
  • Great post and link. Thank you.


    An observation from the article
    :

    -Product teams need to do early and iterative end-user testing. Constantly. And from day one."


    I am amazed that all product teams are not already doing early testing (we used to call this, basic testing, in Telecommunications)


    Early testing should also include subsystem testing, so for example, in the PhD studies of "Microsoft’s speech recognition API to build a human-robot interface to showcase our autonomous surgical robotic system" mentioned by Carole Reiley, in the article, the Application Program Interface (API) should have been tested for the speech recognition for all potential users (including voice pitch). Unfortunately in product design, there's a culture of "what you see is what you get" - hence, if an interfacing tool is incorrectly designed, one is either forced to correct it (unplanned project time and cost); not use the incorrect interfacing tool and develop one's own (which could be prohibitively expensive); carry the error in the interfacing tool forward into the new product development (unthinkable and unacceptable, especially if the product is for a critical system); find some means of compensating for the error in the interfacing tool - which Reiley was forced to do in her PhD studies.


    As for iteractive testing, it goes without saying. Iteractive testing also applies to any configuration changes, including requiremnet changes.



Reply
  • Great post and link. Thank you.


    An observation from the article
    :

    -Product teams need to do early and iterative end-user testing. Constantly. And from day one."


    I am amazed that all product teams are not already doing early testing (we used to call this, basic testing, in Telecommunications)


    Early testing should also include subsystem testing, so for example, in the PhD studies of "Microsoft’s speech recognition API to build a human-robot interface to showcase our autonomous surgical robotic system" mentioned by Carole Reiley, in the article, the Application Program Interface (API) should have been tested for the speech recognition for all potential users (including voice pitch). Unfortunately in product design, there's a culture of "what you see is what you get" - hence, if an interfacing tool is incorrectly designed, one is either forced to correct it (unplanned project time and cost); not use the incorrect interfacing tool and develop one's own (which could be prohibitively expensive); carry the error in the interfacing tool forward into the new product development (unthinkable and unacceptable, especially if the product is for a critical system); find some means of compensating for the error in the interfacing tool - which Reiley was forced to do in her PhD studies.


    As for iteractive testing, it goes without saying. Iteractive testing also applies to any configuration changes, including requiremnet changes.



Children
No Data