Brief Considerations on Design Topics: 14. Inclusive Products, Long Lasting Solutions and Tortuous Usage

I’ve long been an advocate for building inclusive product solutions. One of the aspects I find the most rewarding about crafting solid product outputs, beyond the fact that it pierces through the needs of its users with quality and usability standards, is the fact that it does so in a democratic fashion. It reaches a wide array of users, across multiple demographics, ethnic backgrounds and hopefully cultures. Typically these are solutions which require a fair amount of iterative cycles, a robust amount of testing, in summary a considerable investment in research. And while I’ve noticed throughout the years a progressively more visible focus on Inclusivity (and accessibility), it wasn’t that long ago that many digital products and the teams behind them didn’t consider this to be a priority, which manifested itself in lackluster solutions on the market, with products which failed to meet minimum requirements of multiple platform usage, to name but one of the most obvious issues. Here’s some considerations that I’ve taken into account during my career when crafting inclusive products, which hopefully can generate some interesting reflection and conversations.

1. Build a Design System which accounts for Accessibility/Multi-Platform/Multi-Language standards. This of course sounds rather straightforward, but it’s surprising the amount of products that fail in taking these aspects into consideration. The World Wide Web Consortium (W3C) lists a variety of resources which empowers teams to tackle these problems that much easier. The same goes for The Interaction Design Organization and also The Nielsen Norman Group, to name but a few reputable sources of information and guidance when it comes to crafting these foundational Design Languages. Building a Design system is a considerable investment, but also something that delivers immense (and measurable) results, namely empowering teams to build product solutions consistently, rapidly and with a focus on standards and quality, something that otherwise simply doesn’t exist. Always keep in mind the qualities of good UX (useful, usable, findable, desirable, accessible, credible), alongside the laws of UX making sure the solutions delivered meet those parameters (and those of the Principles of Design themselves). And just as importantly always keep in mind that the Design System that is crafted, does indeed contemplate all those parameters, and effectively solves for all these variables, as opposed to being an archaic and monolithic platform which ends up generating just as many problems as the ones that is trying to solve. Always remember: a Design system is meant to empower and democratize solutions. Not castrate and undermine innovation.
2. Research a lot. This goes without saying. One of the main pillars of Human Centered Design is precisely “Rapid Iterations of Prototyping and Testing”. However and even before getting this far ahead, teams should do pre-research, in the shape of further collecting data on Market, Demographics, Product Standards, Economics, Politics, Compliance, essentially each and every factor which possibly weighs in on users’ habits and how they’ll perceive and use your solution. People don’t consume product solutions in a dome/bubble. They’re influenced by what happens in their households, with their jobs, with the current political environment of their country, to name but a few factors. It’s important that teams understand the context before proposing solutions that may otherwise be a disservice for their user base, and just as importantly, solutions that can discredit the brand perception on the market. While pre-research can take some time, gathering all these sources of data, it’s time well spent, since it also forces the incubation teams level setting their own knowledge base.
3. Iterate and Test. A lot. Again, a self-explanatory statement. And a direct sequel to the previous point. Typically solutions that truly pierce through an identified problem will require quite a lot of iterations and testing. Remember that not all users will perceive a solution the same way. Testing will demonstrate how the concepts are resonating (or not) with those potential consumers. It’s crucial that Design teams are swift in their prototype cadences, be it in sketch/wireframe/UI phases. These prototypes and the materials which sustain them, be it stencils, shared libraries for Figma and XD, should be well structured and functional (Design Systems once again). Just as importantly, it’s fundamental that once testing sessions are done, that processing synthesis is done efficiently and in a timely manner. This informs the iterative cycle further, and allows for the team to understand trends, patterns of usage and uncover the narrative that the users are telling from using the prototype/solution itself. Do not go into this cycle with the expectation of having your unconscious bias confirmed. Be as open to feedback as possible, since only then can you truly benefit from what the testing is telling you. And once again, look into the principles of the Design to make sure that your solutions are in fact something that translates into value for users, for the organization and for retention.
4. Life to its own. Always keep in mind that a product released is not a product finalized. A solution deployed will have to continue to evolve in order to accompany the ever changing user base. And make sure you keep learning from that usage, either through Voice of the Customer sessions, Reviews, Metrics, Customer Support engagements, any source you can retrieve. Remember that product solutions may at times have a different lifecycle, flow of usage and utilization that you may not have initially thought of. And be flexible about it. Case in point. I’m a regular user of Duolingo. I love learning new languages and I find the app a great solution for doing so. However the whole gamification aspect of that ecosystem is of no interest to me. Learning for me is a reward in itself, and I find it a bit unsettling being on a leaderboard with a bunch of strangers. The app is at the point of usage where it’s alienating me. Listening to what users are saying, and refining solutions is not a statement of weakness, quite the opposite. It’s a statement of strategy — the more inclusive and diverse you make a solution, chances are the more users and retention you’ll produce.
5. Keep Inclusivity as part of your Mission Statement and revisit your Design Principles regularly.

I’m going to wrap up this Brief Consideration article with a quote from Malcom Forbes on the topic of diversity:

“Diversity: the art of thinking independently together.”