This is a very open ended question, and the usefulness of the answers will vary for every individual. Nevertheless, on a base level, I feel some of the most common pitfalls are:

1. Trying to adopt/scale-down web and desktop designs: In an effort to preserve “branding” and minimize expenses, I often find app designers trying to maintain the appearance of their app on the web or desktop. Not only does this present an unfamiliar UX for the user, but it serves to do more harm than good for the “brand”.

2. Applying cross-platform design language: There’s nothing more annoying to the user than finding an Android app designed to be an exact duplicate of its iOS counterpart (I’m looking at you, Instagram). I imagine every platform user must feel the same way when they see a non-native appearing app. Avoid this at all costs. As Hilton Lipschitz has mentioned, pay attention to the specific interface guidelines of each platform and stay true to them as much as possible.

3. Slowing down the user with fluff: Mobile users generally multitask while using apps and would like the app to solve its purpose as quickly and efficiently as possible. Splashscreens and animations which take too long to complete (Like the Starbucks Android App) are one of the biggest pain points in using a mobile app and will have the user searching for a faster alternative.

4. Not providing feedback to user’s actions: “Did I tap that button?”, “Has the download started?”. Prevent your user from wondering about the consequences of his/her actions. Provide appropriate audio/visual/haptic feedbacks for actions and the resulting mechanisms in the app.

See Questions On Quora

1) Don’t cut functionality. If it’s available on a real computer, make it available on mobile. More and more people are foregoing computers and only using tablets and phones. This is a shockingly common failure:

• YouTube failed this one epically by blocking half their content on mobile.
• Urban Spoon won’t let you put titles on restaurant reviews that come in through mobile.
• Wikipedia’s mobile pages do not include category tags, although at least it’s easy to switch over to the real webpage.
• I’ll list more as I think of them.

2) Mobile should be one (important) part of a platform-inclusive strategy that comprises computers with large monitors, laptops, netbooks, tablets, minitabs and microtabs, phones, “smart” TVs, and unforeseen new devices. The four most important form factor reference points would be:

Full-scale (PCs and Macs)
Mid-size (Tablets, Chrome/Netbooks)
Transitional (Minitabs – 6-8 inch tablets)
Pocket (Phones and microtabs aka “phablets”)

You should have designs for all four of these form factors as they represent distinct use cases with very different capabilities, and be able to transition between them smoothly with “responsive” design. This allows you to accommodate unforeseen form factors that fall in between without having to create a separate design for every single aspect ratio and size.

Nota bene: If you’re pressed for time or budget, focus your energy on the tablet experience. For many, that’s replacing full-scale computers, and in any case it splits the difference between mobile and PC so should be bearable on both.

If you cannot afford to develop separate mobile and computer UX, split the difference and design for tablets. A tablet site should function largely like a full computer site except for (A) suitability to portrait and landscape modes, (B) absence of hover functionality, and (C) distinct button-like delineations on hyperlinks.

3) How to decide whether to do a native app vs. a web app or website. Apps take up space on people’s phones or tablets. They are yet another object to keep track of for the user. This is why Google even built a notebook based on the principle that no applications would be stored locally. Assume you should first build a web app or website UNLESS:

a. The product is dependent upon nuanced UX functions best standardized to one device. E.g. anything with gyro or motion sensing.

b. The product uses a lot of routine, predictable CPU cycles that aren’t dependent upon outside data, cycles that are best processed locally rather than sent through your cellular service. E.g. a graphically intense video game without multiplayer or a calculator.

c. The product is likely to be used in an area without cellular or wireless internet or where the absence of said would be disastrous. E.g. a guide to edible plants, a flashlight app,

d. A product where speed and instant accessibility are paramount. E.g. a camera or sound recording app.

As for offering a native version of existing web functions, use the rule of thumb that unless a plurality of users are likely to put it on their phone’s home screen, it’s not worth the cost.

4) Otherwise, web first, app second. I can’t tell you how many clowns there are out there who make an iOS only app that is perfectly well suited to a website (see above) when they should have made a regular old website. It completely cuts out Windows, Mac, Android, and Blackberry users. An app that should be a website is a hipster conceit.

Take a look at Instagram. You cannot view your stream on a computer. It’s absolutely ridiculous. Aside from the problem of lack of accessibility, a user may wish to edit their photos on a computer with its superior UI instead of their finnicky phone.

5) No small or tightly spaced controls. Ever.

6) Make it work in landscape mode. Some people use phones with a built-in keyboard which automatically switches to landscape mode when the keyboard is deployed. Minitabs and microtabs, due to their size, may see users preferring mobile sites rather than iPad-optimized sites. For now, just about everyone who uses a mini/microtab is going to use it in portrait mode however if they make a keyboard expansion for Kindle Fire, that may change.

My GMail app does something astonishingly stupid in landscape mode: it increases the size of the font. This means only two lines of text are visible. Clearly someone did not put any thought into this.

7) On a mobile website, link to the full site at the TOP not bottom. Do not hide it, whatever you do. Conversely do the same on the regular site linking to mobile.

8) Bulletproof code. Yeah, I know. This isn’t a UI thing, but code quality obviously affects the UX. Mobile devices are already inherently more annoying to use than a real computer. The slightest inconvenience caused by a defect could infuriate the user. Oftentimes, a mobile app will be used under more stressful situations than a computer program which is likely to be used by someone at home or at least somewhere they can set up a laptop.

9) Test your app out in the worst circumstances. Fingers numb from the cold or from having sat on your hand, dazed having just been woken up out of stage 4 sleep by an alarm clock, driving down in heavy traffic (technically I can’t recommend that but let’s be real here), while intoxicated or stoned, or under heavy stress of any sort.

I know there are others but those are huge.

See Questions On Quora