Technology, Community, and Code: Building an Inclusive UX

We need to be aware of our role as developers and designers in shaping identities as we build our products. It’s critical to understand how code creates communities, online and offline, and how those will be experienced by minorities and the underrepresented— does it marginalise them? Does it enable them to be successful? Let’s learn about those responsibilities, how to be aware of them, and how to build better tech in the process.

Transcript

1. Hi there! @IvanaMcConnell
2. Inclusive UX
3. Inclusive + user experience
4. inclusive =/= universal
5. inclusive (adj.) “not excluding any section of society or any party involved in something.”
6. community (n.) “a group of people…practising common ownership” “sharing or having certain attitudes and interests in common”
7. identity (n.) the answer to “who am I?" what communities do we belong to (and not belong to)?
8. products are communities
9. The best ones foster a sense of togetherness Shared bonds: “I am a [product] user.” products are communities
10. both govern experience— they enable interaction and task completion community = shared experience, built by code & design Code and design matter
11. exclusion what is exclusionary UX?
12. Healthkit “Your whole health picture.”
13. #AirbnbWhileBlack
14. Twitter https://modelviewculture.com/pieces/you-think-youre-helping-the-silencing-of-domestic-violence-victims-on-twitter the “protected” feature silences you for others - this is a design and coding decision
15. Nextdoor
16. Facebook + Snapchat
17. Each exclusion is a decision Someone said yes in response to “will we implement that?”
18. “You don’t belong” Exclusion happens when a product which should empower us does the opposite.
19. Who should your product empower?
20. Who does your product empower?
21. Inclusive UX How do we do it?
22. Bias
23. Bias We all have it. Now address it.
24. Bias We all have it. Now address it. How?
25. If each coding and design decision contributes to a community, we should be able to plan for inclusion at each step… ….right? Break it down
26. 1. Understand the problem Should you build this? Should you make the decision?
27. Empathy has limits Can you really understand how your product will be experienced by a minority? … and if you can’t, should you really be making decisions?
28. 2. Appoint the right decision- makers Coding and design decisions (“yes, we should build that feature”) must be made by those affected
29. …involve them from the start… Asking folks to use a product assumes that a product should be built.
30. …and trust them. Listen. If they tell you that something doesn't work, make the change.
31. 3. Build with intention “move fast and break things” =
32. 4. Mistakes will happen 
 (and that’s OK) It’s how you react that matters!
33. It just has to include those for whom the solution is helpful. “We may not be able to end discrimination but we can provide a solution for people. And that’s ultimately what our company is about: people.” - NOIRBNB 5. inclusive =/= universal
34. Inclusive UX What does success look like?
35. Nextdoor: before
36. Nextdoor: after “When race is included, you must include at least 2 of the highlighted fields.”
37. Mobility Map • Involved the campus’ Disability Resource Center from initial concepts • “It is an example of one of those things that is never done, just on hold until I know more about it.” http://www.keating.design/work/mobility-map/
38. Wayfindr “We are working closely with the Youth Forum at the Royal London Society for Blind People (RLSB), exploring what it could be like for a vision impaired person using the London transport network in the near future.” “we started to explore the journeys together and rapidly prototype and explore ideas.” http://ustwo.com/blog/designing-wayfindr/ https://ustwo.com/blog/validating-wayfindr/
39. “Why was the choice an important one, and why did it matter to the people of color who saw it? The simple answer is that they rarely see something like that.” “These small choices matter, so make them whenever you can. People will notice, and they’ll feel good.” Just a Brown Hand? https://medium.com/@uxdiogenes/just-a-brown-hand-313db35230c5
40. Success as the absence of assumption
41. Do you need to…ask for gender (or sex)?
 …know someone’s race?
 …know someone’s ethnicity?
 …know their name or title?
 …use a loud notification?
 Success as inaction
42. “You shouldn’t ask users for their title. It’s extra work for users and you’re forcing them to potentially reveal their gender and marital status, which they may not want to do.
 There are ways to address people in correspondence without using title, for example by using their name.” GOV.UK Success as inaction
43. This is hard It should be. Don’t we pride ourselves on solving hard problems?
44. 1. Understand the problem (and the limits of empathy) 2. Appoint the right decision-makers (and trust them) 3. Build with intention (not with speed) 4. Mistakes will happen (it’s how you react that matters) 5. Accept that inclusion =/= universality Recap
45. Lay the foundations 1. Start with diverse and inclusive teams. 2. Accept responsibility. 3. Collaborate!
46. That one piece of code, that one wireframe, that one decision — made by the underrepresented minority it will enable — manifests in an interface that is inclusive and contributes to a strong community with a strong identity. Lay the foundations
47. Move fast, break things Move deliberately, build inclusive interfaces Move deliberately, code communities Then scale
48. Thank you.
49. Resources • Calm Technology • So, you want to build an algorithm… (ironically, the usability here leaves something to be desired!) • The Government Digital Service’s checklist for digital inclusion • User research that’s truly inclusive (even when the tools aren’t) • Design for Real Life • Airbnb’s Another Lens (I’m aware of the irony, yes)