How do I design intentional friction in an app?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}






up vote
39
down vote

favorite
5












I am designing an app for iOS where I need to prevent the user from unintentionally trigger an alarm (the action of calling for emergency should be easily accessible, but at the same time it should prevent any accidental initiation).



I don't want to use a confirmation dialog since it requires the user to read and looking for a button in a different position (it seems like too much friction on the other side).



To use a 'slide to' action button occurred to me initially as an good idea, similar to what was/is used to unlock an iPhone screen, but then I run into this topic: Creating a “Slide to power off” like slider on iOS, basically saying that Apple discourages usage of these kinds of components, and they refuse to publish such an app in the store.



Do you have any experience with this kind of user scenarios? Or do you have experience with Apple refusing to publish your app for such reasons?










share|improve this question









New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • This is not an answer so much as a suggestion: a lot of video game UIs contain deliberately difficult-to-perform actions, such as dragging an item from one place to another, holding down one item before another one can be tapped, etc. Consider looking there for inspiration.
    – SPavel
    Nov 9 at 3:09






  • 3




    What is more valuable in your case of calling for emergency - protect system from false alarm or save user by simplifying way to make alarm? Also, does your application always active and never goes into background? If user needs to make app active he need to make some actions to achieve screen with alarm - is it not enough? Could you please clarify your use case.
    – Serg
    Nov 9 at 11:50










  • The intention is to allow user easily and quickly call for help in variety of situations ( quickly - user should not have to read another instructions or confirmation dialog or look for another button, writing anything - there might not be time for it; and also should be easily accessible - user might be in rush, under stress), but not unintentionally run emergency since it's going to alarm authorities / others. Application is not always active, but making it active doesn't necessarily provides enough of friction.
    – enn
    yesterday

















up vote
39
down vote

favorite
5












I am designing an app for iOS where I need to prevent the user from unintentionally trigger an alarm (the action of calling for emergency should be easily accessible, but at the same time it should prevent any accidental initiation).



I don't want to use a confirmation dialog since it requires the user to read and looking for a button in a different position (it seems like too much friction on the other side).



To use a 'slide to' action button occurred to me initially as an good idea, similar to what was/is used to unlock an iPhone screen, but then I run into this topic: Creating a “Slide to power off” like slider on iOS, basically saying that Apple discourages usage of these kinds of components, and they refuse to publish such an app in the store.



Do you have any experience with this kind of user scenarios? Or do you have experience with Apple refusing to publish your app for such reasons?










share|improve this question









New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • This is not an answer so much as a suggestion: a lot of video game UIs contain deliberately difficult-to-perform actions, such as dragging an item from one place to another, holding down one item before another one can be tapped, etc. Consider looking there for inspiration.
    – SPavel
    Nov 9 at 3:09






  • 3




    What is more valuable in your case of calling for emergency - protect system from false alarm or save user by simplifying way to make alarm? Also, does your application always active and never goes into background? If user needs to make app active he need to make some actions to achieve screen with alarm - is it not enough? Could you please clarify your use case.
    – Serg
    Nov 9 at 11:50










  • The intention is to allow user easily and quickly call for help in variety of situations ( quickly - user should not have to read another instructions or confirmation dialog or look for another button, writing anything - there might not be time for it; and also should be easily accessible - user might be in rush, under stress), but not unintentionally run emergency since it's going to alarm authorities / others. Application is not always active, but making it active doesn't necessarily provides enough of friction.
    – enn
    yesterday













up vote
39
down vote

favorite
5









up vote
39
down vote

favorite
5






5





I am designing an app for iOS where I need to prevent the user from unintentionally trigger an alarm (the action of calling for emergency should be easily accessible, but at the same time it should prevent any accidental initiation).



I don't want to use a confirmation dialog since it requires the user to read and looking for a button in a different position (it seems like too much friction on the other side).



To use a 'slide to' action button occurred to me initially as an good idea, similar to what was/is used to unlock an iPhone screen, but then I run into this topic: Creating a “Slide to power off” like slider on iOS, basically saying that Apple discourages usage of these kinds of components, and they refuse to publish such an app in the store.



Do you have any experience with this kind of user scenarios? Or do you have experience with Apple refusing to publish your app for such reasons?










share|improve this question









New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I am designing an app for iOS where I need to prevent the user from unintentionally trigger an alarm (the action of calling for emergency should be easily accessible, but at the same time it should prevent any accidental initiation).



I don't want to use a confirmation dialog since it requires the user to read and looking for a button in a different position (it seems like too much friction on the other side).



To use a 'slide to' action button occurred to me initially as an good idea, similar to what was/is used to unlock an iPhone screen, but then I run into this topic: Creating a “Slide to power off” like slider on iOS, basically saying that Apple discourages usage of these kinds of components, and they refuse to publish such an app in the store.



Do you have any experience with this kind of user scenarios? Or do you have experience with Apple refusing to publish your app for such reasons?







ios






share|improve this question









New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 18 hours ago









Peter Mortensen

1856




1856






New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 8 at 19:35









enn

19624




19624




New contributor




enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






enn is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • This is not an answer so much as a suggestion: a lot of video game UIs contain deliberately difficult-to-perform actions, such as dragging an item from one place to another, holding down one item before another one can be tapped, etc. Consider looking there for inspiration.
    – SPavel
    Nov 9 at 3:09






  • 3




    What is more valuable in your case of calling for emergency - protect system from false alarm or save user by simplifying way to make alarm? Also, does your application always active and never goes into background? If user needs to make app active he need to make some actions to achieve screen with alarm - is it not enough? Could you please clarify your use case.
    – Serg
    Nov 9 at 11:50










  • The intention is to allow user easily and quickly call for help in variety of situations ( quickly - user should not have to read another instructions or confirmation dialog or look for another button, writing anything - there might not be time for it; and also should be easily accessible - user might be in rush, under stress), but not unintentionally run emergency since it's going to alarm authorities / others. Application is not always active, but making it active doesn't necessarily provides enough of friction.
    – enn
    yesterday


















  • This is not an answer so much as a suggestion: a lot of video game UIs contain deliberately difficult-to-perform actions, such as dragging an item from one place to another, holding down one item before another one can be tapped, etc. Consider looking there for inspiration.
    – SPavel
    Nov 9 at 3:09






  • 3




    What is more valuable in your case of calling for emergency - protect system from false alarm or save user by simplifying way to make alarm? Also, does your application always active and never goes into background? If user needs to make app active he need to make some actions to achieve screen with alarm - is it not enough? Could you please clarify your use case.
    – Serg
    Nov 9 at 11:50










  • The intention is to allow user easily and quickly call for help in variety of situations ( quickly - user should not have to read another instructions or confirmation dialog or look for another button, writing anything - there might not be time for it; and also should be easily accessible - user might be in rush, under stress), but not unintentionally run emergency since it's going to alarm authorities / others. Application is not always active, but making it active doesn't necessarily provides enough of friction.
    – enn
    yesterday
















This is not an answer so much as a suggestion: a lot of video game UIs contain deliberately difficult-to-perform actions, such as dragging an item from one place to another, holding down one item before another one can be tapped, etc. Consider looking there for inspiration.
– SPavel
Nov 9 at 3:09




This is not an answer so much as a suggestion: a lot of video game UIs contain deliberately difficult-to-perform actions, such as dragging an item from one place to another, holding down one item before another one can be tapped, etc. Consider looking there for inspiration.
– SPavel
Nov 9 at 3:09




3




3




What is more valuable in your case of calling for emergency - protect system from false alarm or save user by simplifying way to make alarm? Also, does your application always active and never goes into background? If user needs to make app active he need to make some actions to achieve screen with alarm - is it not enough? Could you please clarify your use case.
– Serg
Nov 9 at 11:50




What is more valuable in your case of calling for emergency - protect system from false alarm or save user by simplifying way to make alarm? Also, does your application always active and never goes into background? If user needs to make app active he need to make some actions to achieve screen with alarm - is it not enough? Could you please clarify your use case.
– Serg
Nov 9 at 11:50












The intention is to allow user easily and quickly call for help in variety of situations ( quickly - user should not have to read another instructions or confirmation dialog or look for another button, writing anything - there might not be time for it; and also should be easily accessible - user might be in rush, under stress), but not unintentionally run emergency since it's going to alarm authorities / others. Application is not always active, but making it active doesn't necessarily provides enough of friction.
– enn
yesterday




The intention is to allow user easily and quickly call for help in variety of situations ( quickly - user should not have to read another instructions or confirmation dialog or look for another button, writing anything - there might not be time for it; and also should be easily accessible - user might be in rush, under stress), but not unintentionally run emergency since it's going to alarm authorities / others. Application is not always active, but making it active doesn't necessarily provides enough of friction.
– enn
yesterday










6 Answers
6






active

oldest

votes

















up vote
38
down vote













First, regarding answer that you linked, I think what Apple was having an issue with is the use of the same UI as their slide to power off, not the use of that UX/interaction. They just don't want it to be styled to resemble their power off slider as to not confuse users. If you were to create say, a small blue slider, or a slider that moves in a circle pattern I think you'd be fine.



However, if you want to play it safe, what about press to hold like this:



"press to hold"
Screen recording from MapMyRun app



In the .gif, a user is pressing the "hold to finish" button, which triggers a roughly 2 seconds "finshing" state where a user can let go and cancel the action, or after two seconds the action, in this case "finshing", triggers. There is a visual progress indicator to show the user that they are performing the action and how long until the action completes. You could also experiment with increasing the time or providing haptic or audible feedback to prevent false presses. This also meets your need of not having to read or click anywhere else.






share|improve this answer

















  • 9




    A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
    – HammerN'Songs
    Nov 9 at 5:26






  • 9




    I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
    – Henrik Ripa
    Nov 9 at 7:42






  • 4




    It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
    – Toby Speight
    Nov 9 at 11:03






  • 11




    For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
    – Doktor J
    Nov 9 at 16:34






  • 3




    A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
    – JoL
    2 days ago




















up vote
26
down vote













To send money in my banking app, I must drag a symbol into a target. It is difficult to do accidentally, but quick to accomplish. It may be difficult for someone with limited dexterity or someone who is distracted.



enter image description here






share|improve this answer








New contributor




jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
    – Konrad Rudolph
    13 hours ago


















up vote
21
down vote













I haven't thought this through, but there might be mileage in considering the physical equivalent. On many control panels, such as in power plants or aircraft, the especially dangerous actions have a switch cover that must be lifted before the button can be used.



My suggestion is a control that's normally in a "locked" state, and takes an action to unlock it (perhaps just a press of that control, perhaps a slide). When it's unlocked, it can be used; if it's not used within a reasonable time, or if some other control is used first, the cover "slides back" automatically.



Although it is functionally equivalent to having a "confirm" button or a popup-menu confirmation, the metaphor is somewhat different, and can be presented in a different visual form.






share|improve this answer

















  • 9




    I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
    – Sam Weaver
    2 days ago


















up vote
14
down vote













Additional ideas from this article:
https://www.smashingmagazine.com/2018/01/friction-ux-design-tool/




  1. Delaying the action and allow a window time for users to "undo"

  2. Extra step for security, such as asking for fingerprint

  3. Other types of authentication such as re asking password or 2-factor authentication.


Other articles dealing with the same topic:




  • https://uxdesign.cc/friction-as-a-function-in-user-experience-make-me-think-390ee17c6cf5

  • https://uxplanet.org/when-friction-in-design-is-good-for-ux-e2dd82cfab67






share|improve this answer

















  • 5




    Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
    – sboesch
    Nov 9 at 13:13


















up vote
4
down vote













Let's Talk User Flows & Navigation:




User Flows are a series of steps a user takes to achieve a meaningful goal 1.




From The Science of Great UI by Mark Miller - Navigation consists of two properties:





  • Path - Set of Steps needed to complete a task


  • Step - Physical and Mental Effort


And each step has two properties:





  • Length - Amount of Time to complete


  • Width - Amount of Difficulty to complete.


Difficulty can be broken up into:





  • Mental Difficulty - Remembering information, calculations, decisions


  • Physical Difficulty - Inverse relationship to precision, per Fitts' Law that the smaller the size of an area, the more time it takes to move a mouse cursor to that area.


So if you want to make navigation easier, you can do the following:





  1. Decrease # of steps - ex. Auto-fill city based on zip


  2. Widen steps (make easier) - ex. Increase button size on common actions


  3. Shorten steps (make take less time) - ex. Google's autocomplete suggestions


  4. Add Alternative Steps - ex. Find account by Email or Phone


Contrastingly, if you want to make navigation harder, you can do the opposite:





  1. Increase # of Steps - ex. "Are you sure" modal dialog


  2. Narrow Steps (make harder) - ex. Slide to unlock rather than click


  3. Lengthen Steps (make take longer) - ex. Require long (timed) press rather than click


So all of those tools are within your disposal, and depending on your use case and the severity of performing the wrong action and the difficulty of restoring to the Last Known Good State, you might need any combination.



If the alarm will trigger a nationwide missile alert, you might want to introduce a lot of difficulty, time, and informative content. If you just want to prevent accidental clicks from pockets, increasing the difficulty is probably sufficient. If users might not be aware of the risks of setting an alarm, the introduced friction should include copy to let them know



Here's an example from GitHub that I think introduces severity well





Friction does not have to equal Frustration, so ask your users and get some good telemetry :)






share|improve this answer




























    up vote
    0
    down vote













    I'm a fan of GitHub's approach where you have to type in a repository's name as confirmation when deleting a repository.



    enter image description here



    Your user could be asked to type in something like "911", which is very difficult to accidentally do. The string could be adjusted for locale and desired difficulty.






    share|improve this answer










    New contributor




    tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.














    • 1




      The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
      – kasperd
      9 hours ago










    • The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
      – Dave
      6 hours ago











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "102"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    enn is a new contributor. Be nice, and check out our Code of Conduct.










     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f122057%2fhow-do-i-design-intentional-friction-in-an-app%23new-answer', 'question_page');
    }
    );

    Post as a guest
































    6 Answers
    6






    active

    oldest

    votes








    6 Answers
    6






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    38
    down vote













    First, regarding answer that you linked, I think what Apple was having an issue with is the use of the same UI as their slide to power off, not the use of that UX/interaction. They just don't want it to be styled to resemble their power off slider as to not confuse users. If you were to create say, a small blue slider, or a slider that moves in a circle pattern I think you'd be fine.



    However, if you want to play it safe, what about press to hold like this:



    "press to hold"
    Screen recording from MapMyRun app



    In the .gif, a user is pressing the "hold to finish" button, which triggers a roughly 2 seconds "finshing" state where a user can let go and cancel the action, or after two seconds the action, in this case "finshing", triggers. There is a visual progress indicator to show the user that they are performing the action and how long until the action completes. You could also experiment with increasing the time or providing haptic or audible feedback to prevent false presses. This also meets your need of not having to read or click anywhere else.






    share|improve this answer

















    • 9




      A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
      – HammerN'Songs
      Nov 9 at 5:26






    • 9




      I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
      – Henrik Ripa
      Nov 9 at 7:42






    • 4




      It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
      – Toby Speight
      Nov 9 at 11:03






    • 11




      For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
      – Doktor J
      Nov 9 at 16:34






    • 3




      A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
      – JoL
      2 days ago

















    up vote
    38
    down vote













    First, regarding answer that you linked, I think what Apple was having an issue with is the use of the same UI as their slide to power off, not the use of that UX/interaction. They just don't want it to be styled to resemble their power off slider as to not confuse users. If you were to create say, a small blue slider, or a slider that moves in a circle pattern I think you'd be fine.



    However, if you want to play it safe, what about press to hold like this:



    "press to hold"
    Screen recording from MapMyRun app



    In the .gif, a user is pressing the "hold to finish" button, which triggers a roughly 2 seconds "finshing" state where a user can let go and cancel the action, or after two seconds the action, in this case "finshing", triggers. There is a visual progress indicator to show the user that they are performing the action and how long until the action completes. You could also experiment with increasing the time or providing haptic or audible feedback to prevent false presses. This also meets your need of not having to read or click anywhere else.






    share|improve this answer

















    • 9




      A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
      – HammerN'Songs
      Nov 9 at 5:26






    • 9




      I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
      – Henrik Ripa
      Nov 9 at 7:42






    • 4




      It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
      – Toby Speight
      Nov 9 at 11:03






    • 11




      For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
      – Doktor J
      Nov 9 at 16:34






    • 3




      A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
      – JoL
      2 days ago















    up vote
    38
    down vote










    up vote
    38
    down vote









    First, regarding answer that you linked, I think what Apple was having an issue with is the use of the same UI as their slide to power off, not the use of that UX/interaction. They just don't want it to be styled to resemble their power off slider as to not confuse users. If you were to create say, a small blue slider, or a slider that moves in a circle pattern I think you'd be fine.



    However, if you want to play it safe, what about press to hold like this:



    "press to hold"
    Screen recording from MapMyRun app



    In the .gif, a user is pressing the "hold to finish" button, which triggers a roughly 2 seconds "finshing" state where a user can let go and cancel the action, or after two seconds the action, in this case "finshing", triggers. There is a visual progress indicator to show the user that they are performing the action and how long until the action completes. You could also experiment with increasing the time or providing haptic or audible feedback to prevent false presses. This also meets your need of not having to read or click anywhere else.






    share|improve this answer












    First, regarding answer that you linked, I think what Apple was having an issue with is the use of the same UI as their slide to power off, not the use of that UX/interaction. They just don't want it to be styled to resemble their power off slider as to not confuse users. If you were to create say, a small blue slider, or a slider that moves in a circle pattern I think you'd be fine.



    However, if you want to play it safe, what about press to hold like this:



    "press to hold"
    Screen recording from MapMyRun app



    In the .gif, a user is pressing the "hold to finish" button, which triggers a roughly 2 seconds "finshing" state where a user can let go and cancel the action, or after two seconds the action, in this case "finshing", triggers. There is a visual progress indicator to show the user that they are performing the action and how long until the action completes. You could also experiment with increasing the time or providing haptic or audible feedback to prevent false presses. This also meets your need of not having to read or click anywhere else.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 8 at 20:18









    DasBeasto

    12.9k54469




    12.9k54469








    • 9




      A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
      – HammerN'Songs
      Nov 9 at 5:26






    • 9




      I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
      – Henrik Ripa
      Nov 9 at 7:42






    • 4




      It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
      – Toby Speight
      Nov 9 at 11:03






    • 11




      For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
      – Doktor J
      Nov 9 at 16:34






    • 3




      A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
      – JoL
      2 days ago
















    • 9




      A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
      – HammerN'Songs
      Nov 9 at 5:26






    • 9




      I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
      – Henrik Ripa
      Nov 9 at 7:42






    • 4




      It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
      – Toby Speight
      Nov 9 at 11:03






    • 11




      For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
      – Doktor J
      Nov 9 at 16:34






    • 3




      A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
      – JoL
      2 days ago










    9




    9




    A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
    – HammerN'Songs
    Nov 9 at 5:26




    A long hold seems one of the easier things to accidentally do. But +1, and for the OP I'd advise an easy two-stage action, in case a simple slide would have to be uncomfortably small to prevent accidental activation. A multi-stage confirm (swipe two directions, swipe and press, press and swipe, etc) can have more easily accessed input methods (e.g. larger input area), than a single stage action of comparable safety.
    – HammerN'Songs
    Nov 9 at 5:26




    9




    9




    I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
    – Henrik Ripa
    Nov 9 at 7:42




    I worked for a company that made an alarm app many years ago. Our alarm button had to be pressed for exactly 1.7 seconds before the alarm went off. However, the user was told to press it for 2 seconds. Both numbers came from some well researched usability study that the owner had access to.
    – Henrik Ripa
    Nov 9 at 7:42




    4




    4




    It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
    – Toby Speight
    Nov 9 at 11:03




    It might make sense to cancel the action if held for too long, if there's a risk of activation due to "pocket dialling".
    – Toby Speight
    Nov 9 at 11:03




    11




    11




    For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
    – Doktor J
    Nov 9 at 16:34




    For the "cancel" part (to avoid "pocket dialing"), you could make it a two-part counter: 1) "hold for two seconds" with the advancing circle indicator, and 2) "release now (continue holding to cancel)" with a receding circle indicator (~ 1 second). If the touch is not released before the circle completely recedes, the action is canceled.
    – Doktor J
    Nov 9 at 16:34




    3




    3




    A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
    – JoL
    2 days ago






    A slider in a circle pattern seems like a great balance of being quick and easy to do and not trigger accidentally. In contrast, holding a button for a few seconds seems like an easy way to trigger accidentally while it's in my pocket, maybe while I'm grabbing it and pulling it out or when I just put it in my pocket and it ends up touching the button with a key or something.
    – JoL
    2 days ago














    up vote
    26
    down vote













    To send money in my banking app, I must drag a symbol into a target. It is difficult to do accidentally, but quick to accomplish. It may be difficult for someone with limited dexterity or someone who is distracted.



    enter image description here






    share|improve this answer








    New contributor




    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.


















    • +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
      – Konrad Rudolph
      13 hours ago















    up vote
    26
    down vote













    To send money in my banking app, I must drag a symbol into a target. It is difficult to do accidentally, but quick to accomplish. It may be difficult for someone with limited dexterity or someone who is distracted.



    enter image description here






    share|improve this answer








    New contributor




    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.


















    • +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
      – Konrad Rudolph
      13 hours ago













    up vote
    26
    down vote










    up vote
    26
    down vote









    To send money in my banking app, I must drag a symbol into a target. It is difficult to do accidentally, but quick to accomplish. It may be difficult for someone with limited dexterity or someone who is distracted.



    enter image description here






    share|improve this answer








    New contributor




    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    To send money in my banking app, I must drag a symbol into a target. It is difficult to do accidentally, but quick to accomplish. It may be difficult for someone with limited dexterity or someone who is distracted.



    enter image description here







    share|improve this answer








    New contributor




    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    share|improve this answer



    share|improve this answer






    New contributor




    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    answered Nov 9 at 19:03









    jejorda2

    36124




    36124




    New contributor




    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





    New contributor





    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






    jejorda2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.












    • +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
      – Konrad Rudolph
      13 hours ago


















    • +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
      – Konrad Rudolph
      13 hours ago
















    +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
    – Konrad Rudolph
    13 hours ago




    +1, this is probably the most reasonable tradeoff between safety and convenience. However, I need to say that I used to accidentally unlock my phone constantly when I had “slide to unlock” active. It was so bad that I ended up setting up a PIN to unlock the phone solely for this, rather than due to security concerns.
    – Konrad Rudolph
    13 hours ago










    up vote
    21
    down vote













    I haven't thought this through, but there might be mileage in considering the physical equivalent. On many control panels, such as in power plants or aircraft, the especially dangerous actions have a switch cover that must be lifted before the button can be used.



    My suggestion is a control that's normally in a "locked" state, and takes an action to unlock it (perhaps just a press of that control, perhaps a slide). When it's unlocked, it can be used; if it's not used within a reasonable time, or if some other control is used first, the cover "slides back" automatically.



    Although it is functionally equivalent to having a "confirm" button or a popup-menu confirmation, the metaphor is somewhat different, and can be presented in a different visual form.






    share|improve this answer

















    • 9




      I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
      – Sam Weaver
      2 days ago















    up vote
    21
    down vote













    I haven't thought this through, but there might be mileage in considering the physical equivalent. On many control panels, such as in power plants or aircraft, the especially dangerous actions have a switch cover that must be lifted before the button can be used.



    My suggestion is a control that's normally in a "locked" state, and takes an action to unlock it (perhaps just a press of that control, perhaps a slide). When it's unlocked, it can be used; if it's not used within a reasonable time, or if some other control is used first, the cover "slides back" automatically.



    Although it is functionally equivalent to having a "confirm" button or a popup-menu confirmation, the metaphor is somewhat different, and can be presented in a different visual form.






    share|improve this answer

















    • 9




      I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
      – Sam Weaver
      2 days ago













    up vote
    21
    down vote










    up vote
    21
    down vote









    I haven't thought this through, but there might be mileage in considering the physical equivalent. On many control panels, such as in power plants or aircraft, the especially dangerous actions have a switch cover that must be lifted before the button can be used.



    My suggestion is a control that's normally in a "locked" state, and takes an action to unlock it (perhaps just a press of that control, perhaps a slide). When it's unlocked, it can be used; if it's not used within a reasonable time, or if some other control is used first, the cover "slides back" automatically.



    Although it is functionally equivalent to having a "confirm" button or a popup-menu confirmation, the metaphor is somewhat different, and can be presented in a different visual form.






    share|improve this answer












    I haven't thought this through, but there might be mileage in considering the physical equivalent. On many control panels, such as in power plants or aircraft, the especially dangerous actions have a switch cover that must be lifted before the button can be used.



    My suggestion is a control that's normally in a "locked" state, and takes an action to unlock it (perhaps just a press of that control, perhaps a slide). When it's unlocked, it can be used; if it's not used within a reasonable time, or if some other control is used first, the cover "slides back" automatically.



    Although it is functionally equivalent to having a "confirm" button or a popup-menu confirmation, the metaphor is somewhat different, and can be presented in a different visual form.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 9 at 11:09









    Toby Speight

    57718




    57718








    • 9




      I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
      – Sam Weaver
      2 days ago














    • 9




      I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
      – Sam Weaver
      2 days ago








    9




    9




    I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
    – Sam Weaver
    2 days ago




    I like this option, but I think the "slide back" after a period of time is not necessarily the best option... If I were wanting the option to be available in an emergency I'd feel more comfortable leaving it uncovered with my finger over the button and manually covering it again. I'd hate to look away and then try to trigger it but find it had "auto covered."
    – Sam Weaver
    2 days ago










    up vote
    14
    down vote













    Additional ideas from this article:
    https://www.smashingmagazine.com/2018/01/friction-ux-design-tool/




    1. Delaying the action and allow a window time for users to "undo"

    2. Extra step for security, such as asking for fingerprint

    3. Other types of authentication such as re asking password or 2-factor authentication.


    Other articles dealing with the same topic:




    • https://uxdesign.cc/friction-as-a-function-in-user-experience-make-me-think-390ee17c6cf5

    • https://uxplanet.org/when-friction-in-design-is-good-for-ux-e2dd82cfab67






    share|improve this answer

















    • 5




      Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
      – sboesch
      Nov 9 at 13:13















    up vote
    14
    down vote













    Additional ideas from this article:
    https://www.smashingmagazine.com/2018/01/friction-ux-design-tool/




    1. Delaying the action and allow a window time for users to "undo"

    2. Extra step for security, such as asking for fingerprint

    3. Other types of authentication such as re asking password or 2-factor authentication.


    Other articles dealing with the same topic:




    • https://uxdesign.cc/friction-as-a-function-in-user-experience-make-me-think-390ee17c6cf5

    • https://uxplanet.org/when-friction-in-design-is-good-for-ux-e2dd82cfab67






    share|improve this answer

















    • 5




      Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
      – sboesch
      Nov 9 at 13:13













    up vote
    14
    down vote










    up vote
    14
    down vote









    Additional ideas from this article:
    https://www.smashingmagazine.com/2018/01/friction-ux-design-tool/




    1. Delaying the action and allow a window time for users to "undo"

    2. Extra step for security, such as asking for fingerprint

    3. Other types of authentication such as re asking password or 2-factor authentication.


    Other articles dealing with the same topic:




    • https://uxdesign.cc/friction-as-a-function-in-user-experience-make-me-think-390ee17c6cf5

    • https://uxplanet.org/when-friction-in-design-is-good-for-ux-e2dd82cfab67






    share|improve this answer












    Additional ideas from this article:
    https://www.smashingmagazine.com/2018/01/friction-ux-design-tool/




    1. Delaying the action and allow a window time for users to "undo"

    2. Extra step for security, such as asking for fingerprint

    3. Other types of authentication such as re asking password or 2-factor authentication.


    Other articles dealing with the same topic:




    • https://uxdesign.cc/friction-as-a-function-in-user-experience-make-me-think-390ee17c6cf5

    • https://uxplanet.org/when-friction-in-design-is-good-for-ux-e2dd82cfab67







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 8 at 20:10









    Nicolas Hung

    1,139411




    1,139411








    • 5




      Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
      – sboesch
      Nov 9 at 13:13














    • 5




      Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
      – sboesch
      Nov 9 at 13:13








    5




    5




    Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
    – sboesch
    Nov 9 at 13:13




    Delaying the action and allow a window time for users to "undo" - this is by far the best advice here. Instead of adding complicated gestures you are eliminating the consequences of accidental button presses.
    – sboesch
    Nov 9 at 13:13










    up vote
    4
    down vote













    Let's Talk User Flows & Navigation:




    User Flows are a series of steps a user takes to achieve a meaningful goal 1.




    From The Science of Great UI by Mark Miller - Navigation consists of two properties:





    • Path - Set of Steps needed to complete a task


    • Step - Physical and Mental Effort


    And each step has two properties:





    • Length - Amount of Time to complete


    • Width - Amount of Difficulty to complete.


    Difficulty can be broken up into:





    • Mental Difficulty - Remembering information, calculations, decisions


    • Physical Difficulty - Inverse relationship to precision, per Fitts' Law that the smaller the size of an area, the more time it takes to move a mouse cursor to that area.


    So if you want to make navigation easier, you can do the following:





    1. Decrease # of steps - ex. Auto-fill city based on zip


    2. Widen steps (make easier) - ex. Increase button size on common actions


    3. Shorten steps (make take less time) - ex. Google's autocomplete suggestions


    4. Add Alternative Steps - ex. Find account by Email or Phone


    Contrastingly, if you want to make navigation harder, you can do the opposite:





    1. Increase # of Steps - ex. "Are you sure" modal dialog


    2. Narrow Steps (make harder) - ex. Slide to unlock rather than click


    3. Lengthen Steps (make take longer) - ex. Require long (timed) press rather than click


    So all of those tools are within your disposal, and depending on your use case and the severity of performing the wrong action and the difficulty of restoring to the Last Known Good State, you might need any combination.



    If the alarm will trigger a nationwide missile alert, you might want to introduce a lot of difficulty, time, and informative content. If you just want to prevent accidental clicks from pockets, increasing the difficulty is probably sufficient. If users might not be aware of the risks of setting an alarm, the introduced friction should include copy to let them know



    Here's an example from GitHub that I think introduces severity well





    Friction does not have to equal Frustration, so ask your users and get some good telemetry :)






    share|improve this answer

























      up vote
      4
      down vote













      Let's Talk User Flows & Navigation:




      User Flows are a series of steps a user takes to achieve a meaningful goal 1.




      From The Science of Great UI by Mark Miller - Navigation consists of two properties:





      • Path - Set of Steps needed to complete a task


      • Step - Physical and Mental Effort


      And each step has two properties:





      • Length - Amount of Time to complete


      • Width - Amount of Difficulty to complete.


      Difficulty can be broken up into:





      • Mental Difficulty - Remembering information, calculations, decisions


      • Physical Difficulty - Inverse relationship to precision, per Fitts' Law that the smaller the size of an area, the more time it takes to move a mouse cursor to that area.


      So if you want to make navigation easier, you can do the following:





      1. Decrease # of steps - ex. Auto-fill city based on zip


      2. Widen steps (make easier) - ex. Increase button size on common actions


      3. Shorten steps (make take less time) - ex. Google's autocomplete suggestions


      4. Add Alternative Steps - ex. Find account by Email or Phone


      Contrastingly, if you want to make navigation harder, you can do the opposite:





      1. Increase # of Steps - ex. "Are you sure" modal dialog


      2. Narrow Steps (make harder) - ex. Slide to unlock rather than click


      3. Lengthen Steps (make take longer) - ex. Require long (timed) press rather than click


      So all of those tools are within your disposal, and depending on your use case and the severity of performing the wrong action and the difficulty of restoring to the Last Known Good State, you might need any combination.



      If the alarm will trigger a nationwide missile alert, you might want to introduce a lot of difficulty, time, and informative content. If you just want to prevent accidental clicks from pockets, increasing the difficulty is probably sufficient. If users might not be aware of the risks of setting an alarm, the introduced friction should include copy to let them know



      Here's an example from GitHub that I think introduces severity well





      Friction does not have to equal Frustration, so ask your users and get some good telemetry :)






      share|improve this answer























        up vote
        4
        down vote










        up vote
        4
        down vote









        Let's Talk User Flows & Navigation:




        User Flows are a series of steps a user takes to achieve a meaningful goal 1.




        From The Science of Great UI by Mark Miller - Navigation consists of two properties:





        • Path - Set of Steps needed to complete a task


        • Step - Physical and Mental Effort


        And each step has two properties:





        • Length - Amount of Time to complete


        • Width - Amount of Difficulty to complete.


        Difficulty can be broken up into:





        • Mental Difficulty - Remembering information, calculations, decisions


        • Physical Difficulty - Inverse relationship to precision, per Fitts' Law that the smaller the size of an area, the more time it takes to move a mouse cursor to that area.


        So if you want to make navigation easier, you can do the following:





        1. Decrease # of steps - ex. Auto-fill city based on zip


        2. Widen steps (make easier) - ex. Increase button size on common actions


        3. Shorten steps (make take less time) - ex. Google's autocomplete suggestions


        4. Add Alternative Steps - ex. Find account by Email or Phone


        Contrastingly, if you want to make navigation harder, you can do the opposite:





        1. Increase # of Steps - ex. "Are you sure" modal dialog


        2. Narrow Steps (make harder) - ex. Slide to unlock rather than click


        3. Lengthen Steps (make take longer) - ex. Require long (timed) press rather than click


        So all of those tools are within your disposal, and depending on your use case and the severity of performing the wrong action and the difficulty of restoring to the Last Known Good State, you might need any combination.



        If the alarm will trigger a nationwide missile alert, you might want to introduce a lot of difficulty, time, and informative content. If you just want to prevent accidental clicks from pockets, increasing the difficulty is probably sufficient. If users might not be aware of the risks of setting an alarm, the introduced friction should include copy to let them know



        Here's an example from GitHub that I think introduces severity well





        Friction does not have to equal Frustration, so ask your users and get some good telemetry :)






        share|improve this answer












        Let's Talk User Flows & Navigation:




        User Flows are a series of steps a user takes to achieve a meaningful goal 1.




        From The Science of Great UI by Mark Miller - Navigation consists of two properties:





        • Path - Set of Steps needed to complete a task


        • Step - Physical and Mental Effort


        And each step has two properties:





        • Length - Amount of Time to complete


        • Width - Amount of Difficulty to complete.


        Difficulty can be broken up into:





        • Mental Difficulty - Remembering information, calculations, decisions


        • Physical Difficulty - Inverse relationship to precision, per Fitts' Law that the smaller the size of an area, the more time it takes to move a mouse cursor to that area.


        So if you want to make navigation easier, you can do the following:





        1. Decrease # of steps - ex. Auto-fill city based on zip


        2. Widen steps (make easier) - ex. Increase button size on common actions


        3. Shorten steps (make take less time) - ex. Google's autocomplete suggestions


        4. Add Alternative Steps - ex. Find account by Email or Phone


        Contrastingly, if you want to make navigation harder, you can do the opposite:





        1. Increase # of Steps - ex. "Are you sure" modal dialog


        2. Narrow Steps (make harder) - ex. Slide to unlock rather than click


        3. Lengthen Steps (make take longer) - ex. Require long (timed) press rather than click


        So all of those tools are within your disposal, and depending on your use case and the severity of performing the wrong action and the difficulty of restoring to the Last Known Good State, you might need any combination.



        If the alarm will trigger a nationwide missile alert, you might want to introduce a lot of difficulty, time, and informative content. If you just want to prevent accidental clicks from pockets, increasing the difficulty is probably sufficient. If users might not be aware of the risks of setting an alarm, the introduced friction should include copy to let them know



        Here's an example from GitHub that I think introduces severity well





        Friction does not have to equal Frustration, so ask your users and get some good telemetry :)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 days ago









        KyleMit

        439311




        439311






















            up vote
            0
            down vote













            I'm a fan of GitHub's approach where you have to type in a repository's name as confirmation when deleting a repository.



            enter image description here



            Your user could be asked to type in something like "911", which is very difficult to accidentally do. The string could be adjusted for locale and desired difficulty.






            share|improve this answer










            New contributor




            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.














            • 1




              The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
              – kasperd
              9 hours ago










            • The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
              – Dave
              6 hours ago















            up vote
            0
            down vote













            I'm a fan of GitHub's approach where you have to type in a repository's name as confirmation when deleting a repository.



            enter image description here



            Your user could be asked to type in something like "911", which is very difficult to accidentally do. The string could be adjusted for locale and desired difficulty.






            share|improve this answer










            New contributor




            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.














            • 1




              The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
              – kasperd
              9 hours ago










            • The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
              – Dave
              6 hours ago













            up vote
            0
            down vote










            up vote
            0
            down vote









            I'm a fan of GitHub's approach where you have to type in a repository's name as confirmation when deleting a repository.



            enter image description here



            Your user could be asked to type in something like "911", which is very difficult to accidentally do. The string could be adjusted for locale and desired difficulty.






            share|improve this answer










            New contributor




            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            I'm a fan of GitHub's approach where you have to type in a repository's name as confirmation when deleting a repository.



            enter image description here



            Your user could be asked to type in something like "911", which is very difficult to accidentally do. The string could be adjusted for locale and desired difficulty.







            share|improve this answer










            New contributor




            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            share|improve this answer



            share|improve this answer








            edited 10 hours ago





















            New contributor




            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            answered 10 hours ago









            tom

            1013




            1013




            New contributor




            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





            New contributor





            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.






            tom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.








            • 1




              The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
              – kasperd
              9 hours ago










            • The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
              – Dave
              6 hours ago














            • 1




              The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
              – kasperd
              9 hours ago










            • The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
              – Dave
              6 hours ago








            1




            1




            The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
            – kasperd
            9 hours ago




            The question says a confirmation would be too much friction for the use case, so surely this answer wouldn't fly.
            – kasperd
            9 hours ago












            The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
            – Dave
            6 hours ago




            The purpose of this github confirmation as I understand it is to ensure the user knows which repository they are deleting (since they need to read and type out its name). That's a step above simply knowing that they are deleting a repository. Having a user type in a set phrase doesn't give the same benefit, and adds too much friction when the user does want to perform the action.
            – Dave
            6 hours ago










            enn is a new contributor. Be nice, and check out our Code of Conduct.










             

            draft saved


            draft discarded


















            enn is a new contributor. Be nice, and check out our Code of Conduct.













            enn is a new contributor. Be nice, and check out our Code of Conduct.












            enn is a new contributor. Be nice, and check out our Code of Conduct.















             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f122057%2fhow-do-i-design-intentional-friction-in-an-app%23new-answer', 'question_page');
            }
            );

            Post as a guest




















































































            Popular posts from this blog

            Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

            ComboBox Display Member on multiple fields

            Is it possible to collect Nectar points via Trainline?