How to design intentional friction in app?



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







up vote
27
down vote

favorite
2












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



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



What occurred to me initially as an good idea was to use 'slide to' action button, similar to what was/is used to unlock iPhone screen, but then I run to this topic: https://stackoverflow.com/questions/40500955/creating-a-slide-to-power-off-like-slider-on-ios
basically saying that Apple discourage usage of these kinds of components 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?



Thanks!










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
    yesterday










  • 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
    yesterday
















up vote
27
down vote

favorite
2












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



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



What occurred to me initially as an good idea was to use 'slide to' action button, similar to what was/is used to unlock iPhone screen, but then I run to this topic: https://stackoverflow.com/questions/40500955/creating-a-slide-to-power-off-like-slider-on-ios
basically saying that Apple discourage usage of these kinds of components 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?



Thanks!










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
    yesterday










  • 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
    yesterday












up vote
27
down vote

favorite
2









up vote
27
down vote

favorite
2






2





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



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



What occurred to me initially as an good idea was to use 'slide to' action button, similar to what was/is used to unlock iPhone screen, but then I run to this topic: https://stackoverflow.com/questions/40500955/creating-a-slide-to-power-off-like-slider-on-ios
basically saying that Apple discourage usage of these kinds of components 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?



Thanks!










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 user to unintentionally trigger an alarm (the action of calling for emergency should be easily accessible but at the same time should prevent any accidental initiation).



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



What occurred to me initially as an good idea was to use 'slide to' action button, similar to what was/is used to unlock iPhone screen, but then I run to this topic: https://stackoverflow.com/questions/40500955/creating-a-slide-to-power-off-like-slider-on-ios
basically saying that Apple discourage usage of these kinds of components 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?



Thanks!







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






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 2 days ago









enn

13624




13624




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
    yesterday










  • 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
    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
    yesterday










  • 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
    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
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
yesterday












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
yesterday




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
yesterday










5 Answers
5






active

oldest

votes

















up vote
26
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
















  • 5




    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
    yesterday






  • 4




    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
    yesterday






  • 2




    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
    yesterday






  • 7




    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
    yesterday










  • Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
    – TKK
    yesterday

















up vote
13
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
















  • 1




    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
    7 hours ago

















up vote
9
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
















  • 2




    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
    yesterday

















up vote
7
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.
























    up vote
    0
    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




















      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-to-design-intentional-friction-in-app%23new-answer', 'question_page');

      );

      Post as a guest






























      5 Answers
      5






      active

      oldest

      votes








      5 Answers
      5






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      26
      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
















      • 5




        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
        yesterday






      • 4




        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
        yesterday






      • 2




        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
        yesterday






      • 7




        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
        yesterday










      • Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
        – TKK
        yesterday














      up vote
      26
      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
















      • 5




        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
        yesterday






      • 4




        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
        yesterday






      • 2




        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
        yesterday






      • 7




        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
        yesterday










      • Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
        – TKK
        yesterday












      up vote
      26
      down vote










      up vote
      26
      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 2 days ago









      DasBeasto

      12.8k54469




      12.8k54469







      • 5




        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
        yesterday






      • 4




        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
        yesterday






      • 2




        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
        yesterday






      • 7




        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
        yesterday










      • Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
        – TKK
        yesterday












      • 5




        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
        yesterday






      • 4




        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
        yesterday






      • 2




        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
        yesterday






      • 7




        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
        yesterday










      • Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
        – TKK
        yesterday







      5




      5




      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
      yesterday




      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
      yesterday




      4




      4




      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
      yesterday




      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
      yesterday




      2




      2




      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
      yesterday




      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
      yesterday




      7




      7




      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
      yesterday




      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
      yesterday












      Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
      – TKK
      yesterday




      Or you could do long press - release - long press within a certain interval. You could A-B test different approaches in an entirely unrelated app, with no visible UI, to gather data on accidental activation.
      – TKK
      yesterday












      up vote
      13
      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
















      • 1




        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
        7 hours ago














      up vote
      13
      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
















      • 1




        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
        7 hours ago












      up vote
      13
      down vote










      up vote
      13
      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 yesterday









      Toby Speight

      49718




      49718







      • 1




        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
        7 hours ago












      • 1




        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
        7 hours ago







      1




      1




      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
      7 hours 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
      7 hours ago










      up vote
      9
      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
















      • 2




        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
        yesterday














      up vote
      9
      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
















      • 2




        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
        yesterday












      up vote
      9
      down vote










      up vote
      9
      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 2 days ago









      Nicolas Hung

      1,089410




      1,089410







      • 2




        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
        yesterday












      • 2




        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
        yesterday







      2




      2




      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
      yesterday




      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
      yesterday










      up vote
      7
      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.





















        up vote
        7
        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.



















          up vote
          7
          down vote










          up vote
          7
          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 yesterday









          jejorda2

          1713




          1713




          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.




















              up vote
              0
              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













                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










                  up vote
                  0
                  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 hours ago









                  KyleMit

                  391211




                  391211




















                      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-to-design-intentional-friction-in-app%23new-answer', 'question_page');

                      );

                      Post as a guest














































































                      這個網誌中的熱門文章

                      Barbados

                      How to read a connectionString WITH PROVIDER in .NET Core?

                      Node.js Script on GitHub Pages or Amazon S3