How can we be really inclusive in our product choices?
Recently we have been talking a lot about inclusivity at Hemnet. It all started with Yichu, a UX student intern doing a fantastic job identifying what are the problems that people with visual impairments encounter when using Hemnet. Yichu had a quote that hit me in the presentation that she prepared to summarize her work.
She wrote ”choose not to include is to exclude"
Image from Yichu presentation
When reading and thinking about it, I immediately reflected on how this mindset of including everyone could be in contrast with a common way of thinking used in product development: ship and learn fast.
I am guilty of categorizing ”edge cases” and making product decisions that actively excluded some users from a perfect experience to launch and learn faster. I see a great value in putting a version of the product that we want to build in the hands of users to test assumptions and see if our solution actually solves a problem. At the same time, I also strive to create products that everyone can use and are inclusive. But can speed and inclusiveness go hand in hand when we actively compromise with one to achieve the other?
I strive to create products that everyone can use and is inclusive, but I also find myself guilty of cutting corners to learn faster. This realization made me have a product-identity crisis and reflect on what I really stand for.
The balance of speed and inclusiveness is not an easy problem to solve, but I see it as a fundamental discussion to have any time we build something. Product people have a lot of power to shape products that are used by many and if that product plays a key role in a fundamental step in people’s lives (as we do) we also have a great responsibility of making the right choices.
I do not have a silver bullet for this, but I have been thinking about some concrete things that we can do to cater for inclusive speed:
Do not compromise with your core promise
Pinpoint the core flow of your product, the real job to be done, and make sure that it is fully inclusive. This way everyone will be able to use your product for the main purpose it is built for.
Be ok with cutting some corners to test ideas, but design for inclusiveness when your solution is validated
In the same way, we make time to make the solution technically robust, we should make time to make the solution fully inclusive.
Inclusiveness is a mindset
We will never be done with it, it is therefore important not to think about it as a project but to incorporate it in the way we design products. One way would be to have inclusiveness aspects baked-in in our component library and explicitly talk about it in our UX forums, for example.
Broaden your user-test group
Include minorities when you test your hypothesis, you will catch problems sooner and create empathy for those users.
Do you actively work with inclusiveness and have you found other ways to balance it with speed? I would really love to start a discussion on the topic with anyone who has concrete experience.
If you want to read more about the topic, here are a couple of interesting reads:
Tips from Google on how they work with inclusion practices
A concrete list on how to make your design decisions more inclusive
Like what you read and want to have more?