Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

It is the last general principle of the “decalogue”. Probably the least important because it’s preferable that a system is so easy to use that no further help is needed to supplement the user interface itself. But this goal cannot always be met. Some users will want to become “experts” rather than casual users, and some intermediate users need reminding to perform their objectives.

It’s important to highlight that:

• help is not a replacement for a bad design, the presence of help and documentation doesn’t reduce the usability requirements,
• a help system must be well designed as well.

There are various types of help systems you can provide, but it is always better to use minimal instructions. Nobody read the manual. The help will only be used when the user are in some kind of difficulty, in need of immediate help.

What should not be done (especially in a mobile app)

• A single very long file that lumps everything together. Users will lose focus by scrolling up and down (especially on a mobile device).
• Don’t provide too much information. Users who come to help pages are usually already confused, so they aren’t inclined to read long blocks of text.
• As an embedded web page. It is a common temptation. It takes 5 minutes to place a web view that loads a HTML file. And it also allows to provide a fast text formatting.

I know something about it, here’s how the help section on FreakyAlarm looked like:

The correct way

• Task-oriented help. A minimal manual focused on real tasks to get started doing real work.
• Gather the right questions and write clear topics that answer users’ questions.
• Good scanning aids (such as bolding keywords) to increase readability.
• Good user experience with native user interfaces, easy to navigate, easy to read.

For example, as in the last update 1.7:

Problem 1
Software is designed and implemented by nerds, so they have an innate tendency to put settings anywhere. And even if they try to fight their nature, they are also often surrounded by nerdy friends and colleagues that encourage them to add more settings.
Close encounters with members of the second category are very rare. Usability testing is often neglected due to its relatively high demand in time and resources, and the user experience is often evaluated by nerdy friends and colleagues.

Problem 2
Software engineers live in a statistically not significant sample set that doesn’t reflect the actual distribution of world population.
Nerdy users: ~0.1%
Users: ~99.9%

Don’t hide features in the settings. People should be able to find all the available features in your app¹. Avoid providing access to features only in toolbars or under separate tabs. Features should be zero configuration out of the box. Avoid enabling features only via configuration options or switches. Features should always be available within two-three taps. Do not be surprised if you receive a feature request to add a new functionality that you’ve already implemented in the settings. People never look in the settings section, they see it as an engine room that says “do not touch”.

Don’t hide features in the settings. Provide “under the hood” options for advanced users, and they all lived happily ever after.

This week I attended the iOS Tech Talk in Rome (at the Marriott Park hotel) and it’s been a very exciting chance to learn from Apple and other developers. Here’s a little report on the talks I attended.

9:00-9:50 AM
iOS 5 Tech Talk Kickoff
Recommendations and key insights for iOS 5 development. Examples from Apple Design Award 2011 winners.

Push for excellence, work hard, be creative, exceed expectations. Change things.
Stay hungry! Don’t settle for the status quo.
Stop holding back, move things forward.

10:00-10:50 AM
iPhone and iPad User Interface Design
About the user experience design and best practices for optimizing the user interface for the unique characteristics of iOS devices.
Software analysis according to Apple:

• Tell a great story
• What app do?
• Who are the users?
• Where they will use it?
• How the app will feel?
• Look beautiful!
• Define style of your app (Entertainment vs. Utility)

Recommendations (in open order):

• Reduce visual noise!
• Pay attention on each element
• Design touch centric apps. Focus on touch experience.
• The answer to life the universe and everything is 44 points (comfortable minimum size).
• Some iPhone tips. Cell title: bold, 17 points. Subtitle: 15 points. Preview text: 14 points. Detail body: 15 points.
• Use non integral rows to indicate additional data.
• Don’t hide functionality.
• Focus on determining what is essential.
• Fun UI. Make fun experience for user.
• Customize Game Center.
• Is it Apple quality?
• Software development process according to Apple: prototype and iterate, prototype and iterate, prototype and iterate…
• When you have bad reviews, people may not coming back. Be polished from the beginning.
• Tell a great story!

11:00-11:50 AM
Adopting iCloud Storage — Part 1
Practical understanding of how iCloud storage works and how to take advantage of it. Key-Value Store and UIDocument working with iCloud to store app’s documents.

11:50-1:00 PM (Lunch)

1:00-1:50 PM
Understanding AV Foundation
Introduction to the AV Foundation framework, its core concepts, controls and flexibility.

2:00-2:50 PM
Modernizing Your App Architecture with UIKit
iOS 5 introduces enhancements in UIKit to customize the visual presentation of views and controls using new Appearance APIs. Great talk about how to architect an app to use View Controller containers. Jake Behrens has been the speaker of the day!

3:00-3:50 PM
Modern Tools and Techniques for iOS App Development
Practical understanding of the latest techniques and best practices to get the most out of Xcode 4.2. Interesting demonstration on how Storyboarding can help get from concept to a running app faster than ever.

4:00-4:50 PM
Maximizing Location Awareness on iOS
Geofencing, Core Location framework, region monitoring and geocoding to create a narrowed location-relevant experience for users. Best practices and testing techniques.

5:00-5:50 PM
Your iOS App Performance Hitlist
Make the app feel fastThe best iOS apps are not only beautiful and well designed, they also launch quickly, present a highly responsive interface, and use memory efficiently. Recommendations on the techniques to diagnose and fix common performance problems and the performance hit-list to apply before an app goes out the door.
“Stay safe, stay low”

6:00-7:00 PM (Wine and cheese)

Impeccable organization, interesting technical talks on the newest innovations in iOS 5, the feeling of being for a day at the WWDC (Worldwide Developers Conference), but especially an incomparable chance to talk, exchange views and discuss with other developers.

• …the difference between ‘good enough’ and better
• …that people are at the centre of technology
• …to think first about what is desirable to users and then to consider what’s possible with technology
• …to focus on what truly matters and to keep it simple
• …we can’t connect the dots forward, only backward
• …the difference between a leader and a follower
• …to believe in ourselves and push our life forward
• …to think that we can change the world
• …that “innovation is not about saying yes to everything, it’s about saying NO to all but the most crucial features”
• …that design is not just “how it looks like and feels like, design is how it works”
• …not to waste our time living someone else’s life
• …the importance of quality and attention to detail
• …that our imagination can become real through passion and determination
• …to “keep looking, don’t settle”
• …that compromise is a choice, not a requirement
• …to see things differently

We’ll miss you.

Since Skynet hasn’t yet become self-aware, since the human race hasn’t yet been exterminated by artificially intelligent machines, since end-users are still largely human beings, the technological progress now stands at a crossroads: reengineering all the software or eugenically engineering the human evolution?

This all stems from the fact that almost all existing software is designed for end-users with these requirements:

• Memory of an elephant
• Dexterity of a monkey
• Visual acuity of an eagle
• Navigation skills of a bat
• Stamina of a camel

So at least in the future, as William Hudson says, does not fall prey to the temptation to believe that users

• are working in a quiet, ordered environment with no interruptions or distractions;
• will remember everything they have ever done on a device;
• are motivated to solve any problems that come up without regard to their mental well-being;
• have no need for breaks, meals or sleep;
• only make mistakes through spitefulness;
• understand the internal workings of the system just as its designers do.

The mythological perfect user is only a product of a bad design, so, once in a while let’s take a break and tell ourselves that the user is not stupid, it’s our design that’s wrong!

Customization gives explicit user control
Simplicity gives explicit features

Customization is based on users preferences
Simplicity is based on users needs

Customization generates complexity
Simplicity always wins over complexity

Customization is a geek
Simplicity is a friend

Customization requires assistance
Simplicity is self-explanatory

Customization affects some demanding users
Simplicity affects all users

Customization is a calculator
Simplicity is a metaphor

Customization is a gear in the black box
Simplicity is an abstraction

Customization is a spaghetti condiment
Simplicity is an elegant suit

Customization can become the bad way to apply Personalization
Simplicity can become the bad way to apply Usability

To avoid any possible misunderstandings, Simplicity and Customization are not in opposition. You need for customization in many cases (user controlled content, customized look & feel for each user, personalized preferences, etc) that don’t involve simplicity issues. An excessive search of Customization could undermine Simplicity and an excessive search of Simplicity could undermine Customization.

Simplicity and Customization are not in opposition, are in a row. First Simplicity, then Customization. What is the purpose of the application? What needs does it meet? Where is the “epicenter”? What are the key features? The way to satisfy the requirements is through Simplicity. Then comes Customization.

Anyway, each of the previous statements doesn’t mean much without a context. It depends on the context and on all its sub-aspects. Will you use your application sitting in front of a desk or on the subway? Business or entertainment software? For specific o generic user profiles? And so on…
Can we draw up a comparative table that takes into account all the cases? No, it’s impossibile, too many cases, it depends on the application.

Let’s consider, for example, an app at random… FreakyAlarm!
The context is that of a mobile app on sale on the iTunes App Store, an one-of-a-kind alarm, a freaky app! A very specific context as much as any other context. In this case…

Customization is used to mean you take explicit control of a task that you don’t want to do (FreakyAlarm is not for people with high self-control, they can use a myriad of other alarms)
Simplicity is used to mean “wake me up” (FreakyAlarm is for sleepyheads, its mission is “you must wake up, don’t try to resist!”)

Customization gives you access to every single statistical information (the number of alarms, minutes taken to wake up, wrong answers)
Simplicity summarizes all the monitored statistics in an unique unit of measurement that’s the iWake coefficient

Customization lets you select the alarm sound and the combination of logical-math games
Simplicity randomly chooses from a collection of FreakySounds and FreakyGames to avoid habit-forming

Customization lets you set the number of games, the type of games, the difficulty of games, the tone of alarms
Simplicity provides a unique configurable option that’s the Priority – Tell me how much of a priority is your alarm and I detect how to wake you up

Customization takes place when you program your alarm as if you were planning to launch a Space Shuttle
Simplicity takes place when you reach the goal promised simply by setting an alarm like in Apple’s official Clock app

Simplicity may oversimplify
Customization help you when the simplification process has made the app unsuitable for your requirements

Simplicity can work only if the abstractions are well calibrated. A ready-out-of-the-box, immediate and target-focused application is more easy to use than an customizable app. But Simplicity is more difficult to achive than Customization.

Simplicity can become a nightmare
Customization can be a palliative
Empathy is the cure

Empathy is the key to achieve the right calibration of the abstractions. It is as though you had some knobs that you could twiddle, and only through Empathy you carefully tuned each knob to its user-focused experience value. Empathy is the “Divine Knob-Twiddler”.
As Matt Gemmell says about Apple secret, “Knowing that creating a user-focused experience needs the right combo of empathy, vision and dictatorship“.

Empathy means identification with and understanding of user’s feelings, thoughts and attitudes. Empathy requires knowledge of your users, you have to learn about users, “scratch your own itch”, be one of the users!

And this would open a larger discussion for which a software engineering course would not be enough. User requirements collection methods (interviews, surveys, wants and needs analysis, group card sort, group task analysis, focus group, field visits) and evaluation techniques (cognitive walkthtough, heuristic evaluation, think aloud, controlled experiment, etc) are just a starting point.