Mobile devices must enter a lock/sleep state to reduce power consumption, prevent accidental input, and sometimes to prevent unauthorized input. You must provide a screen to communicate this state clearly, provide key information, and assist with un-locking methods.

The device OS will provide a default lock screen, but some allow replacing or customization. Many full-screen modes, such as video playback, can circumvent sleep timeouts. Certain applications such as alarm clocks or navigation assistants may also benefit from entering a night mode which provides limited information. You may wish to provide a custom low-power, sleep or lock screen for these experiences.

Two types of Lock Screens, clearly indicating they are locked, showing key information (date, time, system status above the rule, removed for clarity), and indicating how to unlock the device.


When the device is locked or sleeping, a Lock Screen or "Sleep Screen" will be displayed. You should display key information about the device, or the context which provided the lock function, such as events, alerts, time and date, and instructions on how to unlock the device.

Lock screens are useful to prevent input, and power consumption is a real issue, but many lock screens go overboard. Backlight should be minimized or removed, but display drivers left on. In the past, most every device had a retroreflective screen, which could be read in ambient light. These are less common, but almost every screen can be read at least a little by carefully looking.

Additionally, many devices have an excessively high minimum brightness. You can often access the display hardware more directly to provide a "super dim" mode for darker environments, or to reduce consumption without turning off the display entirely.

Pixel-illuminated technologies, such as OLEDs provide other possibilities, now being exercised well on a few devices.


The Lock Screen is displayed immediately after a deliberate (user initiated) lock, or when waking from sleep but not yet unlocked. A similar screen is the Sleep Screen, which often has no display at all. These can, and should, still display some information.

Certain newer technologies, such as OLED, have no backlight. Clever design can illuminate just a few pixels, at low power, and display all relevant Lock Screen information at a very low power level, combining it with a Sleep Screen.

Screens displayed when the device is off but charging, and similar special types of screens, are similar enough to Lock Screens to be considered the same pattern. You should display any useful information available to the device. For example, if date and time are stored at a low enough level to be accessed at this point (and they usually are) then display that information, as well as the battery status message.

A Sleep Screen, set up for an OLED device, with very few pixels illuminated. This presumes the device still differentiates Sleep from Lock, so the moon icon denotes sleep, and makes no mention of how to unlock.

Interaction Details

Locking may occur based on an activity timer, or by deliberate user activation. Both systems are usually enabled. Deliberate user locking should use a hardware Lock key, which may be a short tap of the Power key. You should not rely on menu selections and key combinations to activate sleep or lock states as they are cumbersome and will be unused.

If your device has a very low consumption display, or does not rely on batteries, consider if a lock screen timer is needed at all. eReaders, for example, should generally just stay on the last page, indicating they are locked by adding an icon in the corner, but allowing viewing of the basic content. You should still provide a Lock Screen, for when the user deliberately chooses to hide what is on screen, for example.

Some convertible devices (flip or slide form factor) only operate when open. These form factors will immediately lock when closed.

Unlocking may be accomplished via key input, screen interaction or hardware state change (flip or slide). Most devices will require exiting the Sleep Screen first, and may only unlock once the unlock method is displayed on the Lock Screen. Many devices can use any of several methods, such as key input or sliding the keyboard open.

Unlock key input is usually a key combination (2 must be held down at once for a short time) or key pattern (2-4 keys must be pressed in sequence). These are not codes, but you may replace them with Sign On methods if there is a need for additional security.

On screen unlocking for touch and pen devices uses a simple gesture, such as a drag action, which cannot be easily reproduced by accident. The Lock Screen may be combined with the Sign On patterns to create a Secure Lock Screen. Unless on a high security device, or required by policy, you should make this level of security a user enabled feature, and not required or default.

Locking does not imply exiting or suspending applications. Even activities such as voice calls may continue when the Lock or Sleep Screens have activated. Careful consideration must be made to allow the user to unlock without interrupting the process, and to displaying relevant information about the ongoing activity.

Certain actions may also be allowed to take place without exiting the Lock Screen. An ongoing voice call may be terminated, for example. You may design a widget that allows SMS messages received to be viewed and actually answered from the Lock Screen. These must be designed so they are unlikely to be activated by accident either by context (no ongoing call should be loose in the pocket, so End cannot be pressed by accident) or by requiring unlock-like action precision to initiate (responding to an SMS requires tapping a small "respond" area, within a short time after receipt, and all other actions are disregarded).

Notifications, and other actions may appear on the Lock Screen, or even allow limited interaction. Various methods are available from gestures to small targets and limited time, to allow interaction without sacrificing security.

Presentation Details

On the Lock Screen you will display the time of day, the complete Annunciator Row and any information or gesture targets to instruct or assist the user in unlocking. You should also indicate, usually with a lock icon and with text ("Phone is locked") that it is a Lock Screen. This should also be apparent by the lack of conventional controls like Softkey tabs or menus, and from the lack of the Home & Idle Screens icons or widgets . By default, you should display the backdrop from the center panel of the Home & Idle Screens, but users may customize this to be a different image.

The Sleep Screen should display much the same information, but especially the time. Unlock methods will be suppressed, unless the device can be unlocked directly from the Sleep Screen. Assure the display can be seen and used most efficiently by the display technology available. If relying on retroreflectivity, make sure the items are of maximum contrast, and larger than usual. You should make the clock, for example, as large as will fit on the screen. For OLED screens, use outlines and reduce the maximum pixel brightness. For ePaper, do not display the time at all unless partial screen refresh can be reliably accomplished, without undue power drain.

You may also display additional information about alerts or notifications. The conventional Notifications methods should be used, except insofar as they might interfere with the operation of the Lock Screen, or could not be viewed without access which would be difficult without unlocking the device. For example, a large Pop-Up dialogue on a touch screen might cover the unlock gesture area; a smaller item may need to be developed for the Lock Screen.

Certain system messages may demand special screens. When the battery is dead, for example, the screen displayed should still follow the Lock and Sleep Screen concept. If the clock is available, you should display the time and date as well. Display the Annunicator Row even though everything will be disabled. Replace the unlock instructions with critical battery or charge state information instead.


Mobiles are 24/7, always-on devices for their users. Do not dim the screen and/or cut display by default. Consider the actual power drain, and how else the true needs can be achieved.

Consider all available display devices. If there is an external output for use with TVs or projectors, don't just send the same signal, but something more suitable to the large display. Avoid displaying details of notifications by default (to preserve privacy), do not display the Annunciator Row as that is about the device, not the display, and move the display elements around to prevent burn in.

Do not make the Lock Screen display or interactions, including unlocking itself, too different from the design and interaction paradigms used on the rest of the device. If your device is touch-centric, do not rely on a complex hardware button method to unlock the screen.

Avoid using key combinations to unlock which may disrupt ongoing functions. I have devices which use the End key to control all sleep states. The only way to wake them up is tapping the end key. Which also hangs up an ongoing call. Once the device has gone to sleep, there is no way to mute, switch to speaker or initiate a 3 way call. Avoid these sorts of conflicts at all costs.

Next: Interstitial Screen

Discuss & Add

Please do not change content above this like, as it's a perfect match with the printed book. Everything else you want to add goes down here.


If you want to add examples (and we occasionally do also) add them here.

Make a new section

Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.

Lock Screen (last edited 2013-04-10 23:55:07 by localhost)