I'm working on a video editor mobile app.

As usual, when prototyping we'll often find a conflict between UI and UX. Although UX has usually higher priority, from time to time I try to find a balance between them.

I was thinking about adding Play/Pause functionality to the video. As far as I see it, I have three options:

  1. Not adding this functionality - let the video constantly loop
  2. Add this functionality as an invisible tap gesture upon the video container. When you tap it'll Play/Pause the video, Showing a "Play" button when paused, show nothing when the video is playing. (Issue here: the user won't be aware the video could be stopped until they press it for the first time.
  3. Adding an actual small Play/Pause button (Issue here: adding new constant UI element, making the UI less clean).

Illustration of 1 and 2:

enter image description here

What do you think? Thank you for your time.

  • According to Facebook and Youtube mobile apps, you should go with option 2. Commented Sep 19, 2017 at 11:49
  • Don't make the user think. Go with Option-2 (with play/pause button).
    – Ades
    Commented Sep 26, 2017 at 7:09

3 Answers 3


Use a button. It's important to let users know what controls are available to them. Tapping a video (without buttons) to play/pause is not universal; I've personally only seen it commonly used among GIFs.

If you're concerned about covering the video itself, you have some options:

  • Fade the button out after a few seconds of inactivity in that area
  • Locate the button with the other video editor controls

Tapping gestures inside the video area are very common, most users will know how to play/pause, simply because they have used YouTube or any other online video player before.

Adding a play/pause button that is visible all the time could clutter the UI and possibly get in the way of the video. Also, user might assume that they need to click the button and not the whole video area.

You could also use on screen controls that appear on click, with an additional click on a, then visible, pause button. You could show those controls for a second or two at the start of the video, so users would known what they are able to do.


When I have a conflict between UX and UI I always turn to NN/Gs UX Heuristics for advice. (as been shown in my past answers)

In this particular case I think these heuristics are more prevalent than ever:

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

In your app consider these questions:

  • How will a user know that they can pause and resume a video without visible controls? Are you sharing that knowledge anywhere else?

  • What is your reasoning behind hiding the play controls? What do you think will be improved by that?

  • In longer videos (1+ minutes long) if the user misses a scene will they have to wait for the whole video to loop all over again?

I do not know the full extend or capabilities of your app. So in context (e.g if users are gonna edit short 15'' videos) it might make sense to just loop the video over and over.

As a rule of thumb "invisible" tap gestures, unless encountered often (e.g scrolling) are not found and used by all (if any) users which kind of negates the point of the gesture's existence.

And in general it's always better to err on the side of caution and allow users to control their content as they see fit.

As always, test with users the 2-3 different versions you have in mind and see which works best. It all depends on the context of the app and the information the users have before hand.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.