Designing for Critical Actions
Here at ButterflyMX we strive to make interactions clear and intuitive. This cannot be truer when considering actions that have critical implications on the ButterflyMX user experience. Actions that would fall into this category would include allowing device permissions as it relates to visitor notifications, deleting content or changing critical account settings. Over the next few examples, we will discuss our process at iterating upon designing for such scenarios.
Example 1
The first scenario we’d like to highlight: the need to ask for notifications and camera permissions. For our system it is essential for a tenant to receive notifications and allow camera access, as this makes visitor calls possible. Without these permissions turned on, a fundamental purpose of the application would be lost on the user. Accordingly, an initial approach to this was to essentially lock a user out of the application until they allowed the mentioned device permissions. The reasoning here is that the user would not be able to experience the primary feature of the app if they did not allow permissions, so why ever allow them skip this permissions step?
Upon further design consideration, we opted for a more user-friendly approach. We realized that creating a sense of choice is more important than we were allowing for. We realized that we needed to create a smarter solution to increase a user’s sense of autonomy. Our current approach allows the option to disable notifications and camera access, even though this would make it impossible to receive video calls. However, whenever the user presses on an instance in the app which requires notifications or camera access, we will remind them that the app needs the device permissions to be enabled.
This approach allows the user to explore the app and gain trust with the app before allowing access. When they arrive at an action that requires permissions, they are more likely to accept this request, because they have a familiarity with the app and an increased curiosity in the feature which they are currently locked out of. This is also known as “dangling the carrot” of user permissions.
Example 2
Next we’d like to discuss button design when dealing with critical actions. The ability to open a building’s door is the most sensitive action possible in our mobile application. A user would not want to open the door for the wrong person. We originally featured a more traditional, static button to allow the user to open the door. We realized that this was too simple and too prone to error. After several iterations, we landed at this version, which allows door opening via a swipe. The process of sliding one’s finger across the screen is a much more deliberate action than that of a single tap. This is the key point, that critical actions should require deliberate action, as in the case of this swipe, and mitigate the ability for a user to make an action by mistake.
Example 3
Another approach to mitigate a critical action occurring by mistake can come in the form of the classic “Are you sure?” modal. We are all familiar with the iOS and Android standard iterations of this. To expand upon these ubiquitous SDK pop-ups further, a multi-action design virtually eliminates critical actions happening by mistake.
By including two additional check boxes, as in the image above, we can communicate with the user more explicitly what their action is going to cause, and it requires them to interact with the screen several more times before completing the action. A key here is to use explicit language to communicate with the user. We don’t want to recreate the classic “OK | Cancel | Apply” scenario of UX yesteryear.
