Mobile First & Declining Usability

Mobile App Design is Fashion

Mobile app design moves very quickly, and with “mobile-first” thinking becoming the mantra of designers of all kinds, it is a leading indicator for design of just about everything else. So, I think it’s important to take a step back and analyze how apps are designed today. In this I break down the most recent mobile app design trends that I believe are actually hurting us, and making our software worse.

The way mobile app designs is very much a fashion-of-the-week type of situation where the target changes on a nearly daily basis. What was cool a month ago is stale in comparison to today, I use the term “fashion” to generally describe this reality. Before we dig in to the specifics of modern app design, let’s talk a little about fashion itself.

Fashion is irrelevant

I recently found myself reading an essay by Milton Glaser, one of the world’s most celebrated designers. In the essay he talks about “The Bull” by Pablo Picasso. In the work, Picasso renders 11 different variations of a bull each in differing styles. The work ranges from the realistic rendering, to a cartoon rendering, then to a more abstract cubist rendering, and finally simple line art.

Picasso: The Bull

As Glaser puts it, “What is clear just from looking at this single print is that style is irrelevant. In every one of these cases, from extreme abstraction to acute naturalism they are extraordinary regardless of the style.” – Ten things I have learned, Milton Glaser

I thought this line of thinking was very interesting. Glaser makes the point that “Style is not to be trusted”. Or another way to think about that, is that style is fashion, and it comes and goes with the tide. In demonstrating that the style of the work is actually irrelevant to it’s quality, we could draw the conclusion that style in ap design (the aesthetic) is also irrelevant, except for one small problem…

Fashion is of utmost importance

Back in the early days of smartphones the designers at Apple had a clear design goal: Familiarize people with touchscreens. So the style was glossy buttons with shadows, and controls that seem like they want to be touched. If there was a real-world analogue that could be used to symbolically represent a 3D interactive object, they would use it. This is known as skeuomorphism in the design communities, and I won’t rehash why everyone decided they hate it in the past few years here. What I will say however is that there was value in those old ugly interfaces. What we were able to do with skeuomorphism is train users to use our apps with visual language. The best example I can think of from those days is the picker view (called a UIPickerViewController in programmer speak).


Nothing about the design of the picker view makes much sense, really. The only thing it does well is it looks like a spinning wheel, which encourages you to spin it like a contestant on The Price is Right. It’s kind of fun, in fact. But, this interface actually kind of sucks to use. You can only see about 4 or 5 options at any given time, and selecting a specific option requires a fine-tuning sort of interaction where you slowly and carefully align a value with the center of the view. A much simpler approach would be to just put options in a big fullscreen list; which is actually what Apple ended up using more often in their own apps. (Also known as a UITableViewController.)


While these types of interfaces have many drawbacks, I have to wonder if my elderly friends, or my infant nephews would have been able to use smart devices so readily where they not using these metaphors for reality. Would smartphones have become as successful as they are now without skeuomorphism?

It wasn’t just this picker either, skeuomorphism informed the iBooks interface, designed to look like an actual bookshelf:


It inspired the Calendar interface, to look like an actual calendar:


And just for fun: Designer Meng To posted this skeuomorphic version of Facebook that looks like an actual book. on

Facebook by Meng To


Fast-forwarding to 2016, we have completely abandoned the idea that people don’t know what to do with touchscreens. I think we actually have gone too far. Have you ever tried to use Snapchat? It’s like they have made it intentionally confusing to use. Everything is hidden using gestures and invisible buttons you are supposed to know to tap and hold, and weird things like that. Some of the apps most interesting features are completely hidden from view.

There was a lot of positive reactions to the app Clear from a few years ago. It was a huge hit because of it’s unique UI animations. But here’s my question: How many of those downloads translated in to regular users? I don’t want to sit here and hate on the Clear app because I think it was a brilliant design in terms of being unique and fashionable. What it was not however, is usable.


Okay, so I swipe to the right to finish a task… Oops wrong one, how do I undo that? Do I just re-add it? Wait, how do I add a task again? Oh, I take two fingers and separate two existing tasks, and that makes a new one appear in between my existing ones? That’s odd… what if I don’t have two tasks? Do I just sort of “unpinch” the negative space where my tasks would be if I had two?


That’s exactly what you’re supposed to do, and that sucks…

To clear a task swipe to the left, to finish a task swipe to the right. Wait, what’s the difference? I’ve cleared some of my tasks, but deleted others. Either way they get removed from my list…

If you go look at the app store reviews for Clear, you’ll see a lot of people complaining about the same thing, and I can’t even fully explain it to you because I don’t understand it either. But apparently if you perform a swipe gesture up (or down?) it will delete the entire list. How’s that for a fun and wacky gesture! So fun! You just lost your entire task list, which is the entire point of the app! That dismiss animation was sick though, so the app must be great, right?

Clear Reviews

The tutorial for Clear says I should “Pinch together vertically” to collapse my current level and navigate up. So instead of tapping a back button to navigate up, I have to perform a two-handed unpinch gesture for that too? I thought that was the gesture for creating a new task? HOW DO I USE THIS APP I DONT UNDERSTAND!? ARGGGH!!

deletes app…

Fashion sucks

As disappointing as it is, this seems to be the new fashion in apps: I summarize it basically as intentionally terrible user experience. I was talking to a prospect recently about an iOS App we were planning to help them build. They showed me a mockup that involved quite a few hidden buttons and gestures to control the UI. I carefully explained that users were unlikely to find these gestures and that we should move these things in to buttons that are more obvious. As a compromise, we needed at least a quick tutorial to show them these features. The response I received was surprising, to say the least:

We want this to be a secret

If we were designing a video game level this would maybe make some sense. It’s typical to “hide” some areas of play so that it’s rewarding when they are discovered. This is basically what they were going for. But for a mobile app, this is just a poor UI decision that is going to leave people confused. This wasn’t some kind of special easter egg hidden feature. This was basic functionality for switching to a friends list in the app.

You want to hide the friends list from users? This kind of thinking is now fashionable. Whether we like it or not, fashion influences the way we write software. As someone who is going to spend hours of my life building out these features, I hate the idea that most users simply will never find them. That’s why I declined that particular project. I left money on the table, but saved myself from spending time on work I didn’t find meaningful.

It’s our responsibility to fix it

I could sit around critiquing popular app’s designs all day (and I might), but this post wouldn’t be much use to anyone if that was all I did. So, let’s talk solutions…

1. Recognize that you can fix things

First, I think it’s important to accept that application developers have the final say in what their work ends up producing. You may think the decisions are simply made by your client, your boss, your partner, or your dog. Blame who you want, but your apps are the output of your efforts. If you are being boxed in to a corner and being asked to do something that sucks, you should stand up against it. You should learn to say “no” more often. At the end of the day, if you deliver what you think is best to solve the problem at hand, and you do your best work, no-one can complain about that. If they do, then they’re probably not worth working with anyway.

2. Do hallway testing

Hallway testing is the kind of testing you do when you grab some random person “out of the hallway” to test your app. You may have NDAs or similar agreements that make this a challenge, which is why it’s important to make sure agreements like this permit hallway testing. You may not be able to place an ad and have dozens of testers come to your office, but you can at least get family member or friend to try things out.

There are two very important aspects to hallway testing that are required for it to work. The first is that you absolutely can not explain things to the user while testing. It will be your first reaction to want to explain away any rough edges, defend your work, or try to help move things along to avoid embarrassment. This no longer represents a real hallway test though, this represents what it would be like if every user of your app was accompanied by you with your explanation, which obviously is not happening.

The second thing you must do is take notes of any stumbles. If you watch a user struggle with a component of your app for several minutes, and then finally figure it out, you could very easily write it off and say “oh well, they eventually figured that out so it’s not a priority”. WRONG! Your testers will have infinitely more patience than real-world users. If a tester is struggling, you need to make a note of it. Make several notes in fact, you’re going to forget if you don’t, and then those issues won’t be addressed.

3. Don’t hide anything inside of non-obvious gestures

If you are making a feature that involves swiping, pinching, or any other gesture, you should make sure it actually is intuitive to do so. For example, panning on a map (like an Apple Map) is very intuitive… it’s obvious that you would want to scroll the view and it’s obvious how you would go about doing that.

You’ll have to use your judgement on this one, but one way to confirm that your gestures are clear is by doing hallway testing, as mentioned above. You can trust your instinct with this stuff, but you also need to confirm you were right. Often something that seems intuitive to you will not be obvious to your testers.

4. Don’t be clever

There’s a famous quote often cited in software development projects.

Everyone knows that debugging is twice as hard as writing a program in the first place.
So if you’re as clever as you can be when you write it, how will you ever debug it?
“The Elements of Programming Style”, 2nd edition, Chapter 2

The same thing applies to user interface design. If it was a really clever idea, you should always be wary. Often the dead-simple obvious solution is the best one. This is basically just Occam’s Razor restated, which is often quoted for a reason: it’s true.

5. You tell me

What are the other takeaways here? How do you make sure your apps are highly usable? Tell me in the comments or on Twitter.

P.S. As an interesting side note, “The Bull” is also reportedly the subject of Apple’s training materials on their design thinking, for entirely different reasons.

Sign up now and get a set of FREE video tutorials on writing iOS apps coming soon.

Subscribe via RSS

Using open source iPhone app components with Cocoa Pods

For a while after the initial release of the iPhone App Store and it’s SDK, there was not much in terms of open source code to use and learn from. But times have changed, and these days there is a huge database of open source components, and even full projects ripe for use in your next app.

This post is a bit of an instructional guide for those looking to take advantage of open source in their iPhone projects. Whether you are new to iOS, a seasoned developer, or a project manager, you can benefit from this short guide.

Currently, the biggest repository of open source iOS components is CocoaPods. The official list of components, known as “Pods’, is maintained in a Github repository located here:

Unfortunately this list is not particularly easy to browse. To find out the details of any one Pod, you have to select one from the list, pick a version, open the.podspec file, and then pick out the description in the file. Fortunately for you, the handsome reader, you can browse a (possibly slightly out of date) list of these Pods on the site, in a much more easy to digest format.

So how do you use these? If you’ve got a ruby install set up with ruby gems, you can just navigate to your project directory and create a Podfile file, with no extension. It looks like this:

platform :ios, ‘6.0’

pod ‘TestFlightSDK’, ‘>= 1.1’
pod ‘SVProgressHUD’
pod ‘iRate’
pod ‘TimesSquare’, ‘1.0.1’
pod ‘AFNetworking’, ‘1.1.0’
pod ‘iCarousel’

Once you’ve created this Podfile you can run this command in Terminal:

$ pod install

If it gives you some kind of error, you might need to install Cocoa Pods. If that’s the case you first need to run this:

$ gem install cocoapods

And if that doesn’t work, then you still need ruby gems, and maybe even ruby.

Once you generate the pod install, make sure you close your Xcode project if you already have it open, and from now on use the .xcworkspace file when working on your project. What you’ll find is that Cocoa Pods has now created a subproject for your Pods. Yay! This means you can now compile your dependencies separately from the project, and changes to your project shouldn’t call for a full recompile. More importantly, you can easily update your dependencies by just modifying your Podfile, and running ‘pod install’ again.

So to recap:

1. Install ruby

$ \curl -sSL | bash -s stable

2. Install ruby gems if you don’t have ut


3. Install cocoapods

$ gem install cocoapods

4. Create a Podfile in your Xcode project directory

5. Add any relevant pods you might want to use. At this stage I do not specify a version, I let it use the most recent, and then lock it to that version to avoid unwanted updates. I’ll later remove the version specification when I feel it is time to get everything up to date.

6. Run pod install

$ pod install

7. Open your project from the xcworkspace file instead of the xcodeproj file.

8. Enjoy!

Related article: 8 Great Open Source Projects to use in your next iPhone App

Sign up now and get a set of FREE video tutorials on writing iOS apps coming soon.

Subscribe via RSS

The user is a customer. So why doesn’t software treat them like one?

So this may sound obvious. You may be thinking, yes of course the user is a customer. We treat them like customers by providing them with support, pitching to them our value in our sales and marketing materials, and a host of other things. But what about in our software itself?

The fact is, our software tends to be designed as if it were going to be used by a computer interface. When an update is available for example, it may prompt the user with something like this:

“Acme Analytics v2.31 is now available, click here to install.”

Let’s draw a comparison to a real-world business. Let’s consider a gym whose modified it’s membership plan. Ultimately, the situation is similar. A change has taken place that (hopefully) improves the experience for customers. A gym may send out a letter or an email stating what’s new in the facility. For example:

“We’re proud to announce that we are now offering free Yoga classes with your membership. Classes will begin January 1, 2014, and take place every Monday at 8:30am.”

This announcement could be improved by reminding customers of other products, upselling additional services, or just thanking the customer for their continued support. But the important part of the message is that it clearly relays what has changed and demonstrates it’s value. Why would a gym naturally do this? Because it thinks of it’s subscribers as customers, and wants to keep their business. In our software example shown above, we are doing a similar thing, introducing new features. But, we are introducing the new features not as a new valuable service or product addition, but as a technical task that must be performed in order to receive the benefits. What if we instead thought about this in the context of value instead of the technical details? Our update message could be rephrased to sound more like this:

“We’re proud to announce that Acme Analytics now supports multiple users. The update is available immediately and can be installed by clicking here.”


This example communicates the value of our update much more clearly, but more than that it represents a shift in how we are thinking about the user. Instead of thinking of them as users who need to interface with our product, we are thinking of them as customers with whom we need to communicate value.

This is not limited to updates for our apps. Let’s take a look at a few more examples, and how we might modify them to both feel more human, and be sure we are treating our users as customers.

“You have 3 new followers! Click here to log in.”


“Three new people are interested in what you have to say!

Click here to find out who.”

“Download finished. Click here to open.”


“Your video is now ready, click here to watch.”


“Error: File Not Found”


“We couldn’t find the content you were looking for. You could try refreshing the page, or come back later, and see if that works. We apologize for the inconvenience.”


In all of these examples, because we are trying to be helpful to our customer, we deliver a better experience. We can use these opportunities to explain new benefits, apologize for problems (while suggesting solutions), or remind the customer they are appreciated.

If we can remember to treat all messaging in our software as if it were a personal phone call from our companies representative, or a mailer sent out to all customers, I think we gain a huge advantage in the sense of customer service our users perceive.

Related article: 5 things I wish I knew when I released my first iPhone app

Sign up now and get a set of FREE video tutorials on writing iOS apps coming soon.

Subscribe via RSS

4 Steps to Design Marketing into your App

This guest post written by Mike Davis, CEO & Founder of StoryPress

1. Think through the whole sale process before you write any code, in fact it should be a critical component of your UI.  Many people just “know” that it will be an IAP or ads and completely ignore it until the end.  Designing the sale process is as important as anything else and deserves the same level of attention as your apps unique or differentiating feature.

2. Think about social sharing in the UI stage as well.  When people are registering can you ask them to invite their friends?  Maybe show their contacts and/or Facebook friends with 1 click to invite all?  Designing this type of social impact can be critical to your success and not something you want to throw in after the fact.

3. Where will your app be sold?  Is it only inside the app or on the app store?  Many of the leading app brands leverage their website and social media to generate sales.  With tools like AppKeyz now available, you can create a product page on Facebook and a mini-site capable of generating sales to promote on social media, including Facebook and Twitter.  Use these mini-sites to reward social sharing with 2 for 1’s or discounts on your apps.

4. Don’t waste your money on posters and t-shirts at trade shows.  It’s too much clutter and too expensive to stand out from the crowd.  Similarly expensive and extravagant launch parties almost never generate enough buzz or sales to come close to paying for themselves.  A better investment would be a PR person and several way placed interviews or articles.

Related article: Making Apps That Spread

Sign up now and get a set of FREE video tutorials on writing iOS apps coming soon.

Subscribe via RSS

Open sourced startups

When a software startup fails to turn a profit they’re usually left with some newfound knowledge, maybe some debt, and a big chunk of unused code. Why should all that engineering work go to waste just because that particular business failed? Many startups recognize this and have made their software free and open source. I did some searching and came up with a list of startups past whose work may be useful to others. Not all of these are failed startups, in fact a few are quite to the contrary, but they are all useful to study nonetheless.

1. Liftium
There isn’t a ton of documentation in this project but there are quite a few interesting pieces of code working with ad networks and some simple utilities in this code base. From what I could find out this startup was originally planned to be some kind if performance optimization system for ad campaigns.

2. Kill the land line
This startup was designed to allow users to use their existing phone numbers from old land lines that had been in use for years with their cell plans, avoiding the costly $30/mo fee just to keep a phone number so many people knew to contact them through. The software integrates with Tropo in order to do its magic.

3. ExamBuff
This startup is a web service that connects students preparing for exams with PhD’s in their field of study, allowing them to mark up and comment on the students solutions.

4. ComicFlow
As far as I can tell, ComicFlow is the first comic reader that has open sourced it’s app for developers to take advantage of. It relies on a few other open source projects, but is a great source of “code that works” for iPad readers. If you are involved in creating digital stories in any way I recommend checking out the work they have released here.

Come on, you know this! is a great saas that provides some social awareness to our music. What I found most interesting about the source for this iPhone application is their use of Flurry, one of the bigger players in the mobile analytics game. Check them out to see how it’s done.

Sign up now and get a set of FREE video tutorials on writing iOS apps coming soon.

Subscribe via RSS