Methods for designing with disabled persons
Co-design, design thinking and similar concepts are about developing offers together with the target group. Unfortunately, such concepts have not yet become established in Germany, at least in connection with disabilities.
Article Content
- The problem
- Involve the users
- counterarguments
- Customer or non-customer - that is the question
- Social Factors
The problem
The core problem might be that the traditional manufacturers of medical aids do not see the disabled as customers, but rather the payers. For many products, such as screen readers, the health insurance company, the employment agency or the pension fund usually covers the costs. They don't really care what the quality of the tools is, they don't have to work with them. The manufacturers of medical aids, on the other hand, don't really care what the customers might want. In the screen reader market, for example, Freedom Scientific, the developer of Jaws, had a virtual monopoly for a long time. Jaws has always had its quirks, but overall it was a serviceable product. No other program has supported so many office programs so well.
But at some point they lost contact with the customer. The program kept getting bloated, more and more features were implemented that hardly any user needs, but nobody worked on the stability.
It is therefore not surprising that Window Eyes, NVDA or VoiceOver outperform Jaws, at least in the private sector. NVDA and the Linux screen reader Orca are community projects that are fast, stable and simple. Window Eyes has a sensible update policy, Freedom Scientific is the Apple of tool manufacturers.
A similar problem is likely to occur with manufacturers of other aids. The special navigation devices Kapten or Trekker Breeze are offered for resale in bulk. Nobody wants to lug around such an expensive, inflexible piece of equipment when they can buy an iPhone for the same price that has its limitations in terms of accuracy but combines the capabilities of many individual tools.
There is no doubt that blind persons have been involved in the development of these applications. But they are employees of the company and just as operationally blind as their sighted colleagues. It's like having a computer scientist develop a ticket machine: everything works perfectly, but no outsider can operate it.
Involve the users
In the field of blindness and visual impairment, the classic manufacturers of aids will no longer have a great future if they do not learn to adapt to the wishes of the users. One possibility is cooperative design, as I like to call it here. The aim is to involve users in the development process of services or products as early as possible.
In the early days of product development, you just made something that you thought the buyer would take. There was a "seller's market", the user had to take what was there or he was unlucky.
Later came the buyer's market: users had the choice between different products. Companies tried their products and pulled them off the market if they didn't work. This is the standard today, thousands of products come onto the market every year and almost always disappear as inconspicuously as they came on.
The next phase should be to involve interested and committed potential users in the development process. This will certainly not happen with all products, but it makes sense for some.
There are different methods that I don't want to go into detail because I'm not really deep into the subject.
One possibility is the testing of prototypes by a selected group. This focus group should work with a prototype because they can better determine what they like and don't like about a concrete object. You can also gain a lot of knowledge by letting the group discuss. You need a facilitator who can ask the right questions with a lot of skill, without manipulating the group in a certain direction. For example, there is a project in Berlin where seniors test technology .
As a rule, it is of little use to ask users what they would like, they do not know. They do not reflect sufficiently on their actions to be able to make meaningful statements about them. Therefore, observing persons doing specific activities with the envisaged product or service is a co-design opportunity, with their permission of course. The student Sarah Wölfel developed cookware for blind persons , interviewing blind persons and observing them in the kitchen.
This is reminiscent of the usability check from web design, but unfortunately this test only starts at a relatively late stage. It is only checked whether the users can cope with an almost finished product and not whether what they could use is there.
For the reason mentioned, I do not consider questionnaires to be useful either. Out of curiosity, I recently looked at a very long questionnaire from the blind association DBSV on blind navigation systems. While some questions were certainly justified, others were rather poorly thought out. A blind person who has never been guided by a GPS only knows theoretically which functions he would need. Observing ten blind persons with no navigation experience using an existing navigation system would have been much more insightful.
I think the aid manufacturers would very soon come to the conclusion that younger blind persons in particular place more value on getting sensible-looking aids. The second insight would be that a cheap price is more important than all features which are possible. Today it is more difficult than ever to get even simple aids from the health insurance company, we are the customers, not them. This should become the mantra of the tool manufacturers. Unfortunately, my opinion about the behavior of the health insurance companies is not suitable for young persons, but unfortunately we cannot change anything about it.
The third realization that should mature is that expensive tools that are rarely needed are no longer bought. If you only need a navigation system three times a year, you might as well do without it. Why not open a rental service that temporarily lends the equipment and earns money with it?
counterarguments
There are two counter-arguments that are put forward against a cooperative design.
On the one hand, this process increases the costs. An empirically reliable method must be developed in order to obtain meaningful results. persons have to be invited, questioned and the results evaluated.
However, the cost of product development is generally high. No outsider knows how much it costs to design a simple gadget cell phone, for example. It is certainly not cheap and the costs for the process steps described would certainly only make up a small part of it.
The second argument is that users don't know what they want. While that's true, do we know what they want and if so, how do we know? Or do we tell them what to want? You get the idea, it's about systematically and non-suggestively finding out what persons want, and that can only be done in a process that's appropriate for that.
Customer or non-customer - that is the question
Of course, I used examples from the blind here, because that's where I know best. But I think these findings can be transferred to other devices such as hearing aids or devices for AAC. You can put up with the fact that they are expensive, you can put up with the fact that they don't push the envelope. But combining the two is going too far.
I'm not very optimistic about the adaptability of our manufacturers of medical aids. As long as the profits keep flowing, it doesn't seem to matter what the disabled want. I tend to suspect – or rather I hope – that new companies or community projects will develop from the disability movement, which will set up their own projects bypassing the old ones. Approaches to this are recognizable, many apps come from those affected themselves or go back to initiatives from these circles.
Social Factors
- Crowdsourcing and Accessibility
- Waht social projects can learn from inclusion
- Be careful with studies on digital Accessibility
- Open Data and Accessibility
- Curb Cut - how Non Disabled profit form inventions made for Disabled
- How everybody can contribute to Accessibility
- Caught in a lack of Accessibility