Characteristics

Fixed common

• Epilepsy → Solution: make sure the animations do not include flashing, as well as marking places or events when they may be harmful for them. The first solution should be easy to implement if done from the start, hence it is mandatory. The second solution should be also rather easy and cheap to implement, given that when administrators are force to specify if harmful when adding new events or places, and it is mandatory.
• Has young children → Solution: Include a new category for places specifically indicated for families. Should be cheap, easy, and recommended.
• Computer illiteracy → Solution: The UI was intended to be minimalistic and simple to use from the start, partially resolving this issue. Even then, an optional interactive tutorial would ensure every user understands the UI. This should be cheap and easy to implement. Mandatory.
• No driver license → Solution: The app does not focus on travelling and which transports to use from one location to the other. Alternative apps like Google Maps would be recommended. Hence, the app could automatically suggest a direct link between every two places of a schedule. It should be cheap and easy, recommended.
• Dyslexia → Solutions: User larger and easy-to-read fonts (prepared for dyslexic people), add an audio feedback feature. Both solutions should be cheap and mandatory.
• Dietary constraints → Solution: when singing up, the user could be asked for any dietary constraints. Future recommendations will take this into account. This could be changed later in settings. Moderate, as not only the restaurants need to correct indicate this, but also the algorithm needs to be adapted. Mandatory.
• Colour blindness → Solution: Include a Colour Blind mode, replacing certain colours such as red or green by other visible by colour-blind individuals. Cheap and mandatory.

Fixed rare

• Blindness → Solution: Make the app compatible with Voice assistance services (Geerlings, C. (2019, October 21). How to create an accessible app (and why you should). Oberon. https://medium.com/oberonamsterdam/how-to-create-an-accessible-app-and-why-you-should-5493f41f8bdb). Moderate, as the system needs to be built to be compatible from the starting stages, and is very recommended.
• Permanently on a wheelchair → Solution: include filters where places not adequate for individuals with mobility issues are not recommended. Moderate, as not only the algorithm needs to support this but also administrators of events and places need to correctly indicate this. Recommended.
• Limited movement disability, poor motor skills → Solution: The same as above. Moderate and recommended.
• Privacy concerns → Solution: Clear privacy policy, as well as adding the option of using the app without an account, hence not being able to save any information. Cheap and optional.

Changing common

• Financial constraints → Solution: Include a filter where prices can be selected, as well as showing the overall cost when planning a trip. Moderate (as evaluating price is shown in a lot of pages), and mandatory.
• Lack of knowledge of Dutch → Solution: The app can select on default English (most common language worldwide), as well as ask when you start the language of the application (by default English is selected). It is a cheap change, as it simply requires adding another page when signing up and an additional setting option., Hence, it is recommended to be included.

Changing rare

• broken bones / non-permanently in a wheelchair
• Lack of knowledge of English and Dutch