šŸ¤•Ā Do not harm

It seems obvious but most of the applications we use still harm a lot of people.

Public services, for exemple, are often designed in a concrete unaccessible way considering peopleā€™s needs and obligations to use these services are a good reason for them to adapt.

On the other hand, they are still services and should aim to take care of their beneficiaries, no matter their age, health condition, culture, location, language and more.

This guide will help you emphasize with these people and help you make your services more accessible step by step.

šŸ§‘šŸ½ā€šŸ”§Ā Build transversal

When you create products or build a place, you will work closely with technical teams not only to achieve a plan but also to define the plan.

As a person, you will not be able to understand the complexity of the whole system you are building and these people will give you technical insights while you will expose different problems.

Technical workers are not only doers but also efficient ****problem solvers and should be included in design phase or loop.

Would you plan a trip on moon without astronauts ? No. Itā€™s the same complexity for any field or expertise, no matter what your ego says šŸ™‚

Now if I askā€¦ Should astronauts plan to send random people on moon, would they do that without doing a medical checkup first ? No. And so you wont build your rocket project without user research.

You donā€™t have enough resources for user research ? Then you are probably building for everyone and itā€™s great, but you will have to include every possible users to make you design really accessible.

It could be really hard, if all these tech teams works in separate environments, to connect them with every users need. Actually, you wonā€™t have enough of a life time to make it.

But what if all these people are able to collaborate not blindly following a Y axis communication but operating around an artefact designed to give them the more informations they need, from the user and every stakeholders ? This is when you will consider your service fully transversal.

šŸ§˜šŸ½Ā Build less, learn more

Finally, you will probably want to save time and money on your projects, itā€™s good, we donā€™t want you to splurge public money on meaningless projects šŸ™‚

When you may feel like there is a lot to build while reading about accessibility, you will also acknowledge you canā€™t anticipate everything and shouldā€™t. Designers and developers can easily sense when they are about to lose time on something or, on the contrary, when there is much thing to do.

They will give you precious insights than you should listen to and your beneficiaries will do just the same. Your main goal is to learn from both and assume when you donā€™t know.

As an exemple, there is no need to create a localization process or engine for you to give internationalized content if you have no idea how to make it, you should then not do it, document the unknown and observe it. The challenge is not to be blind, wich you will be if your process is so unaccessible that the people with issues will not feel like you actually want or are able to hear from them.

Try to build your services in an iterative and organic way, step by step, alongside with the beneficiaries and the people you work with.