Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm developing an iPhone app that uses pretty standard UI, follows Apple's human-interface guidelines, and in some cases imitates behavior as seen in stock iPhone apps. For example, a table view from which rows can be deleted by either using swipe to delete, or by tapping the edit button in the top right corner. Another example would be a label with underlined text that can be tapped to show a different screen, if a button is just a little too much.

The app hasn't officially launched yet, but some people in management have the app on their devices. These folks don't know much about their phones, though. More than 18 months after introduction of notification center in iOS 5, my boss was surprised when he saw me pull that down. He'd never seen that before. Just recently he asked me how I knew that my phone wasn't connected to WiFi, while the status bar has indicated this since June 27, 2007.

The problem lies in that these same people give me feedback that certain things in my app aren't intuitive. I use the underlined label once, but he and some other people who have access to pre-release versions didn't realize it could be tapped.

The big question is: can I as a developer use commonly used UI elements and paradigms, assuming that the user is familiar with these, or should I point out every tiny detail ("you can tap this button to go here" and "you can select this row to go to screen x or tap the accessory button on that row to go to screen y")?

share|improve this question
1  
Ideally, test it on real users. –  PhillipW Mar 23 '13 at 18:32
    
Very often the computer industry says intuitive instead of familiar. “The only intuitive interface is the nipple.” –  Nicolas Barbulesco Mar 26 '13 at 15:27
add comment

3 Answers 3

You answered yourself in your question: you already have users who have shown you that there are OS behaviors that they haven't yet discovered. This doesn't mean that you shouldn't use the OS's behaviors, standards, and conventions. It simply means that you can't rely on using those as the only way for users to interact with your application.

In your example, it means that you can't rely on Notification Center as an important part of your UX strategy. You know that some users don't know about it. There's also users who dislike it and remove everything from it. You also know that the underlined label isn't necessarily discoverable, so now you need to determine how much of a cause for concern that is. If it's a major part of your workflow, then you should reconsider whether you should rely on that particular method.

You've already done some hallway usability testing of your application; perhaps you should do something more formal to determine whether your application's major workflows are ones that are easily completed by your intended audience. If you gather that data and it turns out that your intended audience is fine, then you'll have some ammunition when one of the managers who couldn't complete the workflow wants you to change things. If you gather that data and it turns out that more people don't know about the conventions that you're relying on, then you'll probably need to reconsider your design.

share|improve this answer
add comment

It's a great question, but I think one without a great answer.

Common UI elements and paradigms

Nobody can answer whether you can rely on common UI elements and paradigms for every situation. I however can tell you that for apps that I have tested, including tutorial screenshots on the first use that simply point to controls and tell people how to use them, have made a measurable difference to how people understand the app. I am inferring that from feedback, reviews, and session information - but I think that is a fair assumption.

What I try to do now, is give as much hint as possible without hurting the usability of the app.

Do people know their device?

My experience has been that more often than I would have thought, users actually don't even know what device they are using. I often ask this and the answer is something like "Samsung" or "iPhone", but when I ask what device specifically the person often doesn't know the answer.

I haven't found an easy way around this yet, but what has helped is that we use a "report a bug" button, which besides the message, will send us logs of the app, including as much information as we can get on the hardware and OS (with user permission of course). This only helps in a limited set of situations, so isn't a solution.

share|improve this answer
add comment

Yes, the swipe to delete and other OS specific interactions for the app are nice features to have. So, by all means, go ahead with them. The iOS HCI guidelines are built for this purpose only.

As for the matter of people not realizing the feature, you can have an introduction setup when the user uses the app for the first time. Just give them a walkthrough of the most useful features of the app. You can leave out the nitty gritty details for a help section or something. Also, keep the intro short. 1 screen intros are the best IMO, but if you cannot do that, try to keep the number of pages around or less than 5. Some examples of walkthroughs: http://www.mobile-patterns.com/walkthroughs

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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