Touch interaction is becoming more ubiquitous and often the only option. Should we be designing for touch first or even touch only?
What are the ramifications of taking this approach?

As someone that is always thinking about UX and HCI I found the discussion on alternatives to “hover” on touch-based devices and other similar posts to be very interesting. However, it felt that this was very much trying to shoehorn a cursor analogy into a touch situation and was simply a bad work around.

Should we be avoiding design choices that rely on a cursor driven interaction? For example hover button states and tool tips (feedback information) or 'hover for options' such as hovering over a table row to show edit button, delete button, etc (action items) or even things like drop down menus (should we only change them on click and not hover or both).

Even on this site I notice that once you take hover states out of the equation then a huge amount on functionality/information is removed (try seeing just how much content on this page relies on a hover state).

Would a better approach be a type of 'progressive enhancement' where certain base functionality is presented which is applicable to both touch and cursor and additional functionality is added when a touch device is detected (allowing for pinch to zoom, multi touch points or even multi user) or a cursor is detected (hover states, tooltips, extra precision).

It is important to note that this applies not only to web design but application design, OS design and HCI in general. This is also not a question about 'mobile first' but rather 'touch first'.

So, should we be designing for touch first or even touch only and what are the ramifications of doing so?

  • In general terms 'mobile first' has a lot of validity and given that mobile is mostly touch now, it makes sense to head in that direction.
    – DA01
    Commented Jan 5, 2013 at 3:16
  • 1
    I'd also add in that if Windows 8 is a hint of the road where Microsoft wants to take future editions of Windows, touch will undoubtedly become bigger than having a pointer available. Discussing Win8 is another topic in and of itself, but I can definitely see the traditional desktop moving towards a touch environment. Commented Jan 5, 2013 at 5:21
  • +1 for mentioning windows instead of websites. I am interested in the wider implications of touch first for web, desktop applications and OS.
    – Tims
    Commented Jan 5, 2013 at 11:35

4 Answers 4


I think designing for touch first could be a good general strategy for websites. It seems many designers, myself included, find it easier add features to an existing design than to remove them. So designing an application without assuming a pointer (the touch version), then adding pointer embellishments for the traditional computer version seems like it could be a successful approach (it's new so I'm really only guessing).

It's important to note that designing without a pointer is usually not compromising much. Pointer changes provide some feedback. Minor hover effects (e.g. links changing appearance on hover) are commonly used but we've done fine without them until the early 90s. There's no real substitute for gross hover effects (e.g. hover drop down menus) but these have dubious usability.

But touch only designs shouldn't end up on traditional pointer UIs, the relatively small effort in adding the pointer reactions is worth while.

  • You raise some good points. I like your thoughts on starting from a touch base and adding embellishments. Very much 'progressive enhancement'. Does this mean that we should be avoiding certain types of interaction for non-touch devices? For example the hover instructions for upvote, downvote and accept on this page. I also agree about no substitute for gross hover effects. Does this mean we should avoid them completely?
    – Tims
    Commented Jan 5, 2013 at 11:29
  • +1 for touch first, and adding in desktop functionality! I think anything that can be done with a hover, can be done with a button. The biggest problem is, such buttons (like tooltips for help) must be relatively small to not interfere with the design (think of the small question marks here on StackExchange). Small buttons/links are often hard to click on a mobile phone, especially if they are close to other buttons.
    – Sardtok
    Commented Jan 5, 2013 at 13:29

Should you design for touch first? You should pick the one with the most audience, AKA the main version. For example, for a site like stackoverflow, it doesn't make sense to have the mobile web version to be the main version since most people are using computers to access the site.

Should you design for touch only? That's not a designer's decision. If your company is going to develop an app as well as a site, who are you to say they should only develop an app? But if you are the boss, then you should think about "would people use my app through a computer?"

  • 1
    Upvote for saying audience is important. However, just because it's a majority audience doesn't mean that minority audiences shouldn't be not thought of. Commented Jan 5, 2013 at 5:19

I design from the most simple and general up to the most powerful and specific.

I take a step back from designing first for mobile or touch, beginning with a design which looks acceptable on the lynx text browser. That's not to be a command line snob, but rather to ensure that the content is laid out optimally for web crawlers, mesh application designers, and individuals with disabilities or special needs.

After having designed that solid base, ensuring that everything is well-structured and semantically coherent, I try to design for the necessary interfaces more-or-less in parallel. That keeps my mind set on ensuring that whatever I'm doing for the traditional browser version isn't going to make it unusable on the mobile edition or look awful on a widescreen.

It can seem like a bit of a bother, and it is. But I think the grief of trying to get our presentations to work on a variety of platforms and in a variety of contexts is going to be suffered at some stage in the design process.


You should design not for the device, but for the task to be accomplished. Remember, everything you do should be to help the user accomplish a task. If designing for touch does that, then do it. Above all else, focus on what the user will be doing.

Given that there is a huge range to what we design, it's hard to give advice that is any more specific than that. For example, what you do for a facebook app is considerably different than for an app designed to be used as a control system on a boat, or for software designed to be used by people with weak fine motor skills.

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.