Mapping Success Together: Tips for Inclusive Process Maps
There are numerous things that we can do to make process maps more inclusive; however, while they tend to go against established practices, they offer a range of benefits to making maps more inclusive for all.
A process map should be standardized within a business to map out the steps to achieve a business goal and show sequential steps, tasks, and gateways. There are a few established standards (UML, BPMN, etc.). My aim is not to advocate methods but to encourage inclusive standardization. Consistency is key, as it enables comparison and evaluation and can also assist colleagues with neurodiversities.
Typically, there are two sight-loss personas: low vision and no vision. Low vision is when a colleague has a combination of: fields—the amount of sight you have (half-close your eyes to see top and bottom field loss). The other is acuity, which is how sharp it can be seen (almost fully closing your eyes until the words go fuzzy can demonstrate acuity loss). The huge amount of variation between fields and acuity loss means that it is very hard to get a one-size-fits-all solution to sight loss.
The second persona has no vision. This is typically what you think of when you think of the word “blind.” No vision means no useful vision—you may be able to see something, but you cannot understand it without third-party intervention. Only a small percentage of vision-impaired people have no vision, but it is crucial to ensure inclusivity for them.
Process maps are inherently visual, so the following tips are mostly based on low vision. Low-vision users, with some tweaks, can read process maps if care is taken by the business analysts to make them as inclusive as possible.
Firstly, some whole-map tips. Use a clear font, classified as “sans serif.” These are simple, non-fancy stroke fonts that are easy to read, e.g., Arial and Calibri. Bad examples are brush script, harlow solid, and monotype cursive. Another consideration is the font size. Typically, it is best to produce it in large print, size 14, or giant print, size 18. This is not just helpful for those with low vision but will also reduce eye strain for fully sighted users. San-serif fonts are also dyslexia-friendly.
Secondly, make the connectors, or the lines between process steps, consistent in both thickness and color. The thicker the better, as there is more chance of seeing them, but they must also be in proportion to the other objects, or else it will look so odd that few people will engage seriously with the map. This is the balance between usability and accessibility.
Advertisement
Thirdly, low-vision users will zoom in a lot more than they are used to, sometimes only having a few letters on screen. With this in mind, there are two things that must be considered: Navigation: ID codes. By coding every step, data object, or note, you allow a low-vision user to navigate quicker using metadata instead of engaging with the full object. Each object class should be different; typically, I use process steps as numbers, notes as N1, N2, etc., and data objects as D1, D2, etc. Depending on which software you use to map your process, this can also assist any user in searching quickly and efficiently.
Screen real estate is also an important consideration. The more you zoom in, the less you can see the bigger picture. So, if objects are spaced far apart, it’s harder to understand the map. I recommend placing objects close together. Where you have multiple connectors coming out of an object, line them up so they overlap, looking like one connector, and have them branch off with the connector text as close to the break as possible, allowing someone who is zoomed in to be able to follow with ease.
Fourthly, color is important. There are several vision-impaired color schemes, such as yellow on black, white on black, etc. These are all highly subjective but share one common feature: they are high-contrast colors. My advice then is not to use similar colors, such as black and grey, white and silver, or white and yellow, as these types of pairings are very hard to see and can be easily missed or unreadable. Neon colors are highly effective, as most accessible technology offers color inversion, and when you invert a neon color, it stays the exact same shade, meaning there can be no misunderstanding in color coding like RAG systems. I advise only using one color scheme, or at most, in the case of impact assessing a process, a RAG for change size and blue for new—all in neon colors.
Finally, for all users, but specifically No Vision users, think about object semantics. By this, I specifically mean connector lines. Accepted practice means that we have no arrow heads on lines, and a double arrow head is assumed. This is presumably to make it look nice. A screen reader, though, has no context for this as there is no semantic instruction to relay to the user. Therefore, adding doule arrow heads will allow the semantic meaning to go through the connector. This is because a screen reader will consider the connector itself, not the thing it is connected to, which is what a person with sight will do. All a screen reader will visualize is a line, and a sighted user will see the line and the objects connected.
To summarize, process maps are visual. We can make them inclusive of low- and no-vision users by adapting our frameworks and standards. Specifically, by looking at font type and size, object layout and identification, color schemes, and the semantic meanings of diagram objects, we can minimize the risk of low- or no-vision users not understanding, thus making the business more inclusive and effective.
These tips are by no means exhaustive nor gospel, so please feel free to use them as a starter for ten, and hopefully they will help you kickstart your own inclusive process map designs!
