Designing a Useful Fallback

A community center introduced an online booking form for its rooms. Most visitors found it convenient, but a few could not complete the form on their devices. The page displayed an error and advised them to 'try again later,' without explaining how to make a time-sensitive request.

The center added a telephone option during opening hours and a clear description of the information staff would need. This was not an instant replacement for every online function. Staff still had to check availability, and requests outside opening hours would wait. Those limits were stated rather than hidden.

A fallback is useful when it preserves a meaningful next step under the conditions in which the main path fails. Merely offering another button is not enough if it leads to the same obstacle. By testing the alternative and communicating its limits, the center made the service more understandable without promising that every request would succeed.